You’ll Never Feel Passed Around: How Spruce Approaches Every Project
The Bait and Switch Pattern
It is week three of a website redesign. A project manager who was never on the original call joins and asks to be caught up. The person who was on that call, the one who nodded along while you explained why the events calendar has to stay, why your development director has veto power over the donate page, why the last redesign went badly, has moved on to the next sale. So you start over. You compress two months of context into eleven minutes. You leave out parts that matter, because you can no longer remember which parts those were.
Then design begins, and a designer joins who was not on that call either. Then development begins, and the designer goes quiet. By launch, a third person is walking you through a site that does most of what you asked for and misses the one thing you cared about most, which you did mention, in week one, to someone who is no longer here.
That sequence is so common it reads as normal. It is also expensive. The Project Management Institute (PMI) has found that poor communication is a contributing factor in 56 percent of failed projects 1. Their research puts roughly $135 million at risk for every $1 billion spent, with about $75 million of that directly traceable to ineffective communication 2. Those losses do not happen because people stop caring. They happen because context bleeds out every time a project changes hands, every time the person who understood your constraints is replaced by someone who has to be caught up.
Spruce’s team structure is built to prevent exactly that: the same people stay with your project from discovery through launch, by design rather than by promise.
Discovery Before Design
Our projects start slowly, on purpose. Before anyone opens a design tool, your project manager, lead designer, and developer work through two questions that are easy to collapse into one: what does your organization need in order to operate more effectively, and what do your users need in order to have a genuinely good experience? Both questions have to be answered. A site that delights visitors is not a success if it forces your communications coordinator into a forty-click workflow. Neither is a technically immaculate build that leaves your donors unable to find what they came for.
Understanding the wider context before committing to solutions is a core principle of discovery, one GOV.UK builds into its service manual 3. That is why Spruce looks closely at both your users and your stakeholders: each perspective reveals something the other cannot. How people actually use your site, and what your team knows about them, show us where the experience breaks down. Stakeholders, meanwhile, hold knowledge about internal processes that no amount of user testing will surface, as the UX research firm Nielsen Norman Group points out 4. Stakeholder interviews are among the most common discovery activities across the industry 5 and they are central to ours.
We review your existing analytics to find out what is actually being used rather than what everyone assumes is being used. We build personas and journey maps, and rethink your sitemap with fresh eyes. At Spruce, personas serve as a shared reference point, a way of keeping your team and ours oriented around the same picture of who we are building for, so that both sides can make decisions against a common understanding rather than diverging assumptions. UX researchers have raised methodological cautions about treating personas as empirically grounded instruments 6, and we take that critique seriously, which is why we treat personas as an alignment tool, not proof. Regular check-ins run throughout, so you always know what the team has learned and whether your input landed.
Developers Join Design Early
A mockup cannot show what a form feels like on the fourth field. Only using the real thing can.
When design begins, our developers are already in the room. They attend the weekly design meetings from the start, weeks before there is anything to build.
Most agencies work the other way. Design is completed, approved, packaged, and handed to a development team encountering it for the first time. That handoff is where projects quietly acquire their most expensive problems. Technical literature from the National Aeronautics and Space Administration (NASA) notes that fixing a software problem after delivery can cost upwards of 100 times more than catching it during early design 7, 8. The exact multiplier has been debated for decades, but nobody argues the curve slopes the other way.
The friction itself is well documented. A 2022 study found that despite years of tooling built to smooth design handoffs, designer-developer collaboration remains brittle, particularly as code implementations begin to diverge from the graphical designs they were built from 9. The Institute of Electrical and Electronics Engineers (IEEE) makes the corresponding recommendation plainly in its software engineering body of knowledge: early involvement of implementation teams in design decisions reduces rework and improves outcomes 10.
In practice, a developer can flag problems early in design that would cost weeks to fix later. They might identify an interaction pattern that will be brittle across browsers. They might also flag a content migration that will not survive the proposed content model, or a component that looks exactly as intended in a static mockup and falls apart on a phone. Those conversations cost an hour while design is still fluid. They cost weeks after development starts. By the time our design phase wraps up, with user interface (UI) components, responsive mockups, and an interactive prototype ready, our developers are not receiving the work. They helped shape it.
Designers Stay Through QA
Most design engagements end when the mockups are approved. Ours do not. Our designers stay involved through quality assurance (QA), reviewing the built product against the design intent and advising on usability problems that only become visible when something is real and clickable.
A mockup cannot tell you that a form feels tedious on the fourth field, that a hover state which reads as elegant in Figma is undiscoverable on a touchscreen, or that a page balanced at one content length collapses at another. Those are things you find by using the thing.
The broader evidence supports keeping cross-functional collaboration alive through delivery. A systematic review of 74 studies identified shared mental models and psychological safety as key factors behind high-performing teams 11. When a designer hands off mockups and disappears, that shared mental model, the accumulated understanding of why a component works the way it does, what edge cases were considered, which tradeoffs were made deliberately, cannot be transferred through a handoff document. It is built by people working alongside each other over time, and it is what walks out the door when the designer leaves before the work is done.
There is also a compliance dimension worth naming. The Web Content Accessibility Guidelines (WCAG), maintained by the World Wide Web Consortium (W3C), define the recognized international standard for accessible digital experiences, covering everything from color contrast and keyboard navigation to screen reader compatibility 12. Requirements like these rarely get violated deliberately. They slip because a focus state got dropped during implementation, a heading hierarchy got flattened, or a contrast decision made sense in one context and not the one that shipped. A developer can implement every technical requirement to the letter and still ship something that fails a real user, because meeting the standard often depends on judgment calls about reading order, label clarity, and interaction flow that belong to design, not to code. That is why accessibility needs a designer in the room through QA, not just a checklist at the end.
One Person, Full Context
Through every phase above, one person has been with you since the first call: your project manager. Not a rotating cast of account leads. One person who knows the decisions made in month two and why, which of your stakeholders needs advance notice before a meeting, and what your last redesign got wrong.
That continuity is not just a nice thing to offer. It keeps your project from quietly falling apart. The U.S. Digital Service made a version of this a formal principle, instructing teams to assign one leader and hold that person accountable 13. When the person managing your work changes mid-project, the new person does not just need a briefing; they need to rebuild a working picture of your organization, your politics, and your priorities. Some of that lives in documents. Most of it does not.
One point of contact does not mean one person’s expertise. Your project manager’s job includes knowing when to bring in someone else, whether that is deeper user research, accessibility review, or guidance on artificial intelligence (AI) implementation, and doing it without making you re-explain your project. You stay in one conversation. The right specialists join it when needed, briefed by someone who already has your history.
Launch as a Transition
Launch is not a finish line. It is the moment a team makes sure its client can actually run what was built.
Launch day is not a finish line. It is the point at which your project stops being built and starts being used, and a surprising amount of digital work degrades in exactly that window.
For mission-driven organizations, the risk is sharper. Many nonprofits run their digital infrastructure with limited dedicated technical staff 14. When an agency disappears at launch, your site does not break dramatically. Instead, it tends to erode gradually. Content models get misused because nobody remembered what they were for. Components get worked around rather than used. A year later your site no longer resembles the thing that was designed, and no single decision caused it.
So we treat the end of a project as a transition from building to supporting. We make sure your team feels capable of running what we built together, rather than merely having received it. We stay available for the questions that arrive in the first weeks of real use, when the distance between documentation and daily reality becomes obvious. The goal is not dependency. The goal is that you actually own what you paid for.
What Continuity Actually Buys
Discovery before design, developers in design meetings, designers in QA, one project manager throughout, support after launch: these are not five separate policies. They are one commitment applied at five moments in your project’s life. Your context is valuable, and it should be held carefully by the people doing your work rather than reconstructed each time a new face appears on the call.
GOV.UK‘s Service Manual keeps the same team through every phase of a program for this reason 15: it preserves the context and relationships that handoffs lose. When the people who made a decision in month two are still present in month six, nothing has to be reconstructed from notes. And because those relationships are already in place, problems surface early, when they are still cheap to fix.
The alternative to a process like this is not a different process. It is the absence of one. That absence produces the question this article opened with, asked in week three by a project manager who genuinely was not there for the original call.
What you get when you work with us is not a set of deliverables. It is a team that remembers what was said in week one and is still acting on it in week twenty: not the tools, not the templates, but the people, and the fact that they stay.
Spruce DX is the digital experience division of Spruce Technology, helping organizations design and build accessible, human-centered digital products.
