View source for Using personas as representations of users in application design and development

Using personas as representations of users in application design and development / ← Best practices for developing personas

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in one of the groups: Users, editor, pegaemployee.
• The action you have requested is limited to users in one of the groups: pegaemployee, editor, Administrators.

---

You can view and copy the source of this page.

{{Design pattern|Title=Best practices for developing personas|Description=Developing personas|Version=8.4|Applications=Pega Platform|Capability Area=Low-Code App Development|Owner=Warburton, chip|Best practices for developing personas=}} A persona defines a typical user or a group of users that use a product or service in a particular way. Personas define internal and external stakeholders who use the system in different ways based on role and desired business outcome. The purpose of personas is to create consistent and realistic representations of your key system users so that we can better understand our users' needs, expectations, and behaviors. This approach helps us better design products and services that enable the right outcomes and experiences. These representations should be based on qualitative and some quantitative data. The more realistic the personas, the more effective they are in helping in the design and development process.   Effective personas: * Represent a major user group for your application. * Express and focus on the major needs and expectations of user groups. * Give a clear picture of the users' expectations and how they are likely to engage with the application. * Aid in uncovering universal features and functionality. * Describe real people with backgrounds, goals, and values. * Consider internal and external systems that would regularly interact with your application == Why personas are important == Personas provide meaningful insights against which you can assess your design and development. We build personas so that we can ask the right questions and base our answers on the real understanding of our users. Personas are incredibly useful when you do not have easy access to real users because they act as "user stand-ins", helping to guide your decisions about functionality and design. Questions like "How would Ross use this feature?" or "Would Frances even be interested in this?" can start great conversations within your team, getting you to think the way that your users would actually interpret and interact with applications to achieve their goals. In short, personas are one of a range of modeling techniques which help us build apps that help users complete their work effectively. == Benefits of personas == Personas help you build your decisions surrounding application features, functions, and components, by adding a layer of real-world consideration to the conversation. They also offer a quick and inexpensive way to test and prioritize those features throughout the development process. In addition, personas can help: * Stakeholders and leaders evaluate new application feature ideas. * Designers create the overall look and feel of the application. * All stakeholders understand what information and functionality is relevant and necessary to a specific persona’s role. * System engineers and developers decide which approaches to pursue based on user behaviors. * All stakeholders make applications consistent and responsive to the specific persona. == Elements of a persona == A persona generally includes the following key pieces of information: * Fictional name * Job title and major responsibility * Demographics, such as age, education, and other relevant information * Goals and tasks the persona tries to complete using the applications * Physical, social, and technological environment * Quote that sums up what matters most to the persona as it relates to your application * Casual picture representing that user group == General guidance == * Do not "make up" personas. Instead, discover them as a part of your user research, which then provides information for your user story development process. * Write specific personas. You will have a much greater degree of success designing for a single person. The "generic user" will bend and stretch to meet the moment, but your true goal should be to develop software which bends and stretches. Your personas should be flexible, as you will not want to build for one size fitting all. * Create a primary persona to represent someone who must be satisfied but who cannot be satisfied by a user interface that is designed for another persona. * Learn what the persona's goals are so that you can see what your system needs and does not need to do, or what data is displayed or not displayed. * Do not identify more than three primary personas. Such a set means that your scope is possibly too large. * Define a finite number of personas. Your goal is to narrow down the people that you are designing the system for. == How personas are used in design == Personas are a design tool that help you group users according to the responsibilities that they assume within a process, the cases on which they work, and the channels that they can access. This grouping provides for a more granular level of control over the user experience, from defining which stages of a case belong to which type of user, to customizing the interface to include only the information that a specific role requires. You can create as many personas as you like and use them as reference for building access groups in your application. However, think about your scope as you develop personas for a specific feature. The size of components, UI elements, and action areas should target the proper device size and persona. For example, because Pega allows multiple app views in a single application, one can easily create a simplified mobile and chatbot view for end-users and a back-office view for employees, each using the same data and processes but displaying in different views based on persona's needs. == Examples of personas == When designing a credit card dispute case, you create a customer persona and a customer service representative (CSR) persona. The customer uses an elegant, consumer-grade mobile app interface, while the CSR relies on a more utilitarian, task-oriented web portal with back-office functionalities. During the design process, you decide that both personas should have access to the first stage of the case, so that both the customer and the CSR can initiate a dispute from their respective interfaces. However, only CSR users should be allowed to view, advance, and resolve the dispute, so you assign the rest of the case to the CSR persona. After you have mapped your case, you can adjust persona settings to include default interfaces, and create relevant access roles for your application in Dev Studio. By keeping your personas, access groups, and interfaces parallel, you make the case flow more transparent and adaptable to future changes. The following table illustrates the configuration of personas in a credit card dispute. {| class="wikitable" |'''Persona''' |'''Channel''' |'''Interface type''' |'''Can initialize dispute''' |'''Can resolve dispute''' |'''Access group''' |- |Customer |Mobile |Customer |Yes |No |Customer |- |CSR |Web |Case worker |Yes |Yes |Case worker |} == Related information == [https://community.pega.com/knowledgebase/articles/application-development/84/creating-microjourney-customer-success Creating a Microjourney for customer success] [https://community.pega.com/knowledgebase/articles/application-development/84/adding-personas-organize-users Adding personas to organize users] [https://design.pega.com/ Pega Cosmos Design System] [http://agilemodeling.com/artifacts/personas.htm Personas on the Agile Modeling page] [https://www.usability.gov/how-to-and-tools/methods/personas.html Personas on the usability.gov page]

Return to Best practices for developing personas.