Integrating Design Sprints into GDS phases
Ways in which Design Sprints can integrate into the GDS agile delivery phases. Examples are provided of how we have done this here at WORTH.
The Introduction
The Design Sprint offers many ways to enrich an organisation’s approach to problem solving and alignment. I believe this is something we can all enjoy.
It is useful in increasing the speed and impact of innovation in your organisation. Particularly within an agile software development environment.
This article is written using my own experience and viewpoint as designer and Design Sprint facilitator. Full disclosure; the company I work for offers Design Sprint facilitation as a service, so I’m not without bias or agenda. That being said, I hope you enjoy the article :)
Design Sprints
Design Sprints are a series of activities for shortcutting a great deal of the product development processes. Developed at Google Ventures by Jake Knapp, who in 2016 published the textbook on the process; Sprint. It works and you should do one as soon as possible. You can find all the resources you need to run your own sprint.
The approach side-steps all the debating and waffle that go with product development. It uses high quality activities that get teams to pool their resources and knowledge and tackle huge problems very quickly.
The process is comprised of five steps:
- Mapping the problems
- Sketching solutions
- Deciding on the solution you want to test
- Creating a prototype
- Testing with users.
Each step comes with its own set of activities which on their own would be a gift to anyone facilitating discussions. Together they form a powerful tool for, as they say, “seeing into the future”.
Since its inception, the Design Sprint has been ripped apart and put together by many, but none more so than Design Sprint agency AJ&Smart. Props for them for pushing the format, working alongside Jake to bring us Design Sprint 2.0 — only four days!
GDS
The Government Digital Service is tasked with driving digital transformation across government services. Started in 2010/11, it’s fair to say that it revolutionised how services were provided in the UK and beyond.
The GDS developed its own set of ten design principles and has used these to underpin everything it has done. Read their blog for more details on how they’ve done this and what they’ve achieved (hint: it’s a lot). GDS works through an agile delivery framework, utilising phases of discovery, alpha, beta and live. You could also view this article as ‘Design Sprints in Agile Phases’.
The work of the GDS has raised expectations among people who use government services on and off-line. Their design system is publicly available, allowing government and suppliers to produce services that are consistent. They continue their work by reaching out to local governments to bring them into the digital fold.
Using Design Sprints
Discovery Phase
Design Sprints help problem definition and team alignment. That is great news for discovery phases. Having everyone on the same page with regards to the aims of the project can help get a project off to a positive start. Combine that with getting everyone excited by the upbeat energy that comes with sprints, and you have a winner.
By running a full Design Sprint in this phase, you will get some very early insight into the riskiest ideas that your team can come up with. You’ll get real feedback from a handful of users, giving an initial steer on how much to focus on or invest in those ideas.
But that’s not all. There are tools and techniques that we can borrow from the sprint that will highlight concerns that your key stakeholders have.
Seeing what’s on everyone’s mind, and then getting a balanced view on which are the most important problems really brings people together. Not only that, but you’ll also go to the next level and come up with solutions to those problems. then smash past that, and agree on actionable next steps for each solution!
I use AJ&Smart’s Lightning Decision Jam all the time for this, both with clients and internally. Borrowing heavily from the Design Sprint, it chucks out all the things about group brainstorming that don’t work. It then brings together all the things about teams of knowledgeable, committed people that do work.
Alpha Phase
In theory, a couple of Design Sprints could be your whole alpha phase! Prototyping and testing your ideas to get a grip on what works and what doesn’t. Finding out what’s feasible and what’s not. Investigating what users will accept and what they won’t. This is what the alpha phase is all about.
In practice, our clients tend to be too large for this to be the whole story. Alpha phase includes a lot of technical discovery and coordination of different systems. That comes along with managing all kinds of stakeholders to produce content or data that affects implementation.
That being said, we have used Design Sprints in alpha to help get project teams over major hurdles. For instance when working with a top UK university. The technical team were doing their due diligence investigating server architectures etc. (Yawn! Sorry developers, this is so not my thing!). The design team worked with senior stakeholders to run a sprint reflecting on the university’s reputation.
The UK higher education market is a closed system, so losing reputation results in your competitors gaining customers. The time spent boiling down all the factors involved, working across a multi-supplier chain, was well worth it. It allowed us to focus on outcomes and brought a sense of alignment to suppliers. Not to mention the rewards of the potentially game-changing solution that we came up with.
The ideas from that sprint are currently in development, but I’ll be sure to share the outcomes of it when the time is right!
Beta Phase
Once development has started, shake-ups in project architectures or approaches are seldom welcome. However, our clients are often large-scale organisations trying to grapple with technological innovation. This means that there are usually corners of a project that are marked as ‘We’ll do that when we get to it’.
What better way to go from nothing to a tested solution in under a week? These sub-projects, although they will need to fit into the larger project vision, can have their own quirks or requirements. This mean that what works for the larger project won’t meet all the business units’ needs.
Knowing where to invest resources as soon as possible is the Design Sprint’s forte. Doing one in these circumstances can help get the sub-project up to speed.
Beyond Design Sprints, beta is when you will be testing your fledgling product with users. The Design Sprint has plenty of tips and tricks for conducting user interviews. These are especially focused around getting that crucial feedback in front of everyone concerned as soon as possible. This leads to feedback being addressed as early as the next development sprint.
Live Phase
Once live, you have actual data from actual users, whom you can actually go and speak to. You lucky dog! You’ll use this to iterate on your product and improve your services.
As a result, you’ll either have a problem, such as shopping cart abandonment, or low service uptake, or you won’t. If you do — Design Sprint! If you don’t — Design Sprint!
Competitive market places are no place to stand still, so getting your team to visualise the next iteration of your product is a must-have. You might not do it for six months to a year, but you should certainly do it by then, IMHO.
Some organisations run Design Sprints as a matter of course. They integrate them into their routine so that they’re always on top of issues, improvements, and user needs. That is a good place to be. On top of your users.
Outside agile delivery — Pre-sales
As part of our pre-sales work at WORTH we have used Design Sprints to align and engage our design team around a client’s perceived needs.
We wouldn’t expect anything we had done without the stakeholders to actually get approval to build. But what it does get is a great big smile from our would-be clients when we turn up with a working prototype and documented user feedback. Before we’ve even been engaged as their supplier.
They can see their problems laid out in front of them, and thanks to the user feedback, they can see that — yes! — there is a way of resolving these problems. What we get out of it is a focused look into our prospective clients’ needs and problem space. This encourages empathy and sparks creativity within the design team.
The Conclusion
So, you have to have a conclusion. I guess the conclusion is a pretty biased ‘Design Sprints are great, so get in touch to buy one’.
But that’s okay, because I honestly believe that they are great. I really enjoy facilitating them, and I don’t mind shilling for The Man if it means I get to do more of them :)
If you’re thinking of running your own sprint, or trying out some of the exercises to get a flavour of it — great! Go for it, I hope you find them as enjoyable and effective as I have. Then call me.
Thanks for reading.
This article originally published on https://worth.systems/
All images are drawn by the author.
