Monthly Archives: October 2011

Why the Credit Card Number is Divided into Groups?

I always knew my credit card number is grouping as 4 digits per group but never thought about why. Today I had an interesting reading about short-term memory. Research has been done showing that short-term memory capacity is a function of chunks rather than the objective number of items. That being said, if you try to remember a string of numbers or digits, divide them into small groups could improve the recall performance. Specifically, Wickelgren (1964) showed that a string of digits are easiest to remember if they are divided into groups of a maximum of four. That’s one of the underlying reasons why we have credit card numbers being organized in groups. Though each part does present different information, but its presentation in groups is also an important strategy to make it easier for customers to check and remember. Similarly, when we design the presentation of information, make sure not offering too much at a time. Instead, group them to make it simple for users to recall.

Wickelgren, W.A. 1964. Size of rehearsal group in short-term memory. Journal of Experimental Psychology, 68, 413-419.

[Reading Reflection] From Requirement to Design

Reading Material:

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

Cooper, Reimann, and Cronin (2007) About Face 3. Wiley. Chapter 7.

These two chapters both talk about converting requirements into real design through framework/ prototype. This is done by applying knowledge gained through previous stage — persona-scenarios and system requirements — to establish the form, input method, and functions of the product. Both chapters emphasize heavily on using low-fidelity prototype at the beginning stage, to encourage discussing, seeing big picture, and trying multiple alternatives at this stage. It is a pleasure journey reading these chapters, seeing how they evolve paper-based sketches to computer-based prototypes ready for user testing. I love the idea of storyboarding talked in both chapters. It reminds me of a class project I did about designing a personal digital health record system on iPhone. My teammates and I build up the interaction process using Powerpoint, mimicking the screen change when our persona interact with the product. It was surprisingly useful to build in the task-oriented key path scenarios, and it also did a great job conveying our design to fellow classmates.

I like Cooper’s structure more because it follows clearly with the serial pathway of developing the design, from low-fidelity framework using whiteboard sketch, to upgrade it to computer-based tool with more details gained from “key path scenarios”; and later, the combination between interaction framework with visual design framework and industrial design framework.

Compared to Cooper’s, Interaction Design gives a “parallel”-like structure: main aspects of prototyping is composed as different topics, in which more detailed comparison between different concepts and methods are given. For example, they talk more about the pros and cons of low-fidelity prototype and high-fidelity prototype, also the difference between product-oriented and process-oriented conceptual model. I love these discussions in terms of giving more deep understanding of what methods we should use and why.

Based on these features of the two books, I would suggest to read Cooper’s first to get a clear big picture and great details of how the whole design process looks like, and what stages are there to compose the work. Then try Interaction Design to extract more insights about some specific parts of the design process. See, this is also similar to the way you build the framework: skeleton first, details later.

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?

[Reading Reflection] Qualitative Study in Usability Research

Paay, J. (2008). From Ethnography to Interface Design. Handbook of Research on User Interface Design and Evaluation for Mobile Technology. IGI Global. Retrieved from http://www.igi-global.com/chapter/handbook-research-user-interface-design/21820
This book chapter wisely captured the connection between contextual characteristic of mobile usability and ethnographic-based study, and provided a ethnography approach to facilitate mobile usability design. As a chapter in a handbook, this reading provided fruitful review of relationship between ethnography and HCI study. One big issue lies in applying ethnographic methods to HCI domain is how to tailor the traditional ethnographic approaches to a relative quick yet informative way to inspire interface design. This chapter provided simple yet informative options for designers to follow. I would love to try it out to see how effective it is.
Eysenbach, G., & Köhler, C. (2002). How do consumers search for and appraise health information on the world wide web? Qualitative study using focus groups, usability tests, and in-depth interviews. BMJ, 324(7337), 573 -577. doi:10.1136/bmj.324.7337.573
This paper is a great example of integrating several qualitative studies. The most interesting thing for me was the inconsistent results between different methods. This probably suggests that in the future studies, we should not rely on single qualitative method to get the credible conclusion. Triangulation through multiple methods is necessary in order to increase the credibility of the study. Another inspiration is the importance of resemblance between experimental environment and realistic environment.
Millen, D. R. (2000). Rapid ethnography (pp. 280-286). ACM Press. doi:10.1145/347642.347763
This paper is cited by Paay in his chapter as a specific approach to carry out ethnography study in HCI research — rapid ethnography. It is interesting yet kind of expected to see the author offered the modification on the traditional ethnography study, to make it adapt to short product realization cycles. It is more like applying a broad methodology (narrow down, specific aiming) to a specific area (ethnography study), but it is valuable to fill in the gap between ethnography study with HCI research in a systematic way.

[Reading Reflection] Pervasive Usability: What and How?

This week’s reading comes from Designing Web Sites that Work: Usability For the Web, chapter 1 (Pervasive Usability: Usability throughout the design process).

This book could be used as an important supplement of Cooper’s About Face 3, as it covers the content corresponding to Chapter 1~Chapter 7 of Cooper’s, but emphasizes more heavily on the usability methods part rather than broader goal-directed design principles. With the whole book aiming for integrating usability into web design process, the first chapter gives us an overview of how usability should be carried out during web development, which they named “pervasive usability”.

The first topic being covered in this chapter is a brief summary of usability methods, dividing into two broad categories: real data from real users and those gathered without users. This topic will be further talked in detail when it comes to description of each methods in later chapters.

The authors then talked about the design process, which they refer to as “pervasive usability process”. In this part, authors underscored the importance of having evaluation at different stages of design, and integrating other usability methods into every stage of process. So we could see their points of how to make usability “pervasive”: at each stage you will involve usability methods such as interviews, focus groups, and task analysis; after each stage, you will go through evaluation “to ensure that the design is on track to satisfy the goals of the design” (Designing Web Sites that Work: Usability For the Web, p15).

The Pervasive Usability Process

The Pervasive Usability Process

In the third part, authors came to the practical issue of project management regarding integrating usability into project plan. This is my favorite part of this chapter, since it opens my eyes to a realistic and critical aspect affecting the success of user-centered design. In order to save usability from being cut off when time conflict or budget conflict happens, it is essential to understand tradeoffs and plan the resources well beforehand. As the author classified, there are mainly three critical resources: money, people, and time. For budget planning, this chapter introduced using a spreadsheet as a good approach. Remember to contain hours needed for each stage, slack time cost, as well as evaluation in the budget planning. Staff planning is closely related to schedule planning, since it is essential to have the right people available at certain stages, while multiple projects might be going on at the same time. The following figure (Designing Web Sites that Work: Usability For the Web, p27) is an interesting standpoint to think about resource arrangement for projects.

Staffing by Project Stages

Staffing by Project Stages

Finally, the author introduced the framework to choose different usability methods throughout the design process. There are several key attributes being considered in this framework: (1) Is it a required task? Non-required task might be omitted if any resource conflict happens, but might lead to product failure. (2) Time to perform the method. A usability method could take as little as 10 minutes, or as long as several months; choose feasible one according to your schedule planning. (3) Costs. Of course, choose one affordable and cost effective for certain stage. (4) Learning time. Extra time should be planned if usability specialists have no experience with this method. (5) Confidence level. We have to take the risk of getting misleading information into account. (6) Impact on final design: the earlier the stage, the greater the impact on final design. As you could see, choosing a “good” usability method is a multi-attribute decision making — which is hard. Maybe eventually, there is no an absolute “good” choice but rather a “suitable” choice, given the budget, staff, and time constrains. But it is always useful to keep these important aspects in mind when making the decision.

I am eager to see more details about how to penetrate these usability methods in each web develop stages in the next chapters.

RAA: Using Design Patterns in Heuristic Evaluation

RAA stands for: Research Article Analysis

Paper discussed:

Botella, F., Gallud, J. A., & Tesoreiro, R. (2011). Using Interaction Patterns in Heuristic Evaluation. In A. Marcus (Ed.), Design, User Experience, and Usability. Theory, Methods, Tools and Practice (Vol. 6769, pp. 23-32). Berlin, Heidelberg: Springer Berlin Heidelberg. Retrieved from http://www.springerlink.com.login.ezproxy.lib.purdue.edu/content/t346743643602746/

1. Purpose of the research:

Proposes a method to use interaction patterns in heuristic evaluation, in order to facilitate the process of heuristic evaluation as well as improve the output of heuristic evaluation in terms of providing redesign advice.

2. Methods:

The authors overviewed the use of heuristic evaluation as usability inspection methods and the prevalence of using design patterns in interface design respectively, and came up with the idea of mapping Nielsen’s heuristics with subsets of design patterns from Welie’s library. This approach seeks to find the correspondence between each heuristic and one or more design patterns, as showed below. The paper also claimed after several evaluation cycles, a refined correlation will be gained.

Mapping of heuristics and design patterns

Mapping of heuristics and design patterns

3. Main Findings:

A case study of heuristic evaluation of a university website using the proposed method shows it is easier to find direct solutions for usability problems found by evaluators.

4. Analysis:

After I re-read Nielsen’s procedure of conducting heuristic evaluation, I figured out that this paper is trying to fill the gap Nielsen mentioned as “Heuristic evaluation does not provide a systematic way to generate fixes to the usability problems or a way to assess the probable quality of any redesigns”. I appreciate the authors effort in mapping Nielsen’s heuristics with design patterns, trying to offer a systematic solution to the problem, but I think it a little bit forced to combine them in this way.

First of all, I think seeking redesign solutions through the successful examples is a common sense, and the use of pattern library as a reference could be a good idea (which might have already been widely used). But I am not sure how practical and efficient to use the mapping methods proposed in this paper as an evaluation step. After all, Nielsen’s heuristics is subjective, Welie’s patterns categories are subjective, and this mapping between them is subjective, it might be hard and unnatural to force people understanding and accepting the mapping. At least, as I looked at the mapping figure, I could not tell directly and clearly the relationship between the left column and right column. With a specific usability problem found, I would say it is more straight forward to find corresponding examples directly in the pattern library.

Anyway, I will try to test this idea when I do my heuristic evaluation, with questions like this: Is the mapping a redundant step? Will it be easier to locate solutions directly in the pattern library without mapping to their categories first?