Improving design sprints with data

I've been contemplating the design process the rest of this morning. About four years ago, I read the Sprint book and it changed how I approached design. The instruction manual to do my job was right there. The method was aspirational, measured and felt absolutely right.

Last February, I ran a workshop at Google Relay. We were welcome to choose a variety of topics. There were the popular topics about inclusivity and creating engaging experiences - the ones that facilitators love to get into.

I chose the one topic I absolutely knew nothing about. Data. Data in design. I did this for two key reasons. The first is pretty self explanatory if you know me: Personal growth. This is why I do a lot of the things I do to be honest. Doing, rather than learning how to do, has been my method from day 1. Choosing a topic I know nothing about puts on the pressure to learn, in a pretty low risk way.

The second reason is probably more beneficial to this community: It's ultimately where we need to get to. Data over assumption. Fact over guesswork. Launching rather than simulating.

I researched, prepared and facilitated two workshops with a select group. We listened to how Google Zoo were running more data-led sprints. We shared ideas how this could benefit our practice and what steps the community could take to improve their design sprints with data.

I'm starting to look at the work we created and choose where to take it next.

After porting the Design Sprint to a virtual space and navigating 'the wild west' of the remote practice, I am starting to become very excited about a new set of 'instructions' that are more data-led, more about product design, with the growth mechanics and product strategy that offers a framework for anyone to solve their product problem - better.

Outputs from the Google Relay session can be found here.