ENTERPRISE PERSONAS

The Challenge

Each stakeholder held a different expectation as to what “their” users would need and designers were conflicted as to what designs should include during design critiques. This lack of shared understanding of our users had been causing many rounds of reworks while nothing moved forward into user testing or development.

The Solution
I built a set of data-driven personas informed by contextual interviews and affinity grouping of insights across seven departments that would be using the new scheduling application. I then circulated these personas through a series of team workshops to ensure the adoption of the personas into product discussions.

The Outcomes
Increase of ~2 designs presented in weekly sync, >5 invitations extended to UX Designers by product leaders for inclusion in product change discussions (seat at the table); shared empathy across product teams for enhanced communication; renewed team excitement for the project and it’s impact on the business and it’s people.

My Role

User Researcher

• Recruited participants

• Scoped + curated study logistics including scripts

• Session Moderator

• Note Taker/Recorder

• Data Analysis

• Presented research findings

• Designed persona

• Led team workshops for persona adoption by teams

My Process

Research ➔ Design ➔ Present ➔ Measure

Methods Used

• Contextual Interviews

• Affinity Mapping

• Personas

• Empathy Workshops

CONTEXTUAL INTERVIEWS

I wrote an interview script and asked the same questions to 16 users from 7 departments, focusing on goals, processes, motivations, and reasoning over the specifics of system knowledge or job responsibilities. The interviews were conducted at each participant’s desk - which allowed me to witness the cheatsheets taped to monitors, the pull out scratch pad hidden in the drawer, and a hard copy of an airport map. All of these artifacts both in and outside the system aided users in describing why they do their work in their own particular way.

AFFINITY MAPPING

From the interviews, I grouped post-its notes of key phrases from participant interviews and was able to identify that users were describing their work in four key principles:

1. System Use - Was the system there to ensure protocols were adhered to or was it a series of road blocks to be worked around?

2. Decision Focus - Were decisions made based on the business’s best interests or the best interest of individual crew members?

3. Process - How users approached the list of work in front of them was either working through problems one by one as they occur or proactively solving for possible problems that had yet to occur?

4. Work Flow - Completing a single task through to completion or pausing on one problem to check and resolve two other problems before having enough detail to solve the first problem

I then took down all of the post-its and re-aligned them within each of these scalars - at which point three core groupings that appeared fairly consistently together.

*note that branding and key words have been replaced due to protected nature of the data

ARTIFACT 1: BASEBALL CARDS

Why?

• Information saturation in the system - physical artifact has a place on desk

• Can remain ‘at hand’ when approached at desk or pulled into meeting

• Matches the classic Americana branding vibe of the company

ARTIFACT 2: WALL POSTERS

Why?

• Marketing philosophy that frequency of exposure encourages greater buy-in

• Presence in regularly used spaces (ex: meeting rooms, cubicle spaces) even when UX team members are not included

METHODOLOGY REBRAND

Why?

Product teams were using Confluence by Atlassian and had already commandeered the “Personas” feature to write out job descriptions of users.

How?

Rebranding the method from “Personas” to “Archetypes” allowed product teams to accept a new concept without having to challenge existing mental models of personas.

TEAM ADOPTION ACTIVITIES

Why?

To better help teams understand and use these archetypes to make decisions, I conducted a series of activity workshops.

How?

I showed designs from common real world products and asked which archetypes would find value. I then presented scenarios in which the teams could practice solving based on the specific needs of our archetypes.

 Step 4: Measure

Measuring the impact of personas is a bit difficult since it’s purpose is served earlier in the process and I would consider as a secondary method to impacting designs rather than specific UI changes or user analytics. I did, however, track a few correlations to the release of the personas for our product teams.

QUANTITATIVE

• ↑ Increase of ~2 additional designs presented on average per semi-weekly UX team critique session

• >5 invitations extended to UX team members by product leaders for a seat at the table when discussing product changes

• By the end of my contract time, an additional 2 screens had been added to the development queue - doubling our previous design work in development

QUALITATIVE

• ↑ Increased empathy by product teams for focused approach to design solutions.

• ↑ Increase in shared understanding during team meetings which allowed for better better morale in design critiques.

• Renewed team excitement for the project as its impact on the people who would be using the designs could now be envisioned.

➔ Measuring the impact of an indirect methodology like Personas is tricky. I would hope to try to better capture the impact using a HEART framework modeled by Google’s UX team to identify a more macro-level and quantitative metric.

➔ Creating personas is only half the battle. Getting teammates to accept and actively use them requires active effort and modeling the desired application of them time and again.

➔ Less is more. I might have all the data on the personas, but the feedback I received was that they were perhaps a bit too detailed.