Mycelium

The Rest

You're Not Designing a Menu

Understanding before building.

You're not designing a menu. You're replacing a phone call.

When given a feature request, most people's instinct is to:

1. Understand the technical requirement 2. Design the UI component 3. Implement it

This is wrong.

Not wrong like "there's a slightly better way." Wrong like: you will build the wrong thing, for the wrong reason, and then spend months fixing problems that shouldn't exist.

You end up with features that technically work but don't serve humans. You miss edge cases, create confusion, and build things that feel disconnected from real use. Not because you're bad at building — because you skipped the only part that actually matters.

The Question Nobody Asks

Before you think about UI. Before you think about pages or views or components. Before you even think about what your system does. Ask:

What exists today?

How is it done now? What process am I replacing? If it's a whole new process that never existed before — that's a completely different thing to think about, and you need to understand why it never existed.

But most of the time, something exists. There's always a before.

A phone call. A spreadsheet. A paper form. A person walking over to another person's desk. A sticky note on a fridge. Something. And that something has been working — imperfectly, probably painfully — but working. People figured it out. They have habits. They have workarounds. They have expectations shaped by years of doing it the old way.

If you don't understand that deeply, you'll build something that solves problems nobody had and creates problems nobody expected.

Rami's Phone

Let me make this concrete.

Say you're building a food delivery app for small restaurant owners. The client says "we need an order management system." The instinct kicks in: order list screen, status toggles, live dashboard, notification system. You start thinking about screens.

Stop.

What exists today? A phone call. A customer calls Rami — he runs a 12-table shawarma place in Haifa — and here's what actually happens in that call:

What the customer needs from Rami:

What Rami needs from the customer:

What Rami does after the call:

That's not a feature list. That's a process. An information exchange between two humans, followed by a physical handoff. Every piece of it exists for a reason.

Now — where does it break?

The customer asks "what do you have?" and Rami recites the menu for the 50th time today. Takes 2-3 minutes. Customer is indecisive. Every single call.

Customer says "no onions" — Rami forgets to write it down. Customer gets onions. Bad experience. Often.

Customer gives address verbally. Rami mishears. Driver goes to the wrong place. Sometimes.

CC number over the phone. Rami reads it back, gets one digit wrong. Charge fails. Has to call back. Sometimes.

Peak hour — line is busy. Customer calls somewhere else. Lost revenue. A lot.

Rami's handwriting is rushed. Kitchen misreads "2x shawarma" as "1x." Sometimes.

Now you understand the process. Now you understand where it hurts. Now you can ask: which part of this process will our system tackle?

Same Information, Different Channel

Here's the thing most people miss: the system doesn't invent new information. It replaces the channel.

The customer still needs to: 1. See what's available → Menu (replaces Rami reciting it) 2. Decide what they want → Item selection + modifications (replaces verbal back-and-forth) 3. Say where they are → Address input (replaces verbal address) 4. Pay → Payment form (replaces CC-over-phone)

Rami still needs to: 1. Receive the order → Notification (replaces picking up the phone) 2. Confirm he can make it → Accept/reject (replaces "yeah we can do that") 3. Hand info to kitchen → Order printout or screen (replaces handwritten paper)

Same information. Same humans. Different pipe. That's it.

When you see it this way, the design almost writes itself. You're not inventing an "order management system." You're digitizing a phone call. Every screen is answering a question that used to be asked out loud.

The Bottleneck You Didn't Mean to Remove

Now here's where it gets dangerous.

The phone call was a bottleneck. Rami could only take one at a time. While he was on the phone, another customer got a busy signal. That was the pain we were solving — make it asynchronous, let multiple people order at once.

But that bottleneck was doing something else too. It was accidental capacity management.

Rami has a physical kitchen. He can prep maybe 10-15 orders per hour. He has 1-2 delivery guys. He bought a specific amount of lamb this morning — when it's gone, it's gone. His real capacity hasn't changed just because we digitized the ordering.

The phone had a built-in throttle. If Rami was slammed, you got a busy signal. Ugly, but it worked. On the phone, Rami could say: "I'm slammed, call back in 20 minutes." Or: "It'll be 45 minutes, is that okay?" Or: "We're out of lamb, want chicken instead?" One sentence that informs, suggests, and retains the sale.

We just removed that throttle. Now 30 people can order simultaneously at 12:15 on a Friday.

Rami is going to drown.

You removed the bottleneck. You also removed the judgment.

Every "edge case" in this system is actually the same question: the phone call had human flexibility. What replaces that flexibility in the system?

"Call back in 20" → needs a busy mode, or dynamic time estimates. "We're out of lamb, want chicken?" → needs stock management with suggestions, not just a greyed-out button. "It'll be 45 minutes, okay?" → needs dynamic estimates based on queue depth. Busy signal as throttle → needs intentional order capacity limits.

The danger isn't that the system fails. The danger is that the system succeeds too well and overwhelms the physical operation it's supposed to serve.

The Order of Thinking

So here's the process. Not as a methodology poster on a wall — as how you actually think through a problem:

First: What exists today? Map the current process. Don't think about your system yet. Just understand reality.

Then: Break the information exchange down to the smallest units. Who needs what from whom? What's the checklist?

Then: Where's the bottleneck? What's painful, slow, error-prone? That's where your solution shines.

Then: What does the current process do well that you might accidentally destroy? What human flexibility exists that your system needs to replace, not just remove?

Then: Extract entities. Customer, order, items, stock, driver. How do they interact? How often? What are the constraints? What's consumed, and who refills it?

Then: Define views — not pages. A view is a lens on data: what does this person need to see right now, given the current state of these entities? The same view might become a page, a modal, a notification. That's decided later.

Then: Map journeys between views. Start broad: sees menu → builds order → sees status. Confirm. Zoom in: sees available items → chooses item → sees options → adds to cart. Confirm again. Keep zooming until you hit states — the atomic level where component specs emerge naturally.

Each layer earns the next. You don't get to think about views until you know your entities. You don't get to think about journeys until you know your views. And you don't get to think about screens until you've done all of the above.

THEN design. THEN build.

Try This

Pick any product you use daily.

Now answer these:

1. What process did this product replace? There was always something before — even if it was pen and paper, or a phone call, or nothing at all.

2. Break down the old process to its smallest steps. What information moved between people? Who gave what to whom?

3. What was the bottleneck in the old process?

4. Now: did the product remove that bottleneck? If yes — what human judgment or flexibility was also removed?

5. What can the old process do that the new product can't?

Every product replaces something. If you don't understand what you replaced, you don't understand what you built.

Think. Plan. Consider edge cases. Consider human emotions. Consider human behavior. Consider the experience. The intent. The previous knowledge and expectations.

Then — and only then — open your design tool.