During the design sprint
With a design sprint underway, understanding user and business needs is a critical step towards creating a useful design solution. Your team might use some of the following methods during the first phase of your design sprint.
Definition of a successful design sprint
Team members are asked two questions, one at a time:
- What does success look like for this sprint?
- How do we evaluate, measure, and track that success?
On a board, team members add notes or stickies next to the question. Group and prioritize the themes to understand which items are most critical to group.
A design team for customer service applications wants to get their customer dispute flow below a 5-day turnaround. Additionally, the team wants to reduce the high percentage of data entry errors during the dispute flow.
Why use it?
Defining a sprint outcome sets the baseline expectations for the team.
Persona and empathy mapping
Walk through the defined business problem to determine whom the problem affects right now. During this process, identify the user persona involved and processes users must take in this flow.
A user persona is a realistic depiction of a group of users of a product or application. Personas depict users by their work objectives, tasks, needs, attitudes, skillsets, and behaviors, in context with the users’ organizational role. User personas are derived from behavioral and work process research with users.
During this exercise, you will provide overview information for this persona, such as a name, role, description, goals, and drivers behind what they do. Once done, use an empathy map to explore what the personas:
- Think or feel
- Hear or see
- Say or do
- Experience as pain points
Additional considerations: Be thoughtful about how to describe each persona. While adding a name, role, photo, and a generic description of whom this persona symbolizes can help humanize the challenges, you may create bias through fake names, gendered language, or photos of people when trying to solve the problem.
Walking through the current dispute resolution problems, the team realizes the flow involves a customer and a call-center agent. When the issue is critical enough, a dispute analyst and a fraud investigator are also included. The team first identifies the details of the customer persona and maps how they feel when they see a strange line item on their purchase history, what they do about it. Then the team discusses how the customer feels as they deal with the whole dispute process. They continue the process for each persona.
Why use it?
Persona and empathy mapping helps the team empathize with the actual people, pain points, challenges, and emotions.
Journey mapping is depicting the user journeys in their current state. Create a flowchart of how the personas interact with each other throughout the process, while looking for clear separation of themes and processes. Map the pain points of each persona as they move through the process. Map the systems or record, tools, and APIs as well that are tied to each step in the process.
Walking through the current dispute resolution flow, the team learns the typical process is as follows: an incoming customer request to the call-center must be verified in two places with a call-center agent before any information can be discussed. Then the agent must find the transaction in question through various systems of record, identify the cause of the charge and relate that information back to the customer. Since the customer seemed to have no knowledge of these charges, the call-center agent had to put the frustrated user on hold while trying desperately to get a hold of the dispute and fraud team members. Then the call-center agent finally can discuss the issue on a conference call with a dispute analyst and fraud specialist. Once done, the call-center agent needs to return to the call and inform the customer what would happen next. Afterwards, the fraud investigator may need to do some additional due diligence and call the customer back with the outcome and an affidavit.
With the current flow identified, the team finds there are two key stages of work: (1) the interaction with the customer, and (2) the potential investigation into more serious cases.
Within the interaction part, there are the verification, find charges, and either elevating to an investigation or ending the call. They’ve also named various systems of records as a pain point, and the frustration of coordinating team members real-time while customers are on hold.
Why use it?
Journey mapping crystalizes the issues with the current flow. It helps the team more easily understand the personas’ relationships, pain points, gaps, and broken processes within the previously defined problem.
Problem trees gather pain points from all previous examples and bundle them into themes. Using the most critical themes, create the problem tree. Problem trees take a pain theme and define both the causes and effects of the current issue.
Within the dispute process, it is clear to the team that the hold time, inconsistent data retrieval methods, and coordination of team members are significant issues in the slow turnaround of the dispute process. These items are categorized into a theme of Too much time and are explored in the problem tree. The team identifies that error ratios may be created during this process. The team also realizes that the high turnover and need to hire more and more agents constantly may also be stem from this sort of issue. As for causes, multiple systems of record stem from the organization not prioritizing a unified way for agents to review data. While the fraud and dispute groups have standardized questions to verify the need for an investigation, they never provided that as a resource for the agent.
Why use it?
Problem trees help the team understand which undesired effects are secondary and which causes are creating the bulk of the issues to tackle the right problem level more quickly.