It is an honest question: how smart are your users? The answer may surprise you: it doesn’t matter. They can be geniuses or morons, but if you don’t engage their intelligence, you can’t depend on their brain power.

Far more important than their IQ (which is a questionable measure in any case) is their Effective Intelligence: the fraction of their intelligence they can (or are motivated to) apply to a task.

Take, for example, a good driver. They are a worse driver when texting or when drunk. (We don’t want to think about the drunk driver who is texting.) An extreme example you say? Perhaps, but only by degree. A person who wins a game of Scrabble one evening may be late for work because they forgot to set their alarm clock. How could the same person make such a dumb mistake? Call it concentration, or focus, we use more of our brain when engaged and need support when we are distracted.

So, what does a S.T.U.P.I.D. user look like?

Stressed

“Fear is the mind killer”, Frank Herbert wrote. Our minds are malleable and easily affected by their context. The effect of stress on the brain is well known, if not well understood. People under stress take less time to consider a decision thoroughly, and they choose from the options presented to them rather than consider alternatives. Stress is often due to social pressures. Car salespeople know to not let a customer consider an offer overnight, but pressure them to buy right away.

Tired

Tiredness is one of the largest causes of industrial and motor vehicle accidents. Interfaces used by tired people should take into account their lowered sense of self-awareness and number of details that the user is likely to miss. A classic example of an interface used by sleepy people, the iPhone alarm clock is typically set right before bed. Unfortunately, it doesn’t ring if the phone is set to vibrate, the default state for many people. When a user sets the alarm, it would be useful to override the vibrate feature, or at least remind them that it won’t ring.

Untrained

Training for enterprise applications is more often discussed then enacted. Users are thrown at an application with a manual and a Quick Reference Card. Applications that are not designed around the user’s workflow have to explain their conceptual model while they are being used: “where” things are stored, how to make changes, who to send things to.

Complex systems that are used infrequently are a particular problem. In the design of the automated external defibrillator, it is assumed the user may have no knowledge of the science or training on the device, and will be using it in a chaotic, stressful environment. The frequency of use should drive design. Yearly processes, like doing your taxes, should assume that the users have never done it before. In rarely used interfaces, customization is likely to be less useful, but a comparison to previous year’s entries is very useful as they remind the user what they did before.

Passive

More important than the user’s mental model of an application is their mental attitude toward the task. Someone sitting in the front passenger seat of a car may have the same field of view as the driver, but unless they are focused on it, they will not remember the path driven. Nothing reduces effective intelligence faster than doing a boring task against one’s will. When a user is passive, complexity becomes insurmountable. Games aimed at casual gamers know to keep the interaction model simple, using a flat navigation and avoiding “modes” (e.g. edit vs view).

Independent

User centered design is a powerful approach because it recognizes that there are many reasons people use a system. Airline booking sites are used to buy tickets, but also to see if the family can afford to go on vacation. The designer should recognize that they cannot solve every problem, but should give users the tools to help themselves, to work independently of the application’s intended method. In internal enterprise systems, the top user request is often “export to Excel”. This often reflects that the system does not meet the user’s needs. Excel empowers the user to do ‘out of the box’ actions. It is the API to the real world.

Distracted

People are multi-tasking more than ever, whether it is simply listening to music while driving or playing Farmville while watching TV. Effective multi-tasking has been shown to be a myth, but it is a popular one. Paying “partial attention” to multiple activities has significant impact to your perception of an interface. Users are often said to be on “autopilot”, clicking on things by shape, rather than reading the text. An interface cannot rely on the user having a clear and consistent working memory across multiple screens. The task and details must be re-stated at each step to remind the user the step they are on and what they need to do. Frequent, automatic saving of user entered data is essential, especially as connections can time out.

Help S.T.U.P.I.D. users by designing S.M.A.R.T.

Start-ups often experience a shock when they emerge from the hothouse of heads-down development. Their intended customers barely have time to listen to their idea, let alone devote time to explore its features. The contrast between a small group of friends working intensely together on a single project with the varied needs and limited free time of their customers can be a disheartening experience.

Projects often fail not because the idea is bad, but because the value their service will provide is not easily understood. The question I ask my team is “What problem, from the user’s point of view, are you solving?” It has to be a problem the user knows they have. If the problem is not obvious to the user, in terms they understand, the solution doesn’t matter. Focusing on the problem keeps a project from drifting into fantasy requirements: solutions looking for a problem.

Design teams often use themselves as model users, but they are almost the perfect storm of differences between themselves and the users.

• They know the product exists and what it is supposed to do.
• They understand the internal concept, including its past and future ideas.
• They care, personally, about the product. Their success depends on it.

The user has none of these things. The user knows nothing about the product, doesn’t understand the concept, and doesn’t care.

What can be done to make S.T.U.P.I.D. users S.M.A.R.T?

Simplify

Why are simple apps popular these days? It is not that people don’t like features, it’s because instant comprehensibility trumps powerful features. In the old search engine wars, Google may have had a better search algorithm, but they became known for having a simpler design. Yahoo and others tried to become portals, losing sight of the users primary goal. I advise people to “Design the mobile version first” to help them focus on the key user benefits.

The down side is that any successful project expands and adds features to address additional user needs. What starts out as “Writer for iPad” can end up as Microsoft Word. Simple is not always better, but keeping the new user in mind helps find the right balance.

Memorable

An app is only as good as the user understands it. That starts with the name – is it cute or does it explain what it does? Is it “pidg.in” or “Automatic Mailbox”? The iPhone / iPad apps’s television ads were effective sales tools, but also trained a generation by simply showing them in use. Each step of a workflow is subject to delays and distractions. Ecommerce sites know to reduce links during the final checkout process. With complex transactions, the risk is greater that the user will have lost their focus. Remind the user what they are doing in big title text. Focus on delivering Clear and Consistent messaging and instructions, for example, adding side notes like Ally.com’s password guidance.

Accept Autopilot

Standard design patterns are good, but they also throw the user into autopilot. It makes sense to break them for critical decisions. The hard part is determining what a critical decision point is. Observing user behavior, customer service records, and identifying risks to the user’s data are good clues. If something is simple enough that the users are mostly on autopilot, for example installing software, make the default action a single click.

Recovery

The dark side of users on “autopilot” is that they will regularly make mistakes by not paying attention. Mistakes are generally not obvious to a system, but it is good practice to highlight destructive actions and enable recovery. Capture data in little steps. Saving form fields instead of form pages, prevents large data loss. It’s a good idea to highlight and ask for confirmation on big, destructive changes, like deleting a database. “Undo”, common on computers, but slow to come to the web, enables the user to recover from errors.

Gmail lets users undo moving a message to the trash.

Gmail also let you restore your contacts if you accidentally make a large, destructive change.

Test in realistic situations

There is an essential flaw in the two-way mirror usability test method. In the interest of copying the form of the lab-coated scientist, these rooms create an artificial aura of “science”. But as ethnographic research can tell you, real world usage is so different as to make the test questionable. It selects for a test population that is free in the middle of the day, motivated by $50, and M&Ms, puts them in an unfamiliar environment with a personal guide to focus on a specific task with no distractions. This is about as unrealistic as it gets.

In reality, the same person may have a child on their lap and only 10 minutes to look up a flight. The fact that an ecommerce session may expire after a few hours is trivial for some, but significant for people who only have a few hours a day to use the computer. “Universal Design” is a great approach, because methods to help specific disabilities tend to be useful to the general public.

Testing should go beyond the user interface and cover the basic business model. The Apple iTunes video download “rental” is for 24 hours. Unfortunately, people tend to watch movies at the same time each day, for example, after the kids go to bed. If your kids wake up, you have to finish it earlier the next day. Would it have killed them to make the rental 27 hours, so parents could actually use it?

Design for the right level of Effective Intelligence

Effective intelligence obviously varies across situations. People are ingenious at figuring out things they really want, but the simplest task is insurmountable to the unmotivated. Both scenarios are solvable, but an application that makes the wrong assumptions about its users will fail. (Interestingly, this study suggests that easier-to-use design can affect the user’s perception of difficulty, and encourage them to complete the task.)

One should adapt their strategy to the user’s desire and the problem’s complexity. Here’s an unscientific matrix for effective intelligence with software interfaces.

This matrix compares the amount a user desires to complete the task versus the complexity of the task to that user type. Different user types will have different measures of complexity, so one might create several matrices.

Low Desire, Low Complexity – The goal here is to finish these tasks as fast as possible. Follow standard design conventions, seek to eliminate steps.

Low Desire, High Complexity Complex – Tasks that the user doesn’t want to do are a danger zone. Can the problem be reconsidered or eliminated?

High Desire, Low Complexity – The easiest quadrant.

High Desire, High Complexity – This is the most interesting quadrant. A self-training interface, (integrated help, training modules) can get the user started; they will often take it the rest of the way. Video games often have a “training” level to train the user on basic skills like moving around.

Get Smart

Effective Intelligence is a helpful concept in the design toolbox. User research and testing are the best ways to know your users, but knowing what may limit a user in reality helps design ways to make them smarter.

Like this article? Want to keep Stephen’s wisdom close at hand? Download the handy, cubicle-friendly, 61kb PDF to hang on a nearby wall and you’ll always remember to design SMART.

Expertise significantly impacts how we seek information online. Just as novice and expert photographers prefer different tools, so novices and experts behave differently when searching for information. Understanding these differences will help us design better search interfaces for both groups of users.

h2. There are experts, and then there are experts

User expertise exists on two levels. If you’re an avid photographer, your domain expertise in photography will be quite high: that is, you’ll be familiar with the terms and techniques of the trade. Each of us is likely a domain expert in a few areas, and a complete novice in others. A second aspect is technical expertise. Familiarity with how computers, the internet, and search engines work significantly impacts how users seek information. Consider these personifications of each quadrant of expertise:

* *Angela Baer*, since completing her MFA at Pratt 5 years ago, is quickly building a reputation as one of New York’s up-and-coming fashion photographers. In the office connected to her studio, Angela edits her photographs on two large monitors and top-end computer. She delivers the edited shoots electronically to her clients, and regularly updates her online portfolio and blog. Angela is highly proficient using her computer, and when it comes to photography, she’s a domain expert.

* Though officially retiring over 10 years ago after a successful career in banking, *William Hayes* still sits on the board of a number of financial institutions. From his Elizabethan cottage on the Kent coast, he uses a 5-year old computer to exchange emails and access financial reports, though he prefers doing business on the phone and keeping up with the world though The Financial Times. While William is a domain expert when it comes to finance, his technical expertise is lacking.

* 18-year-old *Fane Tomescu* helps run an internet cafe in Braşov, Romania. Having saved for over a year, Fane recently came across a car that he’s considering purchasing. But when the time came to arrange car insurance, Fane had no clue how things worked. He asked his parents and friends for advice, and then spent several hours comparing providers online. Fane is a technical expert, but when it comes to insurance, he’s a domain novice.

* *Claire Jones* is a 9-year-old from Colorado Springs. Her school is holding a science fair and Claire has decided to build a model of the solar system using styrofoam balls suspended with string. Having left her science textbook in her locker over the weekend she was meant to start building the model, Claire used the internet to lookup information on the order, size, and appearance of each planet. Though she did eventually find what she was looking for (with her parents help), Claire would be considered both a technical and a domain novice.

While either dimension of expertise is valuable, users are most likely to succeed when both are present. There are, however, a number of design guidelines which can help both novices and experts succeed in their pursuit of knowledge.

h2. Novices Orienteer

Image 2: An orienteer at the 2010 World Orienteering Championships in Trondheim, Norway. Photo by Torben Utzon.

Wayfinding is a challenge as old as humankind, but the discipline of orienteering originated in the Swedish military in the 1800s and is now a sport practiced throughout Scandinavia. Equipped with a map and compass, participants navigate between control points spread across many miles, making tradeoffs between distance and difficult terrain as they strive to complete the course in the shortest amount of time.

The strategies employed by novice users seeking information resemble the sport of orienteering. [1] Users with low levels of domain and technical expertise, typified by Claire Jones, share three main characteristics.

h4. Short queries

Novices tend to enter queries that use about half as many words as experts.[2] Domain novices (like both Claire and Fane Tomescu), feel particularly unsure of which terms to use.

h4. Many queries

Novices perform more queries than experts, but look at fewer documents. Although they frequently reformulate their query, technical novices often suffer from an anchoring bias [3] and make only small, inconsequential changes.

h4. Going back

Novices are much more likely than experts to hit dead ends and seek to get back to a previous state.

These behaviours result in an orienteering-like strategy where novices “test the waters” with a short, general query, quickly skim the top results returned, and immediately reformulate the query based on their improved knowledge of the subject. [4]

h2. Design considerations for Novices

There are a number of design considerations which can help novice users succeed at orienteering. In particular, novices need help formulating their query, refining their query, and backing out of trouble.

h4. Autosuggest

As-you-type suggestions can help users get off on the right foot when they’re uncertain what to search for. Research has shown [3] that users are more capable of choosing a viable option from a list than they are of composing a question out of thin air. Autosuggest provides an opportunity to help users express specific terms (such as airports or stocks), and to suggest queries that other users have performed in the past.


Image 3: Autosuggest on Etsy.com

h4. Related searches

After users have performed an initial search, they may still need help refining the query. A list of related searches can help the user break out of their anchoring bias and help them arrive at the optimal set of results.


Image 4: Foodily.com place related searches on the same line as breadcrumbs

h4. Avoid zero results

If the user is presented with no search results, he may be disheartened enough to give up his quest. Avoid zero-result screens if possible. Tools such as automatic spelling corrections and query expansion (using synonyms and lemmatisation,[5] for instance) can help.


Image 5: Amazon.com’s handling of zero results

h4. Breadcrumbs

Because novices tend to take wrong turns, they often need help navigating back to a previous state. Breadcrumbs are an ideal solution because they communicate both the user’s current location, as well as how to go back.


Image 6: Breadcrumbs on Zappos.com

h2. Experts Teleport

Image 7: In Star Trek, crew members of the USS Enterprise stand on transporter platforms to be beamed down to a nearby planet.

While novices orienteer, experts teleport. Akin to being teleported to a precise but distant location, users with high domain and technical expertise like Angela Baer tend to jump directly to their final destination.

h4. Longer queries

Experts enter longer, more specific queries than novices. Domain experts like William Hayes often rely on their vocabulary of specific terminology, while technical experts such as Fane Tomescu are more likely than novices to use formatting techniques such as quotation marks in their queries (87% of experts compared with 47% of novices according to a 2000 study [1]).

h4. Fewer queries

Experts usually amend their queries less often than novices and move forward with a higher degree of confidence.

h4. More Documents Examined

Experts tend to review more documents and follow a greater number of links within those documents. Domain experts are especially adept at quickly determining whether or not a given document is useful.

In essence, experts often construct queries using numerous highly specific words which act to teleport [6] them directly to a destination, cutting out the query reformulation often practiced by novices. After having arrived at a destination, experts are then likely to explore the surrounding territory.

h2. Design considerations for Experts

Designing for experts involves facilitating their teleporting behaviour, helping them get to their destination as quickly as possible.

h4. Advanced syntax

Technical experts like Fane are often willing to learn special commands in exchange for having greater control. Commonly supported operators include AND, OR, and quotes for searching for exact phrases.


Image 8: Wolfram Alpha is designed to understand domain-specific terminology and return computed answers.

h4. Keyboard shortcuts

Keyboard shortcuts can also increase the speed of interaction. Google, for instance, allows users to press the up/down arrow keys on the keyboard to traverse results, and press return to go to the URL of the selected result.


Image 9: Google places a caret beside the currently-selected result.

h4. Filtering & sorting

Experts are more likely to engage with advanced sort and filtering controls than novices, including operations such as selecting ranges, filtering by format, or excluding certain terms (e.g. everything that includes “apples” but does not mention “oranges”).


Image 10: Getty Image’s Moodstream lets users search for stock photos using sliders.

h4. As-you-type results

As-you-type completion interfaces most often display query suggestions to users. However, another use case is to present actual results in the autocompletion interface, enabling users to skip the search results screen altogether and go directly to a specific document.


Image 11: Rather than suggesting terms to search for, Nutshell returns search results directly without needing to go to a separate page.

h4. Result table of contents

Providing links to the top destinations within a result can reduce the number of steps required for the expert to reach his destination.


Image 12: Google sometimes provides links to the top-level pages within a given site.

h2. Yin and Yang

While novices and experts practice two very different approaches to information seeking, it’s important not to overemphasis one at the expense of the other. As illustrated by the ancient Chinese symbol, understanding the behaviour of both novices and experts can help us design more informed, balanced search experiences.

The author would like to thank Cennydd Bowles for organising the UK writer’s retreat during which this article was written, as well as for the editorial guidance that he provided.

h4. References

[1] Vicki L. O’Day and Robin Jeffries; “Orienteering in an Information Landscape”:http://www.hpl.hp.com/techreports/92/HPL-92-127.pdf

[2] Christoph Hölscher & Gerhard Strube; “Web Search Behavior of Internet Experts and Newbies”:http://www9.org/w9cdrom/81/81.html

[3] Marti A Hearst; “Search User Interfaces”:http://searchuserinterfaces.com/book/sui_ch3_models_of_information_seeking.html#section_3.5

[4] Morten Hertzum and Erik Frokjaer; “Browsing and Querying in Online Documentation”:http://www.cparity.com/projects/AcmClassification/samples/230570.pdf

[5] Christopher D. Manning, Prabhakar Raghavan and Hinrich Schütze, “Introduction to Information Retrieval”:http://www.cambridge.org/us/knowledge/location/?site_locale=en_US , Cambridge University Press. 2008.

[6] Jaime Teevan, Christine Alvarado, Mark S. Ackerman and David R. Karger; “The Perfect Search Engine is Not Enough”:http://people.csail.mit.edu/teevan/work/publications/papers/chi04.pdf

Show Time: 33 minutes 42 seconds

Download mp3 (audio only)
Download m4a (with visuals, requires iTunes, Quicktime, or similar)

iTunes     Del.icio.us     Boxes and Arrows Podcast theme music generously provided by Bumper Tunes

Ireland’s Gerry McGovern shares a few of the key ideas in his recent publication The Stranger’s Long Neck – How to Deliver What Your Customers Really Want. Mr. McGovern, who will be teaching a Masterclass series in Canada on the importance of task management this November, discusses several of the key findings in his new book, including:

Trading with strangers

- The customer is a stranger. On the Web, the customer isn’t king—they’re dictator. When they come to your website, they have a small set of tasks (long neck) that really matter to them. If they can’t complete these top tasks quickly, they leave.
- There is an existential challenge going on right now between organization-centric and customer-centric thinking. Customer-centric thinking is winning.

From Long Tail to Dead Zone

- The Long Tail theory says that the Web allows you to sell more of less, that we are seeing the decline of the blockbuster and the rise of the niche.
- The Long Tail is often a Dead Zone of extremely low demand and hard to find, poor quality products.

The rise of the Long Neck

- The Web is exploding with quantity but quality is still relatively finite. Quality is the ‘long neck’; the small set of stuff that really matters to the customer.
- Understanding and managing the long neck has never been more important.
- Remember that the customer’s long neck—what really matters to the customer—is rarely the organization’s long neck —what really matters to the organization.

A secret method for understanding your customers

- A unique voting method that identifies your customers’ long neck.
- Developed over 10 years, with over 50,000 customers voting in multiple languages and countries.
- Used by the BBC, Tetra Pak, IKEA, Schlumberger, Wells Fargo, Microsoft, Cisco, OECD, Vanguard, Rolls-Royce, US Internal Revenue Service, etc.

Organization thinking versus customer thinking

- Case study that shows how car company managers think differently about how customers buy cars to how customers themselves think.
- Explanation of how to frame the task identification question.

Deliver what customers want—not what you want

- Case study of Microsoft Pinpoint, a website to help businesses find approved Microsoft IT vendors and consultants.
- What’s the top task of US small and medium businesses when it comes to IT? Security.

Measuring success: Back to basics

- Why traditional web metrics such as page views, number of visitors, etc., are often misleading
- Observation-based technique to measure online behaviour.
- The key metrics of task measurement: completion rate, disaster rate, completion time

Carrying out a task measurement

- The benefits of remote measurement
- How to run an actual measurement session

This podcast has been sponsored by:

Publishers of world class content for students, researchers, and practitioners in the UX and HCI fields. To learn more visit http://www.mkp.com/hci

From concepts to rich prototypes and detailed specifications, all in one tool. Get your free 30-day trial at www.axure.com


Boxes & Arrows: Since 2001, Boxes & Arrows has been a peer-written journal promoting contributors who want to provoke thinking, push limits, and teach a few things along the way.

Contribute as an editor or author, and get your ideas out there. boxesandarrows.com/about/participate

This case study shows how the ComputerWeekly user experience team integrated with an agile development group. It’s important to note the methods we used do not guarantee getting the job done. People make or break any project. Finding and retaining good people is the most important ingredient for success.

The brief

In 2008, we were tasked with resurrecting a tired, old, and ineffective site. It was badly out of date, and the information architecture was decrepit to both users and search engines.

Our goals were:

1. Make content visible and easy to find
2. Create an enjoyable and valuable user experience so users would return
3. Increase page impressions to bring in ad revenue
4. Allow site staff to present more rich media content
5. Give the site more personality and interactivity

The UX team created personas from ethnographic studies, online surveys, and in-depth interviews with users. The data gave us a clear idea of the user’s needs and wants. We also gleaned data from analytics that told us where users engaged and where the bounce rates were highest.

At this point the development team maintained the site with an agile process. They created features for the new site in parallel to ongoing site maintenance, but this work was outside the normal maintenance sprints. The new site was considered as an entirely new project with a separate budget and scheduled into longer term.

Boundary Spanner

As the User Experience team gathered data key team members were recruited. The diagram below shows the key team members needed to produce this large scale site, their specific concerns, and their methodologies.

To bring these teams and disparate elements together requires a launch manager or ‘boundary spanner’. Rizal Sebastian wrote about boundary spanners in Design Issues in 2005¹. The boundary spanner needs to be aware of the individual issues the project faces. He need not know the detail but needs to know the cultural context of the collaborative environment.

Do people get on with each other? Are communication lines clear? Are there any personality clashes on the team. To throw developers, interface designers, business analysts, SEO experts, and usability guys together and expect them all to gel is optimistic but unlikely. It also requires those people devote all their time to just one project and that is unrealistic for a large operation where several projects are underway simultaneously.

They are more than a project manager because the user— and not the project—is at the heart of their concerns. He is responsible for delivering and continually developing a quality product. He is not just monitoring the features on a checklist. The user is at the center of all decisions on the design and development of the site. This is the only way you can ensure the user will be heard throughout product development – to employ somebody who listens to user voices and never forgets what they said. They must also ensure that SEO and business requirements are satisfied, and a well-defined strategy is in place. The boundary spanner owns and clearly communicates the vision until the whole team understands.

The boundary spanner’s strength is that they are core to the product and not a department or team known for their skillset (like a UX team for example). In many cases it is a product manager, but in this case it was the website editor who was responsible for synchronizing the teams.

Defining a process

To assist this user focused approach, the IAs produced set of deliverables that ensured the launch manager’s vision could be realized and developed.

Diagramming the process using a concept model engaged key stakeholders with the project by communicating the vision of what the UX team would achieve with the speed and clarity of an elevator pitch.

Information gathering

A content audit revealed broken links, redundant content, and poor usability plagued the site. It also revealed how much content became lost the second it moved from the home page. The high value research papers were impossible to find.

30 interviews, 20 ethnographic studies, and 950 responses to an online survey. created six personas. With the content audit, personas, and business objectives (what we wanted them to do on our site), we began creating the taxonomy.

Analytics

During this project we were very fortunate to work alongside the web analytics manager who provided insight into user behavior, including high bounce rates from visitors arriving from search engines. He also provided a scorecard that showed where the site failed in terms of traffic and user engagement. We knew what users were searching for, and pretty quickly could tell why they were not finding content we knew we had.

By looking at web metrics we were understood usage patterns and popular and unpopular areas of the site. The depth of information enabled us to quickly formulate a plan.

Persona driven taxonomy

As we knew our user base were industry experts, we also knew their vocabulary was related to specific areas of their markets.

The taxonomy was created by gathering as many industry sources (websites, journals, white papers), breaking these down into unique elements, and clustering these elements together to form categories for our content.

The CW taxonomy formed the basis of the navigation, content categorization, and highlighted areas for future development. It also ensured our search results served up related content in context.

We defined four main areas by looking at the community of users.

News was an obvious requirement, defined by their particular area of interest within the sector. The need for knowledge was evident, and we created an in-depth research area where case studies and white papers could be easily accessed. Tools and services, RSS, email news alerts, and newsletters reflected user needs to be kept up to date and in tune with their specialization.

Finally, although the CW community was secretive and did not divulge information amongst their peers, they were very interested in expert opinions. This need gave rise to much more integrated blog postings.

Interface development

The navigation scheme defined the elements of the page the users would use to move to other areas in the site. It clarified the naming of those items on the page.

We then considered the prioritization of information and content for each page, and this facilitated the production of wireframes that represented the culmination of all research, showed the interface and interactions for elements on the page, and were a working document that changed as we iterated the design.

Core and Paths

We used Are Halland’s method for ‘designing findability inside out.’²

• Prioritize and design the core – Satisfy user goals using prioritized content and functionality.
• Design inward paths to the core – Consider how users will arrive at the page from search engine results, facets, menus, search, RSS, aggregation, email, etc.
• Offer relevant outward paths from the core – Ensure that the site delivers both user and business goals through clear calls to action and completion of interaction tasks.

For CW.com, we focused on the cores for the home page, a channel level homepage, and a news article page and looked at key content such as lead news story and the editor’s picks or the best from the web aggregated from external sources. The key functionality and supporting content also had to be included and prioritized on the page.

Next we considered the inward paths, which are the channels that our users are likely to utilize to arrive at the page.

Inward paths included search engines, blogs, bookmarks, syndication, aggregators, RSS, and email subscriptions. Considering inward paths helped us focus on the marketing channels we needed to drive users to the relevant type of page. It also focused on the keywords and themes that users are likely to use and helped us optimize pages for search and online marketing campaigns.

Finally we designed the outward paths that helped users complete online tasks for our business objectives.

These outward paths include:

• Newsletter sign-up
• Inline links to related articles to drive page consumption
• Sharing, printing or emailing of news articles
• Related content types such as video or audio
• Stimulating community participation in forums or blogs
• Contextual navigation to aggregated content or the editors best bets
• Subscription to an RSS feed
• Prioritizing the content



Once the wireframes had been approved, the content was organized so the most commercially valuable and user focused content was pushed to the top of the page. As the design went through user testing, certain elements changed, as with any iterative process, but through team collaboration, the solution remained true to the initial vision from concept to design delivery.

The development cycle

The wireframes were handed over to creative, and they began designing the interface and graphic elements. The development group released some functional elements to the old website before the relaunch.

These agile methods allowed the old site to feel the benefits of the new widgets. However, as the site changed so radically in the new design, we still had to release the site in an old style ‘big-bang’ manner. This is perhaps where agile has its problems as a methodology for new launches. It’s focus on many small releases is a great tool to implement incremental changes but not for a completely new site.

As the html flat pages were passed to the team, the SEO requirements were defined and built into the site. By the time the site launched it, had been through four major pieces of testing.

A holistic solution

Providing user experience deliverables like the concept map and wireframes ensured more comprehensive requirements were delivered to the design and development team. This approach addressed marketing, editorial, sales, and business requirements next to the needs and wants of the user. The vision was aligned with an achievable delivery from the IT team that ensured we delivered the site we wanted to give the user.

The core IA work enabled the new site to be future-focused and versatile. The structure and design of good sites should be able to adapt to change.

User-centered design and agile can work alongside each other but what is more important is having people who can tie all the loose strands of a website design and development cycle together. The concept map, wireframes and the IA strategy document that listed the rationale behind the design decisions helped ensure the product vision was correctly communicated to the development team, so the product that was developed through their agile processes was in line with the overall product vision.

¹http://www.mitpressjournals.org/doi/abs/10.1162/0747936053103020? cookieSet=1&journalCode=desi

²http://www.slideshare.net/aregh/core-and-paths-designing-findability-from-the-inside-and-out

Unfortunately, the enthusiasm I had for my new job waned after six months when an executive was appointed Head of Product Development — who insisted he knew SCRUM¹ better than anybody. As the Creative Director, I deferred authority to him to develop the product as he saw fit. I had worked with SCRUM before, done training with Ken Schwaber (author¹ and co-founder of the Agile Alliance) and knew a few things from experience about how to achieve some success integrating a design team within SCRUM. This required the design team to work a “Sprint” (month long iteration) ahead of the development team. But the new executive insisted that SCRUM had to be done by-the-book. Which meant, all activities had to be included within the same sprint, including design.

Requirements came from the imagination of the Head of Product Development; design was rushed and ill-conceived as a result of time pressure; development was equally rushed and hacked together, or worse, unfinished. The end of Sprint debriefing meetings reliably consisted of a dressing down of the entire team by the executives (since nobody had delivered what they’d committed to i.e. they had tried to do too much, or had not done enough). Each Sprint consisted of trying to fix the mess from the Sprint before or brushing it under the carpet and developing something unstable atop the code-garbage. Morale languished, the product stank, good staff began to leave… it was horrible.

This is an extreme example of where SCRUM went bad. I am not anti-Agile although I’ve been bitten a few times and feel trepidation when I hear someone singing its praises without having much experience with it. Over the last eight years, I’ve seen Agile badly implemented far more often than well (and yes, it can be done well, too). The result of this is mediocre product released in as much time as it would have taken a good team to release great product using a waterfall approach. In this article, I will describe Agile and attempt to illuminate a potential minefield for those who are swept up in the fervor of this development trend and want to jump in headlong. Then I will present how practices within User Centred Design (UCD) can mitigate the inherent risks of Agile and how these may be integrated within Agile development approaches.

Where did Agile come from?

Envisioned by a group of developers, Agile is an iterative development approach that takes small steps toward defining a product or service. At the end of each step, we have something built that we could release to the market if we choose to and therefore it can assure some speed to market where waterfall methods usually fail. Agile prefers to work out how to build something as we go, rather than do a waterfall style deep dive into specification and then finding out we can’t build parts of the spec for some reason e.g. a misjudgment of feasibility, misjudgment of time to build, or changing requirements.

A group of developers such as Kent Beck, Martin Fowler and Ken Schwaber got together to come up with a way to synthesize what they had discovered was the most effective ways to develop software – The Agile Alliance was born. It released a manifesto² to describe its tenets and how it differs from waterfall methods.

Agile can be thought of as a risk-management strategy. Often developers are approached directly by a client who does not know what a user experience designer, information architect or user interface designer is. Roles such as these usually interpret what clients want and translate it to some kind of specification for developers. Without this role, it’s down to the developer to work out and build what the customer wants. Because Agile requires a lot of engagement with the client (i.e. at the end of every iteration, which can be as little as a week) it mitigates the risk of going too far toward creating something the client doesn’t want. As such, it is a coping mechanism for a client’s shifting requirements during development as they begin to articulate what they want. To quote the Agile Manifesto’s principles “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Why do people rave about it?

At the heart of what makes Agile attractive is the possibility of quicker return on investment for development effort, because we can release software earlier than we would have otherwise. In the short term, this is typically borne out. In the long term it can be too, though only when the team hasn’t fallen victim to temptation (more on that later).  Agile is also good at generating momentum because the iterations act as a drumbeat to which the team marches toward manageable deadlines. The regular "push" to finish a sprint ensures that things move along swiftly. Agile is also good at avoiding feature bloat by encouraging developers to do only what is necessary to meet requirements.

Because it emphasizes face to face contact for a multidisciplinary team, Agile tends to encourage contribution from different perspectives. This is generally a positive influence on, pragmatism, innovation and speed of issue resolution. The team is empowered to make decisions as to how requirements should best be met.

The Minefield

In of itself, Agile does a good job of flexing to the winds of change. But one has to ask whether it was devised to treat a symptom of the larger cause: the business doesn’t know what it wants. While Agile enables the development team to better cope with this, it doesn’t solve the problem and in most cases creates new problems.

Mine 1: An unclear role for design

In the best cases of business approaching developers to build some software, some of those developers may have design skills. But that’s not a particularly common scenario. Many developers have also had bad experiences with designers who don’t know what they’re doing. It took a long time for the design profession to come to grips with designing for complex systems and there is still a deficit of expertise in this field. “Business people and developers must work together daily throughout the project” is another principle of Agile. Where does the designer fit into the frame?

Mine 2: The requirements gathering process is not defined

Agile accommodates design activities from the perspective of a developer. It tends to shoe-horn these activities into their view of the world where requirements fall from the sky (from the business or customer who is assumed to be all-knowing) and takes for granted that they are appropriate.

According to Ken Schwaber, SCRUM intends to be a holistic management methodology and leaves space for activities other than programming to occur within the framework of iterative cycles. But when organizations adopt SCRUM, too often the good parts of a waterfall process like research and forming a high-level blueprint for the overall design become the proverbial baby thrown out with the documentation bathwater. As the Agile Manifesto says, “Working software over comprehensive documentation.”² Many latch onto this and don’t want to do any type of documentation that might outline a vision, even if in a rudimentary sense.

Mine 3: Pressure to cut corners

Implementations of Agile that put design activities within the same iteration as they must be developed, ensure designs are achievable in code. But they also put tremendous pressure on the experience design team to ‘feed the development machine’ in time enough for them to implement their vision. This can and does lead to impulsive design. So, what’s wrong with that? Well, nothing if you’re not adhering to user centric principles which suggest you should test ideas with end users before committing them to code.

Some assert that there are plenty of examples of best-practice interfaces to copy out there. So, why reinvent the wheel? Surely we can save time that way? Sometimes they’re right, but how will we know which best-practice interface works best in context with the user’s goals, with no time to test with the user? How can we innovate by copying what already exists? Before Google reinvented internet search, other search engines assumed a status quo which behooved the user to learn how to form proper search queries. It was institutional knowledge among the other search engines that this is how searching was done and customers simply had to learn to use it. Most people’s search results were poor at best. Then Google came along and realized what is now obvious. People just want to find what they’re looking for, not learn how to drive a search engine first. I’m not suggesting the other search engines could not have done what Google did sooner, but I am pointing the finger at a mentality which meant they missed the opportunity. Interestingly, Google is not known for its designers. It’s mainly a development house, but lots of those developers can clearly put a design hat on too.

There is absolutely nothing wrong with using Agile to produce results quickly; that is, if you don’t intend to release them on your poor, unsuspecting user without some usability testing. Just don’t be fooled that this is going to save you a lot of time if you want your new product to be right, because you will have to iterate to arrive at an appropriate solution. Alan Cooper has argued that this creates a kind of ‘scar tissue’ where code that has to be changed or modified leaves a ‘scar’ that makes the foundations of the program unsound.⁴

Mine 4: The temptation to call it “good enough”

Invariably when we have release-ready working code at the end of each cycle, even if it’s sub-optimal, there’s a strong temptation to release it because we can. Agile condones releasing whatever we have so long as it works. Sometimes, that means doing what we can get away with, not what is ultimately best for the user. Equally, if we do decide that a feature isn’t right yet, it’s amendments get fed back into the requirements backlog where temptation strikes again. Should we spend time in our next iteration on a feature that we’ve already got a version of? Or shall we develop something new instead? Too often, the rework gets left in favor of exciting new stuff. An so on we go building a product full of features that don’t quite meet the bar.

Mine 5: Insufficient risk-free conceptual exploration time

Iteration “zero” (i.e. a planning and design iteration prior to the first development iteration) can be used to do this and other planning activities. However, depending on how long this iteration is, the level of rigor applied to exploration may be insufficient. An argument used by some Agile practitioners asserts that a working example of a solution is the best way to validate whether it is the right one through exposure to the market. This ‘suck it and see’ approach bypasses an activity called “concepting.” Concept activities dedicate time to sketching different solutions at a high level and validating them in the rough with users before digging into detailed design or code. “Suck it and see” would have us just build it, launch it and see if it flies. This way, we’ve wasted time building something we will probably have to take apart or rebuild. The counter argument is: if it took as long to build as it would have to research and design before laying a line of code, then we break even. This statement is a stretch in practice because development itself usually does take longer than well-managed design research and conceptual exploration. Also, there has to be some level of design regardless  of which methodology is used, and this adds days to the timeline.

Mine 6: Brand Damage

Let’s just say that design and research takes the same amount of time as development for argument’s sake. In the worst case, we completely miss the mark with the non-researched and designed solution and we have to start all over again. Then we’re back to the same total duration after developing it a second time, but there’s no guarantee we’ll get the solution right the second time either. All the while we’ve repeatedly foisted a botched product design on our users and adversely affected our brand. Many companies succeed on the back of their reputation for producing consistently appropriate products and services. When a company releases a flawed product or service, then their image in the customers mind (i.e. brand) is tarnished. Brand damage takes far longer to mend than it does to make. Software creators that fall victim to the temptation of "good enough" and fail to innovate through conceptual exploration put their companies revenues at risk. In a competitive market, repeated failure to meet user needs well leads to serious brand and subsequently financial repercussions, as other companies who do get it right take the business.

Agile is good for refining, not defining.

If you have an existing product that you want to develop to the next level, then Agile in its truest sense works because you have a base upon which to improve. This means that if you know what your requirements are and these have been properly informed with user research, comparative analysis, business objectives, and analysis of what content you have and what you can technically achieve, then Agile alone can work well.

But spending money on software development without a plan of what to build is like asking a construction crew to erect a tower with no blueprint. Some level of plan is necessary to avoid a Frankenstein of each individual’s perspective on the best design solution.

User Centered Design

UCD requires iteration – design, test with users, refine, test with users again, refine… repeat till it’s right. This is where Agile and UCD can work brilliantly together. Agile really is about presuming you’ll need to change things, and that’s a good thing when it comes to refinement.

Uncovering requirements to form a strategy

User Centered Design (UCD) is not about answering requirements alone, but also includes defining requirements. When we practice UCD end-to-end, we pretend we know little. Little about what the solution to a problem should be; little about what the problem actually is because assumptions close us off to new possibilities. We prefer to allow some design research to create a viewpoint and then form a hypothesis as to what we might build. In this regard, we cross into the realm of product managers, producers, program managers, business analysts and the like, trampling toes with gay abandon and meeting resistance all around. Facing confinement to defining the boring old business need (distinct from the user or customer need), these folks would prefer we constrain our UCD work to usability testing on designs meeting the requirements they set out. They’d prefer we stick to just helping with development… and if we can do that quicker using Agile? Wahey!

Is it always appropriate to do extensive research before starting design? That’s a good question and one that Jared Spool’s Market Maturity Framework⁵ helps answer. Sometimes, just getting something off the ground, regardless of how precisely we meet user’s needs with it is all we can afford to do. Once we graduate out of this "Raw Iron" stage into "Checklist Battles" focused on getting the right features and then beyond, research is a core ingredient to putting our feet in the right place.

After researching what the user and business requires, we can make the “Strategy” tier of Jesse James Garret’s Elements of User Experience³which underpins everything we do during the project. Do this well, and you really shouldn’t come up with something that’s fundamentally wrong. Agile doesn’t account for this beyond a planning phase (i.e. iteration zero), which may well define a strategy of sorts. But does it really define the correct strategy? Surely, that’s created through careful consideration of three things:

1. Empathetic qualitative research that uncovers the user’s context, needs, goals and attitudes i.e. user requirements. Cooper suggests that the customer doesn’t know what they want and advocates a role of interaction designer as requirements planner.⁴ This would avert building to the wrong requirements in the first place, but the time to do this must come into the development lifecycle somewhere. It involves talking to users, preferably visiting with them in their environments to create experience models and user personas.
2. A thorough appreciation of what else in the big wide world exists in terms of products, features and technology that can be emulated somehow (not necessarily addressing a similar situation to ours).
3. A clear articulation of the business problem, objectives, success measures and constraints. Business people sat in a room discussing what they think should be done must be informed by all these things if the right strategy is to emerge. Agile doesn’t preclude that kind of consideration, but it does not mandate it either.

Concept Development

If we manage to built something usable and reasonably intuitive without research or strategy, did we succeed? Most MP3 players fit this bill but none took off like the Apple iPod. Leaving interface usability aside, the iPod had a service concept behind it which included digitizing, replenishing and managing your entire music library with iTunes. This was part of the iPod concept from the outset and in combination with good marketing and design, continues to eclipse the competition over seven years later. But that concept needed to be sketched and iterated at some point. If we don’t explicitly build this into our Agile methodology, we can miss that thinking time.

The best of both worlds

UCD can be too documentation-heavy, isolated and risky but Agile needs help with defining requirements and concept development. How can Agile and user centric principles work together? First let’s understand what works well with Agile and not so well with user centered design. In this regard, the work that user centered design calls the ‘design’ phase can produce buckets of documentation which isn’t read, describing interfaces specified in isolation which may not be feasibly coded in the time allotted to them. So, doing detailed design is best done in conjunction with the development team and in a way where resulting interfaces can be tweaked as you go. 

A shared vision of the interaction fundamentals

In good software development, a conceptual interaction model that has been thought through beforehand, outlines how the user navigates the system, performs tasks and uses tools in generic terms, i.e. not each and every navigation label, task or tool but rather the interface and interaction patterns that will persist. This produces something rudimentary to test with users to see if we got the big picture right. Following this roadmap sketched on the back of research and concepting prior to development activity, ensures consistency and cohesiveness when each component is coded separately to each other later. In many cases, the concept will need iterating to accommodate lessons from the journey. But we’ll at least have some indication of direction at a macro scale. Then, when in the midst of Agile iterations working out the details alongside our developer brethren, a level of expertise and experience is required of the designer because what we design will be built before we’ve had a chance to second-guess ourselves. Domain knowledge and an understanding of interface paradigms that work is also a big help. But to build new projects from scratch without a shared vision is a mistake.

Risky interfaces that are new or significant improvements on what has been seen before, are best tackled as design-only activities in a sprint prior to when they will be developed (i.e. do involve developers, don’t try to produce code). This circumvents the pressure to deliver something before proper thought, reflection and user testing, which ensures you’re not wasting time and effort. Sometimes most of the product will be done this way and that’s fine so long as developers and designers are still working together and talking every day. The first development iterations are an important time for the developers to lay the architectural foundations based on the vision. Designers should use this time to get a jump on any high-priority tricky interfaces so the development team isn’t waiting for something meaty to start on when it comes time to build features.

Most important to success, the business needs to accept that some things won’t be right the first time around and commit to iterating them prior to release i.e. not be led into the temptation to release something that’s not right yet.

Conclusion

In summary, dogmatic attitudes about each of these approaches should be avoided if they are to be combined. Remember, Agile does not mandate how to define concepts or overall design direction, but it is a great way to execute on solid design research and well laid plans. UCD needs to be flexible enough to respond to the reality on the ground when the implementation team encounters issues that mandate a different design solution. Document only what is needed to get the message across and co-locate if at all possible, because cross-disciplinary collaboration and face to face communication are vital. Working a sprint ahead of the development team is helpful in allowing the design team enough time to test and iterate. If these rules of engagement are followed, the two approaches can work very well together.

Notes:
1. Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle

2. Manifesto for Agile Software Development

3. The Elements of User Experience by Jesse James Garrett

4. Extreme Programming Vs. Interaction Design. Interview with Kent Beck and Alan Cooper

5. The Market Maturity Framework is Still Important – Jared Spool

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 collaboration¹ 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

Definition

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:

Figure 1. The basic components of collaboration

Artifacts

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.

Team

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.

Tasks

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?

Calendar

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.

Actions

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

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 collaboration². 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

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.

Zoho

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.

Microsoft

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 primitive³. 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.

Conclusion

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?

Footnotes

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.

Noted scholar on democracy James Banks simplifies its definition: democracy means rule by the people.¹ Philosopher and pragmatist John Dewey, however, interprets democracy more deeply as a way of living together as well as a kind of government.² 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.”³ 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.”⁴ 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.⁵

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.⁶ 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.⁷ They use the site in a traditional “one-way” fashion. Based on statistics which mirror Zipf’s law,⁸ 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.”¹⁰ 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.

Reflection

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.¹¹ It is reflection we undertake conscientiously that makes us good IAs, good designers…and good citizens.

References

[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.

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

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…

Affordance
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.

Orientation
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.

Chunking
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.

Wayfinding
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.

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.

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.

Security

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.

Headers

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

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.

Summary

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.

References

• “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