Remember how I had you condense your interview data and come up with behavioral descriptions and personas?
We’re going to revisit those and identify a list of high-level verbs, or actions, that each persona performs.
For example, here are the personas I created for BizeeBee:
• Small business owner who likes being small. The business owner
who doesn’t have a physical space for their business and may be operating on-the-go or in a shared space. Keeps records of customers.
• Small business owner who believes more in sharing their practice
than building a business. The business owner who believes they should
be spending time with customers, not keeping records or running their business.
• Small business owner who eventually wants to make it big. The
studio owner who owns space and may be looking to expand into another location. Believes in keeping records of customers.
Combing through the interview transcripts, I spotted the following verbs for each persona:
Independent yoga studio owner verbs:
• Teach yoga class
• Take attendance
• Schedule instructors
• Ask students for payments
• Track studio’s income
• Own or manage a studio
• Perform back office tasks (Or, a business partner does this.)
Yoga instructor verbs:
• Teach yoga class 1-1
• Teach yoga classes at a studio
• Teach yoga classes in corporations
• May teach full-time or part-time • Take attendance
• Ask students for payments
• Travel to teach
• Track personal income
We want to design for as many of the common behaviors as we can and validate whether those are enough to appeal to both segments. If they aren’t, then we’ll need to focus on just one persona to avoid complicating our design and confusing our users. Here are the common behaviors across the two personas:
• Teach yoga classes at a studio
• Take attendance • Ask for payment
The next step is to search for tasks in the interview data. Tasks are the steps that customers perform in relation to a high-level behavior (i.e., the verbs identified in the previous steps). The tasks are what you’ll go on to emulate in your product’s design, and you’ll create workflows for them.
However, remember that you have limited resources! You can’t emulate every single task, and it might not be necessary to attract an early adopter. You’ll want to understand a customer’s desires, feelings, preferences, and expectations in relation to each task. This will characterize their level of need, and based on their level of need, we can prioritize what to build!
To evaluate tasks, we need to reference quotes from the interview. Here are a couple examples:
• “Every class, students come in and we need to check them in. As we check them in,
we see if their membership is still valid or expired. If it is expired, we need them to renew their membership. If we don’t do this, then we lose money on expired mem- berships, and we’re basically giving away classes for free.” (This is an important task and translates back to the business staying solvent!)
• “My front desk person checks students in.” (There are multiple people performing
this task.)
• “I don’t like asking students for money right when they check in.” (A strong
preference.)
• “I wish students would just pre-pay for classes and their memberships.” (A strong
desire.)
• “I think students will pre-pay for classes and memberships if it’s convenient.” (An
expectation.)
Based on these quotes, we can start to get a sense of the customers’ goals. Next, we can list the overarching tasks associated with each of these quotes:
• Enter student info • Take attendance • Review attendance
• Collect payment and record membership • Review expired memberships
• Notify students whose memberships have expired
We need to understand whether there are pauses between these tasks, whether they are performed in chronological order, and how the data flows through each of them. So, we model the task flow:
1. Enter student info → 2. Take attendance → 3. Review attendance Then, we identify the data needed between each step:
Once you’ve identified the tasks, you might want to jump into creating wireframes, but there are still two more steps.
First, take a task and translate it into a user story. A user story is a way of representing the task that a user performs, along with the goal that drives it. User stories serve as the common unit that engineers, product managers, and designers reference when they are talking about what is going to be built, how it will function, and the end result.
The format for a user story is: persona + task + goal. Here’s an example of a user story:
As a yoga studio owner, I’d like to take attendance as students check in to class, in order to keep memberships up-to-date.
A set of stories feeds into a feature.
Let’s say we know that we need to create a high-level feature called "account creation." We’ll then need to create a set of stories around that feature, and they might be something like:
As a yoga studio owner, I’d like to create an account on BizeeBee, to keep my business orga- nized.
account on BizeeBee.
As a yoga studio owner, I need to create a unique username, in order to avoid conflicting with another yoga studio owner’s account.
As a yoga studio owner, I need to create a strong password, in order for my password to be secure.
You’ll notice that there are a number of stories that fit into a feature, and they are pretty granular. For now, just know that this is necessary; in an upcoming chapter I’ll explain why. Hopefully, you’re starting to see how all this work is coming together!
Exercise 7.2: Discover common tasks and create user stories.
Objective: Identify common user workflows that you’ll want your product to
automate
Directions:
1. Comb through the interview data and spot common verbs. 2. Next, list out all the tasks associated with each verb.
3. Group the common behaviors across personas and make a list of the ones that are different.
4. Look for customer interview quotes that will give you a better sense of the tasks that are the most important and the goals associated with those tasks. 5. Create user stories using the following formula: persona + task + goal.
Exercise 7.3: Create a storyboard of your customer’s experience with your product.
Storyboarding your customer’s experience will help you ensure that your product actually works well before you start thinking about what it looks like.
Objectives:
1. For each user story you created in the previous exercise (Exercise 7.2), you’re going to identify the steps the user will take through your product to accomplish the goal.
2. Learn how to simulate positive and negative scenarios (error conditions). 3. Demonstrate how every step of the product supports the user in completing
the goal in the user story.
4. Craft narratives using actual customers’ names that can be referred to throughout the whole product development process.
5. Go beyond the user stories and consider the customer’s environment, emotions, needs, and outcomes.
6. Foster collaboration within your team by using low-fidelity collaboration tools (sketching, whiteboard, etc.)
Directions:
1. Start by creating a storyboard template by dividing a page into 8 boxes. You’ll do this for each user story you listed in Exercise 7.2, so you’ll need 1 page for each user story. Be sure to give each person a name and indicate their states of mind, needs, and desires on their page.
2. For each user, fill in the boxes sequentially with each small interaction they make with your product.
3. Next, go back through the boxes and draw very rough screens indicating what the key call to action is for each step.
4. Next, use lines to show how various steps or scenes of the story interact with other steps.
5. Finally, verbally talk through the entire storyboard with at least two people. Under each box on the storyboard, indicate the main purpose of that step along with any concerns, learnings, or important things to keep in mind.
Section 5