Write User Needs Before You Draw Wireframes

Many service-website projects open in a layout tool. Boxes for a hero, a services grid, and a contact form appear before anyone has written down what a visitor is trying to finish—compare options, check whether a firm is a fit, or send a careful inquiry. That order feels efficient. It often produces polished pages that still leave the real job unfinished.

GOV.UK’s Service Manual states the constraint plainly: if you do not understand who will use a service or what they need from it, you cannot build the right thing. Intercom’s long-running guidance on job stories makes a complementary point for product and interface teams: features and UI should resolve a situated job—causality, anxieties, and motivations—rather than decorate a persona or a wireframe assumption.

---

Why wireframes first invent the wrong problem

A wireframe is a proposal about structure. Without a written need, that proposal quietly becomes a guess about what visitors must do. GOV.UK’s discovery guidance is explicit about sequence: find out who likely users are, what they are trying to do, how they do it today, what frustrates them, and what they need from the service to reach their goal—before you start planning, designing, or building.

When that step is skipped, service sites typically show three failure modes:

1. Solution-shaped “needs.” Copy and layout assume visitors “need a carousel,” “need an About tab,” or “need a chat widget,” instead of needing a clear next step after understanding the offer.
2. Internal org charts on the homepage. Sections mirror departments rather than the visitor’s sequence: understand → trust → inquire.
3. Mid-project redesigns. Real inquiry language from emails and calls arrives after components are already approved, and the structure has nowhere to put it.

GOV.UK’s discovery overview also warns against starting from a pre-defined solution. Their reframing example is useful for private service firms too: the problem is not “we need an interactive map of contact centres”; it is closer to “how can people find the nearest place to book a face-to-face appointment?” Replace “contact centre” with “consultation” or “site visit,” and the same discipline applies.

---

What a user need is—and what it is not

In the Service Manual, user needs are the needs a person has of a service so they can get the right outcome. Needs are written from a personal perspective, in language users would recognize, and they focus on the user’s problem rather than a preferred channel. GOV.UK’s validation checks are practical:

Good need	Weak need
Sounds like something a real user might say	Sounds like an internal roadmap item
Based on research evidence, not assumption	Based on stakeholder preference alone
Names the problem (a reminder, a clear price range, a trusted contact path)	Names a solution (an email, a PDF, a chatbot)

Their recommended shape is simple:

I need/want/expect to… [what]
So that… [why]

Optional additions—As a…, When…, Because…—add triggers and constraints without locking the design to a specific component.

A short analogy: a user need is a job ticket pinned to the wall before anyone shops for tools. The ticket names the outcome. It does not specify which brand of wrench to buy.

Intercom’s job-story practice (Alan Klement’s guest post, building on Paul Adams’s earlier framing on the Intercom blog) pushes one step further for interface decisions. Instead of “As a user, I can…,” a job story investigates situation, motivation, and anxiety—then the team designs UI that resolves that job. For a service website, the high-level job might be “hire a firm I can trust for this project”; smaller jobs include comparing scope, checking fit, and sending an inquiry without guessing which form field matters.

---

How to gather needs before the first frame

You do not need a government-scale research program. You do need evidence that outranks opinion. GOV.UK lists methods that transfer cleanly to a studio discovery:

• Review existing evidence: analytics, search queries, call logs, lost-deal notes, previous research.
• Interview or observe actual or likely clients.
• Talk to people who support those clients—reception, sales, project managers—while treating non-user opinions as assumptions to test.

Treat the output as a short, shared list—not a novel. Focus on the needs that decide whether an inquiry happens. Share them as experience maps or concise user profiles so stakeholders can challenge gaps before layout begins. The Service Manual also links needs to later user stories: needs stay high-level and relatively stable; stories become the specific features and content chunks that meet them, with traceability back to the need.

For wireframe timing, Intercom’s sequence is a useful studio checklist:

1. Name the high-level job the website must help finish.
2. Break out smaller jobs on the critical path to an inquiry or booking.
3. Note how people solve those jobs today (phone, email, competitor sites, referrals).
4. Write job stories that capture situation, anxiety, and motivation.
5. Only then propose structure and UI that resolve those stories.

---

Limits and tradeoffs

Discovery has a cost. GOV.UK notes that discovery length should follow the problem—often on the order of weeks for unfamiliar public services—and that stopping after discovery is a valid outcome when research shows building is not worthwhile. A private service firm rarely needs eight weeks; it does need enough evidence that homepage sections and service pages are answering real jobs.

Job stories are not a replacement for accessibility research, content inventory, or technical constraints. They also do not excuse skipping evaluation later: GOV.UK expects continued research in alpha, beta, and live phases so the service still meets needs as designs harden. Finally, needs written only from founder intuition fail the Service Manual’s evidence test—even when the prose format looks correct.

---

Practical takeaways for your next website

1. Hold the wireframe. Do not open the layout file until five to ten evidence-based needs (or job stories) are written and shared.
2. Use the GOV.UK shape. “I need… so that…”—problem-focused, in the visitor’s words, tied to a source (interview, call log, analytics pattern).
3. Separate need from component. “Need a clear way to ask about timeline” is a need; “Need a chatbot” is a solution guess.
4. Trace pages back to jobs. Each major section on Home and Services should map to at least one written need; cut or rewrite sections that map to none.
5. Revisit after draft content. When real copy arrives, check whether the needs still hold—and adjust structure before polishing visuals.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape discovery so wireframes answer real visitor jobs—not internal assumptions.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].