Before committing to a redesign, most teams need to answer the same hard questions: Who is the site really for? What does success look like? What should happen first?
A UX Foundation Workshop is a structured process for organizations that know they need a new website — or a significant overhaul — but haven't yet aligned on who the site is really for, what it needs to accomplish, or what should happen first.
That lack of alignment is more common than it sounds. Most organizations arrive at a web project with strong opinions about what the new site should include, but without a shared definition of success or a clear understanding of what's driving the problems with the current one. Surfacing those differences before design and development begin produces better projects — and avoids the expensive corrections that happen when foundational decisions get made under deadline pressure.
When you need a UX Foundation Workshop.
You have stakeholders with competing priorities. Different departments want different things from the site, and nobody has officially reconciled those priorities. A redesign that starts without resolving this will inherit the conflict.
You're not sure your current site's problems are what you think they are. It's easy to assume the site looks dated when the real issue is navigation, or to attribute low conversions to design when the actual problem is content. A structured evaluation through a user lens often surfaces surprises.
You're about to start a large project and want to get the foundation right. A UX Foundation Workshop is often the right first phase of a major redesign or platform migration — establishing shared goals and a prioritized roadmap before significant investment is committed.
You've had a redesign go sideways before. Projects that skip stakeholder alignment and audience research often end up rebuilding what they already had with a new coat of paint. The workshop is designed to prevent that pattern.
What's involved in a UX Foundation Workshop.
Stakeholder alignment sessions — Facilitated sessions that surface competing priorities and give the project team a shared understanding of what success looks like. The goal isn't consensus for its own sake — it's clarity about which priorities drive decisions when trade-offs come up later.
Audience research and archetype validation — Who actually uses the site, and what do they need from it? This work involves reviewing existing research, conducting or synthesizing user interviews, and developing audience archetypes that represent the real diversity of site visitors — not just the most vocal internal stakeholders.
Current site audit through a user lens — An evaluation of whether the current site helps users accomplish what they came to do, and where it fails them. This is less a design critique and more a functional assessment of what's working and what isn't.
Feature and functionality mapping — A prioritized inventory of what the new site needs to include, grounded in audience needs rather than internal wish lists. This is where competing feature requests get resolved with actual evidence.
Phased roadmap with clear decision points — Not everything can happen at once, and pretending otherwise leads to scope creep and blown timelines. The roadmap sequences work in a way that delivers value early and creates clear checkpoints for re-evaluating priorities.
Success metrics definition — How will you know if the new site is actually better? This step defines specific, trackable metrics tied to the outcomes the project is meant to produce — so that "success" means something measurable, not just "everyone likes how it looks."
What you get.
Stakeholder alignment documentation, audience archetypes, a current site evaluation, a prioritized feature and functionality map, a phased roadmap with decision points, and a success metrics framework. Together, these give the project team a shared foundation that carries through design, development, and launch.
What comes after.
The roadmap produced here typically points in one of a few directions: a platform selection process if the right CMS hasn't been determined yet, or a full design and discovery phase that builds directly on the research and prioritization. The work doesn't sit on a shelf — it becomes the brief that guides what comes next.