The Questions Before the Code

Most bad web projects fail in the briefing phase, not the development phase. Someone was in a hurry to get started and didn't spend enough time understanding what they were actually trying to solve.

What the discovery phase looks like

We start by asking questions that might feel obvious: who uses this site right now, what are they trying to do, what's getting in the way. We ask what success looks like in twelve months, not what the site should look like.

The answers usually reveal something different from the initial request. A client comes in wanting a redesign. They're getting traffic but people aren't converting. That's not a design problem -- it's a content or structure problem. A redesign would have been expensive and wrong.

Why we push back on initial requests

We're not skeptical of what clients ask for. We're trying to understand what they actually need. Those are sometimes the same thing. Often they're not.

When a client says they need a new website, we ask: what's not working about the current one. When they say they need more features, we ask: which users need those features and what would they do with them. When they say they want to rank better in search, we ask: what do you want to happen after someone finds you.

The questions take time. They're worth it.

What gets built as a result

Clearer scope. Less rework. Sites that do what they're supposed to do.

We don't start designing or building until we understand the problem. That's not process for its own sake -- it's how we avoid building the wrong thing.

Tell us about what you're trying to solve.