8 hours → 1 minute

My scope

I owned the project from problem definition through shipped design.

I worked with:

• 4 TPMs supporting product lines including iPhone, MacBook and Audio/Home
• 1 front-end + 2 back-end engineers
• 3–4 senior managers from the partner organisation
• Roughly 30 users per product program, recurring as new programs began each year

Beyond designing screens, I defined the problem, aligned teams around a new operating model, designed the key workflows end-to-end, and worked with engineering through implementation.

Before a new product can be built, every step on the factory line (a station, such as a screw-driving or camera-alignment step) has to be told what to measure and record about each unit: a temperature, a torque, a pass/fail. That list of measurements is the scope. Deciding the scope and getting it onto the machines is the setup. Every design or process change means doing it again.

The workflow for this had been built around processes from almost a decade earlier. As the organisation changed, teams compensated by hand: scope moved through spreadsheets and messages, responsibility shifted between people, and every change could trigger hours of setup.

I interviewed the project, measurement-system and operations teams, mapped the workflow end-to-end, and clustered every finding bottom-up before touching the interface.

The software was only the visible part of the problem. Three things were creating the eight hours:

That changed the project. Instead of redesigning one interface, I redesigned decision ownership, the workflow model, and the software connecting them.

Much of the eight hours existed because teams were reconciling decisions that should already have been made. The owner role rotated, and people couldn't see how their work connected to any outcome.

There was no place where scope was actually decided. The project team asked for measurements against the fear of future problems; the measurement-system team had no way to show whether anything collected was ever used. Scope only grew.

A stage was also treated as either approved or blocked, when in practice it might hold ten feasible measurements and one unresolved one, and the answer differed by build. Waiting for full approval stopped work that could safely move forward.

Even with ownership and approval clear, operations still had to turn decisions into machine setup by hand: aligning station lists, codes and parameters across sites and between the two systems. That's where the remaining work and most errors lived: records that failed to load, and two systems reporting different yield numbers.

This is what collapsed the workflow from eight hours to one minute.

Designing the interaction model

The three insights became one product model:

1. Decision enters the system
2. Owner and blocker are explicit
3. Feasibility is resolved per measurement
4. Confirmed scope moves forward independently
5. System generates the setup
6. Future changes update the same source of truth

Designing the transformation

The project touched teams outside my organisation and challenged a ten-year-old workflow. One of the biggest challenge was moving the organisation toward it without slowing delivery. I did the following 2 things to make it deliver.

Scope approval used to travel through spreadsheets, threads and multiple teams before setup could begin. Now open decisions, owners, blockers, partial feasibility and confirmed scope live in one shared system, which largely improves operational efficiency and avoid manual mistakes.