The title of the article actually reads:
Why Google Design Sprint may not suit your needs
Which is what the article is about.
But hey, let's make anything look like clickbait even when it's not ¯_(ツ)_/¯
This is why quite often these days on here or hacker news/reddit I jump to the comments before I even bother with the article
*Posted by the CEO of ImaginaryCloud
Nothing to hide.
Just curious, why did you change the title here from the actual title of the article? I knew when I clicked on the comments this would be the top comment (someone saying "clickbait"... because the title is exactly that, clickbait).
It's obviously intentional. Why did you feel the need? This act alone really hampers the authors chance at creating an interesting discussion because you've soured the whole thing up front.
This was part of an A/B testing experiment. We did release under the original title first 3h before this one.
The interesting part of the experiment is that this one led to more valid discussions about the topic and the content of the article than the other one.
Why? It's still generating a valid discussion about the subject.
We did release under the original title first 3h before this one.
Where is this post with the original title. On DN? Can't find it.
Anyway, I also hate click bait and don't expect to resort to it again. But was curious about what would happen and the result of this little experiment was indeed interesting.
P.S. You dropped this \
To me, the purpose of the Google Design Sprint always seemed to be making sure that all the stakeholders were in alignment since they had participated in the sprint. That way you would't waste a bunch of time going back and forth to each one trying to get them to agree on something - which is a very real hurdle in the real world. Definitely not user-centered, but management-centered, FWIW.
I see it in the same way. Is in that sense that my recommendation would be to go with a Sprint in a first stage, but then, once the stakeholders are aligned with the general business strategy and goals, move into a PDP to materialize that in accordance to user needs and goals.
I feel like this makes a lot of assumptions about how everyone is executing the Design Sprint methodology. In reference to coming up with solutions for multiple personas or features, the author writes, "To add additional content, you'll have to do several Design Sprints." That's a self-imposed limitation, really. You could organize your sprint such that one group tackles one persona, and another group tackles another, and so on. This even helps for internally validating between the groups on top of validating with users on the last day. There are examples of sprints being run with dozens of participants, allowing them to tackle the gamut of use cases while all benefiting from being on the same page when it comes to initial research, focus, and stakeholder buy-in. Ultimately, it's a framework that's meant to be flexible, not exhaustive. Don't have a "style guide" for visual execution? Not a problem. The goal is to come up with validated solutions quickly and cheaply, not design and build a launch-ready product. Knowing that going in, of course it doesn't suit your needs if your need is to have final designs done in a week.
The limitation of one persona is a limitation recommended by the authors of the Sprint themselves. While certain you can go around this, the results will probably be impaired.
In terms of having separate groups working on separate personas, in practice that is not possible. It's not enough to validate in the last day if you have to build the app information architecture, the user journeys, the interfaces, etc...taking into consideration both personas.
And simply having one larger group to try to deal with more requirements in the same time-frame is not a solution - since co-designing and dealing with discussion and decision-making is difficult in larger groups (Once again, the authours themselves recommend small groups for the process to work).
". Don't have a "style guide" for visual execution? Not a problem. The goal is to come up with validated solutions quickly and cheaply, not design and build a launch-ready product. Knowing that going in, of course, it doesn't suit your needs if your need is to have final designs done in a week." - Yes, that's exactly the point of the article: Design Sprint is a process to test a product concept, the PDP is a process to have a product ready for the implementation to start. Unfortunately, many product owners don't realize this and have irrealistic expectations about the Sprint and/or try to adapt it for a purpose to which it is not suitable, resulting in products with poor UX.
FWIW, design sprints take many, many diverse forms here. They're mostly used to drive wide alignment from diverse stakeholders and ground product process in user-centric thinking.
I respect your approach and wanting to present your product design process, but this article, and your personas article, are much too long. I was completely lost on WHY your approach is better than a Google Design Sprint – I think you told us more about Google's sprint then your own solution. You might have a valid point, but I was lost in such a long winded article.
Hi Adam, thanks for the feedback. We'll keep an eye on clarity from now on.
Taking this into consideration. I hope the article that was released this week is clearer.
Massively biased and doesn't even touch on the benefits of Google Sprint until the conclusion. A fail-fast Sprint technique as opposed to a 2-4 week research heavy sprint with no real tangible artefacts I feel is far more powerful. The product design process that is referenced is very waterfall and in my opinion not agile enough.
I think that there is a misunderstanding here relative to the "level" that methodologies are applied. Agile is great at the product level. You want to define requirements, design, test, develop, test, repeat. Without doubt. But the PDP is not a process for the project level. It is a methodology at the phase level. It's about how to do the design phase.
It does not invalidate Agile. You can (and should) do a PDP, then move to the testing and implementation and then review the work done. But, in the design phase itself, you need to have some waterfall. Otherwise, you will be working ineffectively and ending by spending a lot of time and budget and have a poor quality design - plus an unmotivated team.
Giving you a very basic example. If you don't have any actual data to base your choices in terms of what colours and fonts to use, do you choose them based on what? It will end up being personal preferences or stereotyped assumptions from either the product designer or product owner... And then you will end by changing the look&feel again and again - something that, once you have dozens of screens designed, it's really time-consuming (and boring).
By doing some really quick preliminary research and methodic thinking you reduce the chances of this happening cause you are able to reduce a lot of risk from loose assumptions.
Also, sticking to this example of the colours and fonts (since it's the simpler one) the PDP solves one of the major problems that visual designers face - the communication of abstract concepts.
Stakeholders want the look&feel to convey certain values and feelings. The type of requirements that you get related to that, It's usually something like "I want it to feel luxurious"- But what does luxurious means? How do luxurious look like? More often than not, people have different visions of that. With the PDP, instead of receiving this requirement and jump into designing interfaces just to discover after that you were not aligned (and spending three times the time in changing it and changing it again until you get it right), you have the tools to explore and define the concept properly, so you can move on more efficiently.
Concluding, the PDP doesn't replace any project management methodology (and at the end, even if we recommend to go with a more agile approach, it can work with any PM methodology). The PDP simply brings methodology into the design phase. In those areas that not even the Sprint covers. And shines light into a process that (while is somehow already implemented intuitively by experienced designers) stills being talked and perceived as something kind of random and obscure by project and product managers and less experienced designers.