Several user centric software design techniques have been devised and used in e-government projects over the years, including personas, user walkthroughs, use cases, scenarios, wire-framing and low/hi-fidelity prototyping. Furthermore, Buie and Murray state that governments also use tools such as focus groups, surveys, server log analytics and regulatory checklists to align themselves towards usable designs [24]. van Velsen et al. [166] present a list of citizen-centric RE activities for the development of e-government scenarios, including studies on life-events, interviews with experts, surveys, focus groups and think aloud sessions.
Inviting participants to a focus group is extremely useful, however there’s always the risk of getting outliers who can skew the focus onto trivial issues. Personas are used to encourage the design team to focus their attention on the end user throughout the design stage, mitigating the risk of building systems that appeal to the developers’ own interests [55]. Cooper [36] defines personas as archetypal representations of specific user groups, each bringing onto the drawing board more scope for discussion, and a deeper understanding of what the persona might want, like and dislike. This representation is built on empirical evidence rather than on mere speculation and stereotyping (archetypes vs stereotypes).
Cooper distinguishes personas from user profiles (“a brief biographical sketch”) and market segments (based on demographic, distribution channels and purchasing behaviour). By contrast personas are based on ethnographic data and focus around behaviour and motivations (goals). Without understanding and encapsulating motivations and goals, personas may still serve as an effective communication tool within the design team however it will not contribute as an effective requirements development and design tool [38]. Faily and Fl´echais argue that personas “do not look like specifications” and developers might not relate to aspects such as names, jobs, goals and feelings [55].
Personas are meant to facilitate group discussion while directing the designers’ energy towards a unified direction. Various requirements elaboration and design techniques are proposed in literature and many of these methods suggest the use of personas as a technique to understand the eventual user and inform design decisions [138,54,53,55,123,117,166]. Auto-makers Ford use personas in the design of new car models and in an article in The New York Times3Phil Patten states that the company first designs the driver before designing the car. In fact Ford propose various driver profiles, including details about their social lives based on demographic research. Design teams at Ford believe that personas help get everyone on the same page, while providing a common focus “from the clay modeller to the chief executive”. This statement was made by Murat Yalman, Ford’s director of global advanced product strategy. Yalman encourages the representation or personalisation of the car driver so that everyone understands who they’re working for, creating “very memorable ideas that live on after the meeting or presentation”.
3Phil Patten, The New York Times, http://www.nytimes.com/2009/07/19/automobiles/19design.html?pagewanted=all, (ac-cessed September 2013)
2.2. The Interface Between RE and HCI 53
Personas were initially referred to as CustomerPrints at OgilvyOne and were used to help build market segmentation strategies. Alan Cooper [34] first introduced the term persona in the software field in his efforts to make software more “human and forgiving”. According to Cooper personas are defined by goals and these are generally discovered as a by-product of a rigorous investigation process of the problem domain based on successive refinements. Dotan et al. [44] state that personas make assumptions about end users more explicit, however the authors argue that a persona cannot provide information on critical aspects such as system usability and usefulness. For this reason, other user-centred technique, such as user testing, are still required [44].
To build effective personas a rigorous process of discovery is required, collecting behavioural data across multiple sources and adopting various techniques, including in-context interviews with and ob-servation of potential users, demographic research, historical information such as actual user help-desk requests or complaints and so forth. Adlin and Pruitt [2] take this further and propose the persona life-cycle, a metaphoric and cyclical framework that assimilates persona-related development processes with the human lifecycle. The authors suggest five phases: (1) family planning (why is this persona required and what data sources are available?), (2) conception and gestation (systematically turning data and assumptions into personas), (3) birth and maturation (personas are introduced in the organisation), (4) adulthood (adoption of personas at several stages of a project, including system design, development, evaluation and post-launch) and (5) lifetime achievement and retirement (the point where persona-related efforts are measured and plans are put in place for its re-use, re-incarnation or retirement). Adlin and Pruitt suggest a number of reason as to why persona efforts fail in a practical setting, and these include (1) low management acceptance and support, (2) poor communication of personas during projects and (3) lack of understanding of the technique by the product design and development team [2]. In their book [2], Adlin and Pruitt provide detailed guidelines on how to build and use personas – making this an important resource for both HCI researchers and (especially for) practitioners. Their experience-based, data-driven and methodical approach fills the gap in HCI literature on the proper use of this user centred design tool. The authors continue to argue that personas (and associated processes) should be inte-grated into existing development processes and tools. This may in turn encourage adoption and improve persona-based communication.
Personas also bring forth scope for qualitative discourse, and it is up to the designers to accept or reject statements and assumptions brought forward throughout the design process. Arguments based on personas are subjective as much as the persona itself and its validity can be threatened [52]. Devel-opers may also refute aspects of a persona to argue against a specific product feature. This weakens the persona’s legitimacy especially if other characteristics are called into question [55]. Other risks ex-ist; what if the designers come up with a stereotypical persona which is not representative of actual users? Ethnographic research might be useful at this point however it might still not validate personas since “specific examples of data cannot be provided to prove their accuracy” [55]. Faily and Fl´echais [55] present Persona Cases, a technique that attempt to legitimise the validity of personas by grounding their characteristics in, while making them traceable to the originating source of empirical [qualitative]
data. This technique adopts Grounded Theory as its underlying development method and frames persona characteristics as arguments (see Table2.1) following Toulmin’s Model of Argumentation [164] (cited in [55]). Persona Cases call for a rigorous analytical process whereby thematic concepts are explored, inter-related (after being analysed), and linked to their respective primary source of evidence (refer to Section3.1.2). Faily and Fl´echais believe that Grounded Theory artefacts (i.e., evidence) are helpful when questions about a persona’s characteristics are raised during design meetings [55]. Persona Cases are based on argumentative techniques, adopting terms such as claims (persona characteristics represent-ing any of the followrepresent-ing behavioural variables; activities, attitudes, aptitudes, motivations and skills), grounds (evidence for these claims), warrants (describing how grounds contribute to claims) and their backing (origin of warrant’s assumption). Assumption may also act as rebuttals (challenging a claim’s validity) whereby a modal qualifier determines the degree of certainty for a given claim.
The process for creating Persona Cases involves three steps [55]: the first step (summarise propo-sitions) involves the identification of salient themes (thematic concepts) based on how grounded (in empirical data) and networked (with other themes) these themes are. Propositions are based on quo-tations underlying each theme in the resulting GT model. The second step is to argue characteris-tics, describe claims, justify their existence with propositions (acting as the claims’ grounds/warrant) and specify modal qualifiers (based on the analyst’s confidence on the relationship between claims and propositions). Propositions that rebut a claim are also listed. These may then be used while debating a persona’s characteristic. Finally persona narratives based on elicited characteristics are written for each behavioural variable type. This links such narratives back to the Grounded Theory model as well as sup-porting artefacts. This evidence provides further validation to the persona, however care must be taken not to build “elastic” personas as some characteristics may be irrelevant to the current context of analysis or are poorly grounded – possibly encouraging team members to argue in favour of, or against any de-sign decision using vague or irrelevant attributes. Additional personas might be required to reflect newly discovered characteristics elicited in previous steps. The authors suggest the use of affinity diagrams to organise characteristics into “natural groupings” that form the basis for new personas [55].
Table 2.1: A persona characteristic argument example (adapted from [55])
Relationship Information Security Indifference is a cause of Island Mentality Characteristics SCADA isolation make hacking unlikely
Persona Cases provide solid grounds for discussion and debate, nonetheless this design technique is subject to issues that may inhibit adoption by practitioners (including developers and policy makers). The first issue is related to the level of specialist knowledge required to build Persona Cases (i.e., knowledge of Grounded Theory and thematic coding). Having a team member with such knowledge on board is a rare occurrence in industry especially within small project teams. From personal experience, teams for