It’s fall! I love this time of year when the leaves change, the days are cooler, and everything becomes more festive. Speaking of transitions, a few weeks back I wrote about the beginning of our transition to design sprints. So far we’ve completed three sprints so I wanted to share an update on our progress and an overview of how we’ve customized the process.
We found that the Google Ventures design sprint process was a helpful framework but we tweaked it slightly for our needs as a software development team working within a large enterprise with hundreds of thousands of employees and millions of customers. Since our success is dependent on many partners, we added in more activities related to understanding the enterprise context and creating roadmaps to execute any changes.
Enterprise Design Sprints
Without further ado, let’s walk through the process. There are twelve components and as I wrote about in the previous post, we learned that having “phases” worked out better for us than setting specific days because it allowed for more flexible scheduling. We could complete a few phases within one day or spread one out over the course of the week depending on the nature of the problem, the group’s knowledge, and participant schedules.
Step 1) Pre-sprint planning
In this phase we identify the next important problem to solve. These ideas come from partner teams, user feedback, initiatives, or the next increment of our roadmap. A design sprint might be overkill for very small changes but anything large, ambiguous, or less well-known such as an integration with a new business line, or changes to our approach for handling a business process or user experience benefit from this structure.
We also found that this process was helpful for any change that could be spread out over multiple releases or partner teams because the information gathered during the sprint informs the creation of a roadmap. The built-in user testing component of the process also makes it great for any topic where the team might make assumptions or debate about what is more confusing or less confusing for customers.
Step 2) User needs
In this step, we look at the end user perspective as they are going through life events and interacting with the business process. We start by outlining the customer segments and discuss any special notes about customer roles. Then we walk through each of the major segments and look at life from their point of view. What are their needs? What drives them? What are their pain points? I love how “Value Proposition Design: How to Create Products and Services Customers Want” suggests guiding the conversation because it is so simple and approachable.
Step 3) Business needs
Then we shift focus to the business stakeholders. What are the business goals? What do they hope to accomplish? If the initial request included a solution we ask questions to uncover the business problem. Are they hoping to streamline a step in the process? To improve transparency? A simple five whys exercise is helpful to uncover some of the root causes behind the problem or motivation behind a solution request. We also look at the needs, drivers, and pain points of employees involved in the process.
Step 4) Success criteria
This is the time when the group thinks about what “done” looks like and how we would measure progress towards the goals that we just outlined. How would we measure increased access? Do we have baseline measurements to compare to?
Step 5) As-is state
Since we don’t work on a greenfield project, most new enhancements require updating existing processes and systems. If you’re reading this blog about flipping complex systems you’re probably in the same boat. The as-is analysis phase is where we understand the current business processes and systems that are available. This information is useful at the end of the sprint, when we develop the Minimum Viable Product (MVP), phased approach and roadmap.
This phase also allows us to better understand the vocabulary the business currently uses, the touchpoints that already exist with their customers, and the degree of integration with enterprise services. By this point in the process we also have a pretty good sense of the personality of our stakeholders and how open they would be to radical changes, which informs our approach in the next phase. Stakeholders with less experience ideating tend to need a little more coaching. If a stakeholder seems nervous or impatient about “pie in the sky” discussions then we spend some extra time explaining the value of the exercise and assuring them that we will find feasible and valuable changes to implement quickly.
Step 6) High-level to-be state
When we get to this point in the design sprint we have a good idea of why a change is needed and the current context we are working in. This phase is all about dreaming. We open up the session with some prompts about ways to brainstorm ideas and then we’ll spend about an hour or so together writing ideas about how the future could look. This usually involves one person acting as a scribe and writing down the group’s ideas in an excel file. If your team is also remote, check out these brainstorming tips.
In one of our later sprints I experimented with writing the to be ideas in user story format “As a… I want to …. so that….” This exercise works well if the team tends to jump to solutions because it really forces everyone to think about the benefit of the change. That information is helpful during the next stage.
Step 7) Concept rating
Now we have a ton of high level ideas but we need to narrow them down so we can storyboard and prototype the solutions in two days. There are different ways to accomplish this but we started simple and opened up an excel file with all of the ideas in one column and the success criteria in the next columns. If an idea contributed towards the success criteria we marked “yes,” otherwise we marked “no.” That way the team was aware of potential future features, while we highlighted the concepts that would get us closer to achieving the immediate business goal in the short-term.
Step 8) Storyboarding
We’ve tried a couple of different techniques for this phase and it seems to really depend on the type of change we are implementing. For a change with a large front end component, the process outlined by the Google Ventures team in this article was effective.
Sometimes however the front end change is minimal or we want to design an MVP taking into account current constraints so we found it useful to spend a dedicated amount of time to understanding the components of our end vision and allocating them to earlier vs. later phases. That helped us to design wireframes that would accurately reflect what would be available at each stage so we didn’t confuse stakeholders or end users.
An example would be if we were trying to design an interface to show information, but the partner was not able to change their web services by the desired date. In that case we would need to plan to evolve the interface over time and would probably end up making more than one prototype to test the impact on end users.
Step 9) Prototyping
After the final storyboard is sketched, we assign each group member one or more steps to prototype. Then everyone individually mocks up their screen in powerpoint using a library of standard UI elements. Then we combine the slides and run a group walkthrough to make sure everything flows before a demo with the larger group of stakeholders to obtain their feedback before moving onto user testing. Steps 8 and 9 happen with a smaller group of around 6-7 analysts, designers, and architects. Steps 2-7 also include a larger group of stakeholders and subject matter experts.
Step 10) User feedback
During this phase we run remote user tests and obtain feedback on the usability of our solution and their general reactions to the value proposition and the business process. Those findings are compiled and shared with the rest of the stakeholders involved in the project.
Step 11) Roadmap creation
Throughout the prior phases we’ve been collecting information about the broader context, goals, and potential future states. We decompose the value propositions and write each one on its own post-it. Then, working with our cross-functional group of business, user experience, and technical resources we start identifying value propositions that we could deliver earlier vs. the ones that will require more partner and enterprise changes and therefore will be more likely to go live in a future phases.
I physically move the post-its around the wall with earlier phases on the left and later phases on the right until we end up with a draft plan. Those high level value propositions for customers are documented in a roadmap graphic and then after the stakeholder review are converted to portfolio and program epics and features and managed following the Scaled Agile Framework (SAFe) model. Some of the future phases may spark an additional design sprint when we move closer to implementation of that phase.
Step 12) Implementation
When a valuable and feasible MVP is identified we then move forward with activities needed to implement that change in the nearest release, such as updating documentation, obtaining final requirements approval, requesting web service changes, and so on.
Making these adjustments has allowed us to take advantage of the benefits of the Google Ventures Design Sprints while accounting for our coordination and planning needs. Have you ever tweaked a popular framework and made it your own?