We Didn’t Bring Designs to the Pitch

“So where are the designs?”

The question came about ten minutes into a pitch, from someone plainly looking forward to this part of the meeting. But what we didn’t have was the audience, the goals, the analytics or any customer research. They hadn’t given us that information, so instead we’d brought a plan, a set of questions and an outline of what the site needed to achieve. We had not brought a homepage.

A design is the part of a website most people can picture. It’s easy to react to, easy to share with a board, and it makes a project feel real in a way a list of questions never will. Next to a homepage, a plan and a set of questions can look like a team that hasn’t started.

We spent the next half hour explaining the order we work in, and why, with the information available to anybody at that point, a design would have been guesswork. This article is roughly that half hour.

Why would a design have been guesswork?

Because the two things a design exists to serve hadn’t been settled yet: who the site is mainly for, and what it most needs those people to do.

We asked about the audience and the answer was, more or less, everyone. The list ran to existing and prospective customers, partners, job seekers and the occasional journalist, and every one of those groups really does visit. But a homepage can only lead with one thing, and each of those groups wants a different front door. If winning new customers matters most, the homepage opens with the offer and a reason to believe it. Existing customers are better served by having the login, the support pages and the account tools one click away. Partners and investors mostly want to see a track record.

Choosing between them was a business decision nobody had made yet. There’s nothing unusual in that. Most organisations have never had to rank their audiences, because until someone designs a homepage the question doesn’t come up.

The goals were the same story. When we asked what the site had to achieve, we heard more enquiries, a better brand impression, fewer support calls, easier recruiting and a modern look. Five goals, and some of them pull against each other. A page designed to generate enquiries wants a form above the fold and very little else. A page designed to cut support calls wants the answers to common questions front and centre, which is the opposite of what a sales page does.

If we’d drawn a homepage anyway, we would have been choosing the audience and the goal ourselves and presenting the result as design. That’s a lot to settle on a client’s behalf without telling them, and settling it properly is the first piece of work on the project rather than something to improvise in a pitch room.

What does “UX first” actually mean?

UX, short for user experience, is the work of understanding who uses a site, what they came to do and what the business needs from them, then arranging the site so those things line up. Done first, it answers the questions a visual design otherwise answers by accident.

Think about fitting out a shop. Before anyone chooses the timber for the counter or the colour of the awning, somebody works out who walks in, what they’re usually after, where the counter should sit so they reach it without wandering, and what they see from the door. A shopfitter who turned up to the first meeting with a finished colour scheme would be a worry, however nice the colours were.

For a business website, the early UX work tends to produce a handful of plain things:

A ranked list of audiences. First, second and third, rather than everyone at once, with a sentence on what each of them came for.

The primary goal for each. The one action that counts as success for that visitor: an enquiry, a booking, finding the answer without phoning.

A content inventory and a site map. What exists already, what’s missing, what can go, and how the pages are organised. This stage often ends up reorganising a site around what customers are trying to do rather than around how the business is structured, which on its own tends to justify the work.

Wireframes. Simple grey-box layouts of the key pages showing what goes where and in what order, with no colour, imagery or typography to argue about.

Evidence feeds all of it. That can mean a few conversations with real customers, a look at the current site’s analytics and search terms, and time with the people who answer the phones, who can usually tell you the ten questions customers ask most without looking anything up.

What goes wrong when designs come first?

The obvious cost is rework. A design built on a guessed structure gets redrawn when the real structure arrives, and each round of redesign and review is paid for. That part is visible and people budget for some of it.

The less obvious cost is anchoring. Once a room of people has seen a homepage, they tend to fall for it or against it, and either way the conversation from then on is about that picture. When the research later suggests the navigation should be organised around customer types rather than service lines, the answer comes back that it would spoil the design everyone liked. By week four the research is arguing against a picture people have already grown fond of, which it doesn’t always beat.

Then there’s the feedback itself. Ask a group of stakeholders to review a visual design and you’ll get opinions on colour, photography and whether the logo should be bigger. Those opinions are legitimate and mostly unresolvable, because there’s nothing to measure them against. Ask the same group whether a prospective customer can find pricing in two clicks and you get a useful answer quickly. Grey-box wireframes tend to prompt that second kind of question, because there’s no colour to have an opinion about.

So should a pitch never include designs?

It can, when the thinking behind them has already been done. An agency pitching for a brand it has worked with for years, or one that has spent the pitch period on audience research, market insight and a clear strategy, comes in knowing who the work is for and what it needs to achieve. Design built on that groundwork has something to answer to, and showing it is a fair way to demonstrate the thinking. Often the agency is the one bringing those insights to the client in the first place.

The pitch we were in had none of that available. The research hadn’t been commissioned by anyone, the audiences hadn’t been ranked, and the five goals we’d been given pulled against each other. No amount of preparation on our side would have produced those answers inside a pitch window, because they’re answers only the business and its customers can give. Where that’s the starting point, research and UX come first, whoever ends up doing them, because they supply what a design has to be built on.

Early visual direction is a different matter, and often a helpful one. Mood boards, a sense of tone and a couple of reference sites the client admires are all useful, and they’re often what keeps the brand team comfortable in the early weeks. The trouble starts when a fully composed homepage appears before anyone has agreed what it’s for.

Doesn’t this just add time and cost?

It’s a fair suspicion. Sometimes the UX stage really is very short. A business that knows its customers intimately and is building a modest site for one clear purpose may need an afternoon of structured conversation and a site map, not weeks of research. The work should be sized to the decision it supports.

For anything with several audiences, a lot of content or a job to do beyond looking good, the early weeks are where the money is saved. Designers work faster when they know what they’re designing for. Reviews take fewer rounds because there’s something objective to review against. And the site that launches is built around what visitors actually do, which is what decides whether it produces enquiries or just compliments. It’s the same reasoning behind why a short scoping phase lowers the total cost of a project, where a misunderstanding caught in the first fortnight costs a conversation and one caught after launch costs a rebuild.

How did the pitch end?

Instead of a homepage, we walked through how we’d get to one. The questions we’d ask and who we’d ask them of, the order the decisions would be made in, and when the first designs would appear. We also showed what those designs would be judged against once they did: the ranked audiences and the goal for each, written down and agreed before anyone opened a design tool.

By the end of the meeting, people were asking when they’d see designs and how they’d know if the designs were right. That last question is worth asking on any website project, though it can’t be answered until the UX work has been done.

What this means for you

If you’re about to brief a new website, the most useful thing you can prepare is a short written answer to two questions. Who is this site for, in order of importance? And what’s the one thing each of those people should be able to do easily when they arrive?

You don’t need to get it perfect. Rough answers are enough to start with, since the early UX work exists to test and sharpen them. What matters is that the answers exist before the designs do, because every design decision that follows depends on them.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years turning business ideas into software that actually earns its keep. He has sat through more homepage reviews about the size of a logo than he’d care to count, and far fewer about whether customers could find the phone number. Reach out to Simon to talk through what your next site needs to do before it’s designed.