Good product work usually begins before there is a layout to critique. I want to understand what the product needs to help someone notice, decide or complete, and what the business needs to learn from that behavior.
That shift changes the design conversation. Instead of asking which screen should come next, the team can ask which decision should become easier and which part of the product should support it.
It also changes who can take part. A discussion about the order of two sections is a matter of taste, and taste arguments are won by whoever is most senior in the room. A discussion about which decision a person is trying to make has an answer that anyone can check against the product.
The interface is the output, not the starting point
A screen is a visible response to a product decision. Starting with the screen can make an unclear idea look finished before the underlying behavior has been defined.
I begin by writing the situation in plain language: who is here, what do they know, what are they trying to do and what might prevent the next step. This creates a working model that can be challenged without defending a polished composition.
The cost of skipping this is not a bad screen. It is a screen good enough that nobody questions the assumption underneath it. Polish is persuasive, and it persuades the team before it ever reaches a user.
Visual craft earns attention. Product clarity tells that attention where to go.
Define the behavior that needs to change
Outcomes become useful when they describe an observable change rather than a broad ambition. A product cannot directly design trust, growth or engagement. It can make information clearer, reduce uncertainty and help a person complete a meaningful action.
The more precise the behavior, the easier it becomes to decide what the interface must explain and what can remain secondary.
In MontNoir the ambition was trust: a business had to believe an automated security audit. Trust is not designable. The behavior underneath it was, though - an engineer who did not run the audit had to be able to reproduce any finding by hand. Once that was the target, the interface followed from it, down to what shipped in the exported PDF.
- What should a person understand that is unclear today?
- Which decision should require less effort or uncertainty?
- What action would show that the product direction is useful?
An outcome is not the same as a metric
Teams often reach for a number too early, and the number quietly rewrites the brief. Time on page goes up when navigation is confusing. Activation goes up when a step is made compulsory. Neither result means the product got better at its job.
I keep the behavior and the measurement separate for as long as possible. First: what should someone be able to do that they cannot do easily today. Only then: what would we observe if that were true.
This ordering also protects the work when a number moves for reasons nobody planned. If the behavior was written down, the team can tell the difference between a product that worked and a metric that drifted.
Turn uncertainty into a sequence
Many difficult interfaces are not missing features. They are missing order. The user receives every option at once because the product has not decided which question comes first.
I map the sequence from orientation to decision to action. Each layer should answer one question and prepare the next. This gives hierarchy a product reason instead of making it a purely visual preference.
The default failure is the empty search field. It looks neutral and it is not: it asks a person to be precise before they know what is available. In Bartly discovery opens with concrete offers instead, so the first interaction is a reaction rather than a query, and filters narrow what is already visible.
Design the smallest coherent system
A useful first release is not a pile of isolated screens. It is the smallest set of flows, states and reusable rules that can support the core behavior from beginning to end.
This is where product structure and visual craft meet. Shared patterns reduce the amount a user has to relearn, while focused moments can still carry the character of the product.
Smallest does not mean plainest. In Gettran the whole product rests on one mechanic - the interface takes its light from the asset currently in view - and that single rule does the work that a page of hierarchy guidelines would otherwise do. One decision, applied everywhere, beats twenty local ones.
- Cover the full core journey before polishing secondary branches
- Define empty, loading, error and success states with the main state
- Reuse product language and interaction rules before adding variants
Ship with a learning loop
An outcome-led process does not end when the interface is delivered. The original behavior provides a way to review what happens next and to separate a weak idea from a weak execution.
The important part is to preserve the reasoning. When the team knows which assumption a decision was meant to test, iteration becomes a continuation of the product process instead of a sequence of unrelated redesigns.
This is easiest to see on internal products, where the people using the tool are the people building it. Axis was built for one team and is still used only by that team, so a bad assumption surfaces in days rather than quarters. External products get the same signal eventually; they just have to be designed to notice it.
Designing for outcomes means giving every important interface decision a reason that exists beyond the frame. The visual result still matters deeply, but it becomes stronger when it carries a clear product intention. The test is simple: if a decision cannot be explained without pointing at the screen, it has not been made yet.