Console Redesign

Circus inherited a robot console built by engineers, for engineers. Operators had to call an engineer to do routine tasks. I rebuilt it around their shift: fewer pages, statuses they can read at a glance, and only the actions that make sense right now. Two weeks after launch, key tasks were 15% faster.

Company

Circus Group

Company

Circus Group

Role

Lead Product Designer

Role

Lead Product Designer

Service

Led end-to-end design

Service

Led end-to-end design

Duration

5 weeks

Duration

5 weeks

Also on Medium

A longer, more detailed read ↗

The tool

The tool

In 2023 Circus acquired Aitme, a Berlin startup building cooking robots. With the robots came the Console: the web app used to switch units on and off, refill silos, run cleaning and check stock.

By 2025 we were preparing to sell the robots to other companies, and the people using the Console would be hub operators, not the engineers who built it. The tool still looked and worked like Aitme’s internal software.

The brief was a rebrand. With the brand and product teams, we used it as a chance to rethink the whole tool: if we were going to touch every screen anyway, they should fit the job operators actually do.

News of the Aitme acquisition and the old Aitme Console on a laptop

In 2023 Circus acquired Aitme, a Berlin startup building cooking robots. With the robots came the Console: the web app used to switch units on and off, refill silos, run cleaning and check stock.

By 2025 we were preparing to sell the robots to other companies, and the people using the Console would be hub operators, not the engineers who built it. The tool still looked and worked like Aitme’s internal software.

The brief was a rebrand. With the brand and product teams, we used it as a chance to rethink the whole tool: if we were going to touch every screen anyway, they should fit the job operators actually do.

News of the Aitme acquisition and the old Aitme Console on a laptop

What was wrong

What was wrong

I started with a heuristic audit of the existing Console, screen by screen. Three problems kept coming back.

It was built for the wrong person

Hardware pages, calendars and debug tools sat next to everyday tasks. Operators don’t debug hardware; they keep units running.

Statuses didn’t mean anything

Idle, Awake, Plugged in, Running: nobody could say exactly what each meant, or what to do about it.

The important things were buried

Routine actions like refilling silos sat several clicks deep, in an order that followed the system, not the shift. So operators phoned an engineer instead.

Heuristic audit of the old Console home page with annotated issues

Who it’s for

Who it’s for

There was a catch: when the project started, the operator role didn’t exist yet. So I interviewed the colleague closest to it, someone already doing parts of the job, and turned that into a first persona that stakeholders could check and correct.

Once the first operators were hired, I shadowed five of them through a full shift, from 08:00 to 19:00. That changed the picture in two ways.

The day has three different rhythms

Calm setup in the morning, heavy multitasking at lunch and dinner, deep cleaning at close. One rigid set of screens couldn’t serve all three.

Operators are rarely at the laptop

After loading the unit they moved on to cleaning, orders and procurement. When something went wrong, an engineer called them. The tool had no way to reach them.

An operator at work in the hub, and the operator shift from morning setup to closing

There was a catch: when the project started, the operator role didn’t exist yet. So I interviewed the colleague closest to it, someone already doing parts of the job, and turned that into a first persona that stakeholders could check and correct.

Once the first operators were hired, I shadowed five of them through a full shift, from 08:00 to 19:00. That changed the picture in two ways.

The day has three different rhythms

Calm setup in the morning, heavy multitasking at lunch and dinner, deep cleaning at close. One rigid set of screens couldn’t serve all three.

Operators are rarely at the laptop

After loading the unit they moved on to cleaning, orders and procurement. When something went wrong, an engineer called them. The tool had no way to reach them.

An operator at work in the hub, and the operator shift from morning setup to closing

Deciding what matters

Deciding what matters

I shared the audit with the Head of Product, the Operations Manager and the culinary team, and used the session to test my assumptions, not to sell a solution. Where do we agree? Which problems hurt operators most? Which ones slow the business down?

We agreed on three priorities: a simpler structure (the navigation went from nine items to five), a clear overview of unit status, and better flows for unit actions and silo filling.

Just as important was what we left out. The calendar went, because nobody could show it was needed. Engineering pages stayed out of scope, so the redesign could focus entirely on operators. And because swapping every component at once was too risky, we shipped new colours and type first as a quick win, while the full redesign happened in parallel.

Navigation before and after: nine system-driven items reduced to four per unit, plus a new fleet view

I shared the audit with the Head of Product, the Operations Manager and the culinary team, and used the session to test my assumptions, not to sell a solution. Where do we agree? Which problems hurt operators most? Which ones slow the business down?

We agreed on three priorities: a simpler structure (the navigation went from nine items to five), a clear overview of unit status, and better flows for unit actions and silo filling.

Just as important was what we left out. The calendar went, because nobody could show it was needed. Engineering pages stayed out of scope, so the redesign could focus entirely on operators. And because swapping every component at once was too risky, we shipped new colours and type first as a quick win, while the full redesign happened in parallel.

Navigation before and after: nine system-driven items reduced to four per unit, plus a new fleet view

Designing the Console

Designing the Console

  • A structure built on tasks. I rebuilt the site map around what operators do: start a unit, refill silos, clean, check stock. Five pages remain: Home, Unit, Stock, Interactions and History.

  • Statuses in layers. Each layer answers one question: is it connected, is it on, can it take orders, is anything wrong? Layers combine, so a unit can be Online and Awake but still Not accepting orders because a silo is empty. Plain labels, consistent icons, and a tooltip for each.

  • Only the actions that make sense now. The Interactions page shows what an operator can do in the unit’s current state, grouped in tabs by type of task.

  • Cards, not lists. I started with a list to reuse existing components and test quickly. Cards won: operators watch several units at once, and cards make them easy to scan and compare, across hubs too.

Each step went through quick prototypes, internal tests and stakeholder reviews. Weekly feedback sessions with the team kept decisions moving.

Layered unit status model on a unit card: connection, state, orders, temperature and tasks

Results

Results

Two weeks after launch, we measured:

  • 15% faster on key tasks. Time on task dropped on the Interactions page, where operators start, stop and refill units.

  • Operations efficiency up 5%.

  • 67% of operators satisfied in a CSAT survey. A solid start for a tool they used to work around, and a clear sign of what still needed work.

Routine actions no longer need an engineer, and the new structure gave product, operations and engineering a shared map of the tool.

Interactions page showing only the silo actions available in the unit's current state

Two weeks after launch, we measured:

  • 15% faster on key tasks. Time on task dropped on the Interactions page, where operators start, stop and refill units.

  • Operations efficiency up 5%.

  • 67% of operators satisfied in a CSAT survey. A solid start for a tool they used to work around, and a clear sign of what still needed work.

Routine actions no longer need an engineer, and the new structure gave product, operations and engineering a shared map of the tool.

Interactions page showing only the silo actions available in the unit's current state

What I’d do next

What I’d do next

The same research pointed to the next step: operators need alerts that reach them away from the laptop, for example when a silo is nearly empty or the dishwasher is low on soap. I started exploring a tablet version and multichannel notifications for the moments they’re standing at the unit.

What I’d change: talk to real users earlier. Without operators, I relied on stakeholder opinions that often contradicted each other. A proxy interview and a persona helped, but the shift shadowing taught me more in one day.

Final Console screens: fleet overview, stock, daily tasks and interactions

The same research pointed to the next step: operators need alerts that reach them away from the laptop, for example when a silo is nearly empty or the dishwasher is low on soap. I started exploring a tablet version and multichannel notifications for the moments they’re standing at the unit.

What I’d change: talk to real users earlier. Without operators, I relied on stakeholder opinions that often contradicted each other. A proxy interview and a persona helped, but the shift shadowing taught me more in one day.

Final Console screens: fleet overview, stock, daily tasks and interactions

Create a free website with Framer, the website builder loved by startups, designers and agencies.