Most web projects are defined by their deliverables. We think the real value lives in the process — the conversations, the alignment, and the thinking that happens before anyone opens a design file.
The ongoing joke in the web strategy world is that practitioners — content strategists, information architects, user experience — aren’t writers and editors and designers and testers as much as they’re therapists. While we often think of design and strategy as phases or stages in a large process, both are actually deeply ingrained in the very fabric of every organization. The decisions we make about design, content, and our place on the internet reflects both the brand and direction of a company as well as the relationships and hierarchy within that company.
This is apt. The practice of personal therapy is one of ongoing work; of degrees and progress, of small steps and large breakthroughs. You go to a therapist to be heard, and you go to a therapist to uncover complexities. You go to a therapist for the time you spend with the therapist.
You don’t go to the therapist for their notes. You don’t go to the therapist for a thing. The process is the point. The process is the work.
Looking for a definition for “strategy.”
We get asked to help people a lot, which means we spend a lot of time writing proposals and explaining what we do. When we scope a web project, there’s a natural pressure to define everything in terms of what you’ll receive. A site map. Wireframes. A design system. A working website. These are tangible things — artifacts you can point to, review, and approve. They justify the investment because you can see them and hold them.
But when it comes to discovery and strategy work — the research, the interviews, the workshops, the long conversations about how your organization actually communicates — the “deliverable” gets harder to pin down.
You might see a summary document — a topline debrief, or a slide deck; there always seems to be a document at the end — or it might be something more concrete, like a set of project archetypes or a strategy brief. But, if you forgive the candidness, the document is not really the point. The document is not what a client is paying for, and it’s not what we’re being paid to do.
The process is the point. The thinking, the discussion, the alignment that happens between people in a room — that’s where the value lives. The document is just proof that it happened.
What discovery work actually produces.
We get it. When you’re building a budget or getting internal approval for a project, you need to show what you’re paying for. A line item that says “strategic discovery” is a tougher sell than one that says “twelve wireframes and a site map.” Proposals need to be specific about deliverables, and rightfully so — no one should sign off on a vague promise.
But there’s a gap between what a proposal can describe and what actually creates value during a project. The proposal says you’ll receive a topline debrief of stakeholder interviews. What it can’t fully capture is the moment during those interviews when three different department heads describe the same problem in three different ways — and the conversation that follows, where your team starts seeing the real shape of the challenge for the first time.
So we wanted to put a name to this — to make the process itself visible, so it’s easier to see where the thinking happens and why each step matters.
Blend’s proven strategy process.
Our strategic process follows four phases, each one building on the last. If the shape feels familiar, it should — it’s inspired by the UK Design Council’s “Double Diamond” methodology, in which strategic thinking goes through two rounds of expansion and contraction: discovery and definition, development and delivery. Activities do one of two things: they gather information, or they synthesize it — they ask questions, or they find answers.
We call this Blend’s proven strategy process, but it’s really the core backbone to any organization’s strategic process.
Phase 1: Understand.
What’s happening now, and why does it matter?
This is where the design team grounds itself in your reality: your goals, your audience, your current state, and your constraints. Rather than jumping into recommendations, the Understand phase is for listening and learning, and includes things like kickoff meetings and discovery workshops, stakeholder and audience interviews, content inventories, competitor analysis, and accessibility and performance auditing.
The work here is mostly about asking the right questions and resisting the urge to answer them too quickly, and the documentation is largely secretarial: capturing insights and confirming a shared understanding.
Phase 2: Focus.
What does “better” look like for this organization?
This is where research turns into direction. Your design team synthesizes findings from the Understand phase to establish a strategic foundation — who the audience is, what the content needs to do, how the organization needs to operate, and where the biggest opportunities are. This might involve defining audience archetypes, providing user experience guidance, consulting on governance and team readiness, evaluating digital platforms, or shaping a content strategy.
Focus is where the shared understanding starts to solidify, and learning turns into ideation and a roadmap. In fact, this stage is what makes the idea of documentation hard: the design team doesn’t actually know what an organization needs until they’ve gone through this focus, and the tasks outlined in the Architect phase may adjust based on findings here.
Phase 3: Architect.
How should everything be organized and connected?
This is where strategy becomes tangible. Your design team starts making — building the frameworks and outlining the architectures that shape how content and experiences will actually work. Before anyone starts writing, designing, or building, this architecture provides a purposefully restricted canvas. Design depends on restraint, and so creating guidelines helps expand the possibilities for the site. You can expect site maps, content models, taxonomies, wireframes, prototype testing, copy decks, and migration planning in this phase.
By this point, the process has done its heaviest lifting. The documents that come out of this phase — the site maps, the wireframes — feel like natural extensions of conversations the team has already had, rather than assumptions pulled from thin air.
Phase 4: Shape.
What does it look and sound like?
This is where the strategic work becomes visible — through design, content, and brand expression. Copywriting, design audits, design system creation, mockups, and web brand standards all happen here. Everything in this phase is informed by the decisions made in the phases before it.
That’s really the key to the entire process: each phase feeds the next, and the documents and artifacts that emerge along the way reflect that journey and the thinking that’s already been done.
Why the people matter most.
Strategy work isn’t a solo exercise, and it’s not a speed run — this isn’t a thing where someone disappears into and returns from with a finished report. It’s collaborative by nature. It depends on your team showing up, sharing what they know, and being willing to work through the hard parts together. The quality of the process depends directly on the quality of the participation.
We know this — we know that quality begets quality — because we’ve been around the block quite a few times. We’ve seen what happens when organizations treat discovery as a box to check — when the interviews are rushed, the workshops are skipped, and the strategy document is assembled from assumptions instead of evidence. We can still make something great, because we bring this kind of thinking into every stage of the process, but without that shared understanding at the start the “something great” becomes a lot messier to get to.
Simply put, when teams commit to the process — when they bring the right people to the table and trust that the conversations are doing real work, even when there’s nothing to “show” yet — the rest of the project tends to go more smoothly. Decisions are faster. Revisions are fewer. The final product reflects what the organization actually needs, because the team figured that out together long before a line of code was written.
The best projects start with good process.
It’s tempting to skip ahead. To jump to the wireframes or the design because those feel like progress. But the projects that go the smoothest — the projects that tend to produce the best results — are the ones where the team invested in the messy, unglamorous work of figuring things out together first.
By understanding the problem. By focusing on what matters and what can change. By architecting the details, and by shaping the solution. There are documents in there! But more than anything, there are people, providing valuable insight and making connections that no single Google Doc could even dream of. That’s the deliverable, and everything else is simply a record of the work.