Catering support, on one console.

02Define

Affinity mapping the interviews into a composite.

I affinity mapped the interview notes by theme and flagged each friction point individually for redesign, so the work that followed was scoped against named problems. I wrote a composite kitchen team member to hold the findings in one place: what she needs, and what gets in the way. Every line attributed to her was said by someone in the interviews.

Her three needs became the criteria I designed the console against. Order details had to arrive complete, changes had to reach the kitchen before prep started, and there had to be one place to check instead of four.

02Define

Mapping the current-state tool ecosystem.

Working alongside developers, project managers and end users, I mapped the current-state tool ecosystem end to end, with the tooling for each channel laid against the journey it has to serve. Names and systems are scrubbed here, but the structure and the state of each touchpoint are as I found them.

Of 102 touchpoints across six channels, 15 handled the same information in more than one tool, 18 were a gap or an unknown, and only 6 were working well. That list of duplicates and gaps is what I scoped the design work from. Office workers have been measured switching between applications around 1,200 times a day, and the time spent picking the task back up again adds up to 9% of the working week.1 Hand-keying the same values into a second tool adds errors. One study compared values people had typed in against the same values captured electronically, and 3.7% of the typed entries were wrong.2 Both costs land on the agent who is copying an order between screens while a customer waits, which is why I kept the order, the customer's context and the contact in one panel in the final console.

02Define

Drawing a service blueprint of the catering order.

I drew a service blueprint for the catering order, with swimlanes for customer actions, front-stage agent actions, back-stage actions and the support processes underneath them, separated by the line of interaction, the line of visibility and the line of internal interaction. A journey map stops at what the customer does, so the back-stage work and the tooling under it only appear on the blueprint.

I wrote the back-stage lanes from the agent and kitchen interviews and not from the process documentation, so the handoffs and the waiting ended up on the sheet. The handoffs from an agent to a lead and from an agent to the next team were where details were being lost, and I turned them into the ask-a-lead and warm transfer flows. In NN/g's survey of 97 practitioners, fewer than half said customer support was involved in their blueprinting at all.3 I gave the blueprint a version number and the date of its last update, and kept earlier versions instead of overwriting them, so a change to the service could be traced back to the decision behind it.

03Develop

Auditing Amazon's existing support components.

I audited every Amazon support component and workflow against the catering tasks before drawing any new screens. The audit set the scope of the build: wherever Amazon already had a pattern for a task, the catering flow used it, so my design effort went into the gaps from the ecosystem map and agents met patterns they already knew. Rebuilding a component Amazon already maintained would have left two copies to keep in step. Where duplicated code has been measured in production systems, 52% of it had already drifted from the original, and the differences were turning into defects.4

Scroll sideways to follow the flow.

03Develop

Designing for the catering-specific gaps.

The gap list named the surfaces catering has no equivalent for anywhere else in Amazon, such as pickup details and an order history that marks each stage of a catering order. I designed those from scratch, along with a handful of places where an existing component did not fit the task.

I held color to 4.5:1 on text and 3:1 on the controls and icons. Status is never carried by color alone, because red-green color deficiency affects around 8% of men, so every state carries a label or a shape as well.5 I set the type scale in Amazon Ember, the typeface the rest of the console already used.

Scroll sideways to follow the flow.

03Develop

Extending Amazon's design system for catering.

I extended Amazon's existing design system for the catering work instead of starting a parallel one. A component entered the shared layer only where the same need turned up in more than one place and nothing already in the system covered it, and everything else stayed local to catering.

Every component shipped with usage guidance as well as a specification: when to reach for it, when to reach for something else, and what it deliberately does not cover. Asked what made somebody else's library hard to work with, 334 developers rated documentation problems the most severe obstacle of any they were asked about.6

Releases followed semantic versioning, which forces a decision about what counts as the public contract. I treated component props, token names and class names as part of it, because product teams were depending on them whether or not the system said they could. A deprecation carried a replacement, a removal date and a named owner. Teams keep writing new calls against deprecated code after a deprecation is published, which is why the date and the owner were part of it.7

Requests for new components came in through a single intake, and I answered each one with a variant, a new component or a no. At launch I handed the system to Amazon's team with the documentation, the intake route and the release history behind it, so it didn't depend on me. Across 133 popular open-source projects, two thirds would be stranded by the departure of one or two people.8

04Deliver

Testing the console with agents through launch.

I ran visual design and user testing through to launch on the unified platform. The flows below are the console's core support tasks, and each one is tied back to a problem agents or kitchen teams named in the interviews.