Design Sprints

I remember a few years ago when we first started building a healthcare data platform, our design process was fairly flat. I essentially had an idea or got scope from someone, spent a few minutes researching solutions, and went right into development.

Development at this time happened pretty much in production and was shipped immediately without any sort of review.

You can imagine the challenge with designing products this way. We never really got user feedback until the very end and by that point, we had built up so much supportive bias that it made going all the way back to the beginning pretty difficult.

We’ve come a long way from those days and with such, have built much better products in shorter amounts of time. The reason we’ve been able to become more efficient is because we’ve taken the time to learn with each product build. What works and what doesn’t and build those insights into the design process.

Today, our design process works in two parts. The first part is focused on discovery and wireframing. Our Product Manager will come up with an initial feature list or scope based on existing projects. He’ll then interview users and refine the scope into a MVF or minimal viable feature list. This focuses the scope to the most important aspects of the product. From here, a wireframe is sketched out and reviewed with team members.

The second part of our design process is focused on prototyping and reviewing. We’ll take the wireframe and any notes from the scope and start building a working prototype in the browser. Once we have the prototype done, we’ll get it in the hands of users and team members to play with it and provide additional feedback.

This process has yielded some of our best products to date. However, as with most processes, there’s always room for improvement.

The concepts in the book are not new, however the way they approach and work through the design process as a whole is fantastic. Here is a great talk by Google Ventures discussing their design process: