Design Sprint Workshop

A couple of weeks ago the whole team took part in a design sprint workshop. The goal was to develop a new feature to help novice users design basic deployment scenarios in continuous delivery automation.

The workshop outcome was outstanding. I cannot disclose the details of the prototype (this will be part of the next major version), however, I got some valuable takeaways from this experience that I’d like to share.

First: participants

All stakeholders (pms, consutants, ux designers, product owners and technical writers) spent three days together to define the user experience to be improved (a.k.a “the problem”)  and design a prototype to attain this goal.

This setting provided us with a unique opportunity to mix different backgrounds, skills,  approaches and experiences and come up with a tested idea that would satisfy the user’s requirements.

Although all team members are in direct contact with customers, the consultants’ feedback gave us invaluable guidance on the challenges that our users face when using the software, based on their daily experience on the field.

Second: the method

One ux designer guided the whole team throughout the process. We followed the steps described in the book “Sprint”, which is based on the methodology invented at Google for solving problems and testing new ideas. Other leading companies like Dropbox, Facebook or Uber are also applying this approach.

Design sprint is mainly about solving problems and testing them in a collaborative environment. All voices are heard, and all ideas are voted and discussed. The timeframe scheduled for the design sprint is usually 5 days; however, we had to squeeze it into just three days to adapt to the time constraints of some of the participants.

Third: the process

On our first day, we brainstormed problems and challenges that the users may have when using our software. Where do they struggle? Which suggestions come up more often? Which topics are common when raising support tickets? Which configuration is especially challenging? After some discussion, we picked the target: to develop a prototype to ease the on-boarding process of novice users. The prototype should guide them through the necessary steps to execute a very basic deployment (something as simple as a wizard but with complex background architecture. Easy frontend, intricate backend).

Then, with the goal and the persona in mind (Nick the novice), we started sketching possible solutions to help users learn the software and bring them up to speed as soon as possible. Every participant presented up to 8 ideas (crazy 8’s), and, after a question and answer round, we voted for our favorites. Of course, we could not test all ideas. To avoid endless discussions, we used the sticky decision method with a weighted voting system: 3 votes: 3, 2 and 1 points. PMs could cast more votes (3,3,2,2,1,1). After voting, an idea was selected.

On the following day,  we designed a step-by-step plan for the prototype. To help us visualize it, each of us created a storyboard and again voted for the best concept, taking the sources of complexity and constrains into account.

Then, it was time to create a prototype based on the steps described in the storyboard to simulate the product we wanted to test. Of course, we didn’t have time to configure the system to execute a real deployment, but we could design the steps and determine which input was needed. The mockups created simulated a real process (following the fake it till you make it philosophy). It was almost real 😊

The last day was devoted to testing and improving the prototype. We found some guinea pigs (people with a technical background but no experience with our software) and had separate meetings with them. We showed them the prototype and provided them with a step-by-step scenario. We analyzed their reactions, observed where they struggled and noted their questions, comments and feedback.

I was thrilled that I could carry out some of the interviews. I learnt a lot and got even more interested in delving into the customer experience testing process. Since the design sprint workshop took place, I have a Nick the Novice post-it on my desktop to remind me of the importance of a user-centered design.

Fourth: the takeaways

This experience has helped me appreciate even more the value of user journey research and the power of teamwork: everybody is different, everybody can bring value. Design sprints can greatly reduce the time and money companies have to invest in developing new features and get real feedback to anticipate design mishaps.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s