Wanted/Needed: UX Design for Collaboration 2.0

by:   |  Posted on

No current software supports the full process of collaboration.

That’s a bold claim, and I hope that someone can prove me wrong.

This article is more of a “Working Towards …” position paper than the final word; written in the hope that the ensuing discussion will either bring to light some software of which I’m not aware, or motivate the right people to develop what’s needed.

There is plenty of hype about “Collaboration 2.0” at the moment, but the bugle is being blown too loudly, too soon. Take, for instance, the Enterprise Collaboration Panel at last year’s Office 2.0 Conference. Most of the discussion was really about communication rather than collaboration, with only a hint that beyond forming a social network (“putting the water cooler inside the computer”) there was still a lack of software that actually helped groups of people get the work done. What’s missing from the discussion is any formulation of what the process of collaboration entails; there’s no model from which collaborative applications could arise. If we can figure out a model then we in the UX community should be able to make a significant contribution to it.

I want to start this discussion by proposing a model for collaboration1 that links the various elements of collaboration, comment on the so-called “collaboration software” currently available, and make some tentative suggestions about IA and UX requirements for a real collaboration platform.

A proposed model


Collaboration is a co-ordinated sequence of actions performed by members of a team in order to achieve a shared goal.

The main concepts in this definition are:

  1. Collaboration is action-oriented. People must do something to collaborate. They may exchange ideas, arrange an event, write a report, lay bricks, or design some software. To collaborate is to act together and it is the combined set of actions that constitutes collaboration.
  2. Collaboration is goal-oriented. The reason for working together is to achieve something. There is some purpose behind the actions: to create a web site, to build an office block, to support each other through grief, or some other human goal. The collaborators may have varying motivations, but the collaboration per se focuses on a goal that is shared.
  3. Collaboration involves a team. No-one can collaborate alone. Collaboration requires a group of people working together. The team may be any size, may be geographically co-located or dispersed, membership may be voluntary or imposed, but there is at least some essence of being part of the team.
  4. Collaboration is co-ordinated. That is, the team is working together in some sense. The co-ordination may follow some formal methodology, but can equally well be implicit and informal. There needs to be some sense at least that there are a number of things to be done, some sequences of actions, some allocation of tasks within the group, and some way to combine the contributions of different team members.

Components of collaboration

Any collaboration process involves interactions between six elements, as shown in the following diagram:

The basic components of collaboration.

Figure 1. The basic components of collaboration


The Artifacts are the tangible objects relating to the collaboration. They include the outcomes of the process – the office block that progressively gets built, the web site that finally gets commissioned – as well as a variety of objects that were used along the way to promote, direct and record collaboration – such as design documents, project schedules, and meeting agendas.


The Team element includes the collaborators and the interactions between them: Team membership and authorization, inter-personal dynamics, personal identity, decision making processes, and communication.


The Tasks element includes the list of things to be done in order to reach the goal, along with all the processes necessary to manage that list. How do tasks get formulated? How is their status recorded and tracked over time? How is the list prioritized and scheduled? How are tasks assigned to team members and how are personal ‘To Do’ lists presented?


Most collaboration is extended across time, and consequently requires some degree of time-management: setting deadlines, milestones and task completion dates; scheduling team meetings; and keeping an historical record of events.


Team members perform Actions based on the Tasks assigned to them. The Actions might just involve searching or viewing the Artifacts, but more typically mean modifying the Artifacts in some way. There might also be some meta-Actions such as maintaining the Artifact repository, keeping a log of Actions and commenting on the Artifacts.


Resources enable the Team members to perform the Actions. They include physical equipment, money, external advice, and all manner of software (project management, Wiki, spreadsheet, and content management systems, among others).

The current state of collaborative software

There are three primary ways in which humans interact: conversations, transactions, and collaborations. There is plenty of software that enables conversation–email, VOIP, chat, IM, forums–and plenty of software for transactions–eBay, PayPal, internet banking, shopping carts. But what is available for collaboration?

There are many software applications that seek to enable collaboration2. But let’s see what happens when they are evaluated under these three categories:

  • The extent to which the software provides the required functional components (i.e. the boxes in Figure 1)
  • The extent to which the software supports the interaction between those components (i.e. the lines in Figure 1)
  • The usual criteria that apply to all software , such as ease of interaction, security, integration with other applications, and so on.

It is true that there are software packages for most of the individual components of collaboration:

  1. Artifacts: we have software for maintaining and accessing a repository of digital Artifacts (e.g. any number of CMS applications–well-established ones like Documentum or Stellent, more recent one’s like Joomla! or any of the 925 others listed at The CMS Matrix), and we can easily construct databases for tracking the status of non-digital Artifacts.
  2. Team: software for maintaining team membership, facilitating group-based decision support, and managing remote meetings (e.g. WebEx) and video conferencing. There is even some possibility that virtual worlds like Second Life may provide an effective environment for team interaction. In Growing Pains: Can Web 2.0 Evolve Into An Enterprise Technology?, Andy Dornan quotes a business manager as saying that “Second Life allows more user engagement than traditional video or phone conferencing.” I know of one company whose preliminary experiments with Second Life found that there was a more relaxed and open interaction via avatars than when a team interacted face-to-face.
  3. Tasks: software for maintaining task lists (e.g. Jira, ScrumWorks); task dependencies and scheduling, Gantt Charts (Microsoft Project, @task); brainstorming; workflow and process modeling; and others.
  4. Calendar: Microsoft Outlook (along with Microsoft Exchange Server so that the calendar is shared), Google Calendar, among other similar software.
  5. Resources and Actions: Many software applications act as Resources for implementing diverse Actions. For instance, Wikis enable editing of shared documents, and there are any number of calculators, electronic dictionaries, encyclopedias, search engines, web design tools – software that team members might use as they do their work.

These ‘point’ solutions may address their targeted functions effectively and even showcase the core ideals of Web 2.0 – user-generated content and taxonomies, broad-based participation, software-as-a-service (SaaS), and rich user-interfaces within a web browser. But they can’t just be lumped together and called “Collaboration” (with or without the 2.0 suffix). If you buy into the definition and model described above, it should be clear that true collaboration software must go beyond a set of disconnected point solutions and reach for the broader goal of enabling the whole collaboration process.

A key shortcoming of current so-called “collaborative software” is that there is no compelling metaphor or unifying vocabulary. We have many of the necessary pieces, but they do not interact at either the backend or user interface levels.

Some major contenders

Computer-Supported Co-operative Work (CSCW) and Computer-Supported Collaboration (CSC)

CSCW and CSC both promised such systems, but where are the practical results? While these research areas from previous decades generated many novel and hopeful ideas, there seems to have been an overly academic orientation rather than much focus on software design. Although the theory made useful distinctions, such as the categorization of collaboration by time and space, the software that resulted from these efforts dealt more with communication and co-ordination than with real collaboration.


Google offers an assortment of products that promote collaboration: Google Calendar, Google Apps, and more are promised. I was hoping that their acquisition of JotSpot in 2006 might result in a broader Wiki-based collaboration platform that unified those other offerings. But to date JotSpot has been silent. At this stage, Google’s offering is still an “assortment” rather than a clearly-conceived package.


The Zoho suite encapsulates virtually all the point-solutions mentioned above. It includes the standard office tools (word processing, spreadsheet, presentations, email), remote conferencing, chat, meeting organizer, calendar, project management and a Wiki. All of that and more is delivered via a SaaS model through your web browser. Zoho is way ahead of any competition because of its unified user interface. However, there are still important aspects lacking in Zoho: not primarily additional modules but some key IA and UX characteristics that I outline below.


Perhaps the closest we have today is from Microsoft. Combine SharePoint, Outlook and the Office suite and this provides remarkably effective functionality for team management, scheduling meetings, communication and shared workspaces. Our organization makes heavy use of this combination, and it pushes teamwork and information sharing a long way ahead of where we once were. On the down-side, the Task management in that environment is quite simplistic, with little support for maintaining a complex task list, or prioritization, or comprehensive status reports. The Wiki facility shipped with SharePoint is very primitive3. Microsoft has implemented a “Collaboration 1.0” approach rather than “Collaboration 2.0”, by which I mean it requires a large degree of centralized control rather than drawing on the power of social networking. Of course, the content of email, announcements, uploaded documents, and so on is completely open to freedom of expression, but the constrained environment and heavy IT infrastructure make the system as a whole feels complex and unwieldy.

Multi-user editing

Perhaps something specific needs to be said about one type of so-called collaborative software – the type that enables multi-user editing of electronic documents. Most of these applications are primarily interested in version control: they maintain a repository of documents and control access to that repository. Authorized people can view documents and a subset of those can edit the documents. The software provides some process for giving each editor a copy of the document and when the changes have been made, the software merges the changes back into the master copy, while keeping some form of historical change log. Examples are clearspace and the various text-based code-management tools such as Subversion.

While revision control has an important role, it is a meager offering in terms of the extent of collaboration that it enables. In most cases, such applications assume that individuals work independently of each other. One user edits this part of the document and, as a quite separate task, another user may edit another part of the same document. Two people editing the same part of the document is treated as a problem, and typically the last person to submit changes trumps any previous changes.

A more significant level of collaboration requires the assumption that multiple people will be working together to edit the document simultaneously. That requires a single shared document rather than separate copies of a master document for each editor. See Wikipedia article for a list of such real-time collaborative editors.

XMPP (the Extensible Messaging and Presence Protocol) has extensions for both multi-user text editing and multi-user whiteboarding, so there is at least discussions about how such interaction can be standardized. But tools that use that protocol are few and far between.

The Challenge for IA and UX

There are many human and business activities mediated by computer systems where IA and UX practitioners have provided design guidance to make the interaction more effective. Given that collaboration is fundamentally about interacting effective to jointly achieve some goal, IA and UX can play an even more substantial role than usual.

So, what principles would you apply to collaboration software? Here are my suggestions:

1.      Build the user interface around a consistent, unifying metaphor.

  • The metaphor should be goal-oriented. That is, a stated goal should take center-stage, with the Team, Tasks, Calendar, Resources, and Artifacts being other players in the drama.
  • The user interface needs to enable and encourage interactions between collaborators. Perhaps the metaphor of a sport team would be effective.
  •  A “portal”/dashboard pattern allows simple movement between team management, task list, calendar, documentation management and the like. That approach can collate the answers to core concerns like: What collaboration projects am I part of? What’s the current status of each? What’s on my To Do list?

2.      Build an open, extensible, modular framework: a collaboration platform rather than a single application.

  • The scope of collaboration is too extensive to expect that a single vendor will be able to provide all the pieces. It is important to allow modules to be gathered from multiple sources and plugged into a shared framework.
  • For instance, Jira might be the first choice for the maintaining the Task list, but the framework should allow that to be substituted with alternatives. Similarly, in a basic system there may be a limited reporting feature (e.g. to view the change history for the Artifact), but it should be possible to plug in a more substantial reporting application later on.
  • Most importantly, it will be important to provide a standard API to the Artifact repository, so that any number of applications can view, add and modify Artifacts.

3.      Include at least the following functions “out of the box:”

  • Team management: functions to define and authorize team members, and for individuals to update their personal profiles
  • Task management: functions to add and prioritize tasks, allocate responsibilities to team members, and maintain current status
  • Calendar management: all team members can add events to a single shared calendar
  • Communication: integration with email, IM, and other technologies
  • Meetings: ability to schedule a meeting and invite specific team members, publish an agenda, record notes and decisions from the meeting.

4.      The platform itself should maintain a collaboration history rather than leave that function to the plug-in components. All meetings, decisions, changes to Artifacts, Task status changes and other events are recorded in that history. The history should be displayed as a journal along a time-line as well as being exposed as a life-stream via RSS/Atom.

5.      Connect to other enterprise applications and data stores. A collaboration application will gain significant value if it can interact with existing databases, content management systems, security mechanisms, and if it can exchange data with other applications via some standard like Web Services.

6.      Implement all this as a Rich Internet Application. The complexity of interactions between team members who are potentially geographically scattered indicates the platform needs to be web-based. The complexity of interactions between users and the system indicates that the user interface needs to be very dynamic, with near-real-time synchronization between all concurrent users and a shared Artifact repository.


Maybe all I’ve done here is scratch an itch. But I hope that the itch is contagious.

Collaboration is an essential part of human endeavor and information technology is at a stage where it should be able to add value to collaboration in more ways that just connecting people in a social network. We have many web-based applications that address parts of the process, but who’s going to create the framework to bring it all together?


1 This model was first presented at BarCamp Sydney in August 2007.

2 Capterra’s Web Collaboration Software Directory lists “174 Solutions”. See also the Wikipedia article on collaborative software.

3 Lawrence Liu comments that the SharePoint Wiki is not intended to be best-of-breed, just something that “is sufficient for a very large percentage of our customer base”. Even that is wishful thinking, but fortunately, the guys at Atlassian have made a SharePoint Connector for Confluence that can easily replace the default SharePoint Wiki.

Designing the Democratic

by:   |  Posted on

The role of the information architect (IA), interaction designer, or user experience (UX) designer is to help create architecture and interactions which will impact the user in constructive, meaningful ways. Sometimes the design choices are strategic and affect a broad interaction environment; other times they may be tactical and detailed, affecting few. But sometimes the design choices we make are not good enough for the users we’re trying to reach. Often a sense of democratic responsibility is missing in the artifacts and experiences which result from our designs and decisions.

Noted scholar on democracy James Banks simplifies its definition: democracy means rule by the people.1 Philosopher and pragmatist John Dewey, however, interprets democracy more deeply as a way of living together as well as a kind of government.2 A “way of living together,” in our evolving globalization, means one or more different cultures in contact and interacting. Though this interaction across and between cultures has always existed to a greater or lesser degree, technology enables a historically unequaled degree of such interaction.

Whether it’s clearly recognized cultures interacting (i.e., the business practices between an Australian firm and a Chinese corporation), or less obvious subcultures interacting with a dominant culture (yuppies, castes, etc.), every member is entitled to democratic representation within the user experience. This means acknowledgement of, respect for, and empowerment regarding cultural dynamics of those for whom we design. Users may be of diverse cultures categorized by social class, gender, sexual orientation, religion, ethnic identity, age, racial group, industry, language, ableness, political power and control, and technological capability to name a few.  

I’d like to discuss several elements of democratic responsibility we might have some control over, touching briefly on potentially deeper implications for the design decisions we make. It’s folly to try to establish a canon of best practices in this regard because each of us is informed by a unique roster of experiences—personal, professional, and cultural—when making decisions that influence the user experience. Instead, I am suggesting that we get in the habit of reflecting on our decisions with special attention to the degree to which we are meeting our democratic responsibility.

One-way Design

The most common type of user experience occurs when a user interacts with artifacts in an onscreen ecosystem authored by someone else. Online shopping, music downloads, and rich internet applications are easy examples.

For this type of user experience, generally speaking, designing toward a democratic responsibility is under the control of the design and development team. They are in charge of the content, language and tone, visuals and layout, database management, and all the other aspects of making an end product. Whatever this team comes up with is what the user experiences. So, in addition to the regular tenets of information architecture and design we practice, careful thought about the cultural dynamics of the users is another necessary level of responsibility.

One thing we can do, particularly during the early stages of the design and development cycle, is to recognize the influence of our own culture on our methods, standards, practices, and expectations. Because  a great deal of the computer technology used today was standardized by American and Western European cultures, those of us from those cultures may take for granted many things that make their way into the onscreen ecosystem: feedback style, metaphors, icons, business processes, decision-making, the semantics of buttons or functions, problem solving, aesthetics, image use, etc. Hegemony of these dominant features within most aspects of the technology potentially leads to ineffectiveness ranging from confusion to offense in members of other cultures. To put it in IA-speak, the right information stops getting to the right people at the right time.

By being aware of our own cultural proclivities, we can reflect on our influences and how they may be at odds with those of other cultures. Then we can architect a more democratically responsible user experience. To not do this, particularly for cultures dominant in computing technology, becomes a form of technological imperialism where some users “remain at the mercy of other people’s decisions.”3 Some even consider this a sort of ethical imperialism based on one’s culture dictating what is “good” and “bad” and what “ought to be good.”4 For example, the presence or absence of certain navigation elements on an e-commerce site may inadvertently validate participation by one demographic while disregarding the needs of another. It’s imperialism with modern resources, imperialism in the form of business practices and popular culture imposed on those with less power.5

This has more serious implications as emerging countries struggle to participate in the global marketplace. For example, bandwidth-heavy interactions defeat the helpful intentions between the United States and Kenya as the US tries to share information with medical institutions there.6 What message is this sending to Kenyans and how does it affect their experience? What can IAs and designers do to maintain the integrity of the interaction and content while at the same time accommodating Kenya’s infrastructure?

Representing multiple cultures in an online environment is a challenge, and doing it poorly risks the participation by one or more groups. At best, you might lose them; at worst, you could marginalize or alienate them. For example, the wording of a survey or a form may perpetuate stereotypes, unintentionally convey an agenda, or reinforce control of one group over another. Or persuasion links may impact interaction patterns by other-culture users in unexpected ways, resulting in incomplete communication or lost revenue. For example, because of cultural influences on their mental modeling or on the perceived value of using technology, members of a given group may not understand the organization of a taxonomy you’ve instituted; it can be tricky to establish paths or processes so that users from differing societies can get to crucial features or pages.

Interaction patterns and hierarchy in rich internet applications may be another trouble spot. Because usage patterns, priorities, and functions differ from culture to culture, naturally these differences would need to be reflected or acknowledged onscreen. Users in some cultures may not yet understand the newer interface metaphors of sliders, accordion panels, and other manipulatives. Or they may need to control and organize information in ways that are meaningful to them but have not been considered by the designers and developers. For example, some cultures think contextually, others in a linear fashion. For the IA in this case, integrating a task list function and a calendar suddenly requires deeper cultural consideration.

There will always be instances when there is no choice but to make a design decision which favors one culture over another. But we must make the effort to reflect on the implications of our choices in the hope of coming up with a solution that will result in a positive user experience. How will design decisions affect the function or the business goal for other cultures? How will they affect the meaning of the experience for targeted users?

A good illustration, based more on experience design than IA, is modern coffee makers which may alienate an older demographic (subculture). These devices are often confounding because they rely on assumed knowledge of digital programming and a button-click interaction. How does it feel when you want coffee and have no choice but to interact with a device you don’t understand? Instead of feeling empowered or respected, you’re more likely to feel discounted and helpless. It should be a simple task—running hot water over ground coffee beans—but instead it becomes complex and defeating for that group of users.

Social Media

The need for another kind of democratic responsibility emerges as the use of technology evolves. Social media, commonly labeled Web 2.0, is a stage for users to both obtain and supply content for the interaction or technology space. Examples of such collaboration and information sharing include wikis, social networking sites, folksonomies, and shared databases. How can the characteristics of social networking and Web 2.0 bolster democracy? How can they hinder it?

Nielsen says that online networks that rely on users to contribute content suffer from a participation inequality—most users don’t participate very much.7 They use the site in a traditional “one-way” fashion. Based on statistics which mirror Zipf’s law,8 he has developed a rule he calls the 90-9-1 rule:

  • 90% of users read or observe, but don’t contribute
  • 9% of users contribute from time to time
  • 1% of users participate a lot and account for most contributions

For example, Wikipedia sometimes draws heat because a relative few are contributing a relative majority of the work. (For Wikipedia, the stats suggest that 1% of the users author 50% of the content.)

For as much as social media sites put power in the hands of the people, or crowdsourcing, it can mean an opportunity for revisionist interpretations of history, people, accomplishments, etc. Or, less diabolically, if only certain groups of people contribute, they “out-voice” others and the content becomes unintentionally biased. Users from a technologically emerging nation, for instance, may be at a particular disadvantage because they do not understand the benefits of social networking or how to effectively contribute. Or because of social mores they may not feel comfortable making contributions which become public. As a result, for example, information about one’s own country might be contributed by a foreign visitor who doesn’t have the insight of a native.

Another aspect of social media is the visual elements within a participatory ecosystem. The graphics and visualizations themselves become artifacts with social appeal, impacting the subsequent direction of participation.9 These visualizations might support personal or group identities (encouraging robust participation), they might be relatively neutral, or they might marginalize or ostracize certain people or groups (i.e., the visuals may be defamatory, perhaps inaccurate or manipulative, or they may not be understood by certain groups).

In all cases, social media begs for democratic responsibility from those who are given power to influence that technological environment. As a solution, Chris Wilson suggests we move from “wisdom of the crowds” to “wisdom of the chaperones.”10 This means practicing stewardship and offering principles to guide those contributing to social media. Again, there is no set of rules for accomplishing this. Each social media space is unique in context and requires its own examination to establish a democratic responsibility. In fact, it may be up to us to recommend that a social media setting is not appropriate. Perhaps cultural aspects of the user base mean that some things are better placed in a one-way ecosystem instead of in a participatory setting.


As IAs and UX designers, it’s important to convey the meaningfulness and relevance of democratic responsibility to other cultures or those in developing countries. Sometimes it may seem like we are making more work for ourselves or working to a low common denominator (like the connection to the Kenyan medical institutions). But by demonstrating these qualities with the technology, we encourage an evolving participation which ultimately raises standards. Or the result may be ambassadorial efforts which further the mutuality between two or more culturally diverse populations—a responsiveness which is necessary for healthy globalization. Perhaps the onus is on the more technologically advanced societies to model this democratic responsibility so technologically emerging cultures will more easily understand the value of it as they grow.

Marshall McLuhan’s idea of the Global Village involves the profound impact of information technology on the development of complex relationships within and between cultures. But in order to understand another culture, we must understand our own. In our respective disciplines, we make design decisions based on context, so it’s not hard to see how we can make democratically responsible design decisions relative to the contextual understanding of culture.

The habit of reflecting on the choices and recommendations we make is a big step in the right direction. Designing requires a balance of reason and intuition, an impetus to act, and an ability to reflect on actions taken.11 It is reflection we undertake conscientiously that makes us good IAs, good designers…and good citizens.


[1] Banks, J. A., Banks, C. A. M., Cortés, C. E., Hahn, C. L., Merryfield, M. M., Moodley, K. A., et al. (2004). Democracy and diversity: Principles and concepts for educating citizens in a global age. Seattle: University of Washington, Center for Multicultural Education, College of Education, 17.

[2] Dewey, J. (1961). Democracy and education. New York: Macmillan. (Original work published 1916.)

[3] Nielsen, J. (2006). The digital divide: the three stages. Alertbox, 20 Nov. 2006  http://www.useit.com/alertbox/digital-divide.html.

[4] Martin, J. N., & Nakayama, T. K. (2000). Intercultural communication in context (2nded.). Mountain View, CA: Mayfield Publishing Co.

[5] See Banks, Democracy and diversity: Principles and concepts for educating citizens in a global age, 20.

[6] Kirch, D. G. (2008). Supporting a culture of collaboration across professional medicine. MedBiquitous Annual conference, 13-15 May 2008. Baltimore, MD.

[7] Nielsen, J. (2006). Participation inequality: encouraging more users to contribute. Alertbox, 9 Oct. 2006  http://www.useit.com/alertbox/participation_inequality.html

[8] Zipf’s Law. (n.d.). Retrieved May 12, 2008 from http://en.wikipedia.org/wiki/Zipf%27s_law

[9] Viégas, F. & Wattenberg, M. (2008). Many eyes, democratizing visualization. PARC Forum, Jan 31, 2008 http://www.parc.com/cms/get_article.php?id=715

[10] Wilson, C. (2008). The wisdom of the chaperones; Digg, Wikipedia and the myth of Web 2.0 democracy. Slate. http://www.slate.com/id/2184487/

[11] Rowland, G. (1993). Designing and instructional design. Educational technology research and development, 41(1). 79-91.


Getting a Form’s Structure Right

by:   |  Posted on

iTunes     Download    Del.icio.us     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gif I had the opportunity to speak with Afshan Kirmani on her article, Getting a Form’s Structure Right: Designing Usable Online Email Applications Part 1. We talk about the design of an online web based application. Part 1 of the series focuses on the web based form where the user experience is critical before the user enters the application. The various aspects include a good entry point into a form which determines if users stay or leave. The beginning of every form is most important as details like usability set your apart from your competitors.

We further talk about…

Good entry points into a web based form include a clear path for users to move ahead from the path of contact to the actual entry into the form. Afshan goes on to also elaborate on products and services that are compared to create a good lure into the form.

Afshan talks about the various aspects of orientation where an interface should determine where you at a particular point in time. Afshan elaborates on the importance of a progress indicator with respect to its placement and usage.

Talking about cognitive terminologies like Chunking, Afshan goes on to apply her background to the field of interface design. She emphasizes on the need to group information in a context that is perceivable by end users.

Trust and Online Safety
Trust is a major factor that allows prospects to move ahead and become loyal customers. Talking about elements of trust on a website, Afshan probes into various aspects like security, taking a tour, an overview of what’s to come and language aid.

With data being bombarded into our lives, the topic of wayfinding seems to become an important discussion for all. Afshan talks about it by providing examples from her everyday life.

User Experience Model (Summary Diagram)
Afshan describes a model that involves the working of a user’s mental model, experience and expectations. When mixed well together, this model leads to a positive user experience of a web based form.

Part 2 of the Article
As mentioned in Part 1, the next part of this article will focus on the designer’s role in the process of creating the form’s structure, layout, segmentation, widgets, color schemes, formatting, alignment, and consistency.

Why We Call Them Participants

by:   |  Posted on

It was not an easy recruit. Directors of IT are busy people. Oddly, they’re hard to get hold of. They don’t answer calls from strangers. They don’t answer ads on web sites. The ones who do answer ads on web sites we had to double-check on by calling their company HR departments to verify they had the titles they said they did.

And now this.

“Hi! So we have some executives coming in tomorrow to observe the test sessions.” This was the researcher phoning. He was pretty pleased that his work was finally getting some attention from management. I would have been, too. But. He continued, “I need you to [oh yeah, the Phrase of Danger] call up the participants and move some of them around. We really want to see the experienced guy and the novice back-to-back because Bob [the head of marketing] can only come at 11:30 and has to leave at 1:00.”

“Sure,” I say, “we can see if the participants can flex. But your sessions are each an hour long. And they’re scheduled at 9:00, 10:30, 12:00, and 2:00. So I’m not quite clear about what you’re asking us to do.”

“I’m telling you to move the sessions,” the researcher says, “so the experienced guy is at 11:30 and the novice is at 12:30. Do whatever else you have to do to make it work.”

“Okay, let me check the availability right now while we’re on the phone,” I say. I pull up the spreadsheet of participant data. I can see that the experienced guy was only available at 9:00 am. “When we talked with Greg, the experienced guy, the only time he could come in was 9:00 am. He’s getting on a plane at 12:30 to go to New York.”

“Find another experienced guy then.” What?!

Five signs that you’re dissing your participants

You shake hands. You pay them. There’s more to respecting participants? These are some of the symptoms of treating user research participants like lab rats:

They seem interchangeable to you.

If you’re just seeing cells in a spreadsheet, consider taking a step back to think about the purpose and goals of your study.

You’re focused on the demographics or psychographics.

If it’s about segmentation, consider that unless you’re running a really large study, you don’t have representative sample, anyway. Loosen up.

Participants are just a way to deliver data.

You’ve become a usability testing factory, and putting participants through the mill is just part of your life as a cog in the company machine.

You don’t think about the effort it takes for a person to show up in your lab.

Taking part in your session is a serious investment. The session is only an hour. But you ask participants to come early. Most do. You might go over time a little bit. Sometimes. It’ll take at least a half hour for the participant to get to you from wherever she’s coming from. It’ll take another half hour for her to get wherever she’s going afterward. That’s actually more than 2 hours all together. Think about that and the price of gas.

You don’t consider that these people are your customers and this is part of their customer experience.

You and your study make another touch point between the customer and the organization that most customers don’t get the honor of experiencing. Don’t you want it to be especially good?

They’re “study participants” not “test subjects.”

Don’t forget that you couldn’t do what you do without interacting with the people who use (or might use) your organization’s products and services. When you meet with them in a field study or bring them into a usability lab, they are doing you a massive favor.

Although you conduct the session, the participant is your partner in exploration, discovery, and validation. That is why we call them “participants” and not “test subjects.” There’s a reason it’s called “usability testing” and not “user testing.” As we so often say in the introductions to our sessions, “We’re not testing you. You’re helping us evaluate the .”

Throw away your screener: Tips on recruiting humans

I’m not kidding. Get rid of your screener and have a friendly chat with your market research people. Tell them you’re not going to recruit to match the market segments anymore. Why not? Because they usually don’t matter for what you’re doing. In a usability test, you focus on behavior and performance, right? So recruit for that.

Focus on behavior, not demographics

Why, if you’re testing a web site for movie buffs, will selecting for household income matter? What you want to know is whether they download movies regularly. That’s all. Visualize what you will be doing in the session, and what you want to learn from participants. This should help you define what you absolutely require.

Limit the number of qualifiers

Think about whether you’re going to compare groups. Are you really going to compare task success between people from different sized companies, or who have multiple rental properties versus only one, or different education levels? You might if you’re doing a summative test, but if most of your studies are formative, then it’s unlikely that selecting for multiple attributes will make a big difference when you’re testing 5 or 6 people in each audience cell.

Ask open-ended questions

Thought you covered everything in the screener, but fakers still got into your study? Asking multiple-choice questions forces people to choose the answer that best fits. And smart people can game the questionnaire to get into the study because they can guess what you’re seeking. Instead, ask open-ended questions: Tell me about the last time you went on a trip. Where did you go? Where did you stay? Who made the arrangements? You’ll learn more than if you ask, Of your last three trips taken domestically, how many times did you stay in a hotel?

Learn from the answers

You get “free” research data when you pay attention to the answers given to open-ended screening questions because now people have volunteered information about their lives, giving you more information about context in which you can make decisions about your study design and the resulting data.

Flex on the mix

If you use an outside recruiting firm, ask to review a list of candidates and their data before anyone gets scheduled. You know the domain better than the recruiters do. You should know who will be in the testing room (besides you). You should make the trade-offs when there’s a question about how closely someone meets the selection criteria.

Remember, we’re all human, even your participants. These steps will help you respect the human who is helping you help your company design better experiences for customers.

Getting a Form’s Structure Right: Designing Usable Online Email Applications

by:   |  Posted on

I started writing this article with an emphasis on the financial domain. I then realized that I would like to broaden the focus because my findings are also applicable to a general domain like email account registrations, for example. In this article, I would like to take a simple example of how users register for an email account online. For a first timer, is the transition from a real world of letter writing to the online medium easy? And for a frequent user, is he or she motivated enough to create an email account with another service provider?

Yes, this is for all of you out there—my fellow usability practitioners, information architects, designers, managers, project leads, editors, and people who are looking to develop their UX practice.

In the modern family, where often both parents are working full-time and the children are involved in many after-school activities, people may only have a few minutes to spare on an important task during the day. And it’s the Internet that supposedly helps people achieve this. But do we, as designers and usability practitioners, always help them do it? I say, “No.”

Just the other day, a friend of mine begins to complain of the spam mails that she receives everyday. “I have two separate email ID’s to keep myself away from such mails—one for official purposes and the other for my junk emails. But even my official ID seems to be flooded with these emails. So I found myself moving to another email service provider. Again, I found myself grappling with the registration process.”

There are three people who determine success of a web-based form: the usability practitioner, the designer, and the user (Image 1). Taking a simple everyday example like an email service, I aim to discuss the various aspects that lead to a great forms structure.

Image 1: Success of a web-based form requires involvement of a usability practitioner, designer, and user.

There are a million websites out there. There are a million email service providers out there. How do you ensure that you gain the right audience to join your service? What are those factors that will help users move ahead and become your loyal customer? Part of the answer has to do with the first step: REGISTRATION!

In the first part of this series, I will focus on the basic issues that a usability practitioner must address to create a usable web-based form:

  1. Affordance
  2. Orientation
  3. Chunking

1. Affordance: The Lure

We all know how grueling and tedious a registration process can be. Therefore, we need to ensure that our sites adequately “lure” users into the process. To do this successfully is not just a matter of providing the right cues, but how and where we provide them.

Coming from the real world

Every online form was created keeping the real world in mind. We all once began filling in forms in real life before we began moving to the online medium of getting things done quicker.

Email service providers must allow for a smooth transition from a real world scenario to the internet, for those who are petrified of it. Users should know the advantages of the service provided as compared to the real world scenario of letter writing. Why would users move to your service when they can just write a letter? What are the advantages of sending an email? Is it quick? It is easy? These issues should be addressed upfront to ensure that they are lured forward.

None of the websites that I reviewed follow this practice effectively.

Entry points

An entry point to an application must be clear and appropriate to the specific needs of the user. For example, let’s say a user visits a website to send out an email to a distant relative. He or she has never used a web-based email service before. Not knowing that he/she needs to register, they would look for a direct cue to send out an email. Where do you think this user would look for a cue? This is where you need to perform a quick goal-task analysis. Let’s consider a scenario:

A first timer enters the website to send out an email. This user is hauled because he/she is unsure of their next step.

Let’s have a look at Gmail, our most used email provider. Most websites that I reviewed allow you to register. But users are not lured into it. As a first time user of a website, they need to know the benefits of registering clearly, up front. Gmail does a good job of this (Image 2).

Users often hate to register. Therefore, as usability practitioners, we need to tell them of the benefits of registration when they enter a website for the first time.

Image 2: A good example of enticing users to register online by clearly listing the benefits up front.

Service/Product comparison

Remember, your users are watching your competitors as well. So if you aren’t that big in the market, how exactly would you think big? Compare your features with that of your competitors to formulate your strengths over the others in the market. Let’s see how Bluebottle effectively does this (Image 3).

Image 3: Bluebottle’s website allows users to take a peek at service comparisons. Users also have the freedom to view a detailed comparison.

Online benefits

It is important to inform the user up front of what they will gain after registering. It’s a competitive world out there and users must and should know what the website is selling them. This affirms the brand’s identity and responsibility to gain customers online. A basic cue reassuring users about the benefits helps build trust which encourages them to use your services. As shown in image 2, Gmail clearly provides the online benefits.

Another clever way to entice them is to provide a view of what the service looks like once they have registered or applied. In this case, it would be ideal to show users on the homepage a view of what their personal landing page (the inbox) would look like once they have registered.

None of the websites that I reviewed follow this practice rightly.


It is essential that users know that the information they are entering will be secure. A basic “Lock” or “Key” icon would do the trick. Also, providing them with security information and its benefits improves customer loyalty and trust. With the case of Yahoo, the website uniquely utilizes this feature to grab users towards their secure service (Image 4).

Image 4: Providing a security message increases loyalty which moves users towards registering.

Taking a tour

Before users move ahead to encounter a form, it is necessary to tell them why they need to do it and most importantly how they need to do it. Again, taking the same examples forward, if you look at the example below, you will see how AIM Mail allows users to take a tour (Image 5). This also gives an edge to its competitors as they are showing them of what’s inside even before registering.

Image 5: The website allows users to take a tour before registering.

User’s path forward

This doesn’t just end with the benefits. Users have to be told where to go after they have been guided. All websites do provide a way to move ahead. But I specifically want to use an example that can show improvement in terms of placement of this cue, which is most important while users are making a decision.

We love Gmail. But we sometimes wish it were always right.

Provide users with a clear path forward AFTER you are done enticing them with the meat.

Image 6: The website must provide a clear path forward after enticing users with the benefits.

Consistent design

As users transition from the homepage to the form, it is important that the design of the pages remain consistent. Any small change in the design or layout could affect their performance and decrease the overall experience.

Most websites get this right. But we can still look for improvement. Let’s have a look at the example below (Image 7). Here, as users move from the landing page to the form, we see significant changes in the layout and the visual design.

Image 7: The design of the page is inconsistent with the previous page.

An overview of what’s to come

As users enter the application, they need to know what to expect, however short it maybe. Therefore, throwing users directly into a form is not the best way to help them achieve their goals. Instead, the website must first provide users with an overview of what’s to come, including the application requirements and the next steps. This can be just a few lines telling them of the benefits, the things that are expected and an instant access to their emails soon after they are done.

Let’s have a look at Yahoo as an example (Image 8). It doesn’t do a perfect job. But it’s nearly there. All the information that the user is expected to provide during the registration process is described up front.

Image 8: The website informs users of what is expected of them while registering.

Lending a helping hand

We all know that people fumble along the way. Heck, sometimes I come across forms that I don’t understand. Therefore, it is essential to provide users with online help whenever needed.

For applications that drive business, a toll free number is essential as this brings in the revenue. But with the case of an email service provider, online help would suffice.

The visibility and location of the help link is equally important. By providing this, you can ensure that users not only find it quickly but also feel safe just by seeing it. This is also useful for first time users who are just transitioning from the real world of letter writing to the web world of emails.

None of the websites that I reviewed follow this practice successfully.

Language aid

There are websites that allow users to view their services in the language they choose. This should also be the case with web forms. Choosing the language of their choice gives them freedom and control. It also helps them move forward and register as they can be assured that the website caters to their needs as well.

Image 9: The website provides a way for users to set their language preferences.

Save and continue

Let’s say that the basic goal is to register online, so why not just save users’ information automatically as they proceed? A basic “Save and Continue” button would not only tell users that their information is automatically saved but it would also allow them to access the information if they need to resume the application later.

Now if your form is just a page long, you would obviously need a button that reads “submit” or “done”.

Most websites only follow the later.

2. Orientation

Form title

Ensuring that the page header follows a clear task flow from the preceding cue helps applicants orient themselves to the page. Most websites do this successfully. Let’s take a look at the example below (Image 10). Gmail follows a clear flow from one page to another, telling the users where they are at each specific point in time.


Image 10: The website provides a clear orientation feedback to the users as they move from one page to another.

Progress indicator

How ever short or long your application form maybe, users need to know their path ahead. A well-positioned progress indicator outlining the entire application process helps users see what lies ahead of them. There’s no use of providing the progress indicator on the left or the right of the form. Users need it up front as they do not tend to look to the left or the right of the form when they are entering information into an application. The best way to grab the user’s attention is to display the progress indicator on the top of every page of the application.

Let’s have a look at an example below (Image 11). This website has got the concept right. Yet, it can further deliver what’s best for users at this point. If you are providing users with a form, make sure that you tell them what each step entails. For example, Step 1: Enter your personal details. The example below does provide a progress indicator by telling users of the number of steps ahead. Yet, it fails to mention the step details.

Image 11: An example of a progress indicator. Though, the website needs to take a further step to provide the step details.

Progress feedback

More than 60% of web-based forms that I’ve encountered add in extra steps along the way, ones not included in the progress indicator. As applicants do not see all the steps up front, they are baffled when additional steps start appearing. When you tell users that the form entails 3 steps, don’t cheat them. Keep it to 3 however tempted you might be. With the example above (Image 11), users are probed into a number of pages, viewing the same orientation feedback for pages to come. Make sure that each step is provided on the same page. Moving them through pages and providing them with the same orientation feedback is only going to cause confusion.

3. Chunking

People perceive information more easily when related parts are grouped. This increases users’ efficiency and reduces reading effort. Chunking information into related parts helps users better understand information to navigate more effectively.


Ensure that you break the form into logical content groups and provide relevant headers for each information chunk. I have seen more than 90% of web forms that just provide the main header and then continue with about 20 questions on the same page. This can overwhelm a user. A quick way to organize information into groups would be to do a card sort with potential users of the application or even your co-workers. An example of effective chunking is found at Yahoo and My Way (Image 12 and 13).

A clever trick is to number the chunks to allow users to perceive how much is left and also to perceive that they are moving forward. It provides clear direction of a way forward.

Image 12: The form is well-chunked, with clear headers describing the grouped content.

Image 13: The form is well-chunked, with clear headers describing the grouped content.


Labels on individual pages within the application process must be related to the main header as well as its elements. For example, forms should display a clear and simple header along with related sub-headers. In the example above (Image 12 and 13), the sub-headers (labels) are clearly grouped with their header. You have personal information and password information separated with clear headers that define the structure. This provides clarity and direction.


As usability practitioners, we need to first and foremost understand the user’s intentions and expectations, in order to provide an online experience that accommodates them. The image below (Image 14) shows the mapping between the user’s intentions and expectations and the ways in which the usability practitioner can help accommodate them in order to ensure the ultimate success of online application forms.


Image 14: The usability practitioner ensures that the form’s structure accommodates the user’s mental model, experience, and expectations.

The journey of creating a successful online application form requires three people working in parallel: the usability practitioner, the designer, and the user. The usability practitioner needs to keep in mind the big picture. The designer needs to have a clear understanding of all the details that will go into the form’s structure. The user helps shape the overall approach to the application form and ensures its ultimate success.

You might agree, partially agree, or even disagree with my thoughts. You might even have something to add to this. Let’s hear your point of view. We are innovating, remember?

Coming up…

The next part of this article will focus on the designer’s role in the process of creating the form’s structure, layout, segmentation, widgets, color schemes, formatting, alignment, and consistency.


  • “GUI Design for Dummies” by Laura Arlov, 1997
  • “GUI Bloopers: Don’ts and Do’s for Software Developers and Web Designers” by Jeff Johnson, 2000


Comics for Consumer Communication

by:   |  Posted on

The rising popularity of the comic as an internal communication device for designers has increased our ability to engage our stakeholders as we build interfaces. Yet, social service agencies looking to provide services to hard-to-reach groups like immigrants, cultural minorities, and the poor have taken pride in innovative outreach methods. In situations where traditional printed matter is a barrier, graphical methods can be used very effectively to communicate with audiences.

From guerilla theatre to testimonials, posters to graphic instructions, users have benefited from alternative communication methods, particularly in situations where education or cultural barriers make it difficult for people to access services important to their well-being and safety. In some cases, the comic book format has been used as a way to help people get access to critical legal help. This case study from my time as a publication manager at the Legal Services Society (LSS) of British Columbia (BC) could inspire the use of comics outside the development process. Continue reading Comics for Consumer Communication

UX Design-Planning Not One-man Show

by:   |  Posted on

A lot of confusion and misunderstanding surrounds the term "user experience." The multitude of acitivities that can be labeled with these two words span a vast spectrum of people, skills and situations. If you ask for UX design (UXD), what exactly are you asking for? Similary, if someone tells you they are going to provide you with UXD for an application, website or intranet or extranet, what exactly are you going to get?

Is it just one person who is responsible or is it a team of people who are in charge of UXD? In this story I´ll sketch my ideas of UXD based on my experiences and at the end of this story I will give you my answer.

Let us start at the beginning – UXD starts with experience – experience of the users. And so I will talk about the users first.



UXD-P – every person is an individual

Every person is an individual. Every person is in possession of different roles. For each individual there will be many roles and each person adopts a different role depending on the circumstances.

roles of experiences

User Roles

Sometimes the individual person holds one role, but mainly he will hold quite a few roles like consumer, customer, user, client, investor, producer, creator, participant, partner, part of a community, member, and so on.



UXD-P – network of expectations, experiences and knowledge

Every user is multi-faceted – and is considerably more complex than they themselves can imagine – so it´s not very helpful just to talk to the user or ask him what he needs. We have to watch what people do; we have to listen to what people say and to recognize what decisions people make – and by observing we have to evaluate and understand why they do this and that. Why and what kind of visual elements will the user like, prefer and or understand? Why and what kind of mental model, navigation or function do they respond to?

Jakob Nielsen said “To design an easy-to-use interface, pay attention to what users do, not only what they say. Self-reported claims are unreliable, as are user speculations about future behaviour.” (Jakob Nielsen – Alertbox) and I agree – I think no statement can be objective. Perhaps the circumstances are not realistic or not reasonable for the person. Or maybe the person himself is not really in the “situation,” or he is being influenced by other factors (trying to please the tester for example). Or maybe he is trying to succeed with the test rather than trying and failing, which tells us so much more.

When all three perspectives (do, say, make) are explored together, we are able to realize the experience spectrum of the “normal” user/customer we are working for.

Jesse James Garrett said: “User experience is not about how a product works on the inside. User experience is about how it works on the outside, where a person comes into contact with it and has to work with it” (J.J.Garrett – The Elements of User Experience) .

areas of experiences


Areas of experiences: different areas which effect the quality of communication



UXD-P – personal and individual

When we talk about experiences, we take the individual into consideration, including the subjective occurrences felt by the person who has the “confrontation” with what we want them to use. Experiences are momentary and brief – sometimes they are part of a multi-layered process or they are on their own.

Normally such know-how has been learned as a part of something or by itself and will be remembered in the same way – but that’s not always the case – and the person deals with the situation in a different way. If we look at their exeperience as a continuum, the user brings their experiences of the past to the interaction in the present and adds their hopes for the future. That future could be: to interact with their banking in a safe and secure way.

flow of experiences

Flow of Experience

Flow of experience: the individual user/customer is always in the present – they act in the present. They are influenced by former experiences and current expectations.

UXD-P is taking the users’ views, behavior, and interactions, to figure out the emotional relationship between them and the thing we have built. For the most part these "people" and their experiences are unknown. It requires an appreciation of the customer: their journey, their personal history and their experiences.

It is the collective set of experiences, in the online-world, the offline-world, or even tiny little things (i.e. My coffee was cold this morning) that affects their experience of the products and the companies that represent them. It is about appreciating the individual user’s unmet needs, wants, capabilities and desires in a contextual way. It´s a box of experiences including the things the user saw, acted and felt. (BBC Two [12th February 2008, 9pm, BBC Two] had a program on rational thought. Highlights of the program include: Loss complex, Post-decision rationalization, Priming, Precognition. Watch highlights from the programme : http://www.bbc.co.uk/sn/tvradio/programmes/horizon/broadband/tx/decisions/highlights/ )

Experiences and expectations meet in the present. Both are inseperably combined, and every action we take takes both parts into consideration. When a person uses an application, he tries to understand what happens. He will always try to reference this to his past experiences. The moment is also tightly coupled to his expectations of his personal outlook.

At this point of “present” I think of the UX honeycomb of Peter Morville [1] …

honeycromb – Peter Morville

Morville’s "honeycomb"

honeycomb – Peter Morville (P.Morville – Facets of the User Experience)

In the present we have to deliver to the individual user and his specific task the best answers to following questions.

  • Is the application useful for the individual user and his specific task?
  • Is the application usable for the individual user and his specific task?
  • Is the application desirable for the individual user and his specific task?
  • Is the application valuable for the individual user and his specific task?
  • Is the application accessible? Available to every individual user, regardless of disability?
  • Is the target findable for the individual user and his specific task?
  • Is the application credible for the individual user and his specific task?

In the UXD-P the whole team has to take the users’ views of the GUI and the interactions to figure out the emotional relationship between the brand and potential customers. It requires a common appreciation of the customer journey and their personal history: not only with the product and similar products, but also with similar experiences.



UXD-P – teamwork and cooperation

The first stage in discovering – to invent or design for the experience – is to take a new viewpoint about the people who buy and use the products and services we are designing. This is a birdseye view and from step to step we have to use the "mouseview," which is to say a detailed view from the user’s perspective, as we develop the application we have to switch between these views. Our main desire is to to respect, value, and understand the continuum of experience and expectations our users have .

UXD-P can sometimes be a slippery term. With all the other often used terms that float around: interaction design, information architecture, human computer interaction, human factors engineering, usefulness, utility, usability and user interface design. People often end up asking, “What is the difference between all these fields and which one do I need?” If the UXD is aimed to describe the user’s satisfaction, joy or success with an application, product or website, however we specify it, there are a few key essentials which need to be tackled and I have to point out the UX honeycomb of Peter Morville [1] a second time. Each of these points, as enlightened above, makes up a considerable component of the user experience. Each is made effective due to the design offerings from each of the following elements:

Usefulness is based upon utility and usability. This means the product is able to give exactly the right kind of service and what the user is expecting from it. And it´s the joy of reaching my aims and the joy of doing so easily. The information architecture is in charge of clarity of the information and features, lack of confusion, a short learning curve and the joy of finding. The designing of the interaction is essential for a successful and overall satisfying experience. So the interaction design has to answer the questions of workflow, logic, clarity, and simplicity of the information. Visual design is responsible for the clarity of the information and elements, simplicity of tools and features, pleasant or interesting appearance of the interface, the visual hierarchy, and the joy of look and feel. Accessibility is a common term used to describe how easy it is for people to use applications or other objects. It is not to be mixed up with usability which is used to describe how easily an application, tool or object can be used by any type of user. One meaning of accessibility specifically focuses on people with disabilities: physical, psychological, learning, among others. Even though accessibility is not an element of its own, it is important to notice that accessibility also plays a role on the whole user experience to increase the likelihood of a wide-ranging user experience. People tend to gravitate to something that is easier to use regardless of who it might have been designed for.

The UXD innovation process is a nonlinear spiral of divergent and convergent activities that may repeat over time. Any design process begins with a vision. This applies particularly to the UX process. A vision, however, is not enough to start design. As I mentioned before, we always have different circumstances, users and roles. Therefore, it is critical to accurately understand the end user’s needs and requirements – his whole experience and expectations. The UX process relies on iterative user research to understand users and their needs. The most common failure point in UX processes is transferring the perspective of users to UI design. The key is to define interaction first, without designing it. First, all the research (the user, product and environment) have to be organized and summarized in a user research composition. These lead to user profiles, work activities, and requirements for the users. The user research composition feeds directly into use cases. The use cases show steps to accomplish task goals and the content needed to perform interactions. Completed use cases are validated with the intended user population. This is a checkpoint to see if the vision is being achieved and the value is clear to users and the project team. The next step is to design the user interface, generating directly from the interaction definition. A primary concern with design is to not get locked into a single solution too early. To keep the project on time, this step should be split into two parts: rough layout and exact and detailed design. The rough layout allows experimentation and rapid evaluation. Detailed design provides exacting design and behavior previews of the final application that specify what is to be coded. Iterative user evaluations at both stages are connected to be fast and effective in improving GUI, design feedback, rapid iterative evaluations, and usability evaluations.

UX workflow cycle


design workflow – workcycle – workspiral




UXD-P – Gathering the elements

The diagram below presents the relationship of the elements above:

elements of UXD-P

Elements of UXD-P

Lewin’s equation

Lewin’s Equation, B = f (P,E) ( B – Behaviour; f – Function; P – Person; E – Environment ), …

… is a psychological equation of behaviour developed by Kurt Lewin. It states that behaviour is a function of the person and his or her environment [2].
There is a desired behaviour that we need to encourage, but we have no control over the person, so via interaction design, information architecture and interface design we control the environment and therefore generate the desired behavior. (see reference: books.google.com ).



UXD-P – many steps to go but every step is worth it

How do we involve our team, customer and our user/consumer? We can start at different points, but I like to think about the circumstances first. Where do we come from? Where are we? Where will we go? And who is “we”? “We” means each person who is involved in the project. Iin the centre of each effort stands the user. To get the user with his personal experiences and expectations into the project, the design team and the customer needs a combining glue / tool / instrument. I believe these are the personas of the “target users/consumers” in the process of UXD-P. If there are no personas the second or third choice are scenarios or the workflows (based on a certain user/person).

The management point of view for the most cases is also the view of our customer. It includes the user’s/consumer’s age, income, gender and other demographics. The perspective of UXD-P is to look at behaviour, goals and attitude.

To get a realistic persona we have to identify first of all the target users. Out of my experiences this is not only the task of our client to define the users and consumers – we have to support him. During the identification and characterization we have to go beyond demographics and try to understand what drives individual users and consumers to do what they do and these as detailed in quantity and quality as necessary and possible – like I mentioned above. The approach and the complexity of the characterization depend on the tasks, project and functionalities. Parallel to the very personal description we need a “picture” of the environment. For each persona we must define their business and/or their private concerns and aims. Do they want to research a product for purchase later? Are they concerned about not wasting time primarily? Do they just want to purchase something online as easy and quick as possible?

Depending on these personas we can formulate, discuss and prove scenarios – from the very beginning of the project, during the project and as check or analysis at the end of the project.






UXD-P – my blueprint of schedule – "todos" and deliverables

We are always asking and being asked: what are the deliverables. Throughout my career as an IA, UX-planner and designer, as well as during my study of architecture and town planning, I have constantly asked myself following the questions:

  • What kind of project is it? What are the key points?
  • What should our steps and milestones be in the project?
  • What should our/my deliverables be?
  • How can we/I explain the main idea?

I have realized that if I do not answer these questions previous to creating a deliverable, I waste more time and deadlines slip.

The deliverables are not for us. The deliverables are a means of communication with several people: manager, decision maker, client, designer, front-end developers, back-end developers, etc. Sometimes I have the feeling we overlook this from time to time. After I think about the project I have to ask myself, where will my deliverables and other efforts fit within the process of design? The following diagram describes different lines of work that will lead us to some questions each line must accomplish. Depending on these questions and topics I will outline the basis, basics and deliverables for which each skill and ability which is necessary.

Image_6___schedule of UXD-P_small version


schedule of UXD-P ___ better view – schedule 1238px x 1030px


UXD-P – my conclusion

I studied architecture and town planning. And just like town planning and architecture isn’t just for architects and art lovers, the internet isn’t just for computer users and developers. Similarly, just as the towns and the cities are for the inhabitants and architecture is for the users of a building, so products and applications are for the user, the customer, the member and not for the people who build them.

In every kind of process we should act in a team but in the process of UXD-P it is absolutely essential that we have to think parallel, with the same focus . We have to act in a team, although every team member is a kind of lawyer: lawyer of budget, of the client, of utility, of usability, of look and feel, of brand and finally of the user himself. Because at the end of the project, our user/customer is the final judge.

Good design is not only interface, or look and feel, or technology, or hardware, or how it works. It is every detail, like the structure, the labelling, the border of a button or a little icon. Finally, it is the sum of every element. I believe that a shared vision of a group of creators will have more potential than individual creativity. And that is the point where creativity meets expectation. The point of view on IA and design and the process to get to a well-designed product will be changed by UXD-P.

The persons who use the application or other object that we invent are the real “architects” of the “architecture” – the real “inventor” of the design. The more we know about our users, the more likely we are to meet their needs.

As the capabilities of interactive applications and the internet go forward and grow, more and more consumers use the applications and the various possibilities in new and different ways. We must think about all aspects of user experience.

And I will ask you once again: Is it just one who is responsible or is it the team which is in charge of UXD-P?
Personally, I believe it is the process of planning and designing for User Experiences (and so I think it’s the team which is in charge), but the overview has to have an experienced planner as a kind of captain.


The most common cause of an ineffective website (one that doesn’t deliver value to both the business and its intended constituents) is poor design. The products have to follow, to cover the functions and the experiences. The lack of clear organization, navigation and values of brand and mood mean that people will have an unintentional and maybe bad experience, rather than one that will meet the business’s relationship objectives for each individual. User experience design and planning is a fundamental component to the creation of successful digital products, applications and services.

UXD-P is UXdesign and planning- – In my estimation there are distinctions between Design and Planning.

Design is usually considered in the context of arts and other creative efforts. When I think of design in the UX process it focuses on the needs, wants, and limitations of the end user of the designed goods, but mainly on the visual parts and the mood. A designer has to consider the aesthetic-functional parts and many other aspects of an application or a process.

The planning part provides the framework. The term "planning" describes the formal procedures used in such an endeavors, such as the creation of documents, diagrams etc. to discuss the important issues to be addressed, the objectives to be met, and the strategy to be followed. The planning part is responsible for organizing and structuring to support utility, findability and usability.

I strongly believe that both parts – design and planning – have to work closely together. Every team member should have the ability to think cross-functionally and to anticipate consequences of activities in the whole context.

I’ve often seen timelines like this …


and this doesn´t work for UXdesign and planning …

I give a timeline the preference which looks like this:


… to develop a UXdesign and UXplanning.

And in the center of this team and of this process should stand the leading person – the user!

Image_9___basis points of UXD-P




[1] _ UX honeycomb of Peter Morville




[2] _ The Sage Handbook of Methods in Social Psychology _ by Carol Sansone, Carolyn C. Morf, A. T. Panter

google-books (The Sage Handbook of Methods in Social Psychology)

amazon.com (The Sage Handbook of Methods in Social Psychology)


Blasting the Myth of the Fold

by:   |  Posted on

iTunes     Download    Del.icio.us     Pod-safe music generously provided by Sonic Blue

banda_headphones_sm.gif Jeff Parks had the opportunity to speak with Milissa Tarquini on her article, “Blasting the Myth of the Fold”:http://www.boxesandarrows.com/view/blasting-the-myth-of. They talk about how this long held rule in web design is being de-bunked by web analytics and user testing, as well as how this will impact design and development processes based on screen resolution and browser compatibility.

We discuss…

*Defining the Fold*
Milissa outlines the different terms that people use for the fold. Anything that falls below that point in the screen where the user has to scroll is the fold

*Back in the day*
In the early 90’s at AOL scrolling was prohibited. Milissa talks about the need for balance in designing for the fold while being creative.

*A moving target*
She goes on to talk about the challenge of designing for the fold with different screen resolutions and browsers and how in her opinion no one should be designing for the fold.

*Content is still king*
According to Milissa it all comes down to the quality of the content. If content is engaging and the user is interested in the information, they will follow the path to what they are seeking, regardless of the medium.

*Interaction Design is everywhere*
As Derek Featherstone pointed out in his discussion with Christina about Accessibility, IXDA plays an important role when designing with how users will find content on a page.

*Not the last, but a new frontier*
Milissa addresses social media tools such as Blogs, Facebook, and MySpace and how these new web services reinforce the notion that users do scroll. As Eric Reiss commented, “…perhaps the new frontier is the bottom of the page.”

In Appreciation of Measures That Tell Stories

by:   |  Posted on

Not long ago, usability measures and Web analytics were few and far between. The usual standards amounted to little more than task completion, error rates, and click streams. Yet, they served us well.

Some years ago, when relaying one telling measure—how many clicks it took to find a book—to clients at a large metropolitan library group the room fell silent. Finding a book on a library web site should have been, as my father was fond of saying, “as easy as shooting fish in a barrel.” In our test sessions, however, it took eight of 12 participants an average of 6.25 clicks to find John Grisham’s book, A Painted House. The benchmark for the task was one click.

All but a couple of the participants meandered through pages looking for the best-selling book without feeling they were progressing toward their goal. Some participants clicked 18 or 20 times before giving up. Of all the performance data in our 147-page report, this one piece of information, the number of clicks it took to find the Grisham book, moved the client to take action.


“The Three Cs”

This was back in 2002. Now, of course, we have more measures in our toolbox. Or, at least, we should. While the old standards are still useful, the digital spaces we try to improve have become much more complex and so too, have clients’ expectations for functionality and a return on their investment.


Whether you call this a Web 2.0 era or not, there is no disputing that most clients these days care more than they ever did before about the “Three Cs”: Customers, Competitors, and Conversion. Click streams have made room for bounce rates, search analytics, and so much more. If we play our cards right, we can reduce and synthesize the raw data and give our clients more meaningful information that foments action.


Emblematic Measures Have Teeth

Of all the data we report, there are certain measures that are more meaningful than others. I call the more meaningful data emblematic measures. In dictionary terms, emblematic is a “visible symbol of something abstract,” which is “truly representative.”


In our presentation to the library group, the rate for the Grisham task was emblematic. That is, the measure was representative of the library website’s greater inadequacies: its failure to fulfill the basics of its fundamental purpose and meet its customers’ needs. In turn, the measure was understandable to the client on a visceral level because it was firmly planted in their business objectives.

“Emblematic measures ensure that the data are always in the service of the business,” writes Avinash Kaushik, author of Web Analytics: An Hour a Day. “I can’t tell you how many times I run into data simply existing for the sake of data with people collecting and analyzing data with the mindset that the sole reason for the business’s existence is so that it can produce data (for us to analyze!).”

However, not all of the measures we deliver to clients are emblematic, nor should they be. Emblematic measures need to epitomize the entire study’s findings eloquently and elegantly. In layman’s terms, emblematic measures are a lot like the best line from a classic movie: It’s not the only line, but it’s the one that is remarkable, memorable, and eminently quotable.

Emblematic measures are far from prescriptive, static, or context-free, too. With every bit of user experience research we conduct and on each and every site, the measures will surely vary, given the context of testing, the sample, the tasks assigned, the business objectives for the site, the functionality being studied, and so on.

Therein lies one challenge of our daily work.


The Site Abandonment Measure

Fast forward from 2002 to Summer 2006. During a usability test of a philanthropic extranet for a large foundation, we measured the occurrence of something we had seen happening a million times. We used to think it was just too obvious to formalize and report to clients.


But this time, we found our emblematic measure.

We call this measure a Site Abandonment Measure (SAM). We define a SAM as the percentage (or number) of participants who give up on a specific task (or set of tasks), leave a site altogether, and turn to another source—any source—to get a task done. Put simply, it’s the “I quit—I’ve had it with your site” rate.

When we asked our 15 participants to make a recommendation for a grant in support of a local Special Olympics team, 53 percent of the sample abandoned the task all together. Participants told us they would complete the task elsewhere (usually by using a phone to call the Special Olympics or the foundation directly).

We also found the SAM was significant for informational tasks. When we asked participants to get the latest tax return for the Special Olympics group, 40 percent of the sample left the site all together and went directly to the Special Olympics site for the information.

Overall, the SAM for the foundation’s site was 38.6 percent for the ten key tasks on the extranet. This showing was pretty dismal, especially given the context of our research. We were, after all, testing an extranet with the sole purpose of letting users manage their philanthropic funds—not an e-commerce site and click-through rates on ads. (There are no formal usability standards for unacceptable SAMs rates, as far as we know.)

This means that, on average, on any one task, about six out of every 15 participants agreed to take on the task we asked of them, went through the first motions, and then eventually gave up not only on the task, but on the entire site.

When we presented the findings to the client, the show-stopper was the Special Olympics task and the corresponding SAM. How could they have laid down cold, hard cash for a site that failed to let over half of the test participants make a grant recommendation online?


SAMs vs. SARs

SAMs may bring to mind Web analytics and their main use on e-commerce sites. Under the hood, of course, the data is as different as a Porsche from a Prius.


Web analytics, such as conversion rates and the more narrow site abandonment rates (SARs) for measuring user interaction with shopping carts, leverage quantitative data extracted from transactional logs to measure macro-level interactions across a large sample of users. SAMs, on the other hand, use behavioral data from one-on-one test sessions to measure micro-level interactions with a small set of representative users.

As a measure in our toolbox, SAMs can tell us things about users that SARs cannot. When users “think aloud” during usability sessions, SAMs can give us some information about the rest of the story behind the quantitative measure. They can collect qualitative data about users’ frustrations, annoyances, barriers and solutions. (Granted, there is always the issue “self report” in usability test sessions.)

According to Kaushik, there are, of course, emblematic Web analytics, too. And bounce rate, which measures the number of visitors who see only one page and leave, is a frequent one.

“Everyone (from the CEO on down) gets this metric right away and can understand if it is good or bad,” Kaushik says. “It is so hard to acquire traffic and everyone cares about the percentage of traffic that leaves right away. When I report that ‘your bounce rate is 60 percent,’ it simply horrifies the client and drives them to ask questions to take action.”


What’s in a Name?

Relying on a sexy metric or one type of usability measure alone is not always a sure way to reach a client with a call for change though. The underlying data also has to speak to clients. This means practitioners have to work at breathing life into the data they package and deliver.


Kaushik recounts a story about taking existing metrics and segments and simply renaming them to make them more emblematic: “We were measuring five customer segments: (1) those who see less than one page on a site, (2) those who see three pages or less, (3) those who see more than three pages and did not buy, (4) those who place an order, and (5) those who buy more than once. These were valuable segments and something worth analyzing, but the internal clients would simply not connect with the segments until we renamed them to ‘Abandoners,’ ‘Flirters,’ ‘Browsers,’ ‘One-off-wonders,’ and ‘Loyalists.’”

The simple change in how the data was communicated had a huge impact by creating a story around it. Kaushik’s client had a greater understanding and instantly began asking how they could turn Flirters into Loyalists.

Hitting Clients Right between the Eyes

Sophocles wrote, “The truth is always the strongest argument.” Likewise, many practitioners rely on data to provide the best approximations of truth they can. With so much of our research focused on striving for accurate representations of something as amorphous, varied, and hotly debated as user behavior, we are a profession usually awash in data, practicing a less-than-perfect science.


When I was in graduate school, we discussed ””construct validity”:http://books.google.com/books?id=eAdbEn-yZbcC&pg=PA190&lpg=PA190&dq=babbie+and+construct+validity&source=web&ots=k8tB76zIaW&sig=6-ww5WOHJhLKFk5siib3qUYheis#PPA190,M1.” Construct validity refers to the extent to which a test offers approximate evidence that a certain measure (e.g., the task of finding a library book) accurately reflects the quality or construct (the proficiency of users in carrying out a frequently conducted task on a library site) that is to be measured.

It is essential, of course, to weigh the validity of the tasks we develop and the results delivered. But collecting all of the “right” data is not always enough.

“The problem is that we are so immersed in data in our professional or academic worlds that, to a great extent, we become disconnected with reality,” Kaushik says, “especially when we lose touch with the business side of things and we lose touch with customers and base our analysis on how four people in a lab carried out a task.”

Do your rigorous research justice by communicating the data in such a way that it reveals any significant shortcomings. No matter the size of your project, look for the emblematic measures. They will allow you to tell stories that hit clients right between the eyes and move them to action.



Many thanks to Avinash Kaushik for his email interview for this article on October 4 and 5, 2007.


Kaushik is the author of the book, Web Analytics: An Hour A Day writes the blog, Occam’s Razor, and is the founder of Market Motive, a Silicon Valley startup that focuses on online marketing education. He is also the Analytics Evangelist for Google.

Ease of Use Outside the Box

by:   |  Posted on

As user experience designers in an enterprise, we find ourselves knee deep in pixels. Should we use a dropdown element or a set of radio buttons? 10pt or 12pt size font? A broad-and-shallow or narrow-and-deep information architecture? While such design considerations are necessary and important, we miss huge user experience opportunities outside the webpage, outside the website, outside the browser. By tackling inter-application usability opportunities, user experience (UX) professionals can make things easier in a big way.

Ease of Use Outside the Box

Since enterprise usability issues affect the entire organization, even small gains in improved ease-of-use can reap large benefits in aggregate across the entire user base. Whereas we traditionally focus on intra-system usability, we can also advocate inter-system usability, basically greasing the skids between systems so that all systems are easier to use. We could champion the merits of large monitors, decry unrealistically complex password policies while offering password management solutions, and develop easy-to-remember URL shortcuts for all websites that our colleagues access.

Fundamentally, user experience design strives to optimize the efficiency with which users communicate with other users through a computer. Users retrieve, consume, and input information. Within a system, we design the interfaces that allow users to efficiently perform those tasks. But users access systems in context of the environment that they are in. A system’s user experience may be drastically impaired when users access a system in a suboptimal context.

Take an application with a very well-designed user experience, say Apple’s iTunes. Fire it up, search, sort, categorize, play, and buy songs with ease. Well, perhaps not so easily. What if you were running the application on a computer with a 233MHZ processor, 32Mb of RAM, 640×480 monitor, 28.8Kb modem, and one tinny speaker? What if your iTunes password had to be changed every 15 days, must be 12 characters long, and include at least one number and one non-alphanumeric character? What if simply finding the icon to launch iTunes was a chore?

You would have a drastically different (worse) overall user experience than what you’re probably used to, in spite of the application’s well-designed user experience. Software makers understand the impact that the context in which an application is served can have on the user experience that is actually experienced. Hence the ubiquitous “System Requirements” that helps to ensure that an application is being used in its prescribed context.

Clear Path to Information

A primary system task for users is retrieving information. How can we make it easier for users to get the information they need? Unfortunately, we almost always assume an intra-system perspective—one where the information that the user needs is accessible via the system and the user is already in the system. But what if we were to take a step back and look at the larger context in which the system is accessed? What we’d find are multiple usability hurdles between users and information. In fact, there are many hurdles between the users and the applications.< Let’s take a look at three key inter-system usability issues and how they can be addressed: # Viewport size – How much information can you view at a single time? # Authentication – Can you securely and easily log into your systems? # URLs – How easily can you get to your systems?

Even High Def is Low Def

Walk into any big box electronics store and you’ll see the ubiquitous wall of so-called high-def TVs. Great, stunning, crisp pictures – right? But if you were to compare the resolution of the world’s best hi-def TV to that of printed paper, the paper would easily win. The LCD technology that many hi-def TVs use is the same as that of our computer displays. We are constrained with limited information density.

Computer displays are the viewport though which the majority of communications between the user and computer occur. Because that channel is choked by relatively low resolution and small overall area, communication throughput is limited.
Alleviating this problem is easy – increase the display area. Either get a larger monitor or, better yet, get two larger monitors and use a virtual expanded desktop that spans both. Research has shown that users can complete tasks 10% – 44% quicker with larger screens and that multi-tasking was less, well, tasking.[1] With prices of large LCD monitors drastically dropping, you can have such a setup for under $500. The increased work efficiencies that you’ll gain can easily justify the relatively small upfront expense. In fact, usability guru Jakob Nielsen states, “anyone who makes at least $50,000 per year ought to have at least 1600×1200 screen resolution.”[2]

When More Secure is Less Secure

Everyone logs into applications in the workplace. Whether you’re submitting an expense report, entering worked hours, or just logging into an intranet, you have to authenticate yourself as a valid user. The integrity of authentication lies primarily with password policies that govern password complexity and required frequency of change.

A good password is one that cannot be guessed. And there within lies the problem. What is difficult to guess is most likely difficult to remember. This problem is mulitplied when you have many applications that require authentication, each with its own password policy that dictates password complexity and mandatory resetting. So while a hacker may not be able to guess your passwords, you most likely will not be able to remember them either. So what do you do? Do what everyone else does (but knows they shouldn’t) – write your passwords down on the small piece of paper in your desk drawer. Not exactly the most secure practice.

The problem here is that the security folks design their password policies in a theoretical world where they only consider computers and hackers. Make the passwords very strong. But the primary end users, the people who actually log in appropriately, are not considered. The ultimate result is systems that are less secure. People are people. Defining password policies without considering the complete human context in which they are applied results in lower security.

As usability experts we should prescribe password management utilities. Password management utilities lock all your credentials to multiple applications under one master credential. The master credential is often a master password or a fingerprint scan. Once you have authenticated yourself with the master credential, the password management utility can then submit the individual credential to the respective applications as you access them. Since you no longer have to remember each password, you can realistically use tough-to-hack passwords for each application. Because you only have to remember a single master password, you can be realistically expected to use a strong master password.

Do You Speak URL?

It’s not uncommon to have a dozen websites that you need to access in the workplace. You need to go to one website to track your work hours, another for expenses, another for benefits enrollment, and yet another to log help desk tickets. Just arriving at these websites is often a challenge in-of-itself because each has its own long, cryptic URL. This is especially the case with internally deployed applications where the URL may include the server name, port number and even URL parameters.

A URL for an internally deployed PeopleSoft application such as http://psoft-production.hostinghub.companyname.net:8080/asp/ASPPROD/?cmd=login is not uncommon. Using your browser’s “favorites/bookmark” functionality can alleviate the problem, but that still places unnecessary burden on the users to bookmark each website and organize them. Even if the websites are bookmarked well, each time the user has to access a website, he must open his bookmarks, browse, find, and click.

Fortunately, there is an easy to implement solution that addresses the problem. URL “jumpwords” are words that you can type into your browser address bar that take you directly to a website. Think AOL “keywords,” but more persistent because they are integrated directly into existing browser functionality. So rather than having to bookmark http://psoft-production.hostinghub.companyname.net:8080/asp/ASPPROD/?cmd=login to access your Peoplesoft application, you would be able to just type “peoplesoft” in the address bar and you would be taken to the application.

Catching and rerouting the user can only work within an organization’s network (this does not work across the Web in general for obvious reasons). There are two main steps to set it up. First, you must make an internal DNS entry that catches and routes all jumpwords. All jumpwords are routed to a single, simple application page that maps the jumpword to the specific full URL and then bounces the user to that URL. You’ve then literally brought your organization’s websites to employee’s finger tips.

Big Picture Ease-of-Use

Whether designing a user interface or conducting a usability test, we generally assume that the user has already accessed the system in a predefined context. Take a step back and apply ease-of-use fundamentals to the factors that lie immediately outside of individual applications. By keeping our eyes open for opportunities to improve the user experience in a larger context, we can increase the communication efficiency within organizations and use simple solutions to reduce frustration and confusion of the people using the systems.

1.”Meet the Life Hackers”:http://www.nytimes.com/2005/10/16/magazine/16guru.html?ei=5090&en=c8985a80d74cefc1&ex=1287115200&partner=rssuserland&emc=rss&pagewanted=print New York Times Magazine, October 16, 2005
2. “Jakob Nielsen’s Alertbox”:http://www.useit.com/alertbox/screen_resolution.html , July 31, 2006