Case study

Performance Management was being introduced into a platform already used by construction companies to manage their supply chains and compliance. The idea sounded straightforward: allow customers to assess how their suppliers were performing.

In practice, it touched several parts of the product and several different people. A Supply Chain Manager might set up an assessment, a Project Manager could contribute knowledge about a supplier, and the resulting information needed to come back in a form that could be understood and acted on.

The challenge wasn't simply designing a survey. It was defining how those responsibilities connected into one understandable workflow — and what each person needed to see and do at each stage.

When I joined the work, many of the individual requirements existed, but the end-to-end experience was still taking shape. Questions remained around who should create an assessment, who needed to contribute, when work was ready to be sent, and what happened once responses started coming back.

Rather than treating those as separate screen requirements, I started looking at Performance Management as a system. The questions became less about UI components and more about ownership:

• Who starts the process?
• Who contributes?
• What belongs to each role?
• When does responsibility move between people?
• How does someone understand what needs to happen next?

That became the structure I used to evaluate the designs as the product evolved.

Creating an assessment required several decisions: what was being assessed, which suppliers were involved, who needed to contribute and what information to collect. One large form would have exposed all of that at once.

I structured setup as a guided process instead, separating the decisions into stages while keeping enough context for someone to know where they were.

The goal wasn't to pretend the workflow was simple. It was to reveal the complexity at the point it became relevant — which also drew clearer boundaries between required information, optional configuration and actions that could happen later.

Four of the setup steps. How many there are depends on the first answer: a Project Manager survey runs Project → PM → Template → Review, while a supplier survey adds supplier selection and a named contact.Recreated for this case study from the Supply Chain Manager prototype.

Some of the smallest interaction decisions became important because they represented different commitments in the workflow.

Saving a draft and sending a survey couldn't behave like interchangeable primary actions. Saving meant “I'm still working on this.” Sending meant “This is ready to leave my workspace and become someone else's task.”

That distinction affected button hierarchy, states, validation and what happened next — a small UI decision carrying a bigger product principle: actions should communicate the consequence they create.

1. Save

   Nothing leaves my workspace. The assessment stays a Draft and I keep the only action on it.

2. Continue

   A step is settled, not the assessment. Reversible by going Back.

3. Send survey

   The assessment becomes Sent and appears as Outstanding work for someone else.

4. Submit survey

   The strongest commitment in the workflow: answers become Completed and read-only.

Performance Management wasn't designed from a finished specification. Requirements arrived as conversations with product and engineering progressed, and the boundary between the two experiences moved with them.

Instead of treating each new requirement as another screen to add, I returned to three questions: Who owns this? At what stage? What changes because of it? That surfaced gaps in the product definition before they became more UI.

The clearest example is the setup flow itself: it has no fixed length. Answering “who is this for?” is what decides whether there are four steps or five — a structural consequence of the role model rather than a screen someone specified.

The project moved from a collection of requirements around assessments and surveys towards a clearer product model built around roles, ownership and states.

That gave the team a shared structure for new requirements. Instead of asking only where another field, button or screen should go, we could ask where it belonged in the workflow and who should be responsible for it.

The design became a way of defining the product, not just representing requirements that had already been defined.

Performance Management reinforced something I've found increasingly important in enterprise products: complexity isn't always something you can remove. The roles, responsibilities and stages here were genuinely different, and making them behave the same would have produced a product that was simpler on paper and harder to use.

The better opportunity was deciding who needed to understand which part of the complexity, and when. On a similar project I'd establish the end-to-end role and state model earlier — as the scope expanded, that became the most useful way to evaluate new requirements and find gaps between parts of the experience.

It also changed how I think about 0→1 enterprise design. Sometimes the most useful work happens before there is a screen to polish: making responsibilities, states and product boundaries clear enough that the screens have a coherent system to belong to.