Applying the LeanUX process, part 2

If you haven't check out my previous article that explains what LeanUX is and why it might be a good fit within your organization. Part 1 explains the steps, the roles, and the basic reasons for each.

This article is more like a step-by-step process for facilitating your first LeanUX project within your company. It's built on my personal firsthand experience and it's informed by my own real-world successes and failures in rolling out this process within my company.

So without further ado, let's jump in!

Before the first meeting

Create a Problem Statement

A problem statement is a short blurb that describes the business justification for the project. It should include:

• The current goals of the product or system

• The problem the business wants to address (i.e. where goals aren’t being met)

• An explicit request for improvement that doesn’t dictate a specific solution

More information about Problem Statements is available in part 3 of the series.

Determine Team members

Key disciplines should be represented. Below is a list of suggested participants. Use your own judgement when creating the team.

1. Development *

2. Architecture

3. Quality Assurance

4. Business Analysis *

5. Product Owners

6. Designers *

7. Marketing

8. Sales

9. Customer Support

Identify the Decider role

This person will be responsible for breaking ties and making key decisions during the process. It is usually the Product Owner but could also be a key executive. This role MUST be filled by at least one person, and it must be communicated to the rest of the team.

This is a deviation from the traditional LeanUX process, but in practice I found it was easier to have a high-level executive or product owner serve as a tie breaker for contentious decisions.

Prepare for the first meeting

1. Send the Assumptions-gathering worksheet out along with the problem statement. This should be completed by all team members before the first meeting.

2. Send this outline to the team so everyone is aware of what the process entails.

3. Gather supporting information (Existing product analytics, Usability reports, Support issues/tickets, Competitive analysis)

With the Team

1. Explain this process. (10 minutes)

   1. This is critical to building understanding within the team. Without this step the team will not understand the reason for the new process and will be less likely to buy into it.

   2. Explain the major milestones and deadlines.

2. Read Problem Statement to team and briefly discuss (10 minutes)

Gather Assumptions

1. Gather Assumptions from all team members’ worksheets (15-25 minutes)

   1. For remote teams, this can be done via collaborative editing on a shared Word document (8-10 minutes)

   2. For localized teams, this can be done by reading each answer aloud and writing each on a sticky note

2. Group assumption answers into themes and prioritize the key assumptions. (10-20 minutes)

   1. The goal is to capture what the team thinks might be true.

3. Introduce the concept of Hypothesis Statements (7 minutes)

   1. Why use them? They force the team to think in terms of outcomes and not features, plus, they give the team a way to verify (test) if the hypothesis is correct or not.

   2. 4 parts of a Hypothesis Statement

      1. Business Outcome

      2. User

      3. User Outcome

      4. Feature

Brainstorm Business Outcomes

1. Gather/brainstorm Business Outcomes (40 minutes)

   1. What are the key outcomes that this project can create for your company? What will your company gain by doing this project? What might we lose if we don’t? (ex. Increase in some KPI, additional revenue, session time, etc.)

2. Team votes on the business outcomes they feel are most critical.

   1. Each team member gets 4 votes.

   2. Decider gets final say over which outcomes the team carries forward.

Discuss Users

1. Gather/brainstorm Product Users (40 minutes)

   1. Run Proto-Personas creation exercise

      1. As a Team, discuss and brainstorm potential factors that might influence behavior (these are assumptions that will be vetted later)

         1. Job Role

         2. Type of Business

         3. Device preference

         4. Computer skill

         5. Domain knowledge

         6. Etc.

      2. Differentiate personas by Needs, Obstacles, Desires

         1. Examples of Needs

            1. “Need to make schedule changes while on the floor.”

            2. “Need for quick, bottom-line information”

         2. Examples of Obstacles

            1. “Not enough information to make an informed decision.”

            2. “Can’t spend time in front of a desktop computer.”

         3. Examples of Desires

            1. “Desires to feel respected at work.”

            2. “Wants to feel in control.”

2. As a team, decide on 3-4 Personas to target. Decider gets final say over which personas to target.

3. Share these personas outside the team to get initial feedback. Incorporate the feedback and adjust the personas as necessary.

4. Use the generated personas to begin recruiting testers.

   1. Are you able to find testers that match your personas?

   2. Do they have the needs and obstacles the team brainstormed?

   3. Would they value a solution to the problem you have identified?

5. Save these personas and refer to them in future projects. As you collect new information about a persona, the document should be updated to include that information.

Brainstorm User outcomes

1. Brainstorm potential User Outcomes (30 minutes)

   1. Allow the team to brainstorm in silence (If remote, use a Trello board or similar. A shared Word document can work. If localized, Sticky Notes and markers can work)

   2. Prompt the team to think about these questions when brainstorming user outcome.

      1. What is the user trying to accomplish?

      2. How does the user want to feel during and after this process?

      3. How does the product or service get the user closer to a life goal or dream?

2. Group the collected outcomes into themes

Brainstorm Features

1. Brainstorm potential Features (30 minutes)

   1. The team should keep in mind the user outcomes generated in the previous step, as well as the business outcomes.

   2. Allow the team to brainstorm in silence (If remote, use a Trello board or similar. A shared Word document can work. If localized, Sticky Notes and markers can work)

2. Group the collected features into themes

Generate Hypothesis Statements

Create the following table (either on a whiteboard or in a shared online document)

Strive to generate 7 to 10 rows in this table using the raw materials generated in the previous steps.

Prioritize and categorize the hypothesis statements according to risk and value. See grid below.

You should focus first on the hypothesis statements that are in the shaded cell.

Riskier hypothesis statements should be tested early so that the team can mitigate the associated risks or discard disproven hypotheses.

The team should vote on the hypothesis statements that they think are the most valuable or are most likely to deliver the results the team or company is looking for. Each team member gets 4 votes. The Decider gets to make the final decision on which hypothesis statements to work on.

This document becomes the project's bible. It is a living document, and as the team has bandwidth, the list should be reviewed, and the voting process should be performed again to get new tasks to work.

As new ideas are generated over the life of the project, they can be added to this document and picked up the next time the team has bandwidth. In practice, we found this to be a great way to manage our tasks and decide what to work on.

Collaborative Design

Organize the “working group”

The “working group” is the team that will be responsible for turning the hypothesis statements into a product design. This team should include most, if not all, of the following roles (or a proxy for each of these roles). The group should not be so large, however, that making decisions or coming to consensus becomes difficult. 5-7 people is a good size. In a traditional LeanUX process there is no difference between the planning team and the working group. However, in practice, it is sometimes difficult to get everyone in the room, especially if team members belong to multiple product groups.

• Business Analyst

• Product owner

• Designer

• Front-end developer

• Architect

• Quality Assurance

• Customer Support

Ensuring each of these roles are represented in the working group is critical to ensuring that requirements aren’t missed, and to maximize the “Product IQ” amongst the team. Leaving any of these roles out risks creating a blind spot in the planning and design of the product. For example, there may be back-end server systems that need to be accounted for in the design of a product or interface. Leaving the architect out of the decision-making process or including them late in the process risks delay and redesign.

Schedule at least an hour for this first meeting so the team has time to brainstorm and discuss. Send the Hypothesis Statements generated in the previous meetings out as part of the meeting agenda, so participants know the goals of the next sessions.

Look for existing solutions

Before the first design session, each participant in the working group should take some time to research existing solutions to the problems they are trying to solve. These solutions are frequently found elsewhere on the web or in products the team already uses. The solutions may have been created for other products within the company. Perhaps the ideas were proposed but never completed.

These ideas should be collected so they can be brought into the first Collaborative Design session. Screenshots or printouts should be collected so that everyone on the team can view them.

Collaborative Design sessions

In the first meeting, the team should present the solutions they have found in the previous step. This will give everyone a place to start and generate some discussion. Keep the presentations short and limit the time on the discussion. Each idea should take no more than 3-5 minutes to present.

Make the screenshots available to everyone on the team so that they can be easily referred to during later parts of the design process.

Next, the working group should begin sketching the interface ideas. This is a highly collaborative process at this point and all ideas are welcome. Everyone should be encouraged to draw either on their own or as part of a group process. The point is to generate the ideas that will best address the Hypothesis Statements the team has already decided upon.

For remote teams

Using a shared Microsoft Whiteboard session works well. However, participants without touchscreen or pen-driven devices will have a difficult time contributing drawings. This can still work if the designer leads the process.

The team should continue to meet and work in this way until all screens have been sketched out and generally agreed upon. This may require a few 1-hour meetings. These can be scheduled all in the same day or over a short period, depending on the bandwidth of the other group members.

Review with the team (as needed)

If the working group did not include all stakeholders it will be necessary to hold short check-in meetings where the entire group can be updated on the progress and the design direction. Depending on the make-up of the larger group, this can happen either while the ideas are still in low-fidelity sketches, or later in higher-fidelity prototypes.

The goal of these meetings is to ensure that the entire team is in agreement with the direction.

Gather feedback and adjust the designs as necessary. Continue to check-in with the team during and after the prototyping phase is completed.

During this phase, the team should also begin engaging potential testers.

User Testing

When beginning the user testing process, it is important to answer these two questions:

1. What is the most important thing we need to learn next (or first) about our chosen hypotheses?

2. What is the least amount of work we can do to learn that?

The team should also choose what sort of testing method is best suited for their project. There are two options with pros and cons:

Test What You’ve Got

Testing what you have available means you can focus on the regular process and don’t have to scramble at the end of each week to generate a testable prototype. What this means is:

• Testing becomes much more informal

• Testing can take different forms, depending on what is ready on test day

  • Sketches

  • Static Wireframes

  • Clickable Mockups

  • Coded Prototypes

• Scheduling tests becomes a continuous job

The downside to this is that the feedback you get may not be as rigorous as you would get from the other common methods of getting feedback.

Conduct a Formal Test

This requires a significant time investment, but it can generate quantitative feedback for certain types of problems.

Generate a Prototype

Once the design has been decided by the working group the designer(s) should begin creating high-fidelity prototypes from the initial sketches. These prototypes serve two purposes:

1. Allows the team to make decisions about the development of the product.

   1. Decisions about how to implement specific interface elements will be made based on these high-fidelity prototypes. This will allow the designers and developers to coordinate on the implementation to reduce confusion and maximize developer efficiency

2. Serves as the basis for the upcoming user tests

Review these prototypes with the working group and, if necessary, with the larger group.

Keep in mind that the team should focus on creating the Minimum Viable Product (MVP). The MVP should be a “vertical slice” of the application, meaning it should be a fully usable, but small-scope product. (For example, in the Notifications project, the MVP consisted of everything required to configure, deliver, receive and execute upon ONE type of notification).

Determine the tasks

These tasks should be constructed to test the Hypothesis Statements that were generated in the planning phase. The Designer should coordinate with the Product Owner to generate a list of 3-5 tasks that the user should run through.

Aim to keep the test length between 30 and 45 minutes. You do not want to tire out the tester.

Finalize and schedule the Test Users

The team should begin to schedule the tests. The tests should be scheduled to coincide with the final team approvals of the prototype.

Refer to the User Personas that the team generated earlier to guide the selection of appropriate test users.

Write the Test Script

Run the test

Use the generated prototype and task list to test the users you have selected.

This step will generate action items. Record these to discuss in the next step.

Evaluate Test Results

After the test has concluded the team should discuss the next steps. This will likely involve making changes to the prototype.

Based on the test interviews, you should also take this opportunity to update your User Personas so that future teams will be able to take advantage of the work created by your team.

Other ways to get product insight

• Customer Success team

  • Ask what they are hearing about your product or domain

  • Hold monthly meetings to understand product trends

  • Include them in design sessions and design reviews

  • Incorporate your hypotheses into their call scripts. One of the easiest ways to test an idea is to suggest it as a fix to a customer complaint

• In-site Feedback Surveys

• Simple Email forms

• Customer support forums

Next Steps

At this point we are at the end of our first cycle. Pat yourself on the back! You now must make a decision about what to do next. Your options are:

1. Apply the learning from the test to the MVP and test again.

2. Apply the learning from the test to the MVP and switch

3. Revisit the Hypothesis Statement backlog and incorporate new Hypothesis Statements into your product design.

Keep in mind that this is a cyclical process.

Want more?

Check out my final article in the LeanUX series for frequently asked questions and worksheets you can use to facilitate your own meetings.