My Process

Discovery

Project Kickoff / Stakeholder Interviews

Here the team aligned with the business requirements sit down to discover the problem. This list can include:

• Myself as the designer or researcher, and anyone else needed for this meeting from the design team
• The project manager
• The product owner or C-level executives aligned to the business goal being discussed
• Business analysts
• Any subject matter experts
• Possibly relevant departments such as customer or client support, marketing, sales, operations, legal, or the system implementation team
• A representative from the development team, such as the solution architect

The problem is discussed and questions are asked. Some example problems could include:

• We need to increase customer sign-ups by 20%
• Support ticket volume has increased, we need to find out why and address it
• Key customer satisfaction metrics, such as NPS, are lower this quarter, this needs to be raised
• Recent user research surveys have returned lower-than-expected usability metrics (such as the System Usability Scale or SUS) that we suspect causes people to abandon the product after the trial period

Data Immersion

Here I ask for whatever data we have on hand that could help, such as:

• Website analytics
• Relevant support tickets
• The development backlog and outstanding requests
• Competitor information
• Past user feedback
• Reports, such as sales reports or market research reports
• Documentation for the current production environment

I will also sit down and interview internal stakeholders that were not present for the first meeting. Note that some other role besides me could be doing this part, or this task could be split up by multiple individuals.

Ethnographic Studies, Market Research, and Exploratory User Testing

If you don’t have enough information from the data, it’s time to examine your users. This includes:

• Ethnographic studies: Literally field studies where you observe users in the moment they are using the system to figure out where their painpoints lie. Ask follow-up questions.
• Market research: Do we understand our customer, or do we ASSUME we understand? Customer surveys (including demographics) and other market research processes can help here. Outside agencies dedicated to this type of research are sometimes needed.
• Exploratory user testing: Run through user testing sessions with either your current product, or even a few competitors’ products, to help understand what users’ needs and wants are, and what they dislike.

Design Brief: Timeline and Project Scope / Hypothesis

From all this, another meeting should occur and the project scope or hypothesis should emerge after presenting the data findings. It doesn’t have to be ultra specific, but the project goal template should look something like this:

In order to achieve _________ (long-term goal)
Our product will help _________ (primary users)
In solving problem ___________ (user problem)
By providing them _____ (solution/unique features)
We will know that our product works, when we see _____________ (some Metric to measure success)

This is how you identify your key metric of project success. During this meeting, the project timeline must also be solidified. A project Gantt chart could emerge here.

This can be packaged into a comprehensive design brief document or presentation, which should also include the definition of the project roles and the collaborative framework being used. This is important to understand:

• Who is responsible for what
• Who should be invited to which meetings, and the timing of the meetings
• If there is a disagreement, who makes the final decision
• What the cadence of the design sprints should look like

Ideation

Hopefully I have my footing on solid ground from the previous data collected. Now it is time for the abstract problem to take shape into actionable insights. The following deliverables and workshops can help (usually not all of these are created):

1. Personas and audience definition (work roles)
2. Affinity diagrams—sort and make sense of the data you have collected
3. Empathy mappings—record what the persona is saying, thinking, feeling, and doing
4. Heuristic analysis—which common usability problems exist in the current system?
5. Kano analysis and feature priority matrix—helps shape the product MVP by prioritizing what is important
6. User journey and customer experience mappings—the steps your users go through when engaging with your product, and what they feel during each step (including painpoints)
7. Storyboarding and sitemap—helps set the information architecture
8. Hierarchical task inventory diagram and task interaction model—illustrates the lists of tasks a role can perform and the specific steps for that task
9. User scenarios, user stories, and use case diagrams—detailed requirements that can help the team understand each feature’s specs
10. Wireframe and eventually an interactive prototype—the user interface to help convey the idea for testing

Validation

This is the iterative part of the project. I take my wireframe or prototype and start completing usability tests and user interview feedback sessions, whether moderated, unmoderated, or in more surveys (or a combination). I can also assist with testing recruitment.

This information is then summarized and presented to the team. Sometimes bug and quick enhancement tickets are found as a result from testing. Usually, my user interface is adjusted based on this feedback and tested again, until the product passes our feedback metric benchmarks for the developers to begin work.