I took this on because I wanted to bring order to the chaos. That is the work I keep coming back to. Take something tangled and hand it back simple enough to act on.
A cloud kitchen is delivery only. No dine-in, no counter. Here, one kitchen cooks for three brands at once, biryani, healthy bowls, and burgers, out of one set of stations with one team. Orders arrive from Swiggy, Zomato, and the kitchen's own app. During lunch and dinner, 60 to 80 land together.
One person stands at the pass and runs all of it. His name is Rajeev, and he is the order manager.
What pulled me in early was realizing I would not be designing a dashboard. I would be designing the system underneath it, the logic that decides what gets cooked when, what gets grouped with what, and what pulls Rajeev's attention. The dashboard is only the part you can see.
I got to be honest about where I started. I had never used AI for product design before this. I was carrying two doubts. One, whether directing a tool instead of doing the work by hand would give me something I could stand behind. Two, whether what I designed would hold in a real kitchen or stay a pretty concept. Both moved by the end.
The problem
It was never a speed problem
Rajeev runs the rush today with three tablets, one per delivery app, a stack of paper chits, and his voice. Orders get cooked roughly in the order they arrive. One station gets buried while another sits idle. Food goes cold at the counter because nobody called the rider in time, and riders wait at the door for orders that were never started.
When I first read the problem statement I thought the job was productivity. Help him do more in less time. I carried that assumption for a while.
Then I built the journey map of his current workflow, step by step, what he does and what he needs to know at each point. Laying it out that way showed me something the brief had not. Every decision he makes needs information scattered across three tablets, a pile of chits, and whichever cook he can get the attention of. Before he can decide anything, he has to go and assemble the picture. Then hold it in his head long enough to act.
That was the pivot. He is not slow and he is not unskilled. He knows every cook's pace and every station's limit. His problem was never that he could not decide. It was that he could not see the board fast enough to decide well.
Mapping the current flow is where the problem changed shape. Every decision required assembling a picture from three tablets, paper chits, and verbal updates.
So the problem became: give him one screen carrying everything he needs across all orders, all stations, all brands, and all three apps, so his experience drives the call and his memory does not have to.
The solution
One order, landing to handover
I designed the happy path first, then built outward into the situations most likely to break it.
01
An order lands and enters the feed on its own, tagged with its brand and the app it came from. Nobody goes looking for it.
02
The system reads its items, works out the cook time and the promised time, and puts both on the card before Rajeev has looked at it.
03
Items reach their stations already routed, already sequenced, already batched with matching items from other orders. Station load sits alongside, there to be watched.
04
Once cooked, the order starts counting how long it has been waiting, so it pulls attention before the food goes cold.
05
The packer sees which brand's packaging it needs. The order goes out and clears the board.
A rush rarely stays that clean. Here is the same system when an order starts slipping.
The board at a normal moment. Every order across all three apps in one place, sequenced by promised time, stations reading their own load.
A new order lands and takes its position in the queue on its own, promised time already calculated, items already routed.
An order is projected to miss its promised time. The alert states the problem and proposes a fix. Rajeev takes Handle Manually.
He moves the item up the station queue himself. The system re-sequences everything behind it and updates the projected finish.
The order is back inside its promise and the board returns to a clean state. The whole exchange took one decision.
1 / 5
Decision 01
What stays on screen, and what hides
I was sceptical about putting everything on screen from the beginning. There was no single moment where it hit me. I could picture 60 to 80 orders at full detail and I knew what that would feel like to stand in front of. It would be the same overwhelm Rajeev already has, rearranged into a nicer layout.
Clear goal, hard execution. Deciding what counts as essential is easy to get wrong by taste. I could have picked what looked important, or what balanced the screen, and both would have been guesses.
What I chose
The collapsed state of an order card carries exactly the information Rajeev needs for the decisions he actually makes, and nothing else.
That gave me a method instead of an opinion. I went back to the happy flow journey map, walked it decision by decision, and for each one asked what information it required. Those answers became the collapsed state. Everything else became the expanded state.
Here is what I did not know starting out. Putting everything on the screen and giving Rajeev visibility are not the same thing. One is a data dump. The other is a set of choices about what he is allowed to ignore.
Show every order fully expanded, always rebuilds the overwhelm
Minimal dashboard, everything one click away back to hunting and remembering
The part I value most is that the answer came out of the journey map rather than my preferences. When someone asks why a particular number is on that card, I can trace it to a decision Rajeev makes.
Left, collapsed. Right, expanded. The collapsed fields were chosen by walking the journey map decision by decision.
Decision 02
Why cook time alone was the wrong answer
Same journey map, different thread. Mapping the current process surfaced something I had not expected. Some orders were finishing early and then sitting there. The food was ready before the rider was anywhere near the kitchen.
The cause was first in, first out. Whatever arrived first got cooked first, regardless of when it needed to be ready. An order with a rider twenty minutes away could get cooked immediately while an order with a rider at the door waited its turn.
Cold food is a failure. Not a smaller one than a late order, and it is the one nobody tracks, because the ticket still says the order went out on time.
The two rules the system runs on
Rule 01 · Cook time
An order's cook time equals the cook time of its single longest item. A biryani at 18 minutes sets the clock for the whole order even if the burger beside it takes 10, because the order leaves as one bag.
Rule 02 · Promised time
An order's promised time is the larger of its cook time and the rider's arrival ETA. If food takes 18 minutes and the rider arrives in 22, the promise is 22.
order #2847 · Zomato
items Chicken Biryani 18:00 · Veg Burger 10:00
cook time 18:00 (longest item)
rider eta 22:00
promised22:00(the larger of the two)
Putting rider arrival inside the promise is what stops the system rushing food out into an empty counter.
Why the system does this and not Rajeev
That was a planned effect, not a fallback. A machine is better at calculating an ETA, slotting an order by that ETA, and scanning a live queue for batch matches across three brands. Rajeev is better at judgment calls under pressure. Handing the arithmetic to the system is what frees his attention for the decisions that need him, and those are the decisions he never had time for before.
A faster manual routing board keeps the routing work on him
Suggestions he confirms one at a time eighty confirmations a rush
Automate the routine, reserve the human for exceptions chosen
This is the part of product design I love. A messy operational scenario resolves into a rule you can state in two lines, and once you have the rule the whole system falls in behind it.
Decision 03
A question I could not answer
I asked Claude to role-play as Rajeev and argue against my design. The strongest thing it came back with was a question about the alert.
What happens when more than one breach is happening at the same time? Does the alert show all of them, or does it prioritize on its own?
I did not have an answer. Sitting with it, I saw why it bothered me. I had spent my attention on the flow that goes right and treated the alert as a notification, a thing that tells you something. But the value of this dashboard is tested at exactly the moment things break. That is where Rajeev needs it most and where I had thought least.
It also explained a doubt I had been carrying. I already had an alert designed, and I had never been confident in it. I had been working on how it should look before settling what it needs to do, which left me nothing to judge it against.
Where I had got to before the role-play. It announced a problem and left Rajeev to work out what to do about it, which is fine for one breach and useless for four.
What an alert has to do
Three things, not one. State clearly what is going wrong. Propose what to do about it. Let Rajeev act on that proposal in a single click.
That reframing answered the role-play question too. Once an alert carries a proposed action, it cannot dump five simultaneous breaches on screen and leave Rajeev to sort them. He would be triaging among things that are all already urgent. So breaches are ranked, and the most urgent surfaces first.
How much control the system gets
I want to be precise here, because this is easy to describe as a trust problem and it was not one for me. I never framed it as whether the system or Rajeev is better at handling a breach. I framed it as Rajeev having the option to use the system's help when he judges that it fits.
So the rider-delay flow gives him two clean paths. Confirm Re-sequence, and the system executes its proposal. Handle Manually, and the modal closes while the order card keeps a flag for him to deal with on his own terms. The proposal has to be readable in a couple of seconds, because that is all a rush allows.
The same alert after the question. It states the problem, proposes a fix with a projected finish, and gives Rajeev one move either way. This is the change I am gladdest I made, and I would not have made it on my own.
Beyond the happy path
The situations I designed for
I wanted this to behave like a real product rather than a demo, which meant sitting down and imagining what a kitchen actually throws at you. Those situations produced the rest of the flows.
A full rush, build-up to wind-down
The tool has to hold at 80 live orders, not at two. This is why the vital signs stay visible and why the stress state exists.
One order, New to Handed to Rider
At every state the right people know what is true without Rajeev relaying it by voice.
A rider runs late
Promised time recalculates, the queue re-sorts, and Rajeev stays in the loop without losing his rhythm.
Several orders can be batched
Catching a match across three brands by hand at a rush is close to impossible, so the system finds it.
Craft
The look I was after, and how long it took to get it
I knew what I wanted before I could get any tool to produce it. Easy on the eyes. Light theme. Generous spacing so the screen stays readable when someone is scanning it at speed in a hot kitchen. I did not want components that read as boxes.
The first pass Claude Design produced was not it. Generic and templated, hard outlines, dusty colours. It looked like a dashboard rather than my dashboard. I moved to Figma Make and got more or less the same.
Then I tried Google Stitch, and I also changed my own input. I had been feeding in multiple reference images, so I cut it down to one. What came back was much closer. Not exactly my vision, which I expected, but close enough to be useful. So I stopped treating it as an output and started treating it as a reference, and handed it to Claude as the visual direction to follow. That time it understood.
The lesson there is about my input, not the tools. Four reference images gave the tool four directions to average. One gave it a direction to follow.
The system as it exists in the build, pulled straight from the stylesheet rather than redrawn. The two identical green swatches are the collision described above.
Restraint is doing the work
Light panels on a soft grey page. One accent in green, used sparingly. A small set of status colours that each carry a fixed meaning: amber at risk, red breached, green on time. Inter for the interface, JetBrains Mono for numbers so timers and counts read instantly.
On a screen carrying 80 live orders, colour has to mean something. Spent on decoration, it stops being able to mean anything. Order cards, status chips, and station tiles behave identically everywhere, because at this density consistency is what lets Rajeev read the board by pattern rather than reading every element fresh.
Pulling the tokens out of my own build to write this section caught a mistake. The accent and the on-time status resolve to the same value, #00A36C. Green cannot tell Rajeev an order is on time while it is also just the colour of the interface, which breaks the exact rule the rest of the system runs on. It is a small bug with a real cost, and it is first on the list for the next build.
Building it without writing code
I directed AI tools to build while holding every design decision myself. I read my own Figma wireframe structure through the Figma MCP so the build came from the actual layout rather than my description of it, which caught real errors early.
The experience was empowering, and I mean that plainly. In brainstorming it helped me build out Rajeev as someone to think against. In ideation it helped me sharpen my own ideas, which made that phase lighter rather than just faster. In execution it took my inputs and produced a full dashboard in minutes. The first version had plenty of flaws. It was still close to magic to watch a thing I had only described start existing.
AI builds to the ceiling of your vision and no higher
I arrived at this by getting it wrong first. I went in half expecting the tools to improve on what I gave them. They do not. A well thought out, properly researched vision converts into something meaningful. A vague one converts into a polished version of the same vagueness. Every good thing in this build traces back to thinking I did before I opened a tool.
I was wrong about what using AI would do to my work
I started sceptical and slightly defensive. I had a notion that directing a tool instead of building with my own hands would produce something that was not really design and not really mine. That belief did not survive the process. I had full creative control throughout and never felt restricted in making a change I wanted. What it required was learning how the tool interprets what I say, then adjusting how I say it. That is a skill, and it is the one I got better at.
Letting something argue with me beat reviewing my own work
Putting the persona in the opposite chair surfaced the weakest point in the whole thing, and it did it before I was attached to my answer. I would run that step earlier next time.
Design the behaviour before the appearance
I was stuck on how the alert should look for longer than I should have been. The moment I worked out what an alert is supposed to do, the appearance question mostly answered itself.
What's next
The gap that nags at me
Everything in this tool is built on scenarios I constructed. The persona, the rush, the breach, the late rider. I think the reasoning is sound. I also know that is not the same as being right.
So I do not think of this as version one. I think of it as a draft that has not met a real user yet. What I want next is to put it in front of an actual order manager during an actual rush and find out how close I landed, then close the gap in the next iteration. I expect to find things I got wrong, and I would rather find them than not.
The build has other places to go. Connecting to live data so the logic runs on real orders. Handling the edge cases a clean demo never throws: cancelled orders mid-cook, item shortages, a station going down. Scaling past one order manager or one kitchen is a real question too, and one I deliberately left alone, because the single-screen model is correct for the problem I was given.
