Watch the Video Replay of our June 30th Webinar
The digital side of healthcare brings with it problems that are often large, sometimes ambiguous, and almost always complex. It can be daunting to try and determine where and how to start. That’s where UX Strategy Sprints come in. They’re the perfect approach to develop a clear, actionable plan to solve these uniquely weighty problems.
- Learn what a UX Strategy Sprint is and how to use this framework to unlock innovation in your organization
- See how the UX Strategy Sprint process encourages alignment, uncovers solutions, facilitates informed decisions, and prioritizes opportunities for improvement
- Learn what use cases the UX Strategy Sprint is ideal for and how it can work for you
On June 30th, 2021 we held a webinar on UX Strategy Sprints.
Craig Nishizaki: Hello, and welcome to our unlocking innovation in your healthcare organization with the UX Strategy Sprint webinar. We’re happy to have you all join us today. The UX Strategy Sprint is a process that we’ve developed at UpTop Health for solving complex problems. And our goal today is to share with you this process that we’ve found to be very beneficial to us and to our clients. The agenda for today’s webinar, we’ll be walking through the opportunities and use cases where a UX Strategy Sprint fits well. We’ll talk about what a UX Strategy Sprint is and do a deep dive into the process of a UX Strategy Sprint, and then what the deliverables and outcomes are from that process. At the end of the presentation, we’ll be doing a live Q&A. And so if you have any questions that you come up with during the presentation, please feel free to add those into the Q&A in your Zoom toolbar below. We’ll be monitoring that throughout the presentation.
Joining me today are Michael Woo, our Director of UX and Deborah Roberts, our UX designer, and I’m Craig Nishizaki, head of Business.
Well, let’s look at the opportunities that you face in delivering digital healthcare. And these opportunities come in different ways. Some of the opportunities are created by market shifts. So the consumer expectations are higher than ever. We live in a experience economy, and healthcare is really an experience industry, no longer a delivery industry. Our expectations are shaped by our daily experiences, whether it’s in retail, travel or banking. And those are the high standards that we all need to live up to now in the healthcare industry. The competitive landscape is changing. Digital giants, retailers and startups are all making heavy investments and quickly moving into the space to try to disrupt the industry. Delivery model and business model changes are happening. Value-based care, telemedicine, virtual care, just to name a few. And what Gartner calls the multi-experience has made things even more complex.
As you think about the overall customer experience, what you need to consider, what we all need to consider is not only the digital touchpoints, the physical touchpoints, but the person to person touchpoints. And so in considering each of those, we need to look at the user experience, the employee experience and the customer experience all up to ensure that we’re meeting the mark for our consumers with their high standards and helping them to achieve their objective, which is reducing friction, reducing effort and reducing time. Convenience is the key.
Some other challenges and constraints that we live within in the industry are legacy systems and processes working with them, working around them or replacing them, the complexity of healthcare systems data and data interoperability, the digitization of processes and workflows to create efficiencies and better outcomes, and many of those projects are already in flight, as well as culture. Now you’re having to move at the pace of digital giants and digital natives in a healthcare space. And that’s challenging for many organizations.
In 2019, Gartner reported that 80% of CEOs have a digital transformation or management initiative underway, and nearly three quarters of executives admit to being dissatisfied with the current efforts or the progress being made. But what’s interesting is in 2018, Forrester did a study commissioned by Adobe, and they found that experience-driven healthcare firms attained their goals in experience, digital business and revenue. And these experience-driven healthcare firms, payer, provider and pharma had the same characteristics. They embrace the technologies, strategies and tactics that other industries use to succeed in improving their customer experience and the derived insights on their customers to deliver digital experiences that lead to engagement and loyalty. And the results are pretty astounding.
These experience-driven firms, healthcare firms saw 1.3 times increase in customer advocacy and 1.9 times improvement in customer satisfaction. They were 1.5x more likely to see an increase in stock price and 1.7 times more likely to see an increase in customer lifetime value. And although they were slower at delivering new products, they were 2.3 times more likely to lead in product reviews and ratings on those products. And the common thread again, is that these organizations embraced the technology, strategies and tactics that other industries have been using to improve their customer experience. And they derived insights from their customers to then develop their digital product.
And as we were building out and developing our UX Strategy Sprint process, we found that these held true in terms of whether it’s in the healthcare industry, professional services or software and technology, that there are certain use cases where a UX Strategy Sprint would be hugely beneficial and be the right approach. And there’s four use cases that I’d like to quickly touch on.
One use case is reducing friction across the customer journey. Now, example of this would be a project that we did with Premera Blue Cross when they had an initiative to reimagine their member portal, they wanted to improve the customer experience throughout the journey. So pre-purchase, purchase, onboarding, consumption, and support, if you will. And they were looking for an outside in perspective to guide them through that process. As we went through the UX Strategy Sprint process and the concepting, they took the opportunity or found the opportunity to look at evaluating their third-party services and vendors that were providing products and services through their plan. And in looking at those, trying to evaluate whether they should continue with those third parties or if they should build a roadmap to develop those products internally. And that was one of the outcomes of this UX Strategy Sprint was allowing them to think through what that roadmap might look like.
Another use case would be modernizing processes and systems. So a recent project we did for a Fortune 1000 insurance and financial services company that was looking to evaluate their policy admin tool to make a decision on if they should continue to invest in it or replace it in the next two to three years. In going through this process, the UX Strategy Sprint process, we identified with them opportunities to improve processes and workflows that potentially could cut the time to quote by 50%. And in finding that insight, it allowed them to really have some financial conversations about the cost of keeping a tool versus replacing it, as well as looking at the business impact and the opportunity cost.
Another use case that we found UX Strategy Sprints to be very valuable for is solving complex and ambiguous problems. An example of this could be with Quorum Review IRB. Quorum Review is a third- party independent review board. And they were the first IRB in their industry to create a client portal back in 2006. And their portal had evolved over time, features had been bolted on over the years and the user flows were dictated by old processes, but they needed to modernize their client portal to stay competitive. And they were constrained by disparate legacy systems that were all tied together somewhat loosely in this portal experience. And their big question was where do we start? And so the UX Strategy Sprint process allowed a more formalized structured, but lean way to get them started to create a phased roadmap that allowed them to start planning the budget and the resourcing necessary to then redesign, rebuild and commercialize a new client portal.
And finally, the fourth use case that we found is envisioning the future. An example for this would be outside of the healthcare space, work that we did with Microsoft as they changed their go-to-market strategy and went away from field sales to an inside sales organization, the problem that they needed to solve was hiring, onboarding, training and enabling 6,000 inside sales people worldwide at scale. And with them, we envisioned a sales enablement platform that took that salesperson from day one through the rest of their life of onboarding and training, but more importantly, provided the sellers with the sales tools and resources to enable them to speak to a prospect contextually based on who they are and where they were in their buyer journey. And the big outcomes from that initial concepting was the funding and the support of executive leadership to move forward. And the outcome over time as that product or that tool was commercialized was they were able to reduce time to onboard new sales folks by 50% and increased the consumption and effectiveness of their sales content by 74x.
And so what we found in doing the UX Strategy Sprint process with various companies across various industries, and now really focusing it in healthcare, is that for any of these four use cases, there’s a way that you can align on the vision or identify the problem, align on the vision, look at solutions and then quickly come to an agreement as to an approach that you can then build consensus and alignment around. And I’ll turn this over to Mike to talk about what a UX Strategy Sprint is and move into the next section.
Michael Woo: Thanks, Craig. So let’s dive into what a UX Strategy Sprint is. Our UX Strategy Sprint uses the design thinking framework as the approach for solving large, ambiguous and complex problems within an organization. So just plug in here all the use cases that Craig had just spoke about. Many years ago, we had already a design process in place that drove high velocity at the start of any project through our strategic discovery process to learn more about our clients, the problem space and their users, but when the design thinking framework and Google’s product design sprint were emerging as bonafide tools, we really wanted to figure out how to integrate those into what we are already doing.
So for those who might need a refresher on the design thinking framework, there are five main pillars, empathize with users first and foremost, truly define the problem that you’re trying to solve, ideate or generate as many solutions as possible, prototype the very top most ideas, and finally, test those ideas with actual users so you can gather actionable insights. The underlying themes for this framework are a focus on human empathy, a bias towards action and an attitude that failure is okay. I personally believe this framework can be a great catalyst for innovation when executed both tactically, but more importantly, when integrated culturally across your organization.
I mentioned that our UX Strategy Sprint was inspired by Google’s product design sprint shown here. As you can see, the pillars of the design thinking framework are embedded in this 5-day Sprint, which typically are meant to solve problems that are narrowly defined, have existing research in place, and a team working on the problem that is already aligned. All three of which were the opposite of what we were seeing clients approach us about. But what was attractive to us about this five day sprint process was its structure and the formula for delivering great outcomes. So that takes us to our UX Strategy Sprint framework. We’ve spent a number of years tweaking this framework as we learn new things, trying to make it even better.
The first thing that you notice is the double diamond illustration, which is commonly used to illustrate the divergent and convergent thinking that’s happening throughout the process. We also call this flareup focus. Starting at the end, at the right, you’ll see the North Star Vision. At the beginning of the project, our goal is to define what that North Star Vision is, which basically encapsulates the problem that you were trying to solve and the longterm vision for it. Then once that is defined, we then work towards that end state. So let me describe to you at a high level what’s happening in this framework.
And the initial discovery phase, that’s where we begin intake and research to get up to speed in the problem space. We review any existing research provided by the client and our team conducts any editor research that may be of high value to the project. We then pull in all of this research into the client collaboration workshop, where within that has its own set of structured activities of divergent and convergent thinking.
By the end of the workshop, we will have done a post-workshop analysis, incorporating all the insights and ideas that were teased out. The client team and our team at this point will be in alignment on the problem to solve and have a strategic blueprint to move forward. The design team then starts ideation and concept designs, doing additional exploration on the different possibilities. At the same time, we are beginning to build an interactive prototype of the experience using our designs. And working closely with our client stakeholders, we share our progress and iterate until we are in perfect alignment. The last leg of this framework puts the interactive prototype in front of actual users to elicit additional feedback and actionable insights. And through a series of continued iterations, we will have arrived at the North Star. We’ll go deeper into each phase in a bit.
To summarize here are the high level differences between a 5-day Design Sprint and a UX Strategy Sprint. A UX Strategy Sprint, again, solves complex problems and is the appropriate method when existing research is light or even absent altogether. From a deliverable standpoint, although both methods produce prototypes, a UX Strategy Sprint prototype will typically be more comprehensive and have higher fidelity, which is more beneficial for sharing the vision internally and getting buy-in. A Strategy Sprint will produce the North Star vision that we spoke about of a larger digital experience rather than a smaller experience or just a product feature for that matter.
And of course, recommendations and a UX roadmap are a key part of the deliverables to ensure there is an actionable plan after delivery. Although the Strategy Sprint is much longer than a 5-day Sprint, it is amazingly short timeframe for the type of deliverables that are generated, including the interactive concept design prototype that has been tested with user feedback and iterated on using an accelerated method called RITE, which we’ll touch on later as well. So the team that typically works on a UX Strategy Sprint looks like this. What we found is that keeping the team small yet diverse enables us to be quick, nimble and even more effective. So now I’m going to pass the next couple of sections to Deborah and have her speak to those.
Deborah Roberts: Thank you, Michael. So we’ll start with the first part of the sprint, intake and research. We kick off every project by gathering and reviewing key information from our clients. This might include business requirements, technical documentation, existing UX or market research, internal process docs, and so on. And this allows us to move at a high velocity early on and get a better understanding of the problem space. And often, we’ll find there are some unanswered questions or knowledge gaps for the particular problem we’re trying to solve, which leads us to additive research.
So here, we identify any key research activities that would be critical to the outcome of the sprint and regenerate high value insights for the team. And oftentimes, in working with clients, we find that there is existing quantitative research like analytics data, which can be helpful in identifying problems and patterns. However, it doesn’t always give you the why. So in these cases, we’ll perform qualitative research activities, such as user interviews or usability testing of the current system, where we ask users to walk us through relevant tasks they might complete in the tool or digital experience and answer follow-up questions. And this type of research is extremely valuable because it allows you to get to the what, how and why of your users behaviors and reveals their mental models. We also will note things like physical evidence, body language, tone of voice, cadence of speech, and these findings combined to create a more complete picture of what users are thinking and feeling at each step of their journey.
So moving into insights and analysis. Critical to the process is the UX Strategy Sprint workshop in person or remote, where we walk our clients through structured activities designed to foster divergent and convergent thinking. And using data gathered from intake, our team will plan the exercises for the workshop. And if going remote, we’ll do some additional prep work like mapping the current user journey ahead of time so that during the workshop, we can save time and jump into the critical areas of the flow. And when thinking about who to include in the workshop, you want to make sure that you include key stakeholders from different parts of the business. This typically includes the facilitator and designer, and we often are representing that portion of the team. It will also include a decision-maker and executive, IT representative, product owner, program sponsor and voice of the customer or a user.
The workshop itself is usually scheduled for five hour blocks over the course of two to three days and brings together these stakeholders from the different areas of the business to solve the problem at hand. And always, we try to set the stage at the beginning of the workshop with expectations and guidelines. Some of the exercises we’ve found can definitely push people out of their comfort zone, especially when moving into the ideation and sketching phases. And we just like to encourage people that there are no bad ideas and to have an open mindset because each of them has been chosen for a reason and represents a unique perspective that is extremely valuable when trying to brainstorm solutions to these complex problems.
And the initial workshop and discovery activities, we work to identify and reframe the problems to align with business objectives, technical considerations and user goals. So this includes activities like a long- term goal and sprint questions where we encourage participants to voice concerns about what could go wrong. We also deep dive into the customer journey map, where we conduct a number of activities such as expert talks and How Might We statements that helps you uncover insights and target critical areas of the user flow that can be opportunities for design.
Next, we lead participants through sketching exercises designed to help them think outside of the box and create a multitude of potential solutions. And then finally, we help prioritize by doing impact versus effort assessments through the lens of investment, user benefits and technical effort. This allows you to align around the highest value items and identify any underlying structural issues that must first be addressed.
Post-workshop, our design team will meet to review, analyze and discuss all the insights gleaned from the client workshop. And our design strategy is adjusted if necessary, based on any new information. And we recently completed a UX Strategy Sprint with the leading financial services and insurance company who wanted to explore how they could evolve their current workflow, processes and systems to improve their team’s communication and efficiency. And during intake, we conducted user interviews where we ask participants about their role, responsibilities, goals, motivations, and also to put in their words why the tool should be redesigned. The walkthroughs allowed us to see the flow and steps needed to complete the tasks and illuminated side processes that people were using outside of the tool. It also exposed us to frustrations users felt at the different interaction points along their journey, as well as the functionalities that they wished that they had.
After the research was completed, we created an overview of the primary user personas, highlighting information like their title, background, goals, and motivations. Next, we plotted the resulting workflows on a journey map, including the pain points and emotions they encountered along the way. The full journey map shown above was more than 70 individual steps, which we consolidated down to 21 main steps shown below for the purposes of the workshop. We showed both maps at the beginning of the workshop, which was a big aha moment for the participants as it illustrated the complexity of their process and the need to simplify and restructure.
After reviewing the journey map during the workshop, we invited subject matter experts to deep dive into critical parts of the flow and ask the other participants to frame problems that were identified as How Might We questions. This practice allows more freedom when moving into brainstorming and ideation. And these activities helped workshop participants to visualize the complex workflow, build empathy for their team members, and also highlight the areas that had the largest amount of friction and opportunity for improvement that could map back to their long-term goal.
With this knowledge, we were able to move into ideation and prioritization with confidence. And after the sprint, we received feedback that the process really helped to bring team members along that were feeling unsure about the upcoming changes. They noted that the workshop opened their eyes to how much room for improvement there was with their current system and process and they were really impressed by how many great ideas everyone had for making it better. So now I’ll turn it back to Mike to go through the last two phases of the UX Strategy Sprint.
Michael Woo: Okay. Thanks Deborah for walking us through the first two phases and sharing the examples. Those were great. So what does it mean to define the critical path? The critical path is one of the tweaks that was added later to our framework. Before we start concept designs, we want to establish what we call the critical path, or we even call it the happy path. This means framing the story to be told through the eyes of the user. It focuses on 80% of what the user does and fences in the experience that you’ll be designing and prototyping.
So here’s a guide to writing that story or user scenario. Of your different personas, you want to choose one, which the story will be told about, what is motivating this person to take action? What task or goal is this person trying to accomplish? Are there any relevant demographics about the person that you could pull into the story? What is the main pathway that this person takes to complete the task? You want to include and highlight key user interactions or potential points of friction to highlight how your new design is solving these problems. And just know, most of the time, we’ve seen some alignment of the story or user story to the customer journey map that has been created and shared in the workshop. So that’s a great place start.
So what sparked this idea of the critical path came from the work that we did with Premera. One of the biggest challenges we faced was figuring out how to integrate what was important to five different product teams shown here in blue. Each team had a deep list of issues that they wanted to address, but rather than go deep, we had each team highlight their most critical items on their list. And the aha moment came when we said, what if we can weave together these critical items from each product group into a single cohesive user scenario or story.
So we began writing a draft of what this might look like through the eyes of Mary, who we named this persona. And the abbreviated version of this story is about Mary, who is diagnosed with a hypothyroid problem and require special medication. She relocated to a different state, shops for a new health insurance plan and selects a new primary care provider. After her condition worsens, she’s referred to a specialist by her PCP and is able to look up estimated costs on the site prior to her visit. The journey continues to walk through automatic claim filing from her visit as well as real-time tracking status of that claim. The story wraps up with an easy prescription refill request and approval by the doctor. This scenario became absolutely critical to framing the remainder of the project for us.
So on to ideation and design. Using the critical path as a blueprint, the design team can now start work on the process of diverging and converging on different design concepts. Even though solutions were ideated on within the client workshop, it is within this process that we as designers begin to visualize that. The process may start off as super low fidelity sketches that are part of a storyboard just like this or these designs may start at low fidelity wire frames or graduate into them from sketches shown on the prior slide. After several rounds of review and iteration with the client to ensure alignment, we then eventually graduate to final high fidelity design shown here.
In some cases, high fidelity designs may be accompanied by animation or video within the design because of the value that it brings to the overall experience. But it’s important that it supports your overall goals before you add those things. A pro tip, we found that tailoring the fidelity to the person who will ultimately be the decider for further investment on their project can be very effective. This means doing a little research ahead of time to find out what this person will responds to best. I want to show an example from a recent project we finished with HMA. These were three initial design concepts presented to the client. Now, based on the info we gathered in discovery, it led us towards these directions. Unfortunately, however, none of these hit the mark and not even close, but that’s okay because the designs allow stakeholders to react and respond, which is part of the design process.
So in our second design review, these revised concepts were presented. And I’m happy to say we nailed it. After a further iteration and refinement, we ended up here for the final designs. So to sum up, the ideation and design process is emblematic of the greater framework, which is creating an output to garner reaction and feedback so you can learn and improve.
This is the perfect segue into prototyping and testing. So why should you prototype? I started creating prototypes on a regular basis back in 2008. And since then, have made it a requirement to do it on every single project that we’ve worked on, no matter how small it is. So prototyping turns flat designs into a multi-dimensional experience through proper framing and context, tangibility through interaction and spatial awareness through linkable screen flows. So what this really means is, have you ever looked at screen mock-ups in a PDF or PowerPoint deck and have to figure out which screens connect to one another? That’s what a prototype does for you. It takes the guesswork out and brings clarity to an experience that you’re trying to simulate.
Explain why you should prototype wasn’t enough, here are the benefits. It helps get internal buy-in faster by allowing people to align around a vision and truly understand how a feature experience will work. It helps the design team conceptualize their own vision and more clearly iterate as needed. And finally, it allows the development team to better understand the vision by removing assumptions and allowing them to prepare a roadmap for implementation.
Now, moving on to usability testing, why should you do it? In recent years, I’ve seen an uptick in usability testing as part of the conversation with clients, which is great. But for those of you who are new to testing or maybe thinking about incorporating it into your process, let me remind you what it is and why it’s a must. If you’re creating completely new designs or a new feature for your site or app, no matter how much best practices you use, how do you know for sure how it will perform with your users? Put another way, are you willing to be accountable if it costs your organization thousands of dollars?
Now, I know there’s no way to ship a design with absolute certainty, but usability testing allows you to reduce those risks by cashing them early and allowing the design team to learn from that feedback and produce more optimal designs. It’s just a natural next step after the design team has created a prototype, and this will be used as a basis to learn from. And mind you, testing isn’t just for new experiences. If you want to know the why behind current or live experiences performance outside of the numbers, perform usability tests with real users to find out.
The RITE method. In our design process, we use a method of usability testing called RITE. It was born out of Microsoft, and it allows the design team to rapidly iterate on designs as soon as usability issues surface. So you may have only six total users to test designs with, you can put prototype designs in front of the first two users and come across usability issues. The design team quickly addresses those issues and updates the prototype for the next set of users and so forth. By the end of this process, the designs should be in pretty solid shape devoid of any major usability problems. Now, the downside is obviously the limited number of people that may quantify anything as an issue. However, when you have experienced designers facilitating these tests, it’s pretty easy to spot what may be a real issue versus what is subjective feedback. So use the RITE method as another tool to turn to, but not necessarily as a replacement for traditional usability testing.
So the benefits of a usability testing are, it allows you to see from the user’s perspective how designs actually perform, it helps you see the why behind the numbers. And what I mean by this is Google Analytics can tell you that a page is not performing well, but it can’t tell you the why. Okay. And I alluded to this earlier, but it saves costs in the long run by working out bugs in design rather than in development, which has proven to be as much as a 100 times more, depending on which step of the process you’re at. Usability testing just makes good business sense, period.
For this last customer spotlight, I wanted to share the role that prototyping and testing played in the design process. The work that we did with HMA and their portal design included creating branded experiences for three brands, RGA Washington, HMA, and RGA Oregon. However, we decided to create a single prototype that would essentially use the same template for each of those three branded experiences. As the concept designs were being fleshed out further, we began prototyping the experience to connect all the key screens together. The tangibility of the prototype enabled the product team to really get a sense of how everything flowed, including the flows for submitting a claim and the flows for sending and receiving messages with customer support. Lastly, with regards to usability testing, time and access to real users was limited, which is not uncommon, but we were able to still do testing with a diverse set of folks who had health insurance of course, in the WeWork office that we were at.
What we found from testing was interesting. So simple things that HMA took for granted internally showed up in the experience. For example, taxonomy such as the acronym EOB, which is explanation of benefits and the term schedule of benefits wasn’t terminology that was understood by regular people, not surprising, but icons without supporting labels to them were also not interpreted correctly, tabs using the original design and carried forward into the new design to house claims detailed information was not discoverable. Additionally, the location of specific items like benefits and deductibles on the homepage, which mirrored the original designs were also not discoverable. So again, even though these specific test insights were somewhat minor from a change perspective, they were indeed impactful on usability for the user.
So finally, let’s talk about deliverables and outcomes. Upon the conclusion of the project, the client typically receives a link or downloadable to the interactive prototype for sharing across the organization. Now, this might be in the form of InVision, Figma, Adobe XD, or whatever application that might be best suited for the client, which is determined at the start of the project. We also produce a video walkthrough of the prototype that can be accompanied by narration, which is a great standalone piece that takes the viewer down through the critical path in minutes, providing all the necessary context that the viewer needs without having someone actually explain it to them.
Last but not least, we generate a UX summary report that includes all of the research findings, including links to any user and stakeholder interviews, notes and insights, all of the workshop activities and outcomes captured from the workshop, including video recordings of their workshops themselves, a feature prioritization list of the North Star concept, documentation of the massive ideas that were generated from the workshop that can be prioritized for future exploration, UX recommendations, and actionable next steps for the organization to take. And lastly, a technical implementation roadmap from MVP to vNext.
So just to wrap up, these are the outcomes we’ve seen from a UX Strategy Sprint, tangibility that you get with the interactive prototype, a concept design that’s validated with actual users, business leverage as a by-product of the first two items that I mentioned above, internal cross functional alignment, not only from those that were directly involved in the UX Strategy Sprint, but as the vision is being shared across the organization. And lastly, what we’ve seen is faster and easier executive buy-in, and as a result, additional project funding to move the vision forward. In closing, our UX Strategy Sprint has a lot of similarities to these other frameworks out there. It’s user centered, built for speed and uses a structured approach, think big and focus when you need to. We’ve just created a framework to solve larger and more ambiguous problems, especially those seen in healthcare. Through this process, we’re trying to make the lives easier for both our clients and their customers and create great digital experiences at the same time. So with that, let’s open the webinar up to some questions.
Craig Nishizaki: All right. Well, we have a few questions that have come in and we’ll go ahead and start off with those. There’s about six of them that we’ll start with. Some of them are grouped together and I’ll ask them. And then, Mike and Deborah, you can jump in or I’ll jump in to answer. First question we have is “At what point in a project is the UX Strategy Sprint most beneficial?” Mike or Deborah, do you want to start off?
Deborah Roberts: Yeah, I can start. I was just going to say that a lot of clients that we work with will actually kick off their project with a UX Strategy Sprint. It can even be helpful when you’re trying to get the budget for a particular project. We’ve worked with clients along those lines recently, actually.
So, what we’ll do is we’ll come in. We’ll do the sprint, the workshop on… It’s really great to hear at that point when it’s really early from the different stakeholders of the project and key areas of the business. We’ll create this envisioning prototype. And then, that is actually used to pass around with other stakeholders or higher-up executives that are actually kind of controlling the purse strings, so to speak. That prototype helps to make the project more tangible because you have this visual that you’re passing around, especially like a video where you’re having someone kind of walk you through the prototype with audio and then you can actually see someone moving through what the visual experience will look like. It helps to get people excited and really communicate what the overall vision is. And then, that can lead into funding and then the execution of the project.
Craig Nishizaki: That’s great. Mike, you have anything to add to that?
Michael Woo: Yeah, just really quick. At a high level, when the strategy hasn’t been decided, I think, is when a UX Strategy Sprint would be most impactful. But even if it has been decided internally and then the project gets humming along and all of a sudden it comes to a screeching halt and internally you’re wondering, “Maybe, our strategy wasn’t good.” So, there’s no wrong time to do it, but I do think that it definitely makes sense to do it at a time when you’re questioning the strategy and all that part of process, for sure.
Craig Nishizaki: Great. A follow-on to that is “Is there a scenario where a UX Strategy Sprint would not be appropriate or could a problem be too large for UX Strategy Sprint?”
Michael Woo: That’s a great question, Craig. Yeah. I’ve been thinking about this. I’m not so sure that there would be a problem that would be too big, but one of my first inclinations would be to see if the challenge or the problem could be broken down into smaller chunks. For example, if you wanted to modernize all of your digital systems, rather than thinking of all your digital systems all up, maybe start with one first, the most impactful one. But that depends, right? But if the challenge is, “How do I make my digital systems more cohesive or streamlined?” As an example, that’s different. You can’t just break it down into smaller chunks. I think at that point, you need to just look through it through a different lens and adapt your sprint to work for that problem itself. What that means is maybe you have to pull in more people because with bigger the problem, it involves potentially more stakeholders and that kind of sort, but overall the structure itself would stay. In any case, you still have to adapt to the situation. What do you say, Deborah?
Deborah Roberts: Yeah, I would totally agree and add that in ways that we’ve mitigated that. Well, maybe, you do need to have more stakeholders present as you have maybe, more passive participants that are just watching the workshop itself. That way, they’re there. They’re along for the ride and they’re brought in early in the process. In that way, they can also give their input at some point and voice concerns or et cetera. But that can be a great way to include more folks.
Another way you could do is have breakout groups within the workshop. Maybe, have smaller groups. You would have to maybe, make the workshop longer, but again, I think the overall formula for that UX Strategy Sprint would totally still apply. It’s just being flexible and making kind of adjustments as needed based on your organizations and needs and then the complexity of the problem.
And then, there was also… The first part of your question, Craig, about if… “Would there be a situation where UX Strategy Sprint might not apply?” I would say that, possibly, if you have a more narrow problem, maybe, you’re looking at a particular functionality of your digital experience and you actually have a fair amount of research done already, then a more traditional five-day sprint might be a better approach.
So, it kind of depends on the complexity of the problem at hand, how much research you have, and then, also either, if there’s a number of stakeholders needed or if the problem kind of spans multiple sections of the organization.
Craig Nishizaki: Yeah. Well, that’s great. You actually answered the next question, which is what’s the difference between a UX Strategy Sprint and a design sprint? I think that was a good for both of those questions. The next question is actually interesting since we’ve all been working remote this last year. Are there advantages or disadvantages that you’ve seen to remote versus in-person workshops, as we’ve been talking about doing workshops as part of the process?
Deborah Roberts: For sure. I would say yes and there’s pros and cons to both. The nice thing about going remote is that it just offers flexibility for people’s schedules and if you have different stakeholders that are in different areas. That’s great. I also find that, with the remote workshop, we actually move a little faster. I don’t know, Mike, if you would agree with me there. But then the downside is that it’s hard to replicate the in-person interaction and the rapport that you build. That human-to-human connection, there’s just something about that. When you’re working together in person, it’s hard to duplicate that. We try as best we can. We have a little icebreaker at the beginning of our UX Strategy Sprint generally, as we introduced folks. We have different exercises that involve more collaborative brainstorming and ideation, than those that are more individual.
But the one tricky thing about remote is that you get tired, right? You can only stare at a screen for so long. So, we really have to make sure that we keep that in mind as we’re planning the activities and planning the length of the workshop, if we are doing it remote, so that people won’t get burned out.
Michael Woo: Yeah. I think the one thing too is it’s hard to keep track of what people are actually doing when you’re doing it remote because a lot of times people are multitasking and in person that’s a little bit hard to do.
Deborah Roberts: Absolutely. That’s a really good point.
Michael Woo: Yeah. Yeah.
Craig Nishizaki: Yeah. I think what I’ve observed in any workshop is being intentional, being engaged, and being present is the discipline that not just the facilitators, but the participants, have to have. From the top-down, that type of accountability to the process has to be modeled. I hate to say it, but oftentimes, as folks get higher up in the organization, they have so many other distractions and needs of their time that they have to pop out a lot. As that happens, it seems like the other folks in the organization start to take that on. So, it’s one of those things where I think you both, and our other designers, do a good job of setting the ground rules early, and then just being on top of that to make sure everyone’s participating.
Michael Woo: I was just going to say, going back to something Deborah mentioned earlier about observers, that’s where it actually applies as doing remote workshops because it is so structured and time is limited. You could only have so many people participate. Therefore, we have active participants, which is typically around 8 to 10 folks. And then, I know there’s cases where additional participants are requested by the client. They bring a lot of value, but at the same time, it’s hard. You can’t really blow that number up. And then, we include those as observers, like Deborah was saying. So, they’re participating in the process, understanding all the things that are being discussed, and ultimately are part of the team that’s aligned around the project, but again, it is very structured and there’s just no way for all those people to be participating at the same time.
Craig Nishizaki: Yeah. Actually that answered another question that we had, which was “Why is it important to limit the number of stakeholders in the workshop?” I think obviously, the remote workshop, the advantage is travel. If you’re bringing people in from around the country… We did a large one previously where folks flew in from all over the country to the West Coast and basically a three-day workshop consumed the whole week in that case. So, a remote is much more efficient from that perspective, for sure. From your perspective, are there challenges to… What are the challenges in a UX Strategy Sprint from the client side, as well as from our side, if we haven’t spoke on those? Yeah.
Deborah Roberts: Yeah. I would say, from the client’s side in the workshop… I mentioned this in the presentation, but some of the activities can definitely push folks out of their comfort zone. You might have someone from the tech side and you’re asking them to sketch out ideas. Maybe, that’s something they’re not maybe, comfortable with or they haven’t done a lot of work from that exact side. But again, the sketches don’t have to be pretty. Just to communicate an idea. So, we like to just remind folks of that and encourage them that it’s just so beneficial to have ideas from people from those different areas of the business, because they have proximity to maybe, something that someone else doesn’t. So, just having ideas from unique perspectives is just one of the great things that comes out of the sprint and the workshop in particular.
Michael Woo: Yeah. I like to add that, sometimes the speed at which we move might be a little bit too fast for the client, but once they get the hang of it, I think they are actually excited that things are moving so quick because internally, they may not be used to that. Yeah. I think they really appreciate the speed, the velocity at which we kind of hit the ground and just start running because everybody wants to be involved, right? Everybody wants to be involved in solving a problem that may long have existed. Yeah, I think that’s one thing I’ve observed.
Craig Nishizaki: Yeah. That’s great. I think the velocity, and then as people start having aha moments along the way, or being able to see a problem from a different perspective, and realize, “Wow, I didn’t realize that’s what that group did in terms of processing an order or supporting a client, et cetera.” And then, you start to see empathy grow between groups. Actually, a big outcome that we’ve seen a lot of times is some mended fences and better relationships that come through this because everyone’s working toward the same goal. I think the big question that… This was kind of a recurring theme of her question is “What are the next steps after a UX Strategy Sprint? You talked about a North Star vision. You talked about a roadmap, things like that. How have companies, organizations taken the outputs from a UX Strategy Sprint and applied them in a tangible way?”
Michael Woo: Yeah. I think this was kind of discussed earlier in the presentation, but typically, internally for the client, they began to shop it around, not only to other teams, but to the executive level to get that alignment, that buy-in, and ultimately, in most cases, the funding to move that project forward. And then, in terms of next steps for us and the client, we typically move into feature design. If it’s… It really depends, right, on the delta of the vision and actually building out that product. It could be additional concept with exploration to vet out maybe a little bit more ideas, more usability testing, but what we’ve seen, in a lot of cases, is actually executing on that vision and building that roadmap for an MVP launch. Ultimately, as mentioned, the next phase after that, we kind of stripped down that vision a little bit to get something out quickly and then work into these two-week sprint cycles, whether it’s with our team building it out or alongside with the client. That’s typically what happens next.
Deborah Roberts: Yeah. I would just add to that. Part of what we put together in our UX summary report at the end is kind of a roadmap and prioritization. That can be so helpful. That’s an exercise that we usually do in the workshop too is looking at the impact of the user experience and then also the technical feasibility. That helps you to determine, “Okay, is this an MVP? Can it happen right away? Is this really easy to implement? But maybe it has a smaller impacts. We’ll put that on back burner. Or is this going to be a much heavier technical lift, but maybe it has a really big user impacts. We definitely want to build that in, but we have to plan for it.” So, that is one thing or two that comes out of the sprint is it really helps you to prioritize all the things that you’re looking to do so you can execute most efficiently.
Craig Nishizaki: Yeah, that’s great. I really agree with you on the UX strategy document, the report of findings and the recommendations. I think that is such a valuable output because it allows for the organization to really look at what the findings were and why the decisions were made, or the recommendations were made, and make some decisions that way, rather than looking at things from one side, whether it’s a business requirements document, or a creative brief, or a technical roadmap. It’s really all that, combined together into one strategy that allows you to make some decisions about prioritization and trade-offs. So, I think that’s really a great output of the process.
We’ll, we’re coming up against time and that will actually… There was just a one or two other questions, but they were along the same lines. So, with that, we’d love to thank you again for participating in our webinar. We will be making the presentation recording available for replay and providing you with some downloadable resources as well. So, stay tuned for our next webinar. Hopefully, you gain some value and some knowledge out of this one. We enjoy doing this for you all. Have a great day.