Design Sprints
Enterprise Software
User Experience, Visual Design
8 months // 2019
Over an 8-month period, my manager, Aksa Alex, and I facilitated 5 design sprints to streamline certain workflows that caused the customers a lot of pain. For this discovery work, we were given the freedom to think outside the box and not be bound by current framework restrictions.
UX, research, wireframing, prototyping, user testing, visual design - Kailyn Lim
UX, research, wireframing, prototyping, user testing - Aksa Alex
Design system - Bryan Walker
Product - Kim Howard, Kim Felice, Dan Braun
Engineering - Reda Colli, Amandelyn Wilson
Services - Isabel Keogh, Blair Bonnema
Support - Tracy Urban
Discovery Process and Phases
Below is a discovery process Mitratech employs. It's a highly collaborative process, not only internally, but with our customers as well. Through client calls and onsite visits, we discover the customers' workflows, pain points, and wishlists. From there, we create a value map with ideas and concepts that would relieve pains and create confidence in our users. After validating the ideas with our users, we go into a design sprint to further flesh out the high-level concepts. We share the outputs from the design sprint with our internal stakeholders, as well as our clients, to ensure that we have successfully created meaningful solutions.
  • Customer profiling: prioritized list of jobs, pains, and gains
  • Value map & concepts: prioritized value map with top 3-5 ideas and high-level concepts
  • Solution fit: evaluate value proposition and buy-in on the approach
  • Design sprints: interaction design concepts and prototypes
  • Design feedback: feedback on wireframes and workflows (multiple cycles)
  • User acceptance testing: focused feedback on an interactive prototype
  • The Problem
    A process that should be simple and seamless has become complicated with necessary touchpoints and verifications. That, coupled with a lack of helpful notifications and alerts, hindered the users from completing tasks.
    Streamline and simplify the convoluted process by reducing the number of steps and increasing collaboration between the user groups and platforms. Provide a user-friendly interface with consistent interactions that would allow both parties to achieve their goals with confidence.
    Prior to kicking off the first design sprint, the product team, including the designers, conducted research in order to gain a thorough understanding of the customers and their use cases. In total, we had 13 one-on-one interviews with customers (one was on-site in Houston, TX), 5 stakeholder conversations, and 2 internal and external surveys. Below are some of the findings. Some validated the problems we had already been aware of.
  • One too many - a simple request from one platform to another is currently a two-step process. This area gave user groups the most amount of pain. This is also a workflow that is the most widely and frequently used by the customers, so we knew it should be prioritized.
  • Notifications & reminders - not-so-robust notifications and alerts in the applications make it challenging for the customers to stay on top of their tasks that are interdependent.
  • History - there is not enough historical data for the customers to make informed decisions.
  • Transparency - the lack of communication and transparency between the two user groups often resulted in back-and-forths, rejections, and delay in subsequent workflows.
  • Design Sprint
    A design sprint is a five-day process for answering critical business questions through design, prototyping, and gathering feedback from customers. We actually experimented with our design sprints and have tried various lengths: one week, a week and a half, and two weeks. In the end, we decided that one-week sprints worked best for us. During the design sprints, we got together and collaborated on how to solve a specific problem from many different angles. We have had a total of 5 design sprints so far, each sprint tackling a facet of the bigger problem.
    These are the craziest days! On the first day, we have our first internal meeting to get everyone up-to-speed on the problem and the specific use cases (my manager and I like to review the sprint brief a few days before to feel more prepared). Then the discussion starts. It's a safe place where people think of ideas or solutions, and others bring up important points that could support or challenge those ideas or solutions. It's highly collaborative. After the meeting, the designers go back to our workspace and sync up. This is when we come up with the solution concepts and start producing sketches and lo-fi wireframes.
    On day 3, the designers present the possible solutions in the form of wireframes. We walk through the flows (just screens at this point, no prototypes yet) and gather everyone's feedback. Did we capture all of the use cases? Do you see any potential issues with these solutions that we are proposing? Which solutions should we move forward with?
    Depending on the type of feedback we receive the day before, we may have to go back to the drawing board and come up with new solutions. Sometimes, we just need to make tweaks, big or small. After fleshing out the details, the designers create interactive prototypes that cover all of the use cases. We then share and validate them internally. After that, we do user testing in the client working group to validate our solutions.
    The design sprint comes to an end! The last day is reserved for a retrospective and feedback session, which the designers own and lead. We ask what went well, what can we improve on, and what we should show more or less of in the following sprints. I appreciate this "continuous improvement" approach. It's in this meeting where we decided to try out having a two-week sprint because we thought we could use the extra time to produce more polished work. However, in the end, we decided that having one-week design sprints worked best.
    Design Sprint Outputs
    At the end of each design sprint, we created and validated solutions that not only improve the user experience in specific workflows but also the overall user journey. We simplified and streamlined the process flows to ensure that the users felt empowered and self-assured, which in turn, would also reduce the number of Support calls.
    Design sprint was a lot different than PI (program increment) sprint in that I had the creative freedom to come up with as many ideas as I could without a lot of restrictions. Of course, the solutions had to be technically feasible, and that is why we had two engineers in the internal discussions. Although these sprint weeks were jam-packed with deliverables and meetings, those were also the most exciting, inspiring, and productive weeks.
    Initially, we had trouble getting feedback from customers. We would share our forward-thinking designs in the one-hour working groups following each design sprint, but due to the amount of work we had to share, we would often run out of time for feedback. After two lackluster working groups, I made a suggestion that we utilize the client working groups to do user testing. Rather than just going through our interactive prototypes and explaining our rationale, we would ask the participants to perform specific tasks using the prototypes. The groups were relatively small - consisting of 2-3 people - so this method was effective. It also sprouted engagement from everyone on the call.
    The other challenge we initially ran into was collaboration. This stemmed from my manager working remotely in Houston, TX, while everyone else on the team worked out of the Austin office. Communicating and brainstorming ideas together became difficult at times due to distance. Therefore, we used a tool called Miro to combat this. This platform allowed us to build user flows together and share comments in real-time. In addition to that, my manager drove to Austin for the last two design sprints and spent the first two days, so that we could brainstorm and do sketches together in person.