COVID struck again, the second time, and I spent the entire week at home. I didn’t feel great but somehow pulled through.
At the end of the week, I felt like I feel after every design sprint: ‘Wow, how come we aren’t this fast in a regular week?’ While taking notes in one of the testing sessions on Friday, I sketched a sticker saying, ‘Just do it’ in German. Over the weekend, I finished and sent it to the printer.
Everyone else working on a product or service is earning their mission patches. In the meantime, without contributions to these, I have to create my own.
Running a design sprint remotely
The design sprint wasn’t supposed to be remote. All of us were meant to be in the office. But then, no one was. And still, somehow, we managed to do it. Even last November, when running a design sprint within our Service Standard and Manual team, we all made it to the office.
So on Monday morning, we moved things to Miro, with the slide deck to navigate us through the sprint unchanged. I am still building on a distilled ‘how-to design sprint’ deck that my former colleague Ben created a few years ago.
A design sprint is always excellent for building and testing a realistic prototype within a week. It’s a rapid way to test assumptions and big ideas, an opportunity for a team to learn about and be involved in the design process, and to unite the team’s understanding of the problem.
Design sprints are helpful in some contexts but less so in others, as I said in a tweet some time ago.
We aimed to compress the 5-day design sprint to just 3 days but then realised we needed more time for a much more complex prototype. So Monday was for understanding the problem. Tuesday was all about ideating, sketching, and deciding. Prototyping kept us busy Wednesday and Thursday, so we tested only on Friday afternoon, closing the week with lots of ‘ah’ and ‘oh’s.
With little preparation time and broad scope, I mostly built on recorded material for the expert inputs, usually scheduled for the first few hours of day 1. So, I created a playlist including short excerpts from recordings from Public Service Lab events and the regular calls from the International Design in Government community, plus official videos from other governments.
Well, mostly, the other videos were from Estonia. Have a look at how well made they are:
While there is no consistent style connecting the different videos, the positive approach and storytelling are very similar.
Afterwards, the hundreds of how-might-we questions resulting from those inputs were quickly discussed, clustered and prioritised using Miro boards. And sketching ideas based on the questions worked equally well. While the others drew on paper and uploaded pictures of their Crazy 8 drafts to the Miro board, I used an office iPad and Apple Pencil with the Miro app directly. Thinking about buying such a tablet setup for years, this was a rare great use case and left me impressed.
Warming up to the sketching, we used the squiggle birds exercise from Dave Gray and drew how to make a peanut butter and jelly sandwich in 8 steps. Those things keep design sprints lightweight and fun, even though they are hard focussed work.
In the following steps, we combined our ideas, developed a storyboard for the user flow, discussed our assumptions and how we want to test those.
After facilitating quite a few design sprints over the last few years, I feel more and more routined about running them. No surprise. Depending on people’s previous workplaces and environments, they might not have had any experience participating before. Bringing in more workshop formats will probably be helpful in the coming months. The waves of design thinking and service design movements have not swept into all corners. So not everyone is equally familiar with how much value formats like these can bring. It’s something I have to remind myself of.
Taking the user’s seat
One of the other very few things I did this week was participating in an end-to-end test for an app in development. It’s the first mobile app we have been making, and it’s exciting having a beta version on my phone. The product manager organised and facilitated the test; it was a pleasure to be on the other side.
Having slightly different circumstances, we were both unclear why I got specific errors. Still, we eventually brought me to the end of the journey that involved various other existing government services. It was satisfying to do so. The product manager took plenty of notes which will help address remaining issues before the launch.
Using all kinds of testing approaches is fundamental to creating successful and high-quality software products and digital services. I am glad we have established strong approaches at DigitalService.
While still on the path to recovery, I know next week will be a bit demanding. There will be 2 offsite events that both need sufficient preparation. And there are 1 or 2 public meet-ups to attend as well.
In any case, it means spending more time with all the designers and having time for more profound exchange.