http://www.madebymany.co.uk/

* Luke W on Microsoft’s use of design principles:

http://www.lukew.com/ff/entry.asp?796

* Google UX principles

http://www.google.com/corporate/ux.html

* Sony’s design philosophy

http://www.sony.net/Fun/design/profile/philosophy.html

Overview:

This paper is a look back at the usability methods that were employed as part of the SI 622 “Evaluation of Systems and Services”course in Winter 2008. I was part of Team RENEU which also involved Gaurav Pimprikar, Anran Ye and Yung-Ju Chang. The team was involved in conducting a System Evaluation of Project Engage.

Project Engage:

University of Michigan Engage is intended to provide “one‐stop shopping” for people who want to help medicine move forward by participating in clinical research at the University of Michigan. Engage has several features ‐ study database, public search tool, community information, staff information, as well as a secure Registry. The original study database feature allows study teams here at University of Michigan to post their clinical research trials for the public to view. The Registry is an additional feature that allows interested volunteers to enroll in a registry, which automatically matches volunteers to potential studies, so that researchers can contact them as potential candidates. Medical Resources are also posted so the public can learn about the medical research that is going on at the University.

Our Work:

While Engage works well at facilitating UM clinical research staff’s manual work in finding volunteers, there are still many ways in which it could be improved, some of these may already been remarked upon by the users, while others still await discovery.

Our team completed a thorough exploration of the website structure using the Generalized Transition Network as well as compared it to other similar products used for volunteer solicitation. We have also completed numerous interviews and have been engaged in a focus group. Based on these experiences we have designed Personas of potential users of the website and scenarios that they may face. They have helped us get a better understanding of the users. This was followed by a Heuristic Evaluation using Jakob Nielson’s Heuristics. We also completed a survey by which we gathered useful user information and suggestions on the major improvements needed in the website. The Survey Analysis was followed by a very valuable User Testing. A large portion of the Engage Website is text‐based. Hence the language and textual elements used in the Interface play a very important role in how well the users understand and use the system. For this reason, our team conducted a Vocabulary analysis to analyze the appropriateness of the Vocabulary and Grammar used on the website. Finally, our some of our main findings and recommendations were consolidated into a presentation which was attended by our client and her development team.

Here is a list of the methods used to evaluate the website:

1. Generalized Transition Network

2. Personas and Scenarios

3. Comparative Evaluation

4. Heuristic Evaluation

5. Survey Analysis

6. User Testing

7. Vocabulary Analysis

In what follows, I am going to describe my experiences with each method in detail and suggest some positives and negatives for each.

Generalized Transition Network:

The generalized transition network is an essential tool from the usability perspective. It helps in understanding the system, its loop, paths, different features etc. The final artifact produced while being useful for usability personnel is also extremely informative for all the stakeholders and people involved with the system. The GTN gives a bird eye view of the system.

We found a lot of our issues like broken links, sections not connected etc. while building our GTN itself. The process of building the GTN familiarized us to all the intricacies of the system and helped us know and understand the system better. I feel that the GTN is most helpful when done as the first step in the usability process. It is more valuable before the contextual inquiry phase as you get clues for building your questions from your findings in the GTN. The process itself is time consuming and involves a considerable investment of effort and resources. The printing of the poster is a tad expensive and requires some skill in photoshop or other page layout/photo editing software.

Advantages:

- Familiarizes the team to the system and its intricacies.

- Provides a bird’s-eye- view of the concerned system.

- Can also help in identifying some low level issues.

Disadvantages:

- Time, effort and money consuming

- Requires some skills in page layout or photo editing software like Photoshop, illustrator etc.

Best Time to Perform: Before anything else in the usability process.

Artifact Produced: A poster containing the GTN

Personas and Scenarios:

Personas and Scenarios are tools which help in understanding the system’s users and imagining them using the system under various conditions. The information required to construct Personas and Scenarios is obtained by conducting a contextual inquiry regarding the system and its use. Interviews are conducted, in most cases with the users, and sometimes with other stakeholders to identify user population, demographics and way users use the system. The questions in these interviews are more quality oriented that quantity oriented. An effort is made to ask open ended questions so that the interviewers themselves can lead the team through important information with regards to usage, problems faced and other such experiences.

Personas and Scenarios are one of the best ways of demonstrating the user demographics and ways in which users use/would use the system. However, caution must be exercised when constructing personas and scenarios and it must also be noted that there could be other kinds of users not captured with personas and scenarios.

Our team created three personas clearly identifying and differentiating the three groups of users that the system had. The personas and scenarios were especially helpful when we needed to establish the validity/basis for a particular task or function. Questions like “Would our persona use this feature?” or “Does our persona need this feature?” helped us in thinking analytically and broadly about the various issues that the system faced.

Advantages:

- Extremely useful in identifying and understanding user population.

- Great way to demonstrate the groups/kinds of users and how they use the system.

Disadvantages:

- Contextual Inquiry is extremely time consuming.

- Personas may represent most but not all of the user population.

- Scenarios may not represent all the situations and ways in which users use/could use the system.

Best Time to Perform: After Contextual Inquiry and GTN.

Artifact Produced: A document containing set of Personas and Scenarios presented in an interesting and believable way.

Comparative Evaluation:

Comparative Evaluation involves looking at competing systems to gather information about what is being offered by competing systems and how they are faring in trying to achieve similar goals. One of the goals of comparative evaluation is also to look at the different features being offered by competing systems and get some ideas from it. It also involves looking at what worked and what was unsuccessful with other similar systems.

However, comparative evaluation can reveal less information when the system is new and has little or no competitors. This was a process which gave us comparatively lesser amount of information. The system had little ‘competitors’ and so we looked at other ways that were used by the users to do the same kind of job. From the process we gathered information about the positives of using various other kinds of systems (not just computer related) to do things that the system was trying to do. This gave us a clear picture of where the system stood in terms of its usage. The idea was to try to incorporate the positives of the other methods and to guard against making the same mistakes.

Advantages:

- Useful in getting a sense of where the system stood in comparison with other systems.

- Gives ideas regarding features that could be included/improvements that could be made.

- Gives a sense of what works and what does not work in a particular setting.

Disadvantages:

- Depending on system and competitors, information obtained could vary.

- It is difficult to get a peek into other systems which require authentication.

Best Time to Perform: Following personas and Scenarios.

Artifact Produced: A comparative analysis report containing a thorough analysis of relevant competitors and also conclusions as to what features could be changed/added. Positives and negatives for each competitor should be carefully documented.

Heuristic Evaluation:

Heuristic evaluation is the most popular of the usability inspection methods. It is done as a systematic inspection of a user interface design for usability. The goal of heuristic evaluation is to find the usability problems in the design so that they can be attended to as part of an iterative design process. Heuristic evaluation involves having a small set of evaluators examine the interface and judge its compliance with recognized usability principles (the “heuristics”).

It was of extreme importance in case of Project Engage. A lot of usability issues which are difficult to find using most other methods but which have a big impact on the usability of a product can be uncovered with heuristic evaluation. Jakob Nielson’s set of recommended heuristics are generally suitable for most systems but sometimes need to be tweaked for some systems.

Heuristics evaluation is really quick and does not require any outside influence in terms of users. It can be performed easily within the team and is useful for uncovering basic usability issues. Most of our basic usability issues like ‘Placement of buttons’, ‘color of text’, ‘appropriate feedback’ etc were uncovered from heuristic evaluation.

It should be noted that a heuristic evaluation will not uncover all of the usability problems and other methods have to be applied in conjunction with it for best results.

Advantages:

- Quick and easy.

- No user participation required.

- Great method for uncovering basic usability issues.

Disadvantages:

- Only basic usability issues can be uncovered.

- No participation from users may imply that the quality of information obtained from the process is not that good.

- User related issues are difficult to uncover using heuristic evaluation.

Best Time to Perform: As soon as you get to know about your system and users.

Artifact Produced: A heuristic evaluation report containing heuristic issues and recommendations to overcome them.

Survey Analysis:

It is extremely important to know users attitudes and feelings towards the system under consideration. While a survey helps to reach a wide user population, the information obtained is more quantitative than qualitative. A survey, in conjunction with Contextual inquiry can help obtain qualitative and quantitative information about users attitudes and feelings. A survey could be done at anytime that seems fit in the design cycle. Sometimes it might be a better idea to do the survey before contextual inquiry and sometimes after. It really depends in the need of the project. It is critical to think of the information that you want to get out of the survey and design the questions accordingly. Designing the questions and selecting the right sample are key to the success of the survey as a process.

We did our survey after Heuristic Evaluation and we found that not much new data was obtained from it. However a different system and things would have been different. Looking back, we also might have designed some of the questions differently to obtain better results.

Advantages:

- Can reach a large user population base.

- Good way of knowing general user attitudes and feelings about the system.

Disadvantages:

- Only quantitative information can be obtained.

- Might need a good amount of time and resource investment.

Best Time to Perform: Depending on the project and team.

Artifact Produced: A survey analysis report describing general attitudes and feelings towards the system and highlighting interesting facts or findings.

User Testing:

User Testing is the most important and informative method for discovering usability issues. User testing is a technique used to evaluate a product by testing it on users.It gives direct input on how real users use the system. Usability testing measures the usability, or ease of use, of a specific object or set of objects and is very specific and targeted. It is a long process and requires a great deal of planning.

For Engage, we performed user testing concentrating on Efficiency, Accuracy, Recall and Emotional Response. The results we got were rich in quality and helped us a lot in gathering feedback about the system. Also, they helped us in prioritizing our findings and recommendations.

From my experience, I can say that user testing needs a lot of planning, careful thought and management skills. It is important to start early and think of the many possibilities that could occur within a test. It is also very important to define your goals and know exactly what you want from the tests. Depending on the goals, it is critical to formulate tasks that have a high likelihood of producing interesting results. Careful though must go into formulating tasks as they are the basis for revealing key information. Also, it is important to capture the information correctly and take it back to the team for careful analysis.

Finally, it is crucial to have backups as rest assured something will definitely go wrong during a test and one needs to account for that.

Advantages:

- Reveals great quality information about the usability.

- Information comes directly from the users.

- User input directly enters the usability loop.

Disadvantages:

- Long process.

- A large amount of time and effort goes into user testing.

- Can be monetarily heavy.

Best Time to Perform: After usability inspection methods.

Artifact Produced: A user testing and analysis report capturing qualitative information about users using the system along with interesting recordings, video clips etc demonstrating usability issues.

Vocabulary Analysis:

A large portion of the Engage Website is text‐based. Hence the language and textual elements used in the Interface play a very important role in how well the users understand and use the system. For this reason, our team conducted a Vocabulary analysis to analyze the appropriateness of the Vocabulary and Grammar used on the website.

To accomplish our objectives, we performed three types of analysis, namely, General Vocabulary Analysis, Metaphor analysis and Object/Action analysis: general vocabulary analysis relates the terminology used in the website with the user’s cognitive interpretations and expectations. Metaphor analysis is used to discover whether functions on the website correspond accurately with the user’s experiences on other similar products. Finally, Object‐action analysis reveals inconsistencies in the behavior of different functions in the website.

Vocabulary analysis is most useful when the system is text based and has a lot of object-action pairs. It is a usability inspection method and does not involve users.

Advantages:

- Simple and quick.

- Can reveal vocabulary related issues which cannot be revealed through other usability inspection methods.

Disadvantages:

- Very targeted use revealing only vocabulary related issues.

- Useful only for some systems.

Best Time to Perform: After heuristic evaluation.

Artifact Produced: A vocabulary analysis report capturing issues faced by the system related to vocabulary and recommendations for the same.

Conclusion:

All the usability methods described above give valuable insights into the usability of a particular system. Some of the methods are usability inspection methods not involving the users while others directly involve the users. Each method has its own advantages and disadvantages and there seems to be no ‘correct order’ of performing these methods. Also, there might be no correct way of performing a particular process but there definitely are some do’s and dont’s that need to be considered for the process to be successful. I also think that the more experience one has performing these methods, the better one will get at it.

]]> http://aalapd.wordpress.com/2008/04/21/a-look-at-some-important-usability-methods/feed/ 1 aalapd http://aalapd.wordpress.com/2008/03/20/the-curse-of-knowledge/ http://aalapd.wordpress.com/2008/03/20/the-curse-of-knowledge/#comments Thu, 20 Mar 2008 20:10:09 +0000 Aalap Doshi http://aalapd.wordpress.com/?p=23 ]]> I came across this principle in my Behavioral Science class. The principle states that it is extremely difficult for experts to convey ideas/teach to the less fortunate in those areas of expertise. The reasoning was that experts assumed the amount of knowledge that audience had. Thus they do not think novice users are novice enough. This is easy to imagine. Some things just come automatically to experts but would not come to novices. However, since these things come automatically to experts, they do not notice them and do not think that others would not be able to do them.

The curse of Knowledge is that it makes you less considerate for those without the knowledge.

I could connect this to quite a few examples of great sports personalities not making very good coaches or great academicians not being very good professors.

So what does this have to do with Usability or Design? Well i think it is important to take this principle into account when designing or testing for any system. One has to remember that the designer/tester have become the experts of the system and the system, its paths and all its corners have become automatic to the designer/tester. Hence things that the designer might think to be obvious might not really be obvious to the users.

As designers and usability professionals we should keep in mind that “Obvious is not always obvious….”

Personally i never understood the logic behind using personas to convince people about your users. They would make sense only if you model them on actual users  and get under the skin of them. However the emphasis put on documenting and presenting these personas is not helping much. This is especially true if your personas are not really completely based on a thorough understanding of your users. This article by Andrew Hilton, which appears on Boxes and Arrows , i think hits the nail on the head.  Quoting Andrew Hilton:

Personas and the Role of Design Documentation

How it’s less about deliverables, and more about design.

by Andrew Hinton on 2008/02/26 | [18 Comments]

In User Experience Design circles, personas have become part of our established orthodoxy. And, as with anything orthodox, some people disagree on what personas are and the value they bring to design, and some reject the doctrine entirely.

I have to admit, for a long time I wasn’t much of a believer. Of course I believed in understanding users as well as possible through rigorous observation and analysis; I just felt that going to the trouble of “creating a persona” was often wasted effort. Why? Because most of the personas I’d seen didn’t seem like real people as much as caricatured wishful thinking.

Even the personas that really tried to convey the richness of a real user were often assimilated into market-segment profiles—smiling, airbrushed customers that just happened to align with business goals. I’d see meeting-room walls and PowerPoint decks decorated with these fictive apparitions. I’m ashamed to say, even I often gave in to the illusion that these people—like the doe-eyed “live callers” on adult phone-chat commercials—just couldn’t wait for whatever we had to offer.

More often than not, though, I’d seen hard work on personas delivered in documentation to others downstream, where they were discussed for a little while during a kick-off meeting, and then hardly ever heard from again.

Whenever orthodoxy seems to be going awry, you can either reject it, or try to understand it in a new light. And one way to do the latter is to look into its history and understand where it came from to begin with—as is the case with so much dogma, there is often a great original idea that, over time, became codified into ritual, losing much of the original context.

The Origin of Personas

When we say “persona”, designers generally mean some methodological descendant of the work of Alan Cooper. I remember when I first encountered the idea on web-design mailing lists in 1999. People were arguing over what personas were about, and what was the right or wrong way to do them. All most people had to go on was a slim chapter in Cooper’s “The Inmates are Running the Asylum” and some rudimentary experience with the method. You could see the messy work of a community hammering out their consensus. It was as frustrating as it was interesting.

Eventually, practitioners started writing articles about the method. So, whenever I was asked to create personas for a project, I’d go back and read some of the excellent guides on the Cooper website and elsewhere that described examples and approaches. As a busy designer, I was essentially looking for a template, a how-to guide with an example that I could just fill in with my own content. And that’s natural, after all, since I was “creating a persona” to fulfill the request for a kind of deliverable.

It wasn’t until later that Alan Cooper himself finally posted a short essay on “The Origin of Personas.” For me it was a revelation. A few paragraphs of it are so important that I think they require quoting in full:

I was writing a critical-path project management program that I called “PlanIt.” Early in the project, I interviewed about seven or eight colleagues and acquaintances who were likely candidates to use a project management program. In particular, I spoke at length with a woman named Kathy who worked at Carlick Advertising. Kathy’s job was called “traffic,” and it was her responsibility to assure that projects were staffed and staffers fully utilized. It seemed a classic project management task. Kathy was the basis for my first, primitive, persona.

In 1983, compared to what we use today, computers were very small, slow, and weak. It was normal for a large program the size of PlanIt to take an hour or more just to compile in its entirety. I usually performed a full compilation at least once a day around lunchtime. At the time I lived in Monterey California, near the classically beautiful Old Del Monte golf course. After eating, while my computer chugged away compiling the source code, I would walk the golf course. From my home near the ninth hole, I could traverse almost the entire course without attracting much attention from the clubhouse. During those walks I designed my program.

As I walked, I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program. I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms. Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently.

If we slow down enough to really listen to what Cooper is saying here, and unpack some of the implications, we’re left with a number of insights that help us reconsider how personas work in design.

1. Cooper based his persona on a real person he’d actually met, talked with, and observed.
This was essential. He didn’t read about “Kathy” from a market survey, or from a persona document that a previous designer (or a separate “researcher” on a team) had written. He worked from primary experience, rather than re-using a some kind of user description from a different project.

2. Cooper didn’t start with a “method”—or especially not a “methodology”!
His approach was an intuitive act of design. It wasn’t a scientific gathering of requirements and coolly transposing them into a grid of capabilities. It came from the passionate need of a designer to really understand the user—putting on the skin of another person.

3. The persona wasn’t a document. Rather, it was the activity of empathetic role-play.
Cooper was telling himself a story, and embodying that story as he told it. The persona was in the designer, not on paper. If Cooper created a document, it would’ve been a description of the persona, not the persona itself. Most of us, however, tend to think of the document—the paper or slide with the smiling picture and smattering of personal detail—as the persona, as if creating the document is the whole point.

4. Cooper was doing this in his “spare time,” away from the system, away from the cubicle.
His slow computer was serendipitous—it unwittingly gave him the excuse to wander, breathe and ruminate. Hardly the model of corporate efficiency. Getting away from the office and the computer screen were essential to arriving at his design insights. Yet, how often do you see design methods that tell you to get away from the office, walk around outside and talk to yourself?

5. His persona gained clarity by focusing on a particular person—”Kathy”.
I wonder how much more effective our personas would be if we started with a single, actual person as the model, and were rigorous about adding other characteristics—sticking only to things we’d really observed from our users. Starting with a composite, it’s too easy to cherry-pick bits and pieces from them to make a Frankenstein Persona that better fits our preconceptions.

The biggest insight I get from this story? Personas are not documents, and they are not the result of a step-by-step method that automagically pops out convenient facsimiles of your users. Personas are actually the designer’s focused act of empathetic imagination, grounded in first-hand user knowledge.

It’s not about the documents

Often when people talk about “personas” they’re really talking about deliverables: documents that describe particular individuals who act as stand-ins or ‘archetypes’ of users. But in his vignette, Cooper isn’t using personas for deliverables—he’s using them for design.

Modern business runs on deliverables. We know we have to make them. However, understanding the purposes our deliverables serve can help us better focus our efforts.

Documentation serves three major purposes when designing in the modern business:

1. Documentation as a container of knowledge, to pour into the brains of others.

By now, hopefully everyone reading this knows that passing stages of design work from one silo to the next simply doesn’t work. We all still try to do it, mainly because of the way our clients and employers are organized. As designers, though, we often have to route around the silo walls. Otherwise, we risk playing a very expensive version of “whisper down the lane,” the game you play as kids where the first kid whispers something like “Bubble gum is delicious” into another’s ear, and by the end of the line it becomes “Double dump the malicious.”

Of course there are some kinds of information you can share effectively this way, but it’s limited to explicit data—things like world capitals or the periodic table of elements. Yet there are vast reservoirs of tacit knowledge that can be conveyed only through shared experience.

If you’ve ever seen the Grand Canyon and tried to explain it to friends back home, you know what I mean. You’d never succeed with a few slides and bullet points. You’d have to sit down with them and—relying on voice, gesture and facial expression—somehow convey the canyon’s unreal scale and beauty. You’d have to essentially act out what the experience felt like to you.

And even if you did the most amazing job of describing it ever, and had your friends nearly mirroring your breathless wonderment, their experience still wouldn’t come close to seeing the real thing.

I’m not saying that a persona description can’t be a useful, even powerful, tool for explaining users to stakeholders. It can certainly be highly valuable in that role. I’m only saying that if you’re doing personas only for that benefit, you’re missing the point.

2. Documentation as a substitute for physical production.

Most businesses still run on an old industrial model based on production. In that model, there’s no way to know if value is being created unless there are physical widgets coming off of a conveyor belt—widgets you can track, count, analyze and hold in your hand.

In contrast, knowledge work – and especially design – has very little actual widget-production. There is lots of conversation, iteration, learning, trying and failing, and hopefully eventual success. Design is all about problem solving, and problems are stubbornly unmeasurable—a problem that seems trivial at the outset turns out to be a wicked tangle that takes months to unravel, and another that seemed insurmountable can collapse with a bit of innovative insight.

Design is messy, intuitive, and organic. So if an industrial-age management structure is to make any sense of it (especially if it’s juicing a super-hero efficiency approach like Six-Sigma), there has to be something it can track. Documents are trackable, stackable, and measurable. In fact, the old “grade by weight” approach is often the norm—hence the use of PowerPoint for delivering paper documents attenuated over two hundred bulleted slides, when the same content could’ve fit in a dozen pages using a word processor. The rule seems to be that if the research and analysis fill a binder that’s big enough to prop your monitor to eye level, then you must’ve done some excellent work.

In the pressure to create documents for the production machine, we sap energy and focus away from designing the user experience. Before you know it, everything you do—from the interviews and observations, to the way you take notes and record things, the way you meet and discuss them after, and the way you write your documentation—all ends up being shaped by the need to produce a document for the process. If your design work seems to revolve mainly around document deadlines, formatting, revision and delivery, stop a moment and make sure you haven’t started designing documents for stake-holders at the expense of designing experiences for users.

Of course, real-world design work means we have to meet the requirements of our clients’ processes. I would never suggest that we all stop delivering such documentation.

Part of the challenge of being a designer in such a context is keeping the industrial beast happy by feeding it just enough of what it expects, yet somehow keeping that activity separate from the real, dirty work of experiencing your users, getting them under your skin, and digging through design ideas until you get it right.

3. Documentation as an artifact of collaborative work and memory.

While the first two uses are often necessary, and even somewhat valuable, this third use of documentation is the most effective for design—essentially a sandbox for collaboration.

These days, because systems tend to be more interlinked, pervasive and complex, we use cross-disciplinary teams for design work. What happened in Cooper’s head on the golf course now has to somehow happen in the collective mind of a group of practitioners; and that requires a medium for communication. Hence, we use artifacts—anything from whiteboard sketches to clickable prototypes.

The artifacts become the shorthand language collaborators use to “speak design” with one another, and they become valuable intuitive reminders of the tacit understanding that emerges in collaborative design.

Because we have to collaborate, the documentation of personas can be helpful, but only as reminders. Personas, as documents, should work for designers the way scent works for memories of your childhood. Just a whiff of something that smells like your old school, or a dish your grandmother used to make, can bring a flood of memory. Such a tool can be much more efficient than having to re-read interview transcript and analysis documents months down the road.

A persona document can be very useful for design—and for some teams even essential. But it’s only an explicit, surface record of a shared understanding based on primary experience. It’s not the persona itself, and doesn’t come close to taking the place of the original experience that spawned it.

Without that understanding, the deliverables are just documents, empty husks. Taken alone, they may fulfill a deadline, but they don’t feed the imagination.

Playing the role

About six months ago, my thoughts about this topic were prompted by a blog post from my colleague Antonella Pavese. In her post, she mentions the point Jason Fried of 37 Signals makes in Getting Real that, at the end of the day, we can only design for ourselves. This seems to fly in the face of user-centered design orthodoxy – and yet, if we’re honest, we have to realize the simple scientific fact that we can’t be our users, we can only pretend to be. So what do we do, if we’re designing something that doesn’t have people just like us as its intended user?

Antonella mentions how another practitioner, Casey Malcolm, says to approach the problem:

To teach [designers] how to design usable products for an older population, for example, don’t tell designers to take in account seniors’ lower visual acuity and decreased motor control. Let young designers wear glasses that impair their visual acuity. Tie two of their fingers together, to mimic what it means to have arthritis or lower motor control.”

Antonella goes on:

So, perhaps Jason Fried is completely on target. We can only design for ourselves. Being aware of it, making it explicit can make us find creative ways of designing for people who are different from us… perhaps we need to create experience labs, so that for a while we can live the life of the people we are designing for.”

At UX Week in Washington, DC this summer, Adaptive Path unveiled a side project they’d been working on—the Charmr, a new design concept for insulin pumps and continuous monitors that diabetics have to constantly wear on their bodies. In order to understand what it was like to be in the user’s skin, they interviewed people who had to use these devices, observed their lives, and ruminated together over the experience. Some of the designers even did physical things to role-play, such as wearing objects of similar size and weight for days at a time. The result? They gained a much deeper feel for what it means to manage such an apparatus through the daily activities the rest of us take for granted—bathing, sleeping, playing sports, working out, dancing, everything.

One thing a couple of the presenters said really struck me—they said they found themselves having nightmares that they’d been diagnosed with diabetes, and had to manage these medical devices for the rest of their lives. Just think—immersing yourself in your user’s experience to the point that you start having their dreams.

The team’s persona descriptions weren’t the source of the designers’ empathy —that kind of immersion doesn’t happen from reading a document. Although the team used various documentation media throughout their work – whiteboards and stickies, diagrams and renderings – these media furthered the design only as ephemeral artifacts of deeper understanding.

And that statement is especially true of personas. They’re not the same as market segmentation, customer profiling or workflow analysis, which are tools for solving other kinds of problems. Neither do personas fit neat preconceptions, use-cases or demographic models, because reality is always thornier and more difficult. Personas aren’t ornaments that make us more comfortable about our design decisions. They should do just the opposite—they may even confound and bedevil us. But they can keep us honest. Imagine that.

Using a label function

You can pass a label function to the List control to provide logic that determines the text that appears in the control. The label function must have the following signature:

labelFunction(item:Object):String

The item parameter passed in by the Label control contains the list item object. The function must return the string to display in the List control.

Note: Most subclasses of ListBase also take a labelFunction property with the signature described above. For the DataGrid and DataGridColumn controls, the method signature is labelFunction(item:Object, dataField ataGridColumn):String, where item contains the DataGrid item object, and dataField specifies the DataGrid column.

The following example uses a function to combine the values of the label and data fields for each item for display in the List control:

<?xml version="1.0"?>
<!-- dpcontrols/ListLabelFunction.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" >
    <mx:Script><![CDATA[
        public function myLabelFunc(item:Object):String {
            return item.data + ", " + item.label;
        }
    ]]></mx:Script>

    <mx:ArrayCollection id="myDP">
        <mx:source>
            <mx:Object label="AL" data="Montgomery"/>
            <mx:Object label="AK" data="Juneau"/>
            <mx:Object label="AR" data="Little Rock"/>
        </mx:source>
    </mx:ArrayCollection>       

    <mx:List dataProvider="{myDP}" labelFunction="myLabelFunc"/>
</mx:Application>

This example creates the following List control:

Displaying DataTips

DataTips are similar to ToolTips, but display text when the mouse pointer hovers over a row in a List control. Text in a List control that is longer than the control width is clipped on the right side (or requires scrolling, if the control has scroll bars). DataTips can solve that problem by displaying all of the text, including the clipped text, when the mouse pointer hovers over a cell. If you enable data tips, they only appear for fields where the data is clipped. To display DataTips, set the showDataTips property of a List control to true.

The default behavior of the showDataTips property is to display the label text. However, you can use the dataTipField and dataTipFunction properties to determine what is displayed in the DataTip. The dataTipField property behaves like the labelField property; it specifies the name of the field in the data provider to use as the DataTip for cells in the column. The dataTipFunction property behaves like the labelFunction property; it specifies the DataTip string to display for list items.

The following example sets the showDataTips property for a List control:

<mx:List id="myList" dataProvider="{myDP}" width="220" height="200" showDataTips="true"/>

This example creates the following List control:

I can already see the benefits of this. I have not tried it out myself but soon I will try it. You need to use an HTML control to do this.

For a user interacting with an HTML control, the experience is similar to using a web browser with only the content window and no menu bar or navigation buttons. The HTML page content displays in the control. The user can interact with the content through form fields and buttons and by clicking hyperlinks. Any action that normally causes a browser to load a new page (such as clicking a link or submitting a form) also causes the HTML control to display the content of the new page and changes the value of the control’s location property.