This article is written by Alicja Colon, a UX strategist at GraVoc. She leads UX/UI projects for clients like MIT and Nationwide. With 20+ years in design, she focuses on building digital experiences that feel effortless.
A website needs a job before you redesign it. Once that's defined, the next natural question is what web strategy actually involves and what you get out of it.
From the outside, the deliverables can look deceptively simple. A sitemap is a bunch of boxes. A wireframe is mostly gray rectangles. It's easy to look at the finished product and think, surely that didn't take very long.
Below, our UX Strategist, Alicja Colon, explains the five things that come out of a web strategy phase, what each one is, and what it's actually for.
What is web strategy?
Web strategy is the phase of a website project that happens before design begins. Some people call this discovery, some call it UX strategy. It's where you figure out who the site needs to serve, what those people need to understand, and how that translates into an actual structure like the pages, the sitemap, and the path through them.
In practice, that means stakeholder research, information architecture, a sitemap, and wireframes. The output isn't a design; it's a blueprint that tells design and development what they're building and why.
Below are the five steps that get you there.
Stakeholder conversations
These are structured interviews with the people across your organization who each see a different part of the business and the customer experience.
For me, a lot of web strategy begins with stakeholder conversations. Sometimes that means talking with the same people who attended the project kickoff. Other times, it means speaking with different groups across the organization like people in sales, customer service, leadership, or other areas who each understand a different part of the business and customer experience. Those conversations help fill in the gaps between what an organization thinks its website needs to do and what actually happens in the real world.
Finding patterns
This is the part that’s much harder to put on a project timeline: pattern-finding that turns a stack of interview notes into a direction everyone can agree on.
You start looking for patterns. Where do people agree? Where do their perspectives differ? What keeps coming up? What does the audience really need? Which information matters most, and what can take a back seat?
There usually isn’t a magic sentence in an interview where someone hands you the sitemap. I wish.
The value comes from taking all of those individual pieces and figuring out what they mean together.
Information & content architecture
That research begins informing the information architecture and content architecture. In plain English: what information belongs on the site, how it should be organized, and how someone should move through it.
This is the decision-making layer between "here's everything we could say" and "here's what actually earns a place on the site". It's less visible than design and more consequential than it seems.
The sitemap
From there, the sitemap starts to form, the map of every page on the site and how those pages relate to one another. And this is usually the point where strategy suddenly becomes very real for the client.
Until then, we’ve been talking, asking questions, researching, and moving things around. But once the sitemap and wireframes are in front of them, they can finally see the thinking in black and white.
They can see why one page exists and another doesn’t. They can see what needs to come first, where supporting information belongs, and how someone might move from one part of the website to another.
The website has a blueprint before anyone starts building the walls.
Wireframes
Wireframes are the page-level blueprint — boxes, labels, headlines, and hierarchy, intentionally stripped of visual design so structure is the only thing up for discussion.
I love this stage of a project because there’s nowhere for a weak idea to hide.
There are no beautiful images yet. No fancy animation. No perfect type pairing. It’s mostly boxes, labels, headlines, and hierarchy.
And clients tend to love it too. Because instead of debating whether they like a particular shade of blue, we’re talking about whether the website actually makes sense.
Does this content belong here? Is this the right next step? Are we answering the questions someone will have at this point? Is this page necessary at all?
Those are much easier questions to answer before the site has been fully designed and developed.
Why the blueprint comes first
There’s a reason “measure twice, cut once” has stuck around as advice.
Changing the blueprint is relatively easy. Moving the wall after it’s built is a different conversation.
Web strategy works the same way. Taking time upfront to understand the business, audience, content, and journey can feel slower because everyone is eager to get to the visible parts of the project.
But the goal isn’t to delay design and development. It’s to give those phases better direction.
By the time we start designing, we’re no longer staring at a blank page asking, “What should go here?” We already understand what the page needs to accomplish, what information matters, and how it fits into the larger experience.
That gives design something meaningful to solve and development something much clearer to build.
Strategy isn’t the work you do before you start the website. It’s the work that helps make sure you’re building the right website in the first place.
