Software Engineering, Project Management, and Effectiveness
Personas and scenario can be a powerful tool for driving adoption and business value realization.
All too often, people deploy technology without fully understanding the users that it’s intended for.
Worse, if the technology does not get used, the value does not get realized.
Keep in mind that the value is in the change.
The change takes the form of doing something better, faster, cheaper, and behavior change is really the key to value realization.
If you deploy a technology, but nobody adopts it, then you won’t realize the value. It’s a waste. Or, more precisely, it’s only potential value. It’s only potential value because nobody has used it to change their behavior to be better, faster, or cheaper with the new technology.
In fact, you can view change in terms of behavior changes:
What should users START doing or STOP doing, in order to realize the value?
Behavior change becomes a useful yardstick for evaluating adoption and consumption of technology, and significant proxy for value realization.
I’ve written about personas before in Actors, Personas, and Roles, MSF Agile Persona Template, and Personas at patterns & practices, and Microsoft Research has a whitepaper called Personas: Practice and Theory.
A persona, simply defined is a fictitious character that represents user types. Personas are the “who” in the organization. You use them to create familiar faces and to inspire project teams to know their clients as well as to build empathy and clarity around the user base.
Using personas helps characterize sets of users. It’s a way to capture and share details about what a typical day looks like and what sorts of pains, needs, and desired outcomes the personas have as they do their work.
You need to know how work currently gets done so that you can provide relevant changes with technology, plan for readiness, and drive adoption through specific behavior changes.
Using personas can help you realize more value, while avoiding “value leakage.”
When it comes to users, and what they do, we're talking about usage scenarios. A usage scenario is a story or narrative in the form of a flow. It shows how one or more users interact with a system to achieve a goal.
You can picture usage scenarios as high-level storyboards. Here is an example:
In fact, since scenario is often an overloaded term, if people get confused, I just call them Solution Storyboards.
To figure out relevant usage scenarios, we need to figure out the personas that we are creating solutions for.
In practice, you would segment the user population, and then assign personas to the different user segments. For example, let’s say there are 20,000 employees. Let’s say that 3,000 of them are business managers, let’s say that 6,000 of them are sales people. Let’s say that 1,000 of them are product development engineers. You could create a persona named Mary to represent the business managers, a persona named Sally to represent the sales people, and a persona named Bob to represent the product development engineers.
This sounds simple, but it’s actually powerful. If you do a good job of workforce analysis, you can better determine how many users a particular scenario is relevant for. Now you have some numbers to work with. This can help you quantify business impact. This can also help you prioritize. If a particular scenario is relevant for 10 people, but another is relevant for 1,000, you can evaluate actual numbers.
Let’s take Bob for example. As a product development engineer, Bob designs and develops new product concepts. He would love to collaborate better with his distributed development team, and he would love better feedback loops and interaction with real customers.
We can drill in a little bit to get a get a better picture of his work as a product development engineer.
Here are a few ways you can drill in:
Another approach is to focus on the roles, responsibilities, challenges, work-style, needs and wants. This helps you understand which solutions are appropriate, what sort of behavior changes would be involved, and how much readiness would be required for any significant change.
At the end of the day, it always comes down to building empathy, understanding, and clarity around pains, needs, and desired outcomes.
Here’s an example of a high-level process for persona creation:
Doing persona analysis is actually pretty simple. The challenge is that people don’t do it, or they make a lot of assumptions about what people actually do and what their pains and needs really are. When’s the last time somebody asked you what your pains and needs are, or what you need to perform your job better?
In one example I know of a large bank that transformed itself by focusing on it’s personas and scenarios.
It started with one usage scenario:
Connect with customers wherever they are.
This scenario was driven from pain in the business. The business was out of touch with customers, and it was operating under a legacy banking model. This simple scenario reflected an opportunity to change how employees connect with customers (though Cloud, Mobile, and Social).
On the customer side of the equation, customers could now have virtual face-to-face communication from wherever they are. On the employee side, it enabled a flexible work-style, helped employees pair up with each other for great customer service, and provided better touch and connection with the customers they serve.
And in the grand scheme of things, this helped transform a brick-and-mortar bank to a digital bank of the future, setting a new bar for convenience, connection, and collaboration.
Here is a video that talks through the story of one bank’s transformation to the digital banking arena:
Video: NedBank on The Future of Digital Banking
In the video, you’ll see Blessing Sibanyoni, one of Microsoft’s Enterprise Architects in action.
If you’re wondering how to change the world, you can start with personas and scenarios.
Scenarios in Practice
How I Learned to Use Scenarios to Evaluate Things
How Can Enterprise Architects Drive Business Value the Agile Way?
Business Scenarios for the Cloud
IT Scenarios for the Cloud