[{"data":1,"prerenderedAt":236},["ShallowReactive",2],{"blog-\u002Fblog\u002Fwhy-i-write-the-expected-output-before-the-screen":3,"blog-surround-\u002Fblog\u002Fwhy-i-write-the-expected-output-before-the-screen":216,"blog-related-\u002Fblog\u002Fwhy-i-write-the-expected-output-before-the-screen":225},{"id":4,"title":5,"audience":6,"body":10,"cluster":182,"date":183,"description":184,"draft":185,"extension":186,"factCheckedAt":187,"faq":188,"featured":185,"language":187,"meta":198,"navigation":199,"order":200,"originalAsset":187,"path":201,"pillar":202,"primaryKeyword":203,"relatedProject":187,"releaseScope":187,"reviewCycle":204,"reviewStatus":205,"reviewedBy":206,"searchIntent":207,"seo":208,"sources":187,"stem":209,"tags":210,"type":214,"updated":183,"__hash__":215},"blog\u002Fblog\u002Fwhy-i-write-the-expected-output-before-the-screen.md","Why I Write the Expected Output Before the Screen",[7,8,9],"indie-founder","solo-developer","product-builder",{"type":11,"value":12,"toc":174},"minimark",[13,32,37,49,53,60,82,85,91,95,108,112,139,147,150],[14,15,16,20,21,26,27,31],"p",{},[17,18,19],"strong",{},"Most people start a feature by opening the design tool."," I write one sentence first: ",[22,23,25],"a",{"href":24},"\u002Fblog\u002Fhow-i-position-a-product","the exact output the user should walk away with"," — the result, not the interface. The screen is only ever the path to an outcome. Design it first and you commit to a UI before you know its job. Write the output first and the screen almost designs itself, because now every choice has a test to pass: does this get the user to the result faster and clearer? It's a small habit with an outsized payoff, and it's the same discipline I ran for eighteen years in enterprise delivery — ",[22,28,30],{"href":29},"\u002Fblog\u002Fhow-to-define-a-measurable-outcome","define what's true when it's done, before you build anything",".",[33,34,36],"h2",{"id":35},"the-screen-is-not-the-product","The screen is not the product",[14,38,39,40,43,44,48],{},"The screen is the part you see, so it's the part you mistake for the product. It isn't. The product is the ",[17,41,42],{},"output",": what the user can do, know, or have once the thing works. Delivery Sheet's output is a vague leadership ask turned into a clear, reviewable delivery decision — a ",[22,45,47],{"href":46},"\u002Fproducts\u002Fdelivery-sheet","decision-ready one-pager"," someone can act on. The screen is just how that decision gets handed over. Start with the screen and you can polish for a week on something with no destination, and it will feel like progress the whole time.",[33,50,52],{"id":51},"what-expected-output-first-looks-like","What \"expected output first\" looks like",[14,54,55,56,59],{},"Before any design, I write one plain line: when this works, the user has ____. Then I build the ",[17,57,58],{},"smallest screen that delivers it",". The order is the whole trick:",[61,62,63,70,76],"ol",{},[64,65,66,69],"li",{},[17,67,68],{},"Output"," — the exact result the user should get.",[64,71,72,75],{},[17,73,74],{},"The path"," — the fewest steps to produce it.",[64,77,78,81],{},[17,79,80],{},"The screen"," — the interface for those steps.",[14,83,84],{},"In that order, the screen inherits a job. Backwards — screen first, purpose later — and you're decorating a room before you know what it's for.",[86,87,88],"pull-quote",{},[14,89,90],{},"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.",[33,92,94],{"id":93},"why-ai-raises-the-stakes-here","Why AI raises the stakes here",[14,96,97,98,102,103,107],{},"AI will hand you a slick screen in seconds, which is exactly why this discipline matters more now, not less. When a beautiful UI is nearly free, the beautiful UI stops being evidence of anything — it's the cheap part. The scarce part is knowing precisely what result the product has to produce. Let the free polish lead and you get ",[22,99,101],{"href":100},"\u002Fblog\u002Fhow-i-use-ai-without-letting-ai-decide","an app that looks finished and solves nothing",". Decide the output first and AI turns into a fast way to build the right screen instead of an impressive wrong one — provided you ",[22,104,106],{"href":105},"\u002Fblog\u002Fhow-i-turn-a-rough-idea-into-a-claude-code-ticket","hand it over as a tight ticket",", not a vague wish.",[33,109,111],{"id":110},"what-usually-goes-wrong","What usually goes wrong",[113,114,115,121,127,133],"ul",{},[64,116,117,120],{},[17,118,119],{},"Screen-first design."," Building the interface before the outcome is clear, so polish piles up on an unclear purpose.",[64,122,123,126],{},[17,124,125],{},"No stated output."," No single line saying what the user should get, so the product wanders and every design argument is unwinnable.",[64,128,129,132],{},[17,130,131],{},"Mistaking polish for progress."," A better-looking screen feels like movement even when it gets nobody to a result any faster.",[64,134,135,138],{},[17,136,137],{},"Letting the tool lead."," Chasing whatever's easy to build — now, whatever AI generates well — instead of what the output demands.",[14,140,141,142,146],{},"Write the output first, build the smallest screen that delivers it, and judge every choice by whether it gets the user to that result faster and clearer. Do that and you stop building beautiful roads to nowhere. It's rule two of my ",[22,143,145],{"href":144},"\u002Fblog\u002Fmy-product-operating-system","operating system"," for a reason: the output is the product; the screen is only how you hand it over.",[148,149],"hr",{},[14,151,152],{},[153,154,155,156,160,161,164,165,168,169,173],"em",{},"Part of ",[22,157,159],{"href":158},"\u002Ftopics\u002Fbuilding-ai-products","Building AI Products",". See also ",[22,162,163],{"href":144},"my product operating system"," and ",[22,166,167],{"href":100},"how I use AI without letting AI make product decisions",". The ",[22,170,172],{"href":171},"\u002Fnewsletter","newsletter"," sends one practical build lesson every two weeks.",{"title":175,"searchDepth":176,"depth":176,"links":177},"",2,[178,179,180,181],{"id":35,"depth":176,"text":36},{"id":51,"depth":176,"text":52},{"id":93,"depth":176,"text":94},{"id":110,"depth":176,"text":111},"process","2026-07-24","Define the outcome before design: I write the exact result the user should get before building any screen, because the screen is only the path to an outcome.",false,"md",null,[189,192,195],{"question":190,"answer":191},"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.",{"question":193,"answer":194},"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.",{"question":196,"answer":197},"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.",{},true,3,"\u002Fblog\u002Fwhy-i-write-the-expected-output-before-the-screen","building-ai-products","define outcome before design","annual","reviewed","Tan Gravam","informational",{"title":5,"description":184},"blog\u002Fwhy-i-write-the-expected-output-before-the-screen",[202,211,212,213],"product","design","outcomes","text","1JQA0qblxLb5w_It05k5I9c8Cyh_w--Q6VEdfO5ChrQ",[217,221],{"title":218,"path":219,"stem":220,"type":214,"language":187,"draft":185,"children":-1},"Why I Don't Offer a Free Plan","\u002Fblog\u002Fwhy-i-dont-offer-a-free-plan","blog\u002Fwhy-i-dont-offer-a-free-plan",{"title":222,"path":223,"stem":224,"type":214,"language":187,"draft":185,"children":-1},"Why Most AI-Built Apps Feel Like Demos","\u002Fblog\u002Fwhy-most-ai-built-apps-feel-like-demos","blog\u002Fwhy-most-ai-built-apps-feel-like-demos",[226,229,233],{"path":144,"title":227,"description":228},"My Product Operating System for Building Multiple AI Apps","The product operating system I use to build several focused AI products solo: choosing which problem to build, shipping fast, and killing what isn't working.",{"path":230,"title":231,"description":232},"\u002Fblog\u002Fhow-i-decide-whether-an-ai-product-idea-is-worth-building","How I Decide Whether an AI Product Idea Is Worth Building","How to decide what product to build: the short filter I run every idea through — real recurring problem, one-sentence outcome, small enough to ship solo.",{"path":100,"title":234,"description":235},"How I Use AI Without Letting AI Make Product Decisions","Using AI to build products means AI owns the how — code, scaffolding, drafts — while I keep the what and why: the problem, outcome, cuts and pricing.",1785182343790]