Tag Archives: Persona

RAA: It’s hard to tell a good story — exploring persona-scenarios

RAA stands for: Research Article Analysis

Paper discussed:

Madsen, S., & Nielsen, L. (2010). Exploring Persona-Scenarios – Using Storytelling to Create Design Ideas. In D. Katre, R. Orngreen, P. Yammiyavar, & T. Clemmensen (Eds.), Human Work Interaction Design: Usability in Social, Cultural and Organizational Contexts (Vol. 316, pp. 57-66). Berlin, Heidelberg: Springer Berlin Heidelberg. Retrieved from http://www.springerlink.com/content/6nh13h2684v154lm/

1. Purpose of the research:

Explore the persona-scenario method and propose guidelines about how to construct persona-scenarios as good and coherent stories for IT system design.

2. Methods:

Review of persona, scenarios, and narrative theory was introduced and followed by a case study. Review part is heavy in this paper because of its theoretical characteristic. Case study was presented as a verification as well as supplement for their conclusion.

The case study was reported as group tasks from a persona-scenarios workshop. The task was to build persona-scenarios to facilitate the redesign of Virk.dk, a portal that enables companies to submit forms digitally to government. Sixteen participants were chosen, as key stakeholders in development process, to attend the workshop. They were than divided into 4 groups and worked on building persona-scenarios. Each group was given a short text with a start situation for their persona, and asked to write and present their scenarios based on the situation given. The authors also provided a brief analysis of the case.

3. Main Findings:

The authors brought up their “theory” of building persona-scenarios in narrative theory perspective, mainly based on their review of different methods and theories. Since the nature of scenarios is story-telling, they believed that follow and modify the narrative theory could help to build well-constructed persona-scenarios. They then gave a mapping between narrative elements (characters, time, problem, setting, opening episode, episodes, resolution, plot, overall story, and narrator’s perspective) in the story form and narrative elements in a persona-scenario. In this way, they tried to define the scope and structure of a persona-scenario.

In the next stage, through analyzing the case study, they found out that “for scenario writers, once the story is started, it develops in its own course”, which means they might have different focus and extra preference developing the story. This will inevitably harm the credibility of the scenarios. Based on the case study, they further provided the following instructions as supplements to their previous mapping:

  • In the scenarios, while the persona is the protagonist, the future IT system has to play a prominent role as well — it could be part of the events — rather than a character or tool-like object.
  • In design scenarios, the problem should always be solved and goal should always be reached. Because “the more they address obstacles and design-oriented ways of overcoming the obstacles, the more concrete the future IT system and design ideas for the future IT system stand out within the story and get validated from the persona’s point of view”.

At the end, they gave a comprehensive table of components in a design-oriented persona-scenarios, developed from the original mapping table and the case study results.
4. Analysis:

This paper is well executed in terms of providing very good points for constructing persona-scenarios. The correlation of persona-scenarios and narrative theory was wisely found and presented to construct the structure of persona-scenarios. Analysis of case study was brilliant too, with good points found to further modify the theoretical structure. I enjoyed the analyzing process that they finally come up with the opinion that persona-scenarios should all have a happy-ending in order to provide more insight for design.

The only thing weak in this paper is the way they presented their case study. It is unclear in several critical points, for example, in what degree did these participants already knew about persona and persona-scenarios; at which stage of the workshop did they started to carry out group tasks; how much user research results were given in that “short text”? Without knowing these information, we could not fully trust on the authors conclusion about persona-scenarios couldn’t be well written without their guidelines. In another way, though good points were presented, the credibility of the paper is lowered due to lacking of these information.


[Reading Reflection] Bridge the Research-Design Gap

Reading Material:

Sharp, Rogers, & Preece (2007) Interaction Design. Wiley. Chapter 10.

Cooper, Reimann, and Cronin (2007) About Face 3. Wiley. Chapter 5 & 6.

This week’s reading is aiming at transferring research data to useful design guidelines. The two books went for similar approaches, though slightly different in some concepts. They both use the qualitative research data gained through research phase to synthesis some kind of user models out of it. Then, based on the user models, user scenarios and product requirements could be generated.

Cooper emphasized a lot on the concept of “persona” against other models such as user profile, with very good reasons. Compared these two books, Cooper definitely has a clear route to follow, with a solid source to retrieve from — research based users’ goals. Persona as a user model is presented as individual people, yet represents groups of users with shared behavior patterns. This nature of persona could enable an honest information inheritance from research results and have a vivid characteristic to commute with stakeholders. Once having well-built persona, persona-based scenarios could be gained to represent how the specific persona will interact with specific product or interface. Requirements then could be retrieved from the scenarios correspondingly. We could now see a clear path to follow in terms of defining product requirements: qualitative research –> persona –> persona-based scenarios –> requirements.

The process of creating persona and analyzing persona to generate scenarios & requirements reminds me of a popular Website in China: the Chinese Facebook –Renren.com. I actually met the founder W of this Website about two years ago. He said honestly that when they created Renren, there were several competitors out there in China. Everyone is trying to design the features of the social Website by themselves but no one succeed very well. W and his team then decided they would just copy Facebook since they had similar target users (college students) and Facebook’s success had been verified by the market. However, if they just copied everything from Facebook, I’d say they would fail or at least not that popular as they are now. What did they change, then? Considering the different national culture, it is reasonable to have different users’ goals. For example, Chinese people will more care about who have payed attention to my posts; how people think of me after they saw my posts (status, pictures, or diaries); could I “secretly” visit someone’s page without he knowing about it; and who is the most popular person in my university? According to Norman’s three level of cognitive processing, I would say these belong to behavioral and reflective processing, which are very important to build long-term product relationships. Once these end goals of users are fulfilled, users will “upgrade” to loyal users. To fulfill these user goals, requirements could be generated. Such as users need to see who visited them recently; number of visits should be displayed in dominant position; and Website could show who is the most popular according to visit rate. Then here we go, Renren, a Chinese Facebook:

The "Recent Visitor" Function of Renren.com

The "Recent Visitor" Function

The "Number of Visits" of Renren

The "Number of Visits"

The "Most Popular People" Display of Renren.com

The "Most Popular People" Display

How do you like it, as a non-Chinese?