The Refinement Report: why I start with research, not a requirements list

Most website projects start the same way. The business owner writes up a list. Five pages. A contact form. The logo, but bigger. Make it look like that competitor's site, except blue. Then the list goes to whoever is building the site, and the building begins.

I don't start there. Before I design a single screen, I do research, and I hand the client something most of them have never gotten before a project: a written, graded report on where their current site stands. I call it The Refinement Report. Here is why that beats a requirements list, every time.

A requirements list is a record of what you already thought of

A requirements list is useful. It tells me what the owner wants. But that is also its ceiling. It can only hold what the owner already knew to ask for. It is a snapshot of one person's assumptions on one afternoon.

The trouble is that the people who decide whether your website works were not in the room when the list got written. Your customers were not. And they are asking different questions than the ones on the list. The list says "a services page." The customer, standing in a parking lot on their phone, is asking "do these people do the specific thing I need, and can I trust them?" Those are not the same requirement, and only one of them keeps the business fed.

Build straight from the list and you get a site that satisfies the owner and quietly loses the customer. It happens all the time. The site looks like what was asked for, so everyone signs off, and then it underperforms for years and nobody can say why.

What research finds that a list can't

So before any of that, I do the homework. None of it requires talking to your customers directly. The signal is already there if you go looking for it.

• The reviews you already have. People tell you, in public, what they loved and what frustrated them. That is unfiltered research nobody had to go out and commission.
• How people move through your current site. Where they land, where they leave, what they never find. The site is already running an experiment. Most owners have never read the results.
• The questions you get asked over and over. Every repeated question is something your website should have answered and didn't.
• The language of your industry. The exact words customers search, the terms that build trust, and the places where the stakes are highest.

Then I go through your current site the way a rushed customer would, on a phone, and I mark every place it loses work: the jargon with no explanation, the missing trust signals, the dead ends.

The Refinement Report

All of that becomes The Refinement Report: a written, graded scorecard of your current site on the things that decide whether it earns its keep. How clear it is. How it works on a phone, where most of your customers are. How findable you are when someone searches for what you do. How well it turns a visitor into a real inquiry.

You get it back graded by category, with an overall grade, before we design anything. For most owners it is the first time anyone has shown them, in plain terms, exactly where they stand and why.

That is the difference between a requirements list and research. A list is opinions. The Report is facts. I would rather bring you facts before opinions, the way a doctor runs tests before giving a diagnosis instead of guessing from across the room. Those facts also let me make the case for things you might not think to ask for, like colors that clear accessibility standards, or a logo that still reads on a phone screen.

Why it makes the whole project better

Starting with research changes everything downstream.

The plan gets built around your customers, not the loudest opinion in the room. There is no guessing about scope, because we both saw the same evidence before a single line was drawn. And when the site launches, it is doing a job we defined on purpose, not a job we hoped a list would happen to cover.

A requirements list asks "what do you want built?" The Refinement Report answers a better question first: "what do your customers need, and where is the current site letting them down?" Get that right, and the requirements write themselves.