All posts

May 9, 2026

Design Before You Build

Writing code from a ticket is slower, more expensive, and produces worse products than writing code from a designed interface. Here's the technical case for why design is not a phase that follows thinking — it's what bridges thinking and building.

There's a workflow that most engineering teams know is suboptimal but persist with anyway: a ticket, a description, sometimes a rough sketch, and then an engineer builds the UI from their own interpretation of what was meant.

The ticket said "add a settings page." The engineer builds a settings page. It ships. The PM looks at it and it's technically correct — all the settings are there — but the layout doesn't match the mental model users have from the rest of the app. The information hierarchy is off. The empty state is missing. The labels use the wrong terminology.

Revision. Another ticket. Another build cycle. A second review. The settings page now works the way it was supposed to work the first time.

This cycle is so normal in software development that most teams don't recognise it as waste. It's just how things go. The UI takes a few passes. That's product development.

Except it isn't inevitable. It's the direct result of skipping the design step. And when you look at what the design step actually does — technically, not philosophically — the waste it prevents becomes very concrete.

The cost equation

The research on the cost of late-stage changes in software is old and consistent. Barry Boehm's foundational work on software engineering economics established that the cost to fix a design problem multiplies by phase: a problem identified in requirements costs roughly 1x. The same problem identified in design costs 5–10x. In code: 10–25x. In testing: 25–50x. After deployment: 50–100x.

These numbers have been updated many times by subsequent research. The multipliers vary. The directional truth doesn't: finding and fixing problems earlier is cheaper by an order of magnitude at each stage.

The implication is straightforward. Design artefacts — wireframes, mockups, high-fidelity prototypes — exist precisely to create a stage where problems can be found cheaply. A layout problem caught in a mockup costs an hour of a designer's time. The same problem caught in production costs engineering time, QA time, release cycles, and user trust.

Eighty percent of total product cost is determined by the time the design phase is complete. What that means in practice: the decisions made at the design stage — what exists, how it's structured, how it behaves — determine the vast majority of what everything downstream will cost. The code is largely the execution of those decisions.

UI design as state machine specification

Most engineers think of a mockup as a picture of what something looks like. That's underselling it significantly. A complete set of UI designs is, in a very precise sense, a state machine specification.

Every screen is a state. Every user interaction is a transition. Every conditional render — empty state, loading, error, partial data, different permission tiers — is a branch. When a designer produces a complete set of mockups, they are enumerating the states the application needs to handle. When they produce an incomplete set — which is what you get when you skip to code — the unspecified states become implicit, handled however the engineer thought made sense.

Consider a user profile screen. A spec might describe it as "shows user's name, avatar, and recent activity." A mockup makes explicit: what does it look like when activity is empty? When the avatar hasn't been set? When the name is longer than 40 characters? When the user is viewing their own profile vs. someone else's? When the user's account is suspended? When the viewer doesn't have permission to see certain fields?

Each of those is a state. Each state requires a UI decision. Without the mockup, those decisions happen at implementation time — ad hoc, one developer at a time, with no coordination. The resulting code handles them in technically correct but visually inconsistent ways that accumulate into a product that feels rough without anyone being able to articulate exactly why.

This is not a hypothetical problem. It's the specific, predictable consequence of treating UI states as implementation details rather than design decisions. A mockup that forces every state to be drawn is forcing the state machine to be fully specified before a line of code is written.

What mockups reveal about your data model

Here's something most product teams don't realise until they're deep in an implementation: the UI you're designing is a direct specification of the data model you need. Design a screen with a user's subscription tier displayed, and you've just specified that users needs a subscription_tier field. Design a "last active" timestamp next to each item, and you've specified that you're tracking activity timestamps. Design a "shared with 3 others" indicator, and you've specified a sharing/permissions model.

This seems obvious when stated plainly. It is routinely ignored in practice.

The failure mode is building a UI that implies a data model that doesn't match what was actually modelled. You build a dashboard that shows "30-day trend" arrows, and later discover the database only stores aggregate totals per day — reconstructing a trend requires a query that's either expensive or missing data for users who joined less than 30 days ago. You build a notification system that shows "X and 2 others liked your post" and later realise this requires either a denormalised count column or an expensive JOIN query that wasn't planned for at that scale.

A mockup, reviewed before schema design, is a data model audit. Show it to a backend engineer and they will immediately start reading out the schema requirements: "that's a many-to-many relationship," "that requires a computed column," "that's going to need an index on the timestamp," "that notification pattern means you need a fan-out on write, are we sure about that?" These are conversations that cost almost nothing to have before the schema is written, and are expensive and sometimes architecturally disruptive to have after.

The design artefact forces data model decisions to happen in the right order — before the schema, not after.

Information architecture as constraint discovery

Information architecture is the discipline of deciding what things are called, how they're grouped, and what hierarchy they sit in. It sounds soft. It isn't.

When you design the navigation for an application, you are making hard decisions about the conceptual model users will have of the product. Those decisions have direct technical consequences. Group "team settings" and "personal settings" under a single "Settings" navigation item, and you've made a decision about how permissions work — the settings page will need to conditionally show sections based on the user's role. Split them into separate top-level items, and you've made a different decision — the routing and permission model is different. Neither is obviously right; the point is that it's a decision with technical dependencies, and it should be made explicitly before the routes are built.

Navigation design also reveals entity relationships that aren't obvious from the spec. A spec might say "users can have multiple workspaces." A design that actually draws the workspace switcher — the UI for moving between workspaces — immediately raises questions: does workspace context persist across page loads? Does the URL encode the current workspace? Can you link someone directly to a resource in a specific workspace? What happens when you're deep in a workspace-scoped page and switch workspaces? These aren't design questions. They're data model and routing questions that the design exercise surfaces.

Information architecture (IA) design is, in this sense, a form of API design. When you define the conceptual structure of the UI, you are defining the entities, the relationships, and the access patterns that the API needs to support. Teams that do IA design first arrive at API design meetings with a concrete list of requirements. Teams that skip it arrive with a vague spec and spend half the meeting discovering requirements they hadn't considered.

The API-first parallel

The software industry spent years developing the discipline of API-first design: define the interface contract before writing the implementation. Don't build the server and then document what it does; design the API and then build to it. Tools like OpenAPI, GraphQL schemas, and protobuf definitions are all artefacts of this philosophy — a precise, implementation-independent specification of the interface that both sides of the contract are built against.

The argument for API-first design is exactly the same as the argument for design-first development, and for the same reasons:

Interfaces are hard to change. An API that's in production and being called by clients has consumers. Changing it breaks them. The same is true of UI: a layout that users have learned to navigate has users. Changing it creates relearning cost and confusion. Both are much cheaper to get right before anyone is depending on them.

Interfaces encode assumptions. An API's request/response structure encodes assumptions about what data exists, what operations are valid, and what the caller needs. A UI's layout encodes assumptions about what information users have, what actions are available, and what decisions users need to make. These assumptions need to be made deliberately, not improvised.

Interfaces create alignment. An API spec gives frontend and backend teams a shared contract to build against. A design spec gives engineering and product teams the same thing. Without the contract, both sides build toward an implicit model that may not match.

The design artefact is the UI equivalent of an OpenAPI spec. It's a contract between product intent and engineering execution, with enough specificity that both sides can build against it independently and arrive at the same place.

The cognitive walkthrough as a structured debugging pass

A cognitive walkthrough is a usability inspection method from HCI research: you walk through a design scenario step by step, asking at each step whether the user would know what to do next, whether feedback confirms their action succeeded, and whether error recovery is possible if they go wrong. It's a debugging pass on the user experience, done before anything is built.

The value of a cognitive walkthrough on a design artefact is not primarily in catching obvious usability problems. It's in surfacing implicit assumptions about what users know. The design might assume that users understand what "workspace" means, or that they'll know to look in the settings menu for billing, or that a red badge on the navigation icon means something actionable is waiting. These are assumptions that feel obvious to the team that built the product and are often opaque to users who haven't been in the room for the last three weeks of product conversation.

A cognitive walkthrough makes these assumptions visible as explicit claims: "at this step, the user will know that X." Those claims can be evaluated. They often turn out to be wrong, or to depend on information that isn't in the UI. Catching this in a design review is free. Catching it in user research after the feature ships costs a sprint.

The walkthrough also reveals flow completeness problems that specs miss. A spec describes the happy path. A cognitive walkthrough forces you to think about what happens at each branch: what if the user doesn't have the prerequisite data? What if they need to leave mid-flow and return? What if they complete the flow in a different order than intended? These are the questions that, unasked during design, get answered by individual developers making local decisions — which is how you end up with an onboarding flow where skipping a step produces a broken state that nobody tested.

Design tokens as a type system for visual consistency

In frontend engineering, design tokens are named variables for visual properties: colour values, type scales, spacing units, border radii, shadow definitions, animation durations. They're the implementation of a design system — the mechanism by which "primary blue" means the same hex value everywhere in the codebase, rather than being separately typed in forty different component files where it will inevitably drift.

The analogy to a type system is exact. A type system prevents a class of errors at compile time by constraining what values can flow through a program. Design tokens prevent a class of visual errors at implementation time by constraining what values can appear in the UI. Both make implicit constraints explicit, and both catch violations earlier.

What design tokens require in order to work correctly is a design phase in which the design system was defined. You can't implement tokens without knowing what the token values should be. You can't know the token values without having made the visual decisions: how many type sizes, what the spacing scale is, how many shades of the primary colour the product needs. These decisions come out of the design process. If the design process is skipped, the tokens don't exist, and developers hardcode values, and the values drift, and the product accumulates visual inconsistency that makes it feel unpolished in ways that are expensive to remediate.

This is a specific technical consequence of skipping the design step, not a vague aesthetic concern. The absence of a design token system means the absence of a mechanism for enforcing visual consistency, which means inconsistency accumulates as a direct function of the number of developers and the number of implementation sessions.

What design surfaces that specifications don't

A well-written spec describes what a product should do. Design shows what it actually looks like to use it — and those are not the same thing.

The gap between specification and experience is where most product problems live. A spec can describe a multi-step onboarding flow in reasonable detail: step one collects X, step two collects Y, step three confirms Z. What the spec cannot tell you is whether the flow feels like it takes too long. Whether the progress indicator in step two gives users the right level of confidence. Whether the confirmation screen at step three answers the question users actually have at that moment.

These are not edge cases. They are the product. And they are invisible in text until someone renders them.

Nielsen Norman Group's research on prototyping shows consistently that users respond to mockups and prototypes in ways that don't match their responses to verbal or written descriptions. People often can't tell you what they want in the abstract; they can immediately tell you whether what they're looking at is right. The design artefact creates a surface for genuine reaction — which is the only kind of feedback that actually informs product decisions.

This is why the design step is not redundant with the spec step. The spec establishes intent. The design validates it. Between them, they answer two different questions: "what are we building?" and "does this work?"

What happens when you skip it

The failure mode of building without design isn't dramatic. It's gradual and cumulative.

Engineers make micro-decisions: what to call things, how to order them, how to handle edge cases, what the empty state looks like. Individually, these decisions are reasonable. Collectively, they accumulate into a product that doesn't quite feel intentional — because it wasn't. It was assembled from reasonable individual judgements that nobody aligned in advance.

The alignment cost gets paid eventually. Usually in a "polish pass" — a sprint dedicated to making the product feel coherent, fixing the inconsistencies that accumulated through the build. Sometimes it's paid in user research, where testing reveals that the flow doesn't work the way anyone assumed. Sometimes it's paid in churn, where users leave because the product feels rough and they can't articulate exactly why.

In AI-assisted development, the problem compounds. Vibe coding tools execute confidently. They produce interfaces that look complete. But without a design artefact to generate from, the AI is making the same micro-decisions the human engineer was making — except without a PM to ask, without institutional memory of earlier decisions, and without the ability to hold the whole product in mind simultaneously. The accumulated inconsistency is faster.

The specific mechanism is worth understanding. Each AI session is a locally optimal generation: the AI produces the best output it can given the current prompt and context. But local optimality doesn't compose into global coherence without a shared constraint system. Two sessions that each produce locally reasonable UI decisions can produce globally inconsistent results — different mental models of the same concept, different spacing conventions, different empty state treatments — because there was no artefact establishing the constraints that both sessions should have respected. A design artefact is exactly that constraint system.

Design as communication

There's a second function of design artefacts that is separate from catching problems: alignment.

A mockup requires no context to interpret. A stakeholder who hasn't been in the room for the last three weeks of product conversations can look at a mockup and immediately understand what's being built, react to it, and give meaningful feedback. They can notice that the empty state is missing. They can flag that the terminology doesn't match the sales pitch. They can see that the dashboard shows data the company doesn't actually have yet.

A ticket, a spec, or a conversation cannot do this. They require the reader to construct a mental model of something that doesn't yet exist. Different readers construct different models. The mockup replaces all of those different models with one shared reference — which is the actual product, or close enough to generate useful alignment.

This function — design as a shared language across engineering, product, design, and stakeholders — is independent of whether the design is AI-generated or human-made. The value is in having the artefact, so that everyone working on the product is working from the same picture.

Design-first in the AI era

For most of software history, "design before build" was an ideal that teams approximated with varying discipline. The tools made it possible but not fast. A designer produced mockups; engineering built from them; the gap between mockup and implementation was closed manually, imperfectly, through iteration.

AI tools change the economics of this in both directions.

On one side, vibe coding tools make it tempting to skip design entirely — the barrier to generating a working interface is so low that producing a mockup first can feel like an unnecessary intermediate step. Why design when you can just build?

On the other side, AI design tools — when they work correctly — make the "design before build" step genuinely fast. Generating a high-fidelity, functionally complete set of screens for a product no longer takes weeks. It can take an afternoon. Which means the economics of "design first, build second" have shifted: the upfront cost of having a designed interface to generate from is low, and the downstream benefit — coherent UI, aligned team, caught edge cases, accurate estimates — is exactly what it always was.

The case for design before build is stronger now than it's ever been, not weaker. Not because the principle changed, but because the cost of skipping it has gone up (vibe coding accumulates inconsistency faster than human engineering) and the cost of doing it has come down (AI design tools make mockups fast to produce).

How Mowgli approaches this

Mowgli is built around the design-first principle: you understand your product (via the spec), you see your design (via the moodboard and full generation), and then you build — exporting to your codebase or passing to a coding agent with the designed interface as the source of truth.

The full generation produces every screen your product needs — 20, 30, 40, 50+ depending on scope — in a consistent visual language, from a spec that captured your product intent before any design decision was made. Because the generation is driven by a spec that includes user types, flows, states, and edge cases, the screens that come out represent the full state machine of the product — not just the happy path. Empty states, error states, partial data states, permission-gated states are in there, because the spec defined them, and the generator had a complete model of what needed to exist.

You can slam out a proof of concept in under 30 minutes: questionnaire, moodboard, full generation, and a prototypable, shareable design that covers your product end to end. Founders consistently tell us the questionnaire forces them to think through things they hadn't considered before starting — edge cases, user types, flows they'd assumed were obvious but hadn't actually defined. The product that comes out the other end is a better product than the one they had in their head, because the process of articulating it surfaced the gaps.

The spec also stays in sync. Every design iteration that changes a flow or function updates the PRD automatically — no second prompt, no manual maintenance. You're always generating from an accurate model of your product, not an outdated one. Which means if you export to a codebase or pass the design to a coding agent, the specification they're building against reflects the current state of the design, not the state it was in three weeks ago.

The design step isn't a phase that Mowgli adds to a workflow. It's the workflow. Plan, design, iterate, build — in that order, with AI doing the heavy lifting at each stage and the human in control of the decisions that matter.

We explore the thinking step in Think Before You Build and the specification step in Why Spec-Driven Development Is the Future.

Sources