Design is the fundamental soul of a human-made creation that ends up expressing itself in successive outer layers of the product or service.
— Steve Jobs
Google Design Sprint is, as Google itself puts it, "a process for answering critical business questions through design, prototyping, and testing" that allows product owners to have "a shortcut to learning without building and launching a minimal viable product". In the end, you'll know if your product concept is good, but you'll still have to do a lot of design before implementation.
It's a five-day process:
Day 1. Map out the problem and pick an important place to focus;
Day 2. Sketch competing solutions on paper;
Day 3. Make difficult decisions and turn your ideas into a testable hypothesis;
Day 4. Hammer out a high-fidelity prototype;
Day 5. Test it with real live humans.
The Product Design Process is, in a nutshell, a process that gets you through all the steps of the actual product building. At the end of the process, you'll have everything you need to start implementing, which explains the longer time frame required.
It follows a four-stage process, in which the technical assessment happens simultaneously with the other stages:
Moving on, the Sprint presentation clearly underlines that the assessment of the business viability is its main goal, but also mentions that it can be applied to "make the first version of new mobile apps" or "improve products with millions of users".
While it certainly can, it's not an adequate process to do it, which explains why Google doesn't present the creation of new mobile apps as its main goal.
You also could perfectly start a fire by rubbing two sticks together, but there are very few occasions in which that would be the best way to do it.
It's at this phase that Google has some constraints, demanding that we have only one target customer and one target event. In a simple way, this means that if you're developing the first version of a mobile app, it has to be very basic, as the improvement of an existing product is done only through the addition or changing of a feature.
For instance, you'd be able to change one element at a time, making it impossible to target two different personas simultaneously. While having only one target persona might be the ideal scenario for a designer, we know very well that most of the time we can't get away with it. In any case, we can't overlook them, personas are crucial when developing a new product.
If you either have a complex app, want to work on the improvement of different features, or make several new features, you won't be able to do it on one go. To add additional content, you'll have to do several Design Sprints. That's what happened with the case study presented in the Sprint book about Slack, where it's stated that two Sprints were needed before they started building it.
By contrast, the Product Design Process can contemplate more than one persona, thus being more suited for products that demand several user roles. For instance, healthcare apps that demand different interfaces for professionals and patients or teaching apps that are used by both teachers and students.
The time frame and persona/features constraints are only the first barriers that we face when we pick Sprint to develop a new app. This process has a bigger problem when applied to the development of new products - a problem that can't be solved by doing several Sprints or by extending its duration.
Google Sprint presents you what you should do and by which order, but it doesn't give you any insight on how to move from step to step, nor how to perform some of the tasks in between.
When we reach the part of making the visuals, Sprint mentions that Makers (designers or engineers) should create the individual components: screens, pages, pieces and so on, under the direction of The Sticher, who should give the style guides to follow. However, it doesn't contemplate the making of those style guides, the time to make them or the tasks that are needed to define the visual concept in which the style guides are based. This is not essential to access the product concept viability (Sprint main goal), but it's crucial if the goal is to build it.
When the visual concept definition is neglected (not done or done but without being based on user and market research) it has severe consequences:
It's unlikely that you'll burn up a space shuttle or shoot down a plane, but bad user experience may very well be catastrophic to your product's success.
When creating content, be empathetic above all else. Try to live the lives of your audience.
— Rand Fishkin, founder of Moz
A less blatant case, but still similar, is found at the beginning of the process, in the "Remix and Improves" day (the second one). Here the process tells you to "ask everyone on the team to come up with a list of products or services to review for inspiring solutions" and then present them to the team, writing the most useful ideas down in a whiteboard.
The problem here is that those references are being collected based on team personal preferences and experiences. The process doesn't contemplate any user input, thus not being, in fact, user-centered design. It's important to take in consideration that a feature is only "good" from a subjective point of view.
A good feature for someone may be disposable or even detrimental to others and the same goes for usability and user experience. Some people may find a certain way to display information intuitive, while others may find it confusing. One person may find it appealing and another one is put off by it.
The way to solve that is by defining a user target profile and look at the references that people fitting that profile have and prefer. While Sprint defines a target user on the first day, it doesn't really use it to guide further decisions about the product. We can't stress it enough, you have to design for your target audience, not for yourself.
There is no point (from the perspective of ensuring the product success) of having someone in charge of the user interface that is neither:
The only possible reason to do that is to engage clients in the process, creating a better relationship with them and have easier approval processes, since they feel as the authors of the solution. However, there's no advantage concerning the end product quality.
In fact, it can even be harmful. In the Google venture context, Sprint may work due to the fact that all people are immersed in a design culture, but when the product owner is someone that doesn't come from the product design environment and doesn't have knowledge of the potential user profiles, the tide turns.
In Product Design Process, by contrast, even if you didn't have the chance to contact with potential users to know their personal references and preferences, the team focuses on putting themselves in the user's shoes, researching not their own references but other products that are known to be used and appreciated by the target users.
You have to understand the user. If you can't, he surely won't be able to understand you either.
Summing-up, is the Product Design Process better than Google Sprint? It depends. Google Sprint is well suited for the early stages of the product conceptualization, when you have a new product concept but you haven't clearly defined it and you want to access its viability.
It's also crucial for the Google Sprint's success that the whole design team knows their audience. If that's the case, you can take a lot of advantage by doing a preliminary Sprint.
If you've accessed the product viability with the Google Sprint and wish to move on to the implementation, you can take advantage of the Product Design Process, which places no constraints when building more complex apps or upgrading features. However, it is also possible to start the design from scratch using the latest, which covers the whole design process.
The Product Design Process solves the problem of how you integrate UX with visual design. This guarantees, for visual designers, that they have something solid to sustain their choices and decisions and not simply personal preferences, making their work easier.
As for product managers, it guarantees that UX design adds concrete value to the product and it's not wasted effort, making clear how each UX task reflects on the GUI, which will also help the sales team deal with potential clients, presenting the value of hiring UX designers.
Last but not least, it also means that the developers won't have to spend time making - often wrong - design decisions, and that the interfaces that designers deliver are easy to implement.
At Imaginary Cloud we have a team of experts on UI and UX design. If you think you could use some help with design, drop us a line here!
Found this article useful? You might like these ones too!
With 10 years of experience and a background in cognitive science. I’m passionate about inclusive design and calm technology.
People who read this post, also found these interesting:
