What is SPARC and why is it the critical first step to a successful product design project?
Over the years, our approach to client partnerships has evolved. Today, our favorite projects are those where we are truly embedded into our clients’ organization, working closely and collaboratively with leadership teams, designers, developers, and other internal stakeholders.
In the early days of Neuron we tended to work on a lot of fixed-price engagements, a concept that is second nature with traditional media agencies. But this is not the way UX works. Every high performing digital product company relishes in agile methodologies which essentially means: nothing is fixed and we will pivot the roadmap if need be. Given this mindset, we have since come to learn that fixed-pricing just does not work for us, nor our clients.
Even for organizations not using agile, fixed-pricing should be avoided. The reason why is that inevitably one party wins and the other loses; The common practice for agencies is to pad or over-inflate estimates, providing a layer of protection should things go awry.
In the past we would spend hours combing through PRDs, reading through executive summaries, analyzing OKRs, counting screens, and looking at comps. And then it would come time to “pad”: overestimate, multiply it by the hourly rate, and send over a fixed fee — This was common practice and disingenuous.
Okay, so fixed pricing does not work, but everyone wants some sense of what an item costs, and here is where discovery plays a role. With software there are always an unknown lurking in the shadows; priorities change, and every organization is different. How teams work, collaborate, and make decisions can all impact timeline, and that is something we can reliably predict and define by conducting discovery.
What actually happens during discovery?
Well, discovery is not just paying us to learn more about your company (although we have heard that before). This is about going deep; client teams have boundless information that vendors simply cannot access, especially at the beginning of an engagement. Going deep means conducting workshops and interviews to extract the tacit knowledge of your organization and its users. The output serves as an invaluable north star for the project; articulating vision, objectives, and requirements for both the business and its users.
From there we get into strategy, inclusive of feature definition, prioritization, cardsorting, poker planning, and ultimately building out a design roadmap. By getting developers involved early we can ensure feasibility and are better able to assign realistic estimates to each feature. It is at this stage that we can say (finally!) with confidence how long a project should take. By this point our team also has a sense of how the client works because we will have gained great insight into how quickly they turnaround requests, get things approved, and formulate a consensus.
“We’re tight on time, can we condense discovery?”
Typically, discovery takes about 3–6 weeks depending on the product complexity, desired outputs, and the timeline or budget constraints. Some clients ask if we can skip or condense discovery in the interest of meeting a timeline constraint. The answer is yes, sort of… For projects like this it tends to be the case that discovery is done in somewhat of a piecemeal fashion. It tends to be a less efficient design process as a result because the strategy work is being completed as we push pixels. This approach makes it possible to meet tight timelines, but it can end up costing more in the long run as there is likely to be some rework when discovery and strategy are not holistic conducted.
Projects are successful when we scope with our clients.
This is also why we do not respond to RFP’s, RFI’s, or even the mythical RFQ. Often, they articulate in great detail what the outputs of the engagement should be, but do not actually account for the outcomes or the process. There is often too little insight into what it is like to work with a team and how that will shape both effort and duration. Additionally, RFP’s tend to ask for a solution and the “Neuron process”. Our position is that the solution cannot be known without discovery. In fact, we feel that this is entirely at odds with the desire for a strategic design partner. While it is important to gain an understanding of whether a vendor understands your problem and is qualified to design the solution, an experienced design vendor will want to dedicate a significant amount of time into understanding your business, UX model, culture, the larger context your product fits into, and the work that has been done to date. Effective UX design is far more than applying a set of best practices or principles to an existing product. Every product and team is unique — the approach should reflect that. This is why we are adamant about starting every engagement with what we call a SPARC phase.
SPARC
/spärk/
Strategic Planning, Audit, and Research Compilation
Neuron is not Toptal, you are not hiring us to simply take orders and deliver a reskin. Rather we want to consider the larger context of a digital product and its business model. The interface is merely a touchpoint. It will be beautiful (and accessible) of course, but it exists to do far more.
During SPARC we will be able to ask:
What are users saying?
What can we learn from the analytics?
Where is there friction or a perceived decline of value from a product?
Why is there churn or when is the drop-off happening?
Where do we struggle to compete with other products?
Discovery uncovers the interdependencies.
Even where teams have already done the work of scoping their project, they are inevitably under-scoped. Some teams approach us with a list of known pain points and feature requests, and this is a great start. Some even come with a detailed PRD and developer estimates; Typically the result of known design debt or user feedback and support tickets.
There are (however) always interdependencies between features, which can be significant, but there may also be interdependencies between the features and plugins, associated hardware, and more. All this can be impossible to scope without being intimately familiar with the product. Other commonly overlooked items include different user types (e.g first time user vs experienced user), empty or error states, and account management functionality.
Often, clients will ask us: how long will it take to design a feature… In turn, we seek to uncover:
How does this feature fit in with the others?
How do people get to this feature?
How do they get out of this feature?
Where do they go next?
Often, these kinds of interdependencies are not articulated or documented before discovery.
Priorities change.
For us, collaboration means keeping clients in the loop on how time is being spent and which options are being explored, while giving them many opportunities to provide feedback. The drama of a big reveal (think: Mad Men) can be exciting, but also can derail a project. This is why we trade surprises for transparency. By keeping communication open, it ensures that as we are iterating on design clients keep us informed of what’s happening within their organization. At minimum, we look to connect with clients weekly for an update outside of working sessions, while also using asynchronous messaging tools like Slack or Teams for ad hoc communication.
Open communication makes us better positioned to respond to changing priorities. When working on fixed fee projects, it is not as easy to pivot. However, working in an agile and collaborative fashion means we can reevaluate priorities and are set up to welcome changing requirements with things like adding a mandatory buffer time to each sprint.
Big decisions tend to require high-level stakeholders. And as stakeholders are engaged, inevitably new priorities emerge. Other times competitors launch something new requiring a quick product response. The magic of agile design is that as new features or solutions are launched there is an intentional funnel for receiving feedback from users, stakeholders, and from the designers themselves. In this dynamic reality it is clear that the effort of scoping and estimating a fixed fee project is wasted because it must ultimately be reworked to account for additional scope and change requests down the line.
Starting with discovery sets teams up to first identify the correct priorities and break a project down into sprints. By working on a time and materials basis instead of via a fixed fee, the engagement is structured in a way that maximizes design over legalese. It is not possible to predict how many revisions a team will want or what will happen in the market. It is easy to see however that change requests and rescoping will eat up valuable design time with project management and amended statements of work.
Choosing the right design partner.
The value of a discovery-first approach is easy to articulate.
Teams fixate on their desire for a fixed fee estimate before committing to a vendor.
Part of this fixation is wanting to simplify the process of comparing proposals while part of it is wanting to limit risk and guarantee the desired outputs. However, a great vendor will be able to articulate the outputs of different project phases, work within a cap, and show comparable case studies.
When considering a discovery first engagement, we recommend the following:
Ask to have your desired outputs for discovery (SPARC) listed in your statement of work.
Request references to past and present clients that are engaged in this way.
Get a video walkthrough of similar products and projects to get a sense of output relative to cost, effort, and duration.
Be clear about how your team likes to work and what the known milestones and desired deliverables are.
⚠️Avoid vendors that claim to know the solution without having done a deep dive on the problem.
Neuron is an UX/UI agency based in San Francisco, California. Our team helps B2B product companies solve complex problems with compelling designs (and most importantly Discovery).
Are you about to embark on an exciting UX/UI project?
Learn more about how we work at Neuron.