Enterprise UX 102: Personas (Users are People too)
Know Thy User
“Know Thy User” — a refrain you’ll hear often from usability specialists — gets to the heart of the matter.
As developers, we are often removed from working directly with our clients. In large Enterprises, that may mean that our Devs and our Dev Lead may never speak to the user — they may rely on the Product Manager or even an Account Manager to do that. Being separated from our users comes with drawbacks, one of which is that we lose sight of our audience and their mission.
Now, ”Know Thy User” doesn’t mean that you all need to be best buddies and go to the movies together and finish each others sentences. What it means is that you need to understand your user segments, the roles they play, what they are trying to accomplish in your application.
“Don’t make assumptions about your users. Go out and meet them. Gather data. Perform user testing. Understand who they are, what their goals are, what their needs are, and how they think and feel.”
If you don’t understand your users…
- You won’t understand how your app is used
- You won’t know which features important and which are not (low usage != low importance)
- You may miss key opportunities for unlocking real value from your product
- etc, etc, etc.
Needless to say, understanding your users is important.
“and You Are Not Thy User”
You’re too close to the code. You know where the bugs in your app are and how to avoid them. You know that the return button on one page does the same thing as the submit button on the other page which does the same thing as the save button on yet another page. You know what actions are slow, and know why, and you’re OK with it because of the amount of work it would be to speed it up… Just stop.
Your user doesn’t care about the code complexity, or your penchant for being too logical with button names, or your love-hate relationship with your bug backlog. They just want your app to work… well.
Deciding your Personas
Personas can be app based or project based. Consider identifying 4 Personas for your application. Large applications may have many more than 4 Personas, and they should then be identified per project.
Next… choose your strategy…
Role-based Personas: Describe a person according to tasks, job description, responsibilities, other external factors. The role a person plays in a system. (e.g. “Data Editor”).
Segment-based Personas: Defining users in terms of shared characteristics like demographics or behaviors (e.g. “Power User”)
Goal-based Personas: Users have specific goals in their tasks regardless of what department they sit in, or what hat they may wear. Understanding user goals will be necessary regardless of which strategy you select. (e.g. “Users who want data management to be simpler”)
We are trying to achieve “reliable and realistic representations of key audience segments.”
This will help us:
- Express and focus on the major needs and expectations of the most important user groups
- Give a clear picture of the user’s expectations and how they’re likely to use the site
- Aid in uncovering universal features and functionality
- Describe real people with backgrounds, goals, and values”
Personas for my current web application are:
- Data managers who rekey a lot of information for others
- Portfolio Managers who want an overview of their portfolios
- Browsers who are searching for general portfolio data
Don’t put your users in a box: Putting users in too strict of a box limits your ability to reimagine their world, e.g. my Data Managers who are rekeying data — we want to remove the need for them to rekey data, but I sometimes wonder if we’re even the right application for them.
Don’t put your app in a box: Focusing too closely on a user’s actions or a group’s objective can sometimes cause you to only solve for that user segment. By focusing on only one user segment’s goals, we sometimes lose sight of the product’s goals and potential.
A Few Questions
Ask yourself a few key facts about your product and users to start understanding the segments
- What is your product’s goals?
- Who is your user?
- What is their work experience?
- Why are they using your product? How does it tie into their day-to-day job?
- Where are they getting their information? What is the gold source of the data they are using? What are they doing with it?
- What other software do they use to do their jobs?
- What business line are they in? What other business units support them
- Where are they accessing this product? When?
- How technically savvy are they?