As Agile principles and Lean methodologies continue to take center stage in product management and strategy, it’s easy to get caught up in daily scrums and design iterations and shoot right past the user research (UR). Everything’s moving so fast and we’re seeing big improvements (we think) on a daily basis. Surely user research isn’t as important as full-steam-ahead?
In fact it’s more important than ever not to let user research fall by the wayside. Without understanding users from the ground floor and getting their feedback throughout the process, you could be full-steam-ahead on designing and building exactly the wrong things.
But it doesn’t have to be a big ordeal, and it doesn’t have to halt forward progress in design and dev. Now that design and development are on the Lean train, UR needs to be all aboard too.
With Lean UX, the traditional hesitations with doing user research at all (see earlier postAnybody’s Guess: Why Research Matters) are understandably heightened. Time, money and resources are even more tightly managed now, and user research certainly isn’t as sexy as seeing a new design or interacting with a live feature.
Lean UX involves showing designs early and often, and iterating constantly, along with eliminating anything that doesn’t add value to the project — such as documents or meetings with no tangible, actionable results. Agile dev cycles that employ scrum and kanban see continuous implementation and incremental delivery. To ensure that we’re successfully meeting end-users’ needs, and get our ideas out of the designers’ and developers’ and stakeholders’ heads and into the hands of end-users, Lean UR is a necessity.
So what does Lean UR look like? Well, it looks a lot like traditional UR, but it’s quicker, easier and stickier — and, yes, it typically costs less. And, most important, Lean UR aligns seamlessly with the product development cycle and ensures that when we’re delivering a minimum viable product, it’s actually viable. No more frustrated, confused users. No more post-release refactoring. You’ll see immediate adoption and be able to focus on next steps instead of backtracking.
The crux of Lean UR is that it doesn’t slow down the rest of the teams. Designers can keep designing — work on Sprint 5 while we’re testing Sprint 4. Dev can keep building — work on basic frameworks over detailed interactions. Stakeholders can keep adding ideas and feature requests — to the backlog. The key to Lean UR is empathy not only for the end-users, but also for the way your team works.
In the sample sprint cadence above, Definition and User Research are taking place concurrently with other phases of the project.
Here are a few ways to make UR lean and keep the end-users front-and-center at the Agile table.
1. Lean Requirements Kick-Start
Gathering requirements is tricky. Often we think we know what the requirements are, and then we get down the road a few sprints and realize we’re actually reimagining some early requirements or adding on a ton of requirements we didn’t even consider at the outset. This can be especially daunting in an Agile environment, because incorrect or incomplete requirements can really set a structured project back by several sprints and affect release schedules.
A great way to get started on requirements quickly at the outset of a project is to get all key stakeholders in a room together for a few hours. This should include product stakeholders like product managers and product owners; designers; developers; project managers; and of course researchers. Identify as a group the overarching vision for the product, then break that vision down into the goals we think the end-users will want to achieve. Divide the large group into smaller groups with representatives from each branch of expertise, and assign each group a goal. That group then works together to identify the epics and stories associated with the goal they’ve been assigned. Reconvene with the larger group and discuss each set of epics and stories and fill in any gaps.
The whole exercise takes about half a day, and results in a quick baseline of requirements that leads to further validation with end-users, the market and management, to name a few. Of course, requirements will be fine-tuned throughout the course of the project — that’s the nature of Agileand a necessary outcome of user research — but this is a solid starting point that everyone can feel comfortable with.
2. Lean Audience Definition
Personas are integral to user research, as they identify who the target end-users are and outline the typical user’s needs, goals, behaviors, motivations and attitudes — basically anything about them that affects their experience of a technology or a product. They help to focus the product strategy and design discussions so we’re not constantly accounting for edge cases. And they get everyone on the same page about who we’re targeting and how.
Similar to Lean Requirements Gathering, Lean Personas take about half a day and bring together the larger group of stakeholders — product team, designers, developers and researchers. Get everyone together and identify the 3 or 4 major end-user types. Yes, there will be secondary end-users whose interests we want to take into account, but the primaries are the goal in Lean UR.
Once everyone agrees on the target end-users, divide the group into smaller chunks with representatives from each discipline. Assign each group a user persona, and go to town. Think about things like “Where is this person and where will she use my product?”; “Why does this person need a product like mine?”; “What frustrates or confuses this person about technology?”
Hint: Start with a name. Naming your persona will turn them into a real user you want to understand and ultimately to please.
Once each group has drafted their persona, come back together and go through each persona. Everyone should offer input and insights to improve the persona and fill in any gaps.
Personas will continue to be honed over time as the project goes on and the team learns more about the audience. They should be living, breathing, easily editable documents, and be easily accessible from where Agile teams work — such as a backlog. This exercise is not exhaustive and does not substitute for talking to real users, but it gets the ball rolling and puts the product in the context of the end-users.
Lean personas still offer a breadth of information about the end-user that is invaluable to the design process.
3. Basic Lean User Testing
One of the foundations of user research is of course user testing for usability, usefulness and overall satisfaction. This has traditionally been a full-blown affair, with lots of planning, scripting, revising, scheduling, analyzing and reporting. But it doesn’t have to be. Breaking it down into lean chunks is totally manageable and infinitely valuable.
Basically, the idea with Lean User Testing is to do iterative testing — just like iterative design! Align the testing cycle to the dev/design sprint cycle, and test designs at the end of every sprint. You may be hesitant to show artifacts you don’t consider “complete” or “ready,” but that’s the whole point of testing — end-users are the ones who will get you across the finish line, not anything you or your designer does.
These sprint tests should be 30 to 60 minutes long, always done remotely unless you happen to be on-site with the end-users, and the scripts should be short and fluid. Don’t spend a lot of time creating intricate scripts, don’t make people come to an on-site location, and don’t draft a full, detailed report on the findings and recommendations. Make a bulleted list of top findings, recommendations for design, and recommendations for future testing.
Note: This gets at the just basics of testing within a sprint cycle. There are many other reasons (and times) to conduct user testing, which can also take a Lean approach.
Making Lean User Testing a part of the Lean UX cycle, rather than an add-on or afterthought, will result in better designs, increased dev efficiency and happier customers.
4. Lean A/B Testing
A/B testing enterprise software or other complex tools is a great way to decide on labeling, layout, color schemes, even how interactions should work or which features are most important. But don’t take the time to schedule an in-person user feedback session unless you’ve got a bunch of other stuff to test out. Instead, create a survey or even an email with the A/B you want to test, and send it out to as many users as you can, with 2 or 3 questions attached, like “Which do you prefer?” and “Why?”
It’ll take your respondents less than 5 minutes and give them a break from a dreary Monday afternoon, and you’ll get a whole lot of actionable data in a short time.
Note: Don’t be surprised if your respondents don’t answer the “Why?” question. It’s okay — some of them will, and that’s great for understanding what’s wrong with the other design. But even if they don’t, you’ve still got their preference.
Also note: Don’t use this method too often with the same users because they’ll get tired of it pretty quickly.
These are just a few slices of the Lean UR pie. For more insights on how to do Lean UR or how we can help augment your Agile framework with Lean UR, contact us at info@experoinc.com.
