Good design starts long before anyone chooses a color, adjusts some spacing, or writes the first line of CSS. It starts by understanding what we’re trying to accomplish, who we’re building it for, and what information and actions matter most.

The amount of planning required will vary. A small website may need little more than a conversation, some content, and a rough sketch. A large application might require formal requirements, user stories, architecture, prototypes, and several rounds of review. The process should fit the project, but the questions behind it remain largely the same.

Knowing what you want. Forging a path.

The first step is understanding the problem. What are we trying to accomplish? Who are we building it for? What already exists? What constraints are we working within? And what don’t we know yet?

That process begins with the first conversation and continues throughout Discovery. For a small project, Discovery might happen quickly and informally. For something larger, it can become a substantial piece of work in its own right—collecting requirements, identifying stakeholders, developing user stories, defining priorities, and uncovering the unknowns that could affect the project later.

The goal isn’t to have every answer before design begins. It’s to know enough to start making informed decisions.

Project Plan

What we learn during Discovery needs somewhere to live. That’s the role of the Project Plan.

For larger projects, I typically think of that plan as having two important components: the Project Charter and the Statement of Work (SOW). The Charter establishes the project’s purpose, scope, stakeholders, and responsibilities, while the SOW gets more specific about the work itself—priorities, deliverables, schedule, and budget.

For smaller projects, these ideas don’t necessarily need to become large formal documents. What’s important is that we have a shared understanding of what we’re building, why we’re building it, and what we’ve agreed to do.

And the plan isn’t frozen in time. As we learn more, it should evolve. New information, changing requirements, and approved changes become part of the plan so it remains an accurate picture of the project rather than a document everyone stopped reading three months ago.

Sharpening the vision.

Once we understand the problem and have established a direction, we can start giving the solution shape.

This is where Digital Architecture, UX Design, and UI Design begin to build on one another. They’re closely related, and on smaller projects they may happen almost simultaneously, but they answer different questions.

• Digital Architecture asks: How should this be organized?
• UX Design asks: How should this work?
• UI Design asks: How should this be presented?

By working through those questions in roughly that order, we can make important decisions while they’re still inexpensive to change—before we’ve invested significant time polishing an interface or building it.

Digital Architecture

Before deciding what something looks like, I want to understand its structure.

Digital Architecture is where we organize the information, features, relationships, and paths through the product. For a website, that might mean developing a sitemap and determining how content should be grouped. For an application, it might mean mapping features, defining navigation, identifying different types of users, and understanding how one part of the system relates to another.

The goal is to create a structure that makes sense before we worry about making it beautiful.

This is also where content becomes particularly important. If we don’t know what information needs to exist or how people need to move through it, designing polished screens is mostly guesswork.

Architecture gives the experience a skeleton.

UX Design

Once we understand the structure, we can focus on how someone will actually use it.

UX—or User Experience—Design looks at the paths people take through the product. What are they trying to accomplish? What information do they need at each step? What happens when something goes wrong? How many decisions are we asking them to make?

This is where user flows, wireframes, and prototypes become useful. They let us explore how an experience works without spending a lot of time making it look finished.

That’s intentional. A rough wireframe is cheap to throw away. A polished interface that took days to design—and even longer to develop—isn’t.

UX lets us solve usability problems while they’re still cheap problems.

UI Design

Only after we have a good understanding of the structure and experience do we need to decide exactly how the interface should look.

UI—or User Interface—Design is where typography, color, spacing, hierarchy, controls, imagery, states, and visual language come together. But those choices aren’t merely decoration. Good UI helps communicate the structure we’ve already established.

An important action should look important. Related information should feel related. Navigation should be recognizable. Feedback should make it clear when something worked—or when it didn’t.

This is where a wireframe begins to feel like a real product, but the visual design is now working in service of decisions we’ve already made about content, architecture, and usability.

And now, finally, we’re getting close to needing some CSS.

Now we’re ready to build.

By the time development begins, we haven’t answered every question. We probably never will. Projects evolve, users surprise us, technical constraints appear, and some ideas simply work differently once they’re running on a screen.

But we’re no longer starting from a blank page.

We understand the problem. We have a plan. We’ve organized the information. We’ve thought through the experience. And we have a visual direction for communicating it.

Development will teach us new things, and those lessons will feed back into the design. That’s why I don’t think of design and development as completely separate phases. They’re parts of the same conversation, each making the other better as the project takes shape.