This presentation is focused 3 main areas: - Understand personas, how to create them and their impact on software engineering. - How personas can be adapted for use in making decisions on engineering teams - How to create a proto-persona within your team.

1. Incorporating User
Personas in Software
Engineering and
Design Processes

2. Facilitators
Omotayo Madein
Senior Software Engineer at Andela
@TayoMadein
● Fullstack web developer with expertise in
user experience (UX) and user interaction
(UI) design, research and digital
communications.
● Worked in various industries including
logistics, health, education, e-commerce,
entertainment and publishing.
● Interested in bridging the gap between
software engineering and human-computer
interaction (HCI).
Lade Tawak
Design Researcher & Strategist
@deaduramilade
● Passionate about building products and
services that make people’s lives better and
easier.
● Expertise in research, product strategy,
experience design, service design, and
design thinking.
● Worked with startups, agencies, and
multinationals in various industries within
Sub-Saharan Africa

3. Goals
● Understand personas, how to create them and their impact on software engineering.
● How personas can be adapted for use in making decisions on engineering teams
● How to create a proto-persona within your team.

4. “People ignore design that ignores people.”
- Frank Chimero, Author of The Shape of Design

6. Part 1: What is a Persona and
Why does it matter?

7. Challenges that engineers & designers face
● Poor scoping & estimation of projects
● Inconsistent priorities among various team members
● Ignoring the needs of the end users
● Attempting to design systems that suit all users types
● Designing systems for “The Elastic User”
● Executives, Engineers and designers have differing understanding of the end users and their
needs

8. Some background on personas
● Originated in the marketing industry
● Evolved and adapted to as tools for identifying stakeholders in human-computer interaction
design
● Engineers are now exploring use cases where user personas can be used to solve engineering
problems/pitfalls.

9. What are personas?
A user persona is a “human” representation of a user
group. It is developed from collecting quantitative and
qualitative data on the behaviour, goals, wants, needs,
and capabilities of the targeted user demographic.

10. “Personas aid designers to create different designs for
different kinds of people and to design for a specific
somebody, rather than a generic everybody.” - Shlomo
Goltz

11. So, why create personas?
● Creating a system without considering the actual people that will use it often leads to
recurring issues
● Each team member usually has a differing understanding of the project they are working on
and may even be unaware of how end users behave.
● Personas help bring everyone to the same level of understanding about the users
● Helps to create a clear and realistic knowledge of the final user by efficiently representing their
behaviours, goals and needs
● Helps teams set a common understanding of their user groups so they can build a final
product that is user oriented and prioritize features based on the needs of their user groups.

12. So, why create personas?
● Provide a reality context by helping designers/product managers/engineers remain focused
on the needs of the target users and not on every possible need of every user.
● Prevents designing for “The Elastic User”.
● Helps transform all the data into relatable information.
● Helps us to vet and prioritize feature requests.
● Helps prevent "self-referential design".

13. When are personas not useful?
● When they are not supported by research but one person’s mental models.
● When you confuse design personas with marketing personas.
● When user personas are not evolving with your design.
● When you have too many personas and not enough resources to manage them.
● When you think personas are the one-stop solution to all your user problems.
● When the personas are not shared throughout the team, it becomes difficult to prioritise
features based on the user’s needs.

14. Personas are snapshots in time of your users and can
become obsolete if they no longer reflect your current
users’ behaviors, needs, or goals

15. Personas do not stand alone
As people change, their needs evolve and so should your personas, and
business.
Changes in interaction patterns and technology will also result in
reassessing your personas.
For personas to be effective, they must be combined with other user
research methods and design processes.

17. Part 2: How I Create Effective
User Personas Without A Budget

18. Introducing Proto-Personas
● Creating effective personas usually requires the resources to conduct long term field research
and gather data from the actual target audience.
● Proto personas are a starting point for creating personas when you are resource-constrained
● Proto personas do not replace personas, but evolve into personas based on research
● Proto-personas lower the bar to keep products user-centric early in the process.
● Proto-personas are cost effective since they leverage on existing knowledge.

19. A proto-persona is an ideal user, not your actual user.

20. Creating Proto-Personas
● Proto personas can be low-fidelity or high-fidelity but all stakeholders must be aware that the
proto-personas must evolve throughout the product’s lifecycle.
● Proto personas have four quadrants similar to a typical research based persona: Biography &
Picture, Demographics, Needs & Goals, and Behaviors & Beliefs.
● They are created internally through a brainstorming session with all stakeholders.
● The brainstorming process to create a proto can take between 2 - 5 days to complete.
● Proto-personas are supported by user flows/workflows

22. Proto-personas are created as a representation or variant
of typical personas and are not backed by field research.
Proto-personas are created based on the knowledge,
existing data and intuition of the stakeholders to help
everyone have a clear and unified knowledge of the user
that a product is being built for.

23. When to use Proto-Personas:
● When there’s not enough resources to conduct field and desk research to create traditional
personas
● When you want a unified knowledge base of the assumptions that influence requirements
● When you need to quickly define what features are included in a product’s minimum viable
product based on the assumptions
● When you want to identify potential pitfalls during the requirements gathering phase
● When you combine with user workflows
● When you keep evolving the proto-personas based on real data collected from usage

25. ● Prioritizing proto-personas over actual user behavior
● Not distributing proto-personas across teams
● Not evolving the proto-persona based on real data
Mistakes to avoid when using proto-personas

26. Part 3: A Quick Guide for
Creating a Proto-Persona

27. Practical guide to proto-personas
● Duration: 2 Days for Brainstorming Sessions, 2 - 4 weeks to get the final output
● Participants: 1 to 2 people that represent each team/unit involved in the process, all key
executive team members (From VP of Engineering to Engineering Managers), a facilitator and
someone that documents the session.
● Materials: Post-it notes, whiteboard or plain wall, paper tape, markers, pens
● Guide: Proto-Persona Brainstorming Session Guide

28. Process

29. What We Want To Learn About Our Users

30. Process

31. Appendix

32. Resources - Articles
● Personas – A Simple Introduction by Rikke Dam
● Personas vs Proto-Personas by Matthew Farleo
● How to Make Proto-Personas and Get Everyone on the Same Page by Brent Summers
● Provisional Personas by Christopher Daniels
● Using Proto-Personas for Executive Alignment by Jeff Gothelf
● Creating Proto-Personas by Andrew Jacobs
● Creating Personas by Eeva Ilama
● A Closer Look At Personas: What They Are And How They Work by Shlomo “Mo” Goltz
● Are Your User Personas Growing With You? by Sheena Lyonnais

33. Resources - Journal Articles
● Schneidewind, Lydia & Horold, Stephan & Mayas, Cindy & Kromker, Heidi & Falke, Sascha &
Pucklitsch, Tony. How personas support requirements engineering. First International
Workshop on Usability and Accessibility Focused Requirements Engineering (UsARE), Zurich,
(2012), pp. 1-5.
● Paech, Barbara and Kirstin Kohler. “Usability Engineering integrated with Requirements
Engineering.” ICSE Workshop on SE-HCI (2003).
● Haikara J. Usability in Agile Software Development: Extending the Interaction Design Process
with Personas Approach. In: Concas G., Damiani E., Scotto M., Succi G. (eds) Agile Processes
in Software Engineering and Extreme Programming. XP (2007). Lecture Notes in Computer
Science, vol 4536. Springer, Berlin, Heidelberg
● Jones, M. Cameron, Ingbert R. Floyd, and Michael B. Twidale. "Teaching design with
personas." (2008).