Information Security Application Design: Understanding Your Users

  • Ranjan BhattaraiEmail author
  • Ger Joyce
  • Saurabh Dutta
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 9750)


The basis of Human-Centered Design is the understanding of users’ goals and needs. One way to empathize with users is to create Personas. Yet, traditional methods of creating Personas are time-consuming. In this work, members of the Rapid7 User Experience team illustrate how they have quickly created Personas using the Proto-Persona method. The method, which encapsulates a collective set of beliefs that an organization has about their users, enabled our organization to capture stories of 80 characters. Refining these during the process, resulted in 16 Proto-Personas, which were visualized within a Persona Ecosystem. This Ecosystem, and the Personas within, has allowed Rapid7 to design the right Information Security applications for the right users at the right time.


Personas Proto-Persona Agile User research 

1 Introduction

Understanding users’ goals and needs is the basis of Human-Centered Design [1]. Yet, many application design decisions are made without this understanding [2, 3]. The need for empathy led to the development of Personas [4], which are fictitious representations of users [5]. There are many advantages offered by Personas, including the effective communication about users and their needs [6], as well as their ability to guide decision making [7].

Personas, while fictitious, are generally created from upfront research. However, one of relatively recent challenges to design teams is that Agile software development processes are much faster than older software development approaches. Therefore, researchers and designers have less time for user-centered activities [8, 9], including the comprehensive research needed to create rich Personas. The contribution of this work is to unveil the process implemented at Rapid7, an Information Security application provider, which was modelled on the Proto-Persona approach pioneered by Gothelf and Seiden [10].

2 Related Work

Since their introduction in the late 1990’s, Personas have been a topic of debate among Human-Computer Interaction (HCI) researchers and practitioners. Cooper [4], like many others, has argued that Personas are necessary, as many organizations’ products are not empathetic to users’ needs and goals [11, 12]. This lack of empathy often results in frustrated customers and even failed businesses. Consequently, many researchers have come to the defense of Personas. For instance, researchers have argued that Personas can help pinpoint the actual types of users of a product [13], as well as ensuring that the right problems are being addressed [14]. The Personas can then be shared within the organization [15], which allows for the user to be brought to the forefront, resulting in designs built specifically for the right type of user [16, 17]. With these arguments in favor of Personas, many organizations have begun to utilize the method within their design process [18].

However, not all HCI researchers and practitioners are enthusiastic about Personas. When Pruitt & Adlin, [19] state that Personas have an element of fiction, other researchers argue that this is a reason why many HCI researchers and practitioners cannot relate Personas to real people [20]. This became an issue for Blomquist & Arvola [21] when they found that the participants in a study were uncomfortable using Personas. Yet, while Personas can have an element of fiction, they need to be grounded in research, otherwise they will not be effective. Unfortunately, being grounded in research does not always transpire [22, 23], and this can cause distrust of Personas among HCI researchers and practitioners [24].

Further concerns regarding Personas have been raised by Nielsen [20], who argues that there is no typical understanding of Personas, subsequently each organization and HCI team essentially creates and uses Personas their way with no standards in place. For example, while a common understanding of Personas is that they help with design [7], researchers have found that Personas might not be used for design at all, and instead can simply be used for communication [25]. Even with Personas, designers continue to express their own desires and subjective views, occasionally rarely referring to Personas, which defeats the purpose of creating the Personas in the first place [26]. Yet, despite these concerns Personas remain a popular method of Human-Centered Design [15].

One of the primary gaps in our knowledge regarding Personas revolves around much of the Literature focusing on traditional Persona development. For instance, Mulder & Yaar [27] concentrate on time-consuming upfront quantitative and qualitative user research that eventually lead to Personas. Thus, the development of Personas within fast-paced Agile environments, as advocated by Ambler [28] and Leffingwell [29], such as Ad-hoc Personas and Proto-Personas, is currently under-represented within the Literature. Until this research has been completed, we are left to wonder if accurate, useful Personas can be developed quickly, and still be useful for design teams to build the right product, at the right time, for the right user.

3 Alternatives to Traditional Approaches

Alternative approaches to Persona creation, such as Proto-Personas [10, 30] and Ad-Hoc Personas [31], were proposed to enable organizations to quickly take steps towards understanding users. While not a replacement to the research-driven Persona creation, these methods can still be effective and can be a catalyst for an organization to adopt a customer centric point of view.

Norman [31] conveyed that while Ad-Hoc Personas “…are created quickly, …do not use real data, and…are employed without much background information and attention to detail.”, they were still useful in generating empathy and enabling a user or a customer point of view.

Gothelf [30] proposed the Proto-Persona method, which can encapsulate a collective set of beliefs that an organization has about their users. These collective beliefs can then be validated. A significant difference between the Proto-Persona method and the traditional method driven by research data, is that the Proto-Persona method enables participation and contribution by a diverse group of stakeholders across the organization. Not only does this result in a strong cross-sectional contribution, but involvement in the creation process fosters early buy-in and support during persona rollout. Another benefit of this method is the rapid surfacing of differing and conflicting beliefs about the customer/user. These differences are successively discussed, probed, and resolved. Similarly, this method also illuminates areas of strong agreement. The overall output of this method is a set of Proto-Persona that reflect a reasoned set of hypothesis that can be validated against the real world data. This remainder of this work focuses on the use of the Proto-Persona method within Rapid7.

4 Proto-Persona Method

The development of Proto-Personas is at its core a moderated working session. The session produces a host of artifacts that capture the individual and the group’s beliefs about users. After the working session, one or more HCI practitioners digitize and synthesize the materials, and present them back to the group to ensure continued alignment.

4.1 Before the Session

It is critical to ensure that a diverse group of individuals representing a wide cross-section of the organization are selected for this kind of session. The most important requirement, other than time commitment, is the fact that participants interact with the organization’s customers in some form. However, potential participants must be screened. The danger of simply inviting eager individuals is that a substantial amount of opinion-based data might be collected. While this will occur regardless of the screening process, this should be minimized by inviting individuals who currently or in the past have had direct contact with customers.

4.2 During the Session

The moderator kicks off the session with a short presentation that covers the purpose of the session, the various sections, the amount of time the team is expected to spend on each session, and the expected output at the end of the session. The moderator also introduces the team to each of the various sections of the session at a high level with examples of output associated to each section from other sessions. Additionally, the moderator ensures all of the cross-functional teams represented in the session are called out to emphasize one of the core purposes of the session– namely, cross-functional collaboration and alignment to better understand and serve the organization’s users. Finally, before commencing the session, the moderator pauses for, and answers, any questions participants might have.

Gothelf [30] suggests two 3-hr working sessions, ideally one session a week, and conducted within two consecutive weeks. Our team found it logistically difficult follow this model as many participants were not co-located, and needed to travel to attend the session. Instead, we opted for one, slightly longer working session (about five hours with breaks), during which we were able to achieve all our goals.

We also conducted three separate rounds of Proto-Persona sessions at three different locations that develop three different product lines. We fully understood that participants in each location would be focused on their product lines, but we wanted to capture the widest variety of perspectives and beliefs within our organization. After analysis of all of the characters from the sessions, we began to see recurring themes and that the personas behaviors, beliefs, needs and goals transcended product lines.

The Proto-Persona session has 3 parts: Character Development, Meet the Cast, and Character Refinement. From our experience running these sessions, a break before Character Refinement is needed and appreciated by participants (Fig. 1).
Fig. 1.

A cross functional team working through Character Development part of the session. We conducted three separate sessions across our offices to accommodate wider participation.

Part 1: Character Development. During the Character Development section of the Proto-Persona process, all participants write down their beliefs about customers or product users. A character development worksheet is critical for this process (see Fig. 2). The moderator shows a sample completed worksheet, and distributes blank worksheets to all participants. The moderator then asks the participants to reflect back on one or more interactions with customers and/or users, and to write down their understanding of the customer/user’s needs, beliefs, behaviors, and goals. The moderator also clarifies that participants can create as many characters as they wish.

The worksheet is a letter-sized piece of paper divided into quadrants. In the top left quadrant, Biography and Picture, participants list a set of salient customer/user characteristics. In the bottom left quadrant, Demographics, participants fill in more details about the character that shed. In the top right quadrant, Behaviors and Beliefs, participants showcase what the character believes in and what he/she does. Finally, in the bottom right quadrant, Needs and Goals, participants list what the character wants to ultimately achieve.
Fig. 2.

A side by side view of the Persona Worksheet before and after it was filled in by participants.

In all sessions, we have found that exhibiting a completed worksheet help participants understand how to populate their worksheets. We have also had to remind our participants to go beyond product specific enhancements and postulate the reasons behind such enhancements.

Part 2: Meet the Cast. Meet the Cast is the part of the process where participants introduce their characters to the rest of the group. This is a particularly exciting time in the session, as this is most likely the first time participants have written or spoken about the user or customer in this way. Before commencing this part of the session, the moderator reminds participants to introduce the character(s) they have developed similar to how they might introduce a friend at a party. The focus on storytelling enables participants to move away from worrying about the beauty of the artifact, such as the legibility of their handwriting, focusing instead on the story of the character they are introducing. The moderator requests that participants stand in front of the wall labeled “Meet the Cast” as they introduce their character(s). Once a participant is finished introducing their character(s), the participant affixes their completed worksheet(s) on the wall. As this process unfolds, the entire wall is covered by various characters and their stories.

During Meet the Cast we observed that, regardless of their functional background within the organization, all participants generated multiple characters, and were visibly excited to share the stories of each character. As participants told their stories, many within the group verbally agreed with the points made– which were the first signs of alignment. The storytelling also helped humanize, and began to generate empathy for, the characters. (Fig. 3)

Part 3: Character Refinement. Character Refinement is the most challenging step in the Proto-Persona process. Character Refinement demands strong focus from both the moderator as well as all participants. Allowing participants to take a break before this step enables enhanced focus during this final part of the process. During the Character Refinement phase, the group identifies similar characters, merging each into one character, thus effectively reducing the overall data. At the request of participants, the moderator will group similar characters by either physically moving the worksheets into a group, or by using a colored post-it note to indicate similarities. Should disagreements arise within the group during the Character Refinement phase, dialogue is encouraged within the group to resolve differences. Initial focus on easy-to-solve disagreements enables constant forward movement while avoiding larger disputes. The end goal is to get to a manageable number of characters, with a view to start considering each Proto-Persona’s attributes. With attributes defined and measured, further opportunities arise for Character Refinement.
Fig. 3.

A snapshot of a Meet the Cast presentation and a sample of its accompanying artifacts

To that end, the next step involves identifying what those key attributes might be, and to plot those on an abstract scale. Based on the character stories, a few key attributes will naturally emerge. Should this not be the case, the moderator can kick start this process, by using demographic information, such as years of experience or technological fluency, and asking the group to consider if these attributes are significant for the business. In one of our sessions, the group felt that the number of years of experience did not domain expertise. Therefore, the group amended this attribute appropriately. In another session, the group thought that the personality of the character, introverted/extroverted, was a significant attribute to consider. Having defined each attribute, the group measured each on an attribute scale from 0 to 5. Once again, disagreements were resolved through dialogue.

It is important to clarify with the participants that the attribute scale and the numbers plotted are not absolute values. The attribute scale establishes a relative degree of sophistication and enables comparison between two Proto-Personas on a same attribute. In all our sessions a 0 was synonymous with none and a 5 was the ultimate sophistication on that attribute. Often, we found that participants had a difficult time agreeing on a specific number along the attribute scale. As discussions unfolded, participants proposed a range for a particular attribute (see Fig. 4). Participants considered a single digit to be overly simplistic, resulting in an incorrect reflection of the diverse user population the group was attempting to serve. For example, we used a range, 3 to 5, instead of a specific number to capture a security knowledge of an executive proto-persona.
Fig. 4.

The moderator plotted the metrics along an abstract scale. Each participant choose a color and a symbol like an “x” or “o” or a “dot” to represent the character they were plotting against. One can also see how the need for range was expressed by connecting lines between symbols.

A key point to remember is that both the attributes and the attribute scale are hypotheses, and are subject to change based on field research. The focus during this part of the session should be on narrowing down of the characters and continued alignment among the participants.

4.3 After the Session

While the Proto-Persona session can be exciting, and at times challenging, participants walk away with a sense of accomplishment, as well as with a shared point of view about the types of customers or users that exist. For the moderator and the HCI practitioners present, the next step is to rapidly digitize, analyze, and synthesize learnings. Having a follow-up shorter session within one week with the original participants enables the presentation of the digitized Proto-Personas. This, in turn, enables final agreement, ensures momentum, and continued focus on the overall Proto-Persona initiative. While it is not necessary for participants to meet in person during the follow-up session, it is important that all Proto-Persona artifacts be available in digital format for further discussions.

4.4 Follow Up Sessions

One should fully anticipate changes and not fall into the trap of finalizing Proto-Personas, or converting them as Personas without research from the field. After the Proto-Persona session and additional analysis, key characters will emerge as important to the organization. These characters are the ones that should be vetted with the original participants in a follow-up session to ensure that the team agrees on the synthesis.

Another area of follow-up are key executives and stakeholders who ultimately are in a position to support this initiative. While it is impractical to involve every single person in the company, it is important to share the process, the artifacts and the synthesis to date, and allow for input. In our organization we conducted multiple rounds of input throughout the organization to explain the process, the artifacts, and solicited input. This has resulted in larger buy-in and support from a wider cross-section of the organization.

5 The Proto-Persona Ecosystem

The Proto-Persona sessions enabled our organization to capture stories of 80 characters. Through the Character Refinement phase, the 80 characters were reduced to 16 Proto-Personas. As relationships between Proto-Personas were not clear, an Ecosystem was developed. To that end, the Proto-Persona Ecosystem allowed us to see a basic organizational relationship. Additionally, the Ecosystem enabled us to see who is involved in a particular task. For example, when our team wished to design an easy setup workflow, it was understood that two separate Proto-Personas needed to work together to complete the task. This was not a question of whether one Proto-Persona was primary and the other secondary, rather, it was the understanding that the workflow needed to account for both Proto-Personas. The ability to expose this level of interconnection between Proto-Personas via the Ecosystem helped us demonstrate the need to really understand the users involved in many of the complex workflows.
Fig. 5.

Example of a Persona Ecosystem used to demonstrate the organizational hierarchy. In many companies some of these roles outlined are performed by one individual, while some organizations have multiple individuals performing one role.

The Proto-Persona Ecosystem is not part of the Proto-Persona method. The authors arrived at this communication tool as we saw a need an opportunity to provide more clarity around the hierarchy and the interconnectedness between Proto-Personas in a single view. The ecosystem also allowed us to capture the prevailing hypothesis of how inter-dependent our customers are within their organization’s functional groups. (Fig. 5)

6 Conclusion

This paper summarized the Proto-Persona methodology, and how the method can enable organizations to jump start the process of better understanding their customers and users. Specifically, Proto-Persona sessions align internal points of view to arrive at a set of testable hypotheses about a customer or a user. These hypotheses can then be further validated, adjusted, and refined based on field data. The paper also introduced the Proto-Persona Ecosystem that visually demonstrates a Proto-Persona’s organizational hierarchy and inter-dependence with others.

Another aspect of the Proto-Persona method is inclusiveness. Unlike the traditional methodology, where much of the process, data, and analysis stay within the purview of a small group of researchers, Proto-Persona methodology enables participation from a cross-functional team from the beginning. This fosters an early buy-in, confidence in the process, and a sense of collective ownership of the output. These factors are beneficial when Personas are rolled out to larger audiences within the organization.

While this paper focused primarily on the methodology, further validation, socialization, and use of Personas during product and service decisions is the ultimate goal. Validation is a continuous process and as new attributes are discovered, these need to be captured, analyzed, and applied to the appropriate persona.

Socialization of Personas within the organization is another challenging, yet critical step that requires a careful rollout strategy. In our experience, this requires numerous rounds of education, evangelization, and feedback sessions at various levels. We recommend starting with the Proto-Persona session participants, as these individuals are well positioned to provide additional context to the team and can also become a point of contact when questions arise.

As product teams embark on their daily work, it is essential that as a part of the rollout strategy, a wide variety of artifacts such as Persona posters, cards, and slides are generated and made visible across office locations, and electronic copies be shared as widely as possible. Ultimately, Personas are tools, and regardless of the method used to generate them, their goal is to enable organizations and teams to make product and service decisions from a customer or user point of view.


  1. 1.
    Kim, J.W.: Human computer interaction. Ahn graph (2012)Google Scholar
  2. 2.
    Dahl, D.W., Chattopadhyay, A., Gorn, G.J.: The use of visual imagery in new product design. J. Mark. Res. 36(1), 18–28 (1999)CrossRefGoogle Scholar
  3. 3.
    Wiegers, K., Beatty, J.: Software Requirements. Pearson Education, New York (2013)Google Scholar
  4. 4.
    Cooper, A.: The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. Macmillan, London (1999)CrossRefGoogle Scholar
  5. 5.
    Adlin, T., Pruitt, J.: The Essential Persona Lifecycle: Your Guide to Building and Using Personas: Your Guide to Building and Using Personas. Morgan Kaufmann, Burlington (2010)Google Scholar
  6. 6.
    Ma, J., LeRouge, C.: Introducing user profiles and personas into information systems development. In: Proceedings of the Americas Conference on Information Systems, AIS (2007)Google Scholar
  7. 7.
    Long, F.: Real or imaginary? the effectiveness of using personas in product design. In: Proceedings of the Irish Ergonomics Society Annual Conference, pp. 1–10. Irish Ergonomics Society (2009)Google Scholar
  8. 8.
    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.) XP 2007. LNCS, vol. 4536, pp. 153–156. Springer, Heidelberg (2007)CrossRefGoogle Scholar
  9. 9.
    Humayoun, S.R., Dubinsky, Y., Catarci, T.: User evaluation support through development environment for agile software teams. In: Smart Organizations and Smart Artifacts, pp. 183–191 (2014)Google Scholar
  10. 10.
    Gothelf, J., Seiden, J.: Lean UX: Applying Lean Principles to Improve User Experience. O’Reilly Media Inc., Sebastopol (2013)Google Scholar
  11. 11.
    Gulliksen, J., Goransson, B., Boivie, I., Blomkvist, S., Persson, J., Cajander, A.: Key principles for user-centered systems design. Behav. Inf. Technol. 22(6), 397–409 (2003)CrossRefGoogle Scholar
  12. 12.
    Schaffer, E.: Institutionalization of usability. Pearson Education, Boston (2004)Google Scholar
  13. 13.
    Hourihan, M.: Taking the “you” out of user: my experience using personas. Boxes and Arrows (2004). Accessed 21 Jan 2016
  14. 14.
    Negru, S., Buraga S.: Towards a conceptual model for describing the personas methodology. In: Proceedings of the ICCP 2012. IEEE (2012)Google Scholar
  15. 15.
    Junior, P.T.A., Filgueiras, L.V.L.: User modeling with personas. In: Proceedings of the 2005 Latin American Conference on Human-Computer Interaction, pp. 277–282, ACM (2005)Google Scholar
  16. 16.
    Goodwin, K.: Perfecting your personas. Cooper Interact. Des. (2004). Accessed 1 Feb 2016
  17. 17.
    Miaskiewicz, T., Kozar, K.A.: Personas and user-centered design: how can personas benefit product design processes? Des. Stud. 32(5), 417–430 (2011)CrossRefGoogle Scholar
  18. 18.
    Manning, H., Temkin, B., Belanger, N.: The power of design personas. Forrester Res. (2003).,1338,33033,00.html. Accessed 14 Jan 2016
  19. 19.
    Pruitt, J., Adlin, T.: The persona lifecycle: keeping people in mind throughout product design. Morgan Kaufmann, Burlington (2010)Google Scholar
  20. 20.
    Nielsen, L.: Personas - User Focused Design. Springer Science & Business Media, London (2012)Google Scholar
  21. 21.
    Blomquist, Å., Arvola, M.: Personas in action: ethnography in an interaction design team. In: Proceedings of the Second Nordic Conference on Human-Computer Interaction, pp. 197–200. ACM (2002)Google Scholar
  22. 22.
    McQuaid, H.L., Goel, A., McManus, M.: When you can’t talk to customers: using storyboards and narratives to elicit empathy for users. In: Proceedings of the 2003 International Conference on Designing Pleasurable Products and Interfaces, pp. 120–125. ACM (2003)Google Scholar
  23. 23.
    Chang, Y., Lim, Y., Stolterman, E.: Personas: From Theory to Practices. Proceedings of the Building Bridges, pp. 439–442. ACM, (2008)Google Scholar
  24. 24.
    Chapman, C.N., Milham, R.P.: The persona’s new clothes: methodological and practical arguments against a popular method. In: Proceedings of the Human Factors and Ergonomics Society, HFES, pp. 634–636 (2006)Google Scholar
  25. 25.
    Matthews, T., Judge, T., Whittaker, S.: How do designers and user experience professionals actually perceive and use personas? In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 1219–1228. ACM (2012)Google Scholar
  26. 26.
    Friess, E.: The sword of data: does human-centered design fulfill its rhetorical responsibility? Des. Issues 26(3), 40–50 (2010)CrossRefGoogle Scholar
  27. 27.
    Mulder, S., Yaar, Z.: The User is Always Right: A Practical Guide to Creating and Using Personas for the Web. New Riders, San Francisco (2006)Google Scholar
  28. 28.
    Ambler, S.: Tailoring usability into agile software development projects. In: Law, E., Hvannberg, E., Cockton, G. (eds.) Maturing Usability Quality in Software, Interaction and Value, pp. 75–95. Springer, Heidelberg (2008)CrossRefGoogle Scholar
  29. 29.
    Leffingwell, D.: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, Boston (2010)Google Scholar
  30. 30.
    Gothelf, J.: Using proto-personas for executive alignment. UX Mag. 821 (2012). Accessed 21, Feb 2016
  31. 31.
    Norman, D.: Ad-Hoc Personas and Empathetic Focus (2004). Accessed 27 Feb 2016

Copyright information

© Springer International Publishing Switzerland 2016

Authors and Affiliations

  1. 1.Rapid7BostonUSA

Personalised recommendations