Should you design the UI or define the outcome first?

Define the outcome first. The screen is only the path to a result — what the user should be able to do, know or have when the product works. If you design the interface first, you commit to a UI before you know what it's for, and you end up polishing screens that don't clearly serve an outcome. Writing the expected output first gives the screen a job, and a screen with a clear job almost designs itself. It's the same discipline as defining a measurable outcome before starting any piece of work.

What does 'expected output before the screen' mean?

It means writing down, in plain terms, exactly what the user should get from the product — the result, the answer, the artifact, the changed state — before you draw any interface. For a delivery tool that might be 'a decision-ready one-pager the user can act on'; for a forecast it might be 'the number they can fund against.' You define that output first, then design the smallest screen that delivers it. The output is the destination; the screen is just the road.

Why do so many apps have polished UIs that don't help?

Because they were designed screen-first: someone built a beautiful interface before being clear on the outcome it was supposed to produce, so the polish sits on top of an unclear purpose. A gorgeous screen that doesn't deliver a clear result is decoration, not product. Defining the expected output first prevents this, because every design decision then has a test — does this get the user to the output faster and more clearly? — instead of just looking good.

Why I Write the Expected Output Before the Screen

Before I design a single screen, I write down the exact output the user should get — the result, not the interface — because the screen is only ever the path to an outcome. Design the screen first and you fall in love with a UI before you know its job; define the output first and the screen almost designs itself, because now every design choice has a test: does this get the user to the result faster and clearer? It's a small habit with an outsized effect, and it's the same discipline I spent years applying in enterprise delivery — define what's true when it's done, before you build anything.

The screen is not the product

It's easy to think the screen is the product — it's the part you see. But the screen is the road, not the destination. The destination is the output: what the user can do, know, or have when it works. A cash tool's output is a number they can fund against; a delivery tool's output is a decision-ready one-pager they can act on. Confuse the road for the destination and you'll build a beautiful road to nowhere in particular.

What "expected output first" looks like

Before any design, I write one plain sentence: when this works, the user has ____. Then I design the smallest screen that delivers that. The sequence matters:

Output — the exact result the user should get.
The path — the fewest steps to produce it.
The screen — the interface for those steps.

Do it in that order and the screen has a job. Do it backwards — screen, then figure out what it's for — and you get polish sitting on an unclear purpose.

A gorgeous screen that doesn't deliver a clear output isn't product — it's decoration. Defining the output first gives every design decision a test to pass, instead of just something to admire.

Why AI makes this more important, not less

AI can generate a slick screen in seconds — which is exactly why output-first discipline matters more now. When producing a beautiful UI is nearly free, the beautiful UI is no longer evidence of anything; it's the cheap part. The scarce, valuable part is knowing precisely what result the product must produce. If you let the easy polish lead, you get an app that looks finished and solves nothing. Define the output first and AI becomes a fast way to build the right screen, instead of a fast way to build an impressive wrong one.

What usually goes wrong

Screen-first design. Building the interface before the outcome is clear, so polish accumulates on an unclear purpose.
No stated output. No single sentence saying what the user should get, so the product wanders and every design debate is unresolvable.
Mistaking polish for progress. A better-looking screen feels like progress even when it's not getting the user to a result any faster.
Letting the tool lead. Following whatever's easy to build (now: whatever AI generates well) instead of what the output requires.

Write the expected output first, design the smallest screen that delivers it, and judge every design choice by whether it gets the user to that result faster and clearer — and you stop building beautiful roads to nowhere. It's rule two of my operating system for a reason: the output is the product; the screen is just how you hand it over.

Part of Building AI Products. See also my product operating system and how I use AI without letting AI make product decisions. The newsletter sends one practical build lesson every two weeks.