Writing · 4 min read
How I move a complex workflow from ambiguity to release
A broad product request becomes useful through shared problem framing, focused investigation, realistic prototypes, and decisions made with engineering, not through a design handoff at the end. The work is to make the uncertainty specific, give the team something concrete enough to judge, and stay involved while it becomes a working part of the product. The scenario below is illustrative, not an account of a project already delivered.
Key idea 1 of 7
A complex request arrives as a signal, not as a design problem
A complex product request rarely arrives as a design problem.
We need better visibility. Customers should be able to do this themselves. Too many issues end up with support.
Those are useful signals and they are not yet enough to decide what to build. My job is to make the uncertainty specific, not to wait for it to clear.
I do not expect the requirements to be settled before design starts. Helping settle the right ones is the work.
- Frameone testable sentence
- Engineering inwhile it is defined
- Small and wholeone supported path
- Right fidelitythe awkward records
- Release criteriabehaviors agreed
- Stay involvedmeasures and support
Key idea 2 of 7
A request becomes a problem when it fits in one testable sentence
Say the request is a better dashboard for the progress of new trading-partner onboarding.
Before deciding what goes on it, I would ask what someone cannot determine today. Does an implementation coordinator need to know which setup tasks remain? Is a customer waiting to hear whether testing passed? Does an administrator need to know who owns a blocker?
Those may all end up in one experience. They are not the same task.
I would start with the product manager and the people closest to the work: users, support, implementation specialists, and the engineers who maintain the existing flow. The aim is a testable account of the problem, in one sentence. Something like: an implementation coordinator cannot tell what remains before a partner goes live without checking three places and asking a specialist.
At that point it is a hypothesis. I would take real examples and find out whether it holds, who it holds for, and what it misses.
Key idea 3 of 7
Bring the technical reality in early
I would have engineering and architecture in the room while the experience is still being defined, not after.
Where does readiness information come from? Which steps are recorded automatically and which depend on a person? Does a passing test mean the configuration is production-ready, or does an approval still stand between them?
Those answers decide what the product can honestly say. Product management sets the business priority and the scope. Engineering and architecture name the constraints and dependencies. I bring the user evidence, the proposed workflow, and what each option costs the person using it.
The goal is not unanimous agreement on every detail. It is a clear decision, an understood trade-off, and a written record of the assumptions still to be tested.
Key idea 4 of 7
Choose an improvement that is small and whole
I would not make the first release a redesign of the onboarding platform.
One supported path, with a clear view of completed steps, unresolved blockers and the owner of the next action, is a smaller scope that still carries a complete task. A coordinator should arrive with a question, understand the situation, and take or request the next action.
A dashboard that looks better and leaves the last step in an email thread has not solved the problem it was asked to solve. So I would state the boundary: what this release supports, what it does not, and how people handle what falls outside it.
Key idea 5 of 7
Prototype at the fidelity the next decision needs, on the awkward records
Early, a rough flow is often enough to expose that two people mean different things by ready.
Later, a prototype has to let us investigate behavior. What happens when a prerequisite changes? Can someone tell a failed test from one that has not run? What does a person without edit permission see?
I would use representative data, including the awkward records, rather than the ones that make the layout look good. AI-assisted tools shorten the route to something the team can put hands on, and I review what they produce and keep simulated behavior clearly marked as simulated. The prototype exists so we can decide together, not so I can present.
Key idea 6 of 7
Make the release criteria part of the design
Leading UX across more than forty SAP Fiori applications taught me that a design decision needs a way to survive implementation and everything that comes after it: shared patterns, feedback from real users, and UX and accessibility checks inside the release process. That account is here.
So before calling a design ready, I would agree the behaviors with engineering. A blocker carries a useful explanation and a next step. A status has one meaning. A failed update does not erase someone’s work. Keyboard order and focus are specified alongside the visual states.
Where a constraint changes the experience, I would work the alternative through with the team rather than around them. If live status is out of scope for this release, a clearly labeled last-confirmed state and a deliberate refresh is an honest answer; a display that implies it is live is not.
Key idea 7 of 7
Stay involved after people start using it
Before release I would agree how we will know whether it worked. Here, whether coordinators can judge readiness correctly, name the owner of a blocker, and move the process along without pulling in a specialist.
After release, those measures read alongside observation and what support hears. If the new experience moved the confusion somewhere else, that is the next design problem, and I would rather find it than be told about it.
The value of a senior designer is not the screens. It is helping a team understand what matters, decide with enough evidence, and keep improving the thing as the product and its users change.