Product Design vs Google Design Sprint: Which to Fund?

Design

Run the Product Design Process when the problem is not yet defined and the product is being built or re-thought from scratch. Run a Google Design Sprint when the problem is already known and you need a decision inside a week. That is the whole answer, and it is the difference between drawing up plans for a house and remodelling a room in one that already stands. Both are design work. Only one tells you where the load-bearing walls are.

This article compares our Product Design Process, which puts user and market research before anything is built, against the Google Design Sprint, a five-day method for accelerating a decision. It is written for the CTO, product owner or founder deciding which of the two to fund before design work starts.

Product Design Process vs Google Design Sprint at a glance

	Product Design Process (PDP)	Google Design Sprint (GDS)
Duration	Weeks, across four phases and twelve design steps	Four to five days, one phase per day
Team involved	Product design team, with the client's business and technical stakeholders at defined points	The whole cross-functional team in one room, plus a named decider
Starting point	The problem is not yet defined	The problem is known and the team has lived with it
Output	Research, wireframes, style guide, GUI design, prototype, high-level architecture and project plan	One high-fidelity prototype, tested with end users
Best fit	A product built from scratch, or an existing one being completely re-thought	An existing product being improved, feature by feature
Main risk	Time spent on research before anything is visible	Prototyping on assumptions that were never validated
Commercial argument	Realistic schedules and fewer redesigns later	A decision reached in a week instead of a quarter

The rest of this article explains each process, then works through the differences and when each one pays off.

The Twelve Steps to create a successful digital product

Where this comparison comes from

We did not arrive at this from theory. Back in 2014 we ran a service called The War Room: a product owner, a designer and a development team in one room for three days to deliver a Minimum Viable Product. It was, in spirit, a sprint. The results were a mixed bag. We shipped a few products, and they failed on first contact with the market. The Lean Startup and the Google Design Sprint were on everyone's bookshelf, but on their own they were not making the cut for the work we were doing.

The lesson we took from those failures was specific: a digital product being built from nothing needs real research before anyone prototypes, and at the time no documented process chained that research to delivery. So we built one. That is the Product Design Process, and the comparison in this article is the one we have been making, project by project, ever since. We still run sprint-style work. We just know now which problem each is for.

To find out more about how we apply our product design process to our projects, visit our portfolio!

What is Product Design?

The Interaction Design Foundation defines product design as the process designers use to blend user needs with business goals so brands can make consistently successful products.

Product design graphic showing business goals versus user experience process steps like research and prototyping.

Take Uber. The problem is the need for convenient, fast transport on demand, and Uber solves it with an app where the user taps a button to request a driver. That solution is then combined with business goals, such as pricing models that hit sustainable revenue based on supply and demand.

So a product designer builds the bridge. On one side, how the product meets users' needs by ensuring a great user experience. On the other, what the business needs it to earn.

What it costs to skip product design

Here is the thing about skipping design: you do not remove the design decisions. You move them into the build, where they get made by whoever is writing that screen, on the day, with no research to check them against. Three things follow, and all three cost money.

The first is rework. A screen built on an assumption nobody tested gets rebuilt once the assumption fails, and by then it has dependencies hanging off it.

The second is estimation. A team that has not seen the full set of screens, states and integrations before it estimates is estimating a product it has not been shown, so the schedule slips for reasons nobody could name in advance.

The third is coherence. Features designed one at a time, in the order they were requested, produce a product that works but does not hold together, and every later addition has to accommodate the inconsistency rather than the pattern. Back to the house: rooms added one by one, each to a different plan.

None of that arrives labelled as a design problem. It arrives as a delivery problem, a budget problem, and a support queue. The cost is not hypothetical: the Consortium for Information and Software Quality puts the cost of poor software quality in the US at roughly 2.41 trillion dollars a year, with accumulated technical debt, the price of reworking suboptimal software, at about 1.52 trillion dollars. More on those figures later, because the pattern behind them is the whole argument.

What is the Product Design Process?

As we cover in our post on the twelve steps to create a successful product, the Product Design Process (PDP) is a multi-disciplinary, user-centred process created by Imaginary Cloud. It chains together existing techniques, matured over time by the industry, to keep the design team's workflow as efficient as possible.

The PDP has four phases, research, ideation, execution and technical assessment, split into twelve steps. Each step produces something the next one needs. That is what makes it design by process rather than by opinion: the order is not a preference, it is a dependency chain.

Product design process diagram including research, ideation, execution, and technical assessment phases.

Research. The goal is to ensure no decision rests on a vague assumption, and to identify the core of the business model and user needs. Three steps: the briefing, an agreed statement of what the product is for, who it serves and what success looks like; user research, interviews and data on the actual users that produce the needs the design has to answer; and a design benchmark, a review of how comparable products solve the same problems, and where they fail.

Ideation. The goal is to formulate the product concept from the user's needs and the business model. Four steps: the user journey, the end-to-end path a user takes through the product before any screen exists; a decision matrix, a scored comparison of directions that picks one on stated criteria rather than on the loudest opinion; wireframes, low-fidelity layouts that fix structure and hierarchy before any visual design; and a mood board, a reference collection that agrees the visual direction before a screen is designed.

Execution. The goal is to create a physical representation of the concept defined so far. Three steps: the style guide, the components, type, colour and spacing rules every screen is built from; the Graphic User Interface (GUI) design, the finished screens drawn against the style guide; and the prototype, the screens linked into something a user can click through and be tested on.

Technical assessment. The goal is to guarantee that every requirement and idea is realistic to implement. Two steps: the high-level architecture, the systems, services and integrations the design implies, mapped before estimation; and the project plan, the sequence, effort and dependencies for building it, estimated against a design that already exists.

Flowchart outlining a product design process with stages like user research, wireframes, and prototyping.

Read also: Design Research: impacting the human experience, and, if a first shippable version is your real question, the different types of MVP.

The Product Design Process in practice: FundSpace

Theory is cheap, so here is the process on a real product. FundSpace is a financing platform that unlocks capital for SMEs, and it came to us as an undefined problem: build a web portal that reports fund performance clearly to two very different audiences, the fund managers who create funds and the investors who read the reports.

That is precisely the case for the full process, not a sprint. The hard part was not a screen; it was a data structure that had to model funds, funds of funds, and funds of funds with several share classes. We started by building a technical prototype to prove such a datastore was even possible, then ran the four PDP phases over the top of it to align the interface with the brand and the two audiences. The build used Ruby on Rails, React and Node.js, delivered by a dedicated team of product-oriented designers, front-end developers and a project manager.

The number that matters: the redesigned interface enabled a 10x faster decision-making process for both fund managers and investors. The platform earned a 5.0 client rating, the product was selected for 500 Global's 917Ventures Accelerator programme in 2023, and the work saw Imaginary Cloud recognised as a Top Financial App Developer by Techreviewer. A sprint could have tested one screen of that in a week. It could not have found the data model the whole product stands on. You can see the FundSpace case study in full, along with comparable PDP builds for Pulsar Helium and NotaryCam.

UX/UI design tips e-book offer for website conversion with desktop, mobile, and magnifying glass icons.

Create engaging and highly tailored interfaces with our Product Design Process

What is a Design Sprint?

The Design Sprint is a step-by-step one-week process that starts with mapping a challenge and ends with a high-fidelity prototype or testable product. Product teams use it to test big ideas fast, and to compress potentially months of work into a few days.

5 phases of a product design sprint process: Understand, Sketch, Decide, Prototype, and Validate.

In four to five days, the Design Sprint aims to help you understand, by mapping the problem and picking an area to focus on; sketch, by drawing competing solutions; decide, by turning ideas into a testable hypothesis; prototype, by building something realistic; and validate, by getting feedback from real users. We break each of these down below.

Within the week, the sprint sets out to prioritise user feedback, so a working prototype reaches real users at the beginning of the product rather than after launch; to accelerate the decision, by gathering every team in one room and naming a single official decider, which is the thing that stops a week-long sprint becoming a month-long discussion; and to improve collaboration, by putting fast ideation, iteration and decision-making first so work does not stall waiting on the next meeting. Those habits tend to outlast the sprint.

What is the Google Design Sprint?

The Google Design Sprint (GDS) was developed at GV, formerly Google Ventures, the venture firm that provides seed, venture and growth-stage funding to technology companies. It gathers business strategy, innovation, behavioural science and design thinking into a single approach a team can run in a week. The definitive account is the book Sprint, by Jake Knapp with John Zeratsky and Braden Kowitz, which remains the primary source worth reading before you run one.

The process takes Design Thinking, understanding the user, framing the problem and testing solutions before committing to one, as its base, then chases insight through fast solutions, prototyping and user testing. Five phases, each roughly one to eight hours.

1. Understand. The goal is shared knowledge, so the team can spot the business problem together. You bring everyone in and unpack what they already know through lightning talks, short ten to fifteen minute briefings on business goals, insights from user research, an overview of competitors, and technical opportunities. Note what this day is not. It unpacks knowledge the team already holds. If that knowledge does not exist yet, one morning of lightning talks will not create it.

2. Sketch. An individual effort. Everyone produces a detailed solution, usually on paper, because paper is quick and changing it costs nothing, and it lets the whole team take part, even people who have never opened a wireframing tool. For large, complex problems it can help to break the problem into chunks and give each person one. The aim is volume: get as many ideas down as possible.

3. Decide. This is about which idea goes through to the prototype, and about where your solutions might conflict with your objectives and abilities. Start by listing your assumptions about budget, users, technology capacity and business drivers. Then review each idea against the conflicts it creates. The infeasible ones come out, leaving the best to build into a storyboard that shows each interaction step by step. That storyboard becomes the specification for your prototype.

4. Prototype. One day to build something your users can test. Use whatever you are comfortable with: cardboard, glue and colour to build it physically, or sketch it digitally.

5. Validate. On day four or five, bring in a group of end users to test the prototype, and make sure the whole team observes how they interact with it, live or on recordings. Bringing in experts and stakeholders to review helps too. The sprint is linear, but you are encouraged to revise and re-run based on what the first one teaches you.

Product Design Process vs Google Design Sprint: the main differences

Is one right and the other wrong? No. The PDP suits building a product from scratch or re-thinking an existing one; the GDS suits an existing product already in place.

Slack is the example. A sprint improves it slowly, feature by feature. Applying the full Product Design Process to Slack would mean a completely new approach and solution, which is not a sensible thing to do to a product millions of people already know how to use.

The practical difference is what each hands to engineering. A sprint hands over one validated prototype. The twelve steps hand over a specified product: the screens, the states, the architecture the design implies, and a plan estimated against all three. A full process supports a schedule. A sprint supports a decision.

So a Design Sprint is the best option when the problem is known, when the team has lived with it, or when experience already tells them what it is. But if there are no specific options for action, or the target group is still unknown, a sprint will not bring useful results. There is nothing to compress into a week if the team is still guessing at what it is deciding. The foundations go in first, and that is where the Product Design Process shows its value.

Decision diagram comparing the product design process vs Google design sprint. — The one question that decides which to fund. Diagram by Imaginary Cloud.

What a CTO is actually deciding

The cost of the wrong choice is not the design budget. It is the build that follows it. A sprint run on an undefined problem produces a prototype the team believes in and no evidence the problem was worth solving, so the validation happens in engineering, at engineering rates, after the roadmap has already been committed.

The economics of catching it late are well documented, and they have only grown. The 2002 NIST study The Economic Impacts of Inadequate Infrastructure for Software Testing put the annual cost of software errors to the US economy at 59.5 billion dollars, and attributed roughly a third of that to defects that could have been found earlier. Two decades on, the Consortium for Information and Software Quality's 2022 report puts the cost of poor software quality in the US at about 2.41 trillion dollars a year, with accumulated technical debt near 1.52 trillion dollars. The figure did not shrink as software matured; it grew by a factor of roughly forty, because software became the foundation of everything. The pattern is the one product teams see at their own scale: the later a wrong assumption is caught, the more has been built on top of it.

Every time a new idea is prototyped on top of scuttled requirements, much of what was already done has to be redesigned. Force that rework and you get a product that looks patched together rather than built as a whole piece. Rooms added one by one, each to a different plan. Weighed against a four to five day sprint, the weeks a full design process takes are the cheaper half of the comparison, because they are paid once, before the estimate, rather than repeatedly against a codebase.

That is why at Imaginary Cloud we break the process into logical phases that follow a sequence. The PDP balances design quality against cost and a rapid market launch, so what reaches the market is both usable and shipped on a schedule the business agreed to.

Frequently asked questions

How long does the Product Design Process take?

It runs across four phases and twelve steps, so it is measured in weeks rather than days. Research and ideation carry most of that time, because they are what the remaining steps depend on.

How long does a Google Design Sprint take?

Four to five days, one phase per day, with each phase taking roughly one to eight hours.

When should you not run a design sprint?

When the problem is not defined, or the target group is unknown. A sprint compresses decision-making, and there is nothing to compress if the team is still guessing at what it is deciding.

Can you combine a Design Sprint with the Product Design Process?

Yes, and for an established product it is the common case. The Product Design Process sets the foundations, then sprints improve individual features once the problem space is understood.

Which one is right for an existing product?

The Google Design Sprint, if the product is being improved incrementally and the problem is already known. The Product Design Process, if the product is being completely re-thought, because at that point it is effectively a new product.

What do you actually get at the end of each?

A Design Sprint ends with one high-fidelity prototype tested with users. The Product Design Process ends with research, wireframes, a style guide, GUI design, a prototype, a high-level architecture and a project plan.

Everything comes back to one question: do you know what the problem is? If you do, sprint. If you do not, find out first, because no prototype will tell you.

‍

If you would rather talk it through, tell us about your product and we will say which of the two approaches fits it. You can also browse our full portfolio of projects to see the process at work.