Knowing who will use the technology is great, but what’s better is understanding their motivation for interacting with the solution in the first place. Personas drive out what I call BANG: behavior, attitude, needs, and goals. With BANG in tow, I discuss how I have guided projects from personas to success.
- Create profile types to full personas depending on time, information and leadership support
- Teams need context and goals to rationalize features and functionality for end users
Align around who?
Where do you start? You have been working with the team at your company for years. You have gathered around an understanding and a shared knowledge of your team’s process for successful delivery. Your team is now presented with a new project to deliver with a cross-functional team.
How do we know what the downstream needs or is going to do? You are experienced in your work stream and are great at planning out your work within a larger delivery plan. You know there are several work streams later in the delivery of the project, but are not familiar with the intricacies of their work. Your work has a high impact on the outcome of the project.
What could be considered a valuable feature? You moved to a new team to help deliver a project. You need to ramp up quickly and have no experience with the project. You have been asked to join to assess where the most value can be derived.
Within the answers to these questions live silos of knowledge, understanding and communication. Teams and work streams need a way to bridge the knowledge gaps and reach success. They also need alignment in communication that drives towards value for the end user or consumer of the project. Through research and agreement, persona development has become my go-to experience design tool.
Facing tight deadlines and a lack of shared knowledge of how we drive real value, persona development helps me improve team alignment. Creating reliable and realistic representations of key audience segments has put my team in successful positions to develop solutions for users of our technologies. These representations have been based on qualitative and quantitative user research and knowledge sharing. The quantitative and qualitative picture of the users has been valuable for identifying support or design and development priorities, and is often a baseline starting point for user flow analysis. Persona development has not always been taken up at the beginning of a project.
Interjected in the middle
For some projects, I have on-boarded during the development process, several weeks or months after the start of the project. The challenges at this point are identifying work streams alignment on what should be delivered and how much the teams know about the end user of the project. The complexities of this initiative is compounded by politics and attitudes within cross-functional teams and among project leadership. With this purview, I ramp up by reviewing use cases, user stories, and requirements and make note of identified attributes of end users. Review notes provide details of where the gaps in understanding lie and steer my investigation of where to get the information to fill in those gaps.
Preliminary personas are born as profile types for the team to continue to refine. Refinement typically comes through analysis of historical data around similar projects delivered to end users of the current project. Stakeholder interviews driven from identified gaps allow for targeted questions about user adoption goals and target audience attitudes. Combinations of reviews and interviews give me enough data to quickly turnaround personas that can be used to validate current development efforts. The personas not only point out where functionality could be more robust, but also aid in grooming the roadmap for new features. Continuous development cycles can be measured earlier to ensure the end user will find the solution valuable. This supports the development team in obtaining the right requirements and alignment on “who” and “what” is driven.
Bringing up the rear
There have been projects where I was brought onto a team near the end of development to provide experience design direction. When there are vague requirements and, in an Agile project, undefined acceptance criteria, warning alerts go off in my head. Can the team really develop the “how” without understanding or aligning on the “who” or the “what”? It is possible to more forward with development with such a low quality end user identification, but the propensity of missing the audience and failure of the project increases. In these last-minute-experience-design-inclusion moments, I rely on my workshop facilitation skills to quickly gather perspective on the end user before conducting a heuristic analysis and review of development efforts to that point.
Building this perspective will enable me to point out where easy wins can be gained with the remaining development cycles. The journey mapping and straw-man persona definition workshops include project stakeholders and cross-functional team leads in order to understand who the end user is and what potential touch-points can be captured and planned for. Pivot time is short, but a clearer picture of the end user’s behaviors, attitudes and goals will help build the foundation for mitigation and planning.
The sweet spot, from the beginning
The best situation is being brought to the table at the very beginning of the project. This is the sweet spot! Personas can help focus decisions about workflows, journeys, or software components by adding a layer of real-world consideration to the conversation. They also offer a quick and inexpensive way to test and prioritize features before development starts. At this point in the project (or anywhere they can be used) personas:
We are crafting the lens through which users will see the world. With those glasses on, it is possible to gain a perspective similar to the user’s (person’s or role’s). With this understanding, when we make a decision, we do so having internalized the persona’s goals, needs and wants.
This helps us to define who the project is for and who not to focus on. Having a clear target is important. For projects with more than one user type, a list of personas will help us to prioritize which users are more important than others.
Communicate and form consensus
We work on multi-disciplinary teams with people with vastly different expertise, knowledge, experience and perspectives. As a deliverable, the persona documentation helps communicate findings to people who were not able to be a part of the interviews with users. Establishing a medium for shared knowledge brings teams onto the same page.
Make and defend decisions
Just as personas help prioritize who to design or develop for, they also help to determine what to design or develop for them. When we see the world from a user’s perspective, determining what is useful and what is an edge case becomes simpler.
They are stand-in proxies for users when the budget or time does not allow for an iterative process. Various implementations of a design can be “tested” by pairing a persona with a scenario, similar to how we test designs with real users. If someone who is play-acting a persona cannot figure out how to use a feature or gets frustrated, then the users they represent will probably have a difficult time as well.
My experience across various project types has helped me identify how important persona development is to the success of a project. They have become a key part of my experience design toolbox.