Article updated in August 2026
Redesigning a website starts with a conversation. Often, a marketer reaches out to say: “We are redesigning our website. Can you provide a proposal?” or “We are releasing an RFP for the redesign of our website, and we would like you to submit a response.”
Our response to requests like this is, “Yes, absolutely, but let’s have a conversation or two before we do that.”
Why? It all starts with understanding. Not just understanding the immediate pain points, but understanding the bigger picture.
- Do you have a vision for your redesign?
- Do you have objectives for your redesign?
- Is this effort tactical or strategic?
- How are the organization’s digital practices?
- Do we agree on the fundamentals of digital marketing?
- Do we both believe the website is central to those efforts?
- Is there a desire for results beyond a new design?
- How are you going to measure those results?
The question we want you to be able to answer by the end of our conversations:
- Are we the right team for you?
If we’re not right for each other, the best outcome is for both of us to realize this early and move on to a partner better suited for the work.
If it’s a good fit, we both will know it. Our conversations get productive quickly, and it’s through those discussions that we start to shape a clearer picture of what your website can do for your organization. That’s when the excitement really begins.
We’ve written separately about what to expect when you reach out to us, so let’s say we’ve had those conversations and decided to work together.
How We Structure the Work
Every engagement follows the same shape: Understand, Align, Grow. We start by understanding your organization and what the website actually has to accomplish. We align on a plan your team can see, question, and agree to. Then we grow the site through repeated cycles of build, launch, and learn.
A redesign is the first pass through that cycle, not the end of it. We use this approach with healthcare systems, nonprofits, and member organizations, and it holds whether the site is forty pages or four thousand. The sections below walk through what each part looks like in practice.
Organizing for Success
Throughout our sales process, we bring in expert team members to weigh in on the proposed approach for the work. Our team leaders help us put together contracts and statements of work. As we work through contracting, we map out which team best suits the job and when we will begin. You can read about our teams in our blog post on team structure.
Once we are set, we onboard the assigned team with a sales briefing that covers work details, critical points from our conversations to date, the outcomes and vision we’ve captured, and what is included in our agreement. The leadership team assigns an executive sponsor based on who is best suited to help shepherd the process. Team members ask questions, poke holes, and work together to understand as much as possible before anyone starts building.
Team members then do independent research on the site we are redesigning to understand its current state. This is often done through exploratory review of the existing website, a read of the materials provided (marketing assets, brand guidelines, technical specs), search results, and tooling like a site crawler.
This understanding matters, because it lets each discipline anticipate issues we may run into once the work is underway.
- Product Managers may find opportunities to establish calls to action that drive better results.
- UX Designers may notice issues with the navigation or content that needs to serve a clearer function.
- UI Designers may identify problems with how the existing website reflects the brand.
- Developers may find hidden pages or features that must be considered during redesign.
- QA Analysts may see accessibility gaps and opportunities for test automation that will need to be validated.
- Software Engineers may notice infrastructure performance issues that require further investigation.
Once everyone has done their due diligence, the team returns to prepare for discussions with you. This usually happens just before we kick off officially.
Introducing… A Great Relationship!
One of the first things we do is meet with you and your assigned Product Manager to review how we work and what you can expect from us. This conversation covers communication channels, meeting cadence, scope, timeline, and how decisions get made and approved. Knowing who approves what, and how quickly, prevents most of the bottlenecks that slow projects down later.
Alongside that first meeting, we set up the project. That means development environments, design files, shared documentation, and the project management structure the work will run through.
We also share access to the COLAB Resource Center. We use it to document activities and deliverables and to post progress against the work remaining, the timeline, and the budget. It can be shared with anyone on your side who needs visibility. We’ve found that this level of transparency supports a good working relationship and keeps communication clear throughout. Want more? Give us a call or join our Slack and ping us whenever you’d like. The more direct contact we have, the better.
Learning More About The Business
Our next several meetings are with subsets of the team in what we call Discovery. Discovery looks different in every organization. At COLAB, it is a series of conversations led by the project team to understand the outcomes we are working toward. It is the foundation for everything that follows, and it anchors our product strategy work.
We dig into three key areas: the organization and its marketing efforts, brand and design, and technology. Inside those areas, the ground we cover usually includes:
- Business and marketing: the goals the website supports, the audiences it serves, and how success will be measured.
- Content planning: a content inventory and audit to decide what to keep, update, or retire, along with a migration approach that protects existing SEO value.
- Information architecture: sitemap and navigation work so people can find what they came for.
- Brand and UI: a review of your style guide and existing components to align on visual direction and spot where the brand needs room to evolve.
- Administrative experience: how your team publishes today, where that breaks down, and what roles, permissions, and CMS controls they need to work independently.
- Technical discovery: infrastructure, integrations, hosting and security needs, compliance requirements, and platform decisions.
Depending on the engagement, we supplement these conversations with research: stakeholder interviews, user research, personas that define key audience segments, user stories, and maps of how people actually move through your site. We review analytics before we make recommendations, not after.
Often, people say: “Do we really need to do Discovery? We’ve already done a Brand Discovery. Isn’t that enough?”
The answer? Yes, we still need to do Discovery. Ours is focused entirely on what is needed to redesign the website and achieve measurable outcomes. Any research or Discovery artifacts you have already collected are appreciated and always used as input. They rarely cover everything we need to understand to get great results, but when they come close, they speed us up and let us make recommendations sooner.
Discovery generally runs three to four weeks. The main variable is your team’s availability.
Planning for Action
Once we have wrapped up Discovery, the team understands what needs to be built and how we will approach the work. We bring that back to you in three pieces.
- Vision Presentation: we present our recommendations to your stakeholders, validate the information architecture, and agree on what belongs in the initial launch.
- Product Roadmap: a source of truth that outlines the vision, direction, priorities, and progress of the work over time. It documents short, medium, and long-term goals, the milestones between them, and what gets tackled when.
- Strategic Direction Document: the written record of content architecture, user experience decisions, technical requirements, integrations, security protocols, and analytics implementation.
The roadmap is a plan, not a contract with the calendar. Priorities shift as we learn, and the roadmap is built to absorb that without losing the thread.
We do our work in iterations, bringing you in every two weeks to see progress. You always have access to the COLAB Resource Center, but we also want to show you the work itself. An iteration is a short, time-boxed period when a dedicated team completes a fixed amount of work. Iterations break big, complex projects into pieces we can review honestly, and they give everyone room to adapt when something changes.
Once we finalize the Product Roadmap with you, we determine the first priorities and assemble a granular list of deliverables for the first iteration.
Doing the Work
In each iteration, the team focuses on the priorities set in the roadmap or reprioritized after the previous iteration. An iteration can look quite different depending on where we are in a project. Team members may be working independently or collaborating to produce a single deliverable. Most iterations include:
- Product Management: focusing the team on the next set of priorities and connecting them to the larger goals for the site
- UX Design: planning and prototyping against user priorities through analytics, research, and wireframes
- UI Design: extending the design system through component design that serves user needs in a way that is visually considered and true to the brand
- Software Engineering: architecting how data will be structured to support platform longevity and application performance
- Development: bringing designs to life through responsive frontend code, feature development, and CMS creation
- QA: confirming that requirements are met, function consistently, and are accessible
When we complete an iteration, we present the work with demo URLs so you can see what we’ve been building. We discuss any issues we hit during the iteration and any changes we should plan for in the next one. This is usually the point where the project stops feeling abstract for everyone involved.
Internally, the team talks through stumbling blocks and what we could do differently next time. That habit is how we gain traction as the build progresses.
Most redesigns run four to ten months from kickoff to launch. Where a project lands in that range depends on the maturity of the existing site and the operational needs behind it. A site with clean content, a current brand, and one decision-maker moves differently than one carrying fifteen years of accumulated pages, a rebrand in flight, and six departments with a stake in the outcome. Clients often have a specific date in mind, and we can compress or extend the timeline, but we will tell you which trade-offs a compressed schedule forces before you commit to it.
Quality, Accessibility, and Compliance
Quality assurance is part of every iteration, not a phase we save for the end. Finding an accessibility problem in a component the week we build it costs a fraction of finding it in forty templates a month before launch.
Across an engagement, that work covers:
- Accessibility: we build to WCAG 2.1 Level AA, testing components as they are built and validating templates before release
- Cross-browser and device testing: confirming behavior across the browsers and devices your audiences actually use
- Security: applying platform and hosting security practices, and meeting the compliance requirements identified during Discovery
- SEO continuity: preserving rankings through redirect mapping, metadata migration, and technical checks before launch rather than repairs after it
- Performance: measuring page speed and Core Web Vitals during the build, while there is still time to act on what we find
Milestones Along the Way
The roadmap marks key milestones across the iterations. At COLAB, those are:
- Demo Day: a review of work with your stakeholders to gather impressions and feedback
- Alpha and Beta Releases: review URLs shared ahead of launch, first for feedback and then for sign-off. Not every project needs both, and when it does, they can run as separate releases.
- First Public Release: the version of the site that balances what is essential against the ideal future state, and is simple, complete, and something people will actually want to use
- Post-Launch Iterations: continued releases of features and improvements after the First Public Release
Scope, Change, and the Backlog
Something new always comes up mid-project. A stakeholder sees a demo and has a better idea. A department surfaces a requirement nobody mentioned in Discovery. A vendor changes an API.
We handle this by documenting items outside the original scope in a prioritized backlog rather than absorbing them without comment or letting them disappear. When a new request matters more than something already planned, we have a direct conversation about the trade-off: what it displaces, what it costs, and what it does to the launch date. You decide with the full picture in front of you.
The same applies to problems. When we see a risk, a technical constraint, or a decision that is going to create trouble later, we raise it early, even when it complicates the conversation. Surprises during delivery are expensive, and they are almost always avoidable.
🚀 It’s Go Time!
As we wrap up the iteration work, we plan for the First Public Release. Because you have been seeing the work all along, there are no surprises about what is launching. We either manage the launch ourselves or walk through it with the IT staff who will assist.
We work from a detailed set of deployment checklists and prelaunch activities. This ranges from final compliance and accessibility checks to redirect validation, DNS and SSL coordination, analytics verification, and small details like favicons. On larger launches we run a deployment rehearsal first, so launch day is an execution of something we have already done once. Most of this is for our collective mental health, keeping everyone’s anxiety at bay.
The day we launch, we coordinate with you and any technical staff to keep disruption to your audiences and business functions minimal. Once we are live, we run through post-launch checklists and smoke testing, then keep watch over the site through the first days while traffic settles. This also includes celebrating with 🚀, 🍺, and 🙌 emojis in Slack (and sometimes real 🍺 or 🍷 so we can get together IRL).
Handing Over the Keys
A site your team cannot confidently edit is not finished, no matter how well it launched. Training is part of the engagement, not an add-on.
Before and after launch, we run hands-on CMS workshops with the people who will maintain the site, record walkthroughs your team can return to when someone new joins, and write documentation covering the components, content models, and admin workflows built for you. The roles and permissions we defined in Discovery get configured so the right people can publish without waiting on anyone, including us.
Our engagements include a window of immediate post-launch support, typically 30 to 60 days, for the questions that only surface once real people are using the site. The goal is your team’s independence. We would rather you call us because you want to, not because you have to.
Now What?
We’re relationship people. Real business results come from what happens after launch, over time, in partnership. Most of our engagements build in a few months of enhancements and improvements from the start.
This is where the learning part of the cycle does its work. During the iterations we identified “nice to haves” worth revisiting. Now we weigh those against what the analytics show and what users tell us once the site is live. Honest user feedback is the most useful input we get, and it regularly reorders the list we thought we had settled. We work with you to prioritize what will move you toward your objectives, then build the next round.
After the redesign, we typically continue working together in whatever capacity suits your team and your growth plans. We discourage a “launch it and leave it” mentality and generally only take on clients interested in a long-term partnership, because that is where the return is largest. It starts with our very first conversations. What does success look like, and how will we measure it? Then we go achieve it. Read more about how we work with clients over the long term in our blog post on support and maintenance.
What It Adds Up To
We hope this helps explain what it’s like to work with us. The process described here comes from hundreds of launches since 2009. Trust is built through delivery.
In a website redesign, that means:
- Expectation alignment
- Understanding the organization
- Clear vision setting
- Smart planning
- Effective execution
- Quality and accessibility built in along the way
- Excellent communication throughout
- A team equipped to run the site themselves
- Consistent measurement
- And ongoing improvement
Process descriptions only go so far. If you want to see what comes out the other end, our work has the results of these engagements: what the organization needed, what we built, and what changed after launch.
If you’re looking for this from an agency or have questions, call us at (804) 433-3582, email us at [email protected], or contact us via our Contact page.
