Analytical User Personas

17 Sep 2013

Ben Parkison Photo
Mike Nash

We've discussed how we use rapid prototyping at Applied by Design and its ability to align stakeholder's mental models of a system. User personas serve a similar purpose in delivering shared understanding of the intended end-user.

User personas play a key role in our approach to user-centered design. They attempt to bucket common traits, behavioral tendencies, and properties of a target audience into a subset of generalized archetypes. Instead of designing an application to meet the needs of 100 different users, a detailed persona seeks to generalize the subset of users you're specifically targeting with your solution. Your team can then focus on the needs of a single user who represents the needs and wants of the greater target audience. That's the concept.

I'll admit, user personas can be pretty fluffy. The trick for us was to add our own modern spin on the artifact of a persona to better support and resonate with our design process. What we were looking for was something with less 'fluff' and more of an analytical basis as our customers are often engineering or technical teams. We ended up taking more of an infographic approach to the user persona. Here's a peek at a sample we put together.

Blue information is for this specific persona (Ben, Aviation Analyst). Orange information references the aggregate set of personas for a given team or project (there are 3 personas that represent the 25 team members in this example). Let's break some of it down by section.

1. Persona Bio

In our example, we're helping a team of 25 employees build an application solution to facilitate their daily operations. This persona represents one-third of the target users for the intended application. We gather the information from user interviews and surveys statistics, and find that this group has, on average, multiple degrees and came from the airline industry prior to their current job. In their current role, they're generally aviation analysts with 10-15 years of professional experience. Calling this persona 'Ben' humanizes the archetype to make it easier to identify with and recall later.


2. Technology

We're building an application solution, so we need to get a grasp on the segment's comfort level with technology. We can ask questions about their internet usage, breaking it down into subcomponents and drilling deeper into specific preferences for browser technology and email clients. On a weekly basis, this group spends 4 hours checking email (blue bar), which is fairly consistent with the broader group of aggregate personas (orange bar). General browsing indicates that this group spends ~60% more time per week than the team average casually engaging with the internet, and they're fragmented among browers.


3. Skills & Expertise

Understanding a segment's areas of expertise allows us to identify the application design considerations that might be most influenced by specific groups. For example, this graphic indicates that the the "Ben's" more often self-identify themselves as experts in data analytics and data visualization compared with their peers. Conversely, they're less comfortable in financial analysis.


You get the point. Each section should have an intended purpose. The set of questions and attributes collected in a persona will vary with the project and the team, but the concept is still the same. Personas typically don't take this type of analytical approach, but we think a healthy appreciation for the data driving them can help instill a sense of confidence and trust in the messages they're conveying.

At the end of the day, the persona is customized for the specific application. This artifact ultimately informs operational level requirements ranging from UI/UX considerations to the level of detail and interactivity of the analytical engines themselves. By anchoring all downstream requirements on these conceptual views of the end user, project decisions become traceable to a common, agreed upon model of the user. This is of value not only at the inception of the project, but throughout, and should be used as a touchstone for operational as well as tactical decisions as the application evolves. Our persona process provides an artifact that isn't just a onetime exercise, but is an actionable document that acts as a reference throughout the life of the project.


Mike Nash