At Revelry, we’re able to utilize the principles and exercises of a Design Sprint to enhance the effectiveness of the product over a series of our one-week, Lean Agile Sprints. It’s design thinking, the Revelry Way.
Design Sprints and Agile Sprints
Design Sprints are intensive, structured learning activities.
The purpose of a Design Sprint is to produce shared understanding, hypotheses, and minimal forms of testable solutions.
Agile Sprints are equally intensive, structured iteration activities.
Each Agile Sprint produces a usable, testable unit of software.
We’ve weaved design thinking into iterative product development — our Lean Agile Sprints — in order to challenge assumptions within an existing product creation process.
This helps us identify opportunities for improvement while still performing necessary builds. It’s too easy to drop the learning aspect from Agile when the default is to build. We believe in the value of the principles, and our innovation partners benefit from the quick wins that come out of slowing down once in awhile. Here’s how we do it.
Debriefing: Gather “How Might We” Statements
In a typical, formal Design Sprint that you might hire consultants to perform, you’ll devote a full day to gathering the existing knowledge about a product market. This includes reviewing any existing user interviews and performing demos of existing products in order to arrive at a shared definition of the product space. When we apply design thinking to an existing product, we can fast-forward a lot of market learnings.
So, we kick off with a round of user observations. Because we ship usable bits of software each sprint in Lean Agile, there are customers already using the products we’re still iterating on. Together with the stakeholder, we can identify areas of needed improvement and set out to run design thinking in those areas.
In Week One of this exercise, we schedule 5 user observation sessions (at 30-45 minutes each) targeted to these areas. We perform and compile the observations over a few hours during two days within the sprint.
Then, we spend one hour of another day during that sprint debriefing our observational notes to share with the product owners. Together with our internal team and the product owners, we utilize the technique of listening and documenting potential opportunities or pain points under the framework of “How Might We” (HMW) questions and statements.
How To Write a Quality “How Might We” Statement
- It’s not too broad: “How might we build a better house?” generates too many unhelfpul ideas.
- It’s not too narrow: “How might we build a door that swings inward and outward?” produces a solution within the question.
- It’s just right: “How might we improve traffic flow in high-use areas of the house?” targets a segment and makes room for possibilities.
Each of our projects utilizes its own dedicated Slack channel, where external product owners and the internal team share all progress and discussion. We create a single thread in the Slack channel to collect all of the “How Might We” statements we’ve generated. That way, there’s no hunting them down or relying on notes. When we’re ready to pick this up in the next sprint, they’re all here in the thread. This conversation involves both our internal team and the product owners.
And that’s where we leave it during Week One. In the subsequent sprint, we will look at these statements and decide what to prioritize.
How to run design thinking without existing users
If you’re running agile sprints to build products, and you’d like to apply design thinking without stopping for a full design sprint, you can still incorporate design thinking exercises even without an existing product or customers. You’ll want to assign some homework to the stakeholder before beginning. Ask the client or product owner to review their own existing market research and identify an area where questions remain, or where they’d like to challenge assumptions. The design thinking exercise should be focused on a single aspect of the product, customer, or market.
Your product owner should present their information to you a distilled format. If they require your assistance in deciding an area to target, set up a one-hour session to help narrow down the focus. Then, you can launch into a one-hour debrief of their market knowledge to form How Might We statements.
Voting and Sketching: Explore and Create
In Week Two, we quickly focus our efforts on prioritizing problems, challenges, and opportunities. This helps us move quickly to the key exercise that will lead our exploration of solutions.
Here’s the mechanism we use to surface the most promising “How Might We” questions to address. Remember the Slack thread we created in Week One? The team is directed to that thread, and the process begins:
Voting: How we identify 2-3 HMW questions
NOTE: this process does not include discussion. It’s silent.
- Start a timer (5 minutes).
- Open the Slack thread.
- Each team member gets 3 votes (use emoji as votes).
- Mark with your emoji each HMW question you feel is most important.
- You can use all 3 votes on a single HMW question.
- You can vote on your own HMW question.
- When the time is up, the time is up.
- Organize the top vote-getting HMWs.
We arrive at no more than two questions to lead our exploration of solutions. Even better: deciding on one question. And then we can get to our ideation exercises.
Focusing on our two main “How Might We” questions, the team performs drawing, sketching, and mind mapping exercises. Each activity is conducted in parallel — that is, independently, but synchronously. It’s important that these exercises are individual and that they’re timeboxed.
Sketching: How we explore solutions with a story
We begin with one “How Might We” example, and each team member dives into some messy mind mapping to get some loose ideas on paper.
Then, we each perform Crazy 8 sketches. For Crazy 8s, each individual fills up 8 rectangles on a sheet of paper with a different solution for one problem.
And repeat, for the next “How Might We” example.
Then, we each review our own ideas to determine the strongest among them and create a 3-panel storyboard.
This storyboard is an interface sketch that should speak for itself. It has a title, and it’s shared with the group. Note: we share the storyboard. We don’t present it.
In a two-minute session, the team performs heat-mapped voting to select the section of the storyboard that most speaks to each team member.
Heat mapping is a great way to perform this exercise, because it helps us identify commonalities among the team. Based on stickers or pointers, we can point out interesting areas of the user flow or interesting pieces of the solution. We can also identify ideas that are different, and worth exploring. This may sound like an exercise that has to be done in person, but that’s certainly not the case. You can perform remote design thinking exercises by using Zoom and some creativity.
How we review the storyboards using heat maps
Give the team 5 minutes to silently and individually examine each storyboard and place tiny dot stickers anywhere on the storyboards where they find something of interest. This allows the team to identify specific areas within each storyboard that stand out. It might be a single button or interface element, an implied transition, or some other piece of the user flow.
The value of this heat map comes by way of identifying common patterns among the story boards as well as avoiding an all-or-nothing mechanic before making final decisions.
For remote teams: It takes some creativity and patience, but it’s possible to do a virtual heat map. One way we’ve done it is with the Mac Preview app. The remote voter will add tiny dots to the storyboard pictures that the onsite team shares. This is a little cumbersome because it requires an onsite member to transfer/combine the two different artifacts.
The next time we do this, we will try uploading each storyboard into one large Miro board. Then we’ll have the entire team place small, filled-in circles on top of each image (just like they would use tiny dot stickers). This should create a more level playing field for all participants and result in a single artifact that doesn’t need re-compiled.
With the heat map complete, it’s time for a verbal critique.
Set a timer for 3 minutes per storyboard. Have the team talk through each storyboard for 2 minutes (the creator stays silent, actively listening). The purpose is to highlight what the team finds interesting, challenging, or even confusing. Then, in the final minute of each, ask each storyboard creator if the team missed anything important.
Once this review is complete, the team is ready for decisionmaking. Conduct a super vote, similar to the one used in the HMW exercise. Each team member receives just 2-3 votes and places their votes (use large dot stickers this time) on the storyboard(s) they feel should be pursued in prototyping. Vote for your own storyboard, or put all your votes on a single storyboard. All voting is fair game.
With the super vote in hand, there should be a standout storyboard to carry forward into prototyping. Don’t forget the heat map as you move forward, though; often small ideas from each of the storyboards make their way into the prototype as valuable additions.
After analyzing the heat maps, it’s time for a final round of voting. We’ll pursue two final solutions and move them toward testable prototypes.
User Testing: Experimenting with a Prototype
Three weeks into the process, we’re ready to select users for prototype testing. This prototype does not need to be (read: shouldn’t be) a piece of usable software. We sketch a more robust, but still lo-fi, walkthrough of what the User Interface will look like.
Sometimes, the two final solutions merge into a single solution. But it’s perfectly fine to present two testable prototypes for your selected users. This might add a week to your design thinking exercises, and that’s ok. It also adds highly valuable learnings to your agile product development process.
Ideally, you’ll aim for a minimum of 5 people for testing and reviews. While we’re not following a strict Registered Trademark Google Design Sprint, there are particular elements that require purity in order to work. And one of those elements is the user test.
How to Perform Valuable User Testing
It’s important to educate the entire team about the importance of purity in the process during this stage. This is not a demo. This is not a feedback session. User testing means putting the prototype into the hands of a user and observing their interactions and challenges.
Tip: use Post-Its or index cards for note taking. This way, when compiled, they can be consolidated and categorized.
There is one facilitator who leads the interaction with the user. There should be another team member who is responsible for all note taking (it’s important that this is not the facilitator.) The rest of the team witnesses the interaction, firsthand, via Zoom or other remote monitoring. They shouldn’t be interacting with the user, but they need to take their own notes to round out the observations.
Don’t rely on recordings to allow the team to go back and observe. Facilitate real-time observations that support learning together by the whole team. And, make sure to leave enough time between each user test to capture notes.
The Role of the Whole Team
Design thinking exercises work best when cross-department team members participate. It’s not always obvious to an engineer how product ideas are generated, and “doing UX research” is very rarely a task performed by a developer. This process allows the product makers to think and learn more about the unique needs of their users.
So gather the designers, the developers, the QA testers, the marketers.
Help your team develop and expand their skills. They’ll learn how to prepare for and conduct a user test. They’ll tap into creative techniques through the constraints of prototyping. And, their input can inform how to arrive at better solutions or improvements to pieces of the process that no one else had thought of. Improving the way we gather and organize notes, lending structure to preparation for the activities, and disseminating learnings into shared knowledge are all ways we’ve benefited from having multiple Revelers participate in our exercises.
In a very fast paced Lean Agile format, our scope is often very limited. And we can forget to stop and be creative or mindful. So making space for exercises like this allows the team to open their minds and let their thoughts go to far-off places in terms of problems and solutions.
Challenges and Tricks: Making Room for Design Thinking
Agile software development is an action-oriented process. It’s easy to fall into the trap of expecting action or a really solid outcome when launching design thinking exercises.
Agile is also learning, so be sure to give your team credit when progress is made, even if progress during learning doesn’t look the same as progress during a build.
Challenges: Will we lose momentum?
When we break out these various design thinking exercises, will this affect the ability of the team to deliver software solutions? Isn’t one of the principles of a single one-week, intensive design sprint, that time-boxed constraints force decisions and result in effective learning?
Yes. The answer is, of course. In certain situations, a one-week intensive is better than any incremental efforts. But the availability to dive into a full design sprint probably only comes around once a quarter, at most.
We find great value in making sure that the Build-Measure-Learn loop happens with great frequency. I might even make the argument that sometimes that loop should be re-oriented to Learn-Build-Measure.
What we have found is that we can leverage the principles of a design sprint and infuse design thinking into our fast-paced, lean-agile process and create massive value. All too often, “agile” becomes code for “deliver fast and keep moving.”
Moving fast for speed’s sake doesn’t increase value. Velocity is not success. Working software that creates value for the customer and the business is success.
The main obstacle to momentum is commitment. If the team values the principles, then it isn’t difficult to find the right exercises to work these deeper dives into the regular cadence of our one-week sprints.
Tricks: Value principles over methods
We often stumble upon valuable insights during any single exercise described above. There is no need to wait until a design prototype is user-tested before applying our learning. We actively look for insights during each step of the process that might be able to be peeled off and inserted into the parallel process of building that is continues to occur.
For example, during our debriefing of user observations, and as we create our “How Might We” questions, we may discover a low-risk, high value change to an existing userflow.
Great! Write the user story, prioritize it, and work it into the next one-week sprint commitment. Don’t think that you have to wait until the very end of this process to apply your learning.
Tricks: Recognize temporary limitations and adapt
This process works best when we start with user observations. But we don’t always have the benefit of working on a product that has already shipped and is regularly being used by customers. Sometimes, we are working on the very first, Minimum Viable Product (MVP) with startup founders.
We still apply the overarching design thinking principles, regardless of the status of the software.
- Come to a common understanding of the problem/opportunity.
- Explore the problem with structured, time-boxed exercises.
- Create a multitude of possible solutions.
- Work together to make decisions.
- Test your ideas.
Challenges: What if the whole team can’t participate?
We don’t usually have the whole team! It’s really beneficial to have some representative mix of stakeholder, product, design, engineering, and QA participating throughout the process. The beauty in the approach of breaking up a traditional, dedicated, intensive design sprint into a “parallel-and-integrated-within-our-one-week-lean-agile-sprints” is that we can work in the various members of the team throughout. Spreading knowledge is an agile value. Making these exercises an opportunity for co-creation across the entire team brings that value to life.
We’ve also found that it’s okay if, say, one engineer participates in the first week’s activities; and a different engineer participates in the second or third week’s activities. Same for design. As long as you document the work and collaborate transparently, each exercise is discrete enough for team members to join as resources are available.
Challenges: What if the CEO/major decision-maker doesn’t have time?
This is almost always going to be the case. Decide whether the C-suite needs to be directly involved (many times, they have already designated someone else as the Product Owner). Decide when and where their time is needed. Starting something new or pondering a radical departure? Perhaps that’s the time to conduct stakeholder interviews in place of or in addition to user observations. You can invite your C-suite to participate only in the “How Might We” note taking and decision-making exercise. Don’t let them be a blocker.
Challenges: What if I have never done this?
The best way to learn is by doing. This might seem overwhelming, and it will feel like a lot of new information. The great thing is that there is structure to each of these activities. Sure, you’ll feel uncertain. You’ll fumble and stumble. But by taking action, you’ll make progress.
We all had to do this for the first time at some point. Google and YouTube are your friend. All of these exercises are well-documented. You can do it!
Challenges: Why is it worthwhile to build “fake things”?
Prototypes are prototypes. If they convincingly communicate the product idea, the learning should be valuable. If you work in a culture where the only thing that matters is functioning code, try helping your team take a step back. Ask them if they would rather have some level of validation of a concept that is gained in parallel to building prioritized features (and gained in 4 weeks or less) or if they would like to budget the full team’s efforts over a greater time period only to risk delivering a solution that may fall flat or fail completely?
Address the cost. But also think about how motivating and energizing co-creating can be.
Challenges: How can this fall apart?
Oh, let us count the ways.
But seriously, risk is inherent in any product initiative. Keep to the structure. Don’t let exercises spin out of control. Respect the timeboxes (use a timer!). Rely on the voting and other decision-making mechanisms. Identify a final “decider” before you begin, if one is needed.
Don’t let the process spread out over too many weeks. Be flexible, but firm.
Be open to learning along the way. Don’t wait to implement quick wins.
Above all, figure out what works for you, what doesn’t, adapt, and make this your own.
Tricks: Useful tools
Honestly, we’re still figuring out the best way to facilitate some of these exercises in our remote-first culture. Sometimes it feels like nothing can beat being in the same room. It’s fun to attach sticky notes and sketches to a whiteboard, placing colorful, tactile dots on ideas and drawings. And it’s a real bonding experience to take breaks with your colleagues over the beverage of your choice.
We lean heavily on:
- Zoom for audio/video: try to make sure each person on the team has a web cam on, even for the exercises that include mostly solo work. If there is a group in one location and individuals who are remote, see if you can get all of the local group members on the video feed. Test your audio, especially in group settings. Ask people to speak up and repeat themselves.
- Slack: a dedicated Slack channel can help. See the “How Might We” list and voting mechanisms above. There are ways to adapt those same ideas for other needs, too.
- Miro: try it as a digital replacement for a physical whiteboard.
We hope that you’re inspired by our design thinking experience to try this in your own product development process. Use the tips and tricks that we’ve outlined here to help sell this process to your internal and external teams.
We're building an AI-powered Product Operations Cloud, leveraging AI in almost every aspect of the software delivery lifecycle. Want to test drive it with us? Join the ProdOps party at ProdOps.ai.