Different people approach the same goal very differently. When we don’t truly identify our users, we end up with software that dehumanizes, waters-down, and otherwise fails to succeed at anything more than grudgingly tolerated functionality. Even worse, we may ignore the needs of our key demographic, resulting in software failure. When we use personas instead of generic use cases, we can avoid both the misery of a failed product and mediocrity of marginal success.
Different Strokes for Different Folks
James Kalbach has a post at Boxes and Arrows about how to design for the four different modes of seeking information. This makes for a great analogy to how different people will approach the “same” task differently. All of these examples can be generically classified as “User searches for information on the internet”
- Searching for information about a known item. Imagine that you know a bunch about growing chile peppers. You want to learn the specifics of how to grow a habanero plant in Zone 3 of North America. You know what to look for, you know what terms to use to look for information. You know what questions to ask, you just need answers.
- Exploring an area of knowledge. You are tired of your job, and you want to find out if starting your own franchise business is a good idea. You have a reasonable idea of a starting point and general questions, but no idea what detailed questions to ask.
- Not sure what you even need to know. You decide to invest in a vacation property. You have no idea what you need to understand in order to know what questions to even ask.
- Repeat searches. Two years ago you learned about what it means when the yield curve inverts. Now that it’s time to rebalance your portfolio, you need to refresh your understanding of macro-economics.
Each of these examples represents a distinctly different user goal, even though they are all users of the same search software, and they are all searching for information. The same solution is unlikely to be ideal for all of them.
Personas for Requirements Management Software
Consider requirements management software and the users that are forced to live with it (most of us). Only enterprise software is consistently more obtuse about the notion of different users requiring different interfaces. RM software like Caliber RM, DOORS, RequisitePro and their ilk all suffer from the design specifications of myopic requirements experts. They suffer from other things too – featuritis, failing to clear the suck threshold, and an expert-only interface.
Requirements management software is intended to be not only a central repository for documenting requirements, but to be a dynamic hub of information. Everyone on the team should be able to use the system and consume information from it. When the software is designed for a single user (the requirements manager who inputs and manages the data), it makes it harder for other users to isolate the information that is relevant to them. An RM system is designed both for input and output, and where the major systems consistently drop the ball is in output.
Let’s look at three of the personas who need to consume status information that comes out of a requirements management system. We’ll start with their roles and their corporate goals
- Program Manager. Responsible for the management of the requirements for a software application.
- Development Manager. Responsible for delivering the functionality required to support each requirement in each release of the software. Also responsible for growing the development team’s capabilities.
- Project sponsor. Responsible for delivering increased sales across every channel in every region the company serves. Funded the project.
Progam Manager – Joe K.
Joe has been with the company for two years, ever since the startup he was at was acquired. He has a passion for driving new product innovations, has friends all over silicon valley and knows the latest ideas being explored by the current wave of startups. He’s driven some real innovation in embedded software development before. This is his first project with a user interface. Joe competes in an ultimate frisbee league every weekend, to burn off the energy he builds up with late nights at work. Joe’s biggest challenge isn’t getting the work done, it’s determining which work to do – he’s bursting with ideas. When Joe looks at the status of the product, he’s concerned that the dev team is hitting or will hit all of the releases. When they have to change the schedule, Joe works with the stakeholders to reprioritize and works with the development manager to find out what can be done.
Development Manager – Thom Jai
Thom is all but burnt out. He’s managing development for two products right now, and both teams are global, with people down the hall and people on the other side of the planet. When he’s not trying to meet deadlines, he’s trying to figure out how to scale the offshore operations to save the company money. Thom has a family at home, and the midnight conference calls are really starting to frustrate him. He can’t cancel them, because his developers always have questions about what to implement, and he has no time in the schedule to let anyone lose a day while he waits to get an answer to a question. He has to interpret the requirements for his developers and provide them with context, clarification, and design suggestions. Maybe next month he’ll be able to work on performance reviews. When Thom is looking at the status of the product, he is trying to make sure that requirements aren’t changing after they’ve been scoped or scheduled. He also wants to know whenever the schedule changes for a requirement, or anything that the requirement depends on.
Project Sponsor – Julie Rogers
Julie manages a two-hundred person global service operation. Julie quickly rose up the sales-management ranks because of her ability to create strategic relationships with her clients. Every account she ever signed is still a customer. Julie contacts a different customer every week just to ‘check in’ and make sure the customer is happy. Her managers told her that their number one problem in closing more deals is getting the right prices for the products. Julie commissioned the IT department to build her software that helps her regional managers set the right prices for the company’s products. The IT team promised to deliver an application that could report on historical prices by the end of the quarter. By the end of the year, the application will even provide profit information, lead-time data (another big problem), and the ability to review customer-history when closing a deal. Julie’s daughter is in high school and applying to colleges across the country. Julie is spending every minute she can helping her daughter when she isn’t running her sales organization. She wants updates on the status of the project, but does not care about the details – “it’s like making sausage” is her favorite quote. She knows what her team needs, and she knows what Joe has committed to deliver.
Different roles, different goals
Each of our personas has very different goals. Joe wants to deliver the most valuable requirements as fast as possible. Thom wants to make sure the ground doesn’t shift beneath his feet – he’s busy enough making sure his team can execute to meet their commitments. Julie wants to increase sales, and believes the software will help, once it’s been deployed to her team.
Persona non gratis
If we ignore the different needs of our different users, we can use the same (and only) interface for all of our user tasks.
Julie will look at the schedule for the top-level goals in the system. Joe has explained that all of the structured requirements in the system roll up to those goals, so she can ignore everything else. Julie is immediately overwhelmed with information, but with some coaching is able to ignore the noise and focus on the signal (the scheduled dates for the goals). She’s content that everything appears to be ok. What Julie doesn’t realize is that the underlying requirements for one of her main goals has slipped by a release, and the date for the goal hasn’t been updated. She would not be able to work through the traceability matrix in the application to find the problem.
Thom is struggling – every morning he sees that at least a dozen requirements for the current release have changed. He has to keep an archived version of the SRS and compare the two files to see which changes are irrelevant (typos, etc), and which ones affect his scoping, or change functionality after it’s been implemented. Thom can use the interface, but it’s yet another complex system that he doesn’t have time to learn. He’s frustrated that he has to spend any time at all doing it, and especially frustrated that the one thing he needs the most (to understand what has changed, at a detail level) has to be done manually by him.
Joe is snug as a bug in a rug. The software works just like he expects it to work. Sure some steps are manual and tedious, but hey – managing requirements is hard work. Since Joe spends so much time in the application, all of the traceability is intuitive, he knows where everything is, and he’s even learned the shortcut keys for jumping around and mass updating of files. Joe doesn’t spend any cycles thinking about the UI, because it was designed for him – he gets to spend all of his time on his work.
Persona gratis
Just thinking about the problems from the perspective of our key users makes the problems glaringly obvious. Why didn’t the RM software vendors tackle these problems? Aren’t they supposed to be requirements experts? Shouldn’t they have an appreciation that a central tool for a team is used by more than one team member? They implemented row-level locking in the database to support multiple users (says so right in the press release). Shouldn’t they realize that the simultaneous use is by different people? Someone needs to hurry up and build a requirements management system that is designed for all of the people that use it. Or at least the most important ones.
We can learn from their mistakes
When we are gathering requirements, if we do it in the context of the user personas, we can create great software. Goal driven development is a great framework for doing this. When we keep things at an abstract level, we run the risk of making the software unusable by key users. It may not prevent a sale, but it certainly jeopardizes a renewal or future sale.
2 thoughts on “Persona Grata”