DeAndre Design

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:

Build empathy

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.

Develop focus

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.

Measure effectiveness

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.