Focus groups might appear to be a convenient, time-saving way to get feedback from eight or ten people in a single session. In practice, however, the technique is not particularly reliable. Watching a demonstration is not the same as having the opportunity to interact with the product hands-on. And group dynamics can vary widely; different groups can come up with completely different conclusions.

Focus group discussions often tend to be dominated by one or two loud and opinionated participants, and the quieter participants often say little and go along with the group consensus. There is also the risk that the facilitator may consciously or unconsciously lead the discussion towards a particular outcome. If you choose to use focus groups, you should use them with caution and be aware of the limitations.

To create an ergonomically sound software application, it is important to first think about the properties and the context of use of the hardware device on which the application will run. For the majority of consumer and business applications, there are currently three main forms of general-purpose personal computing devices:

• Desktop and laptop computers with a screen, keyboard, and a pointing device such as a mouse or trackpad, are comfortable for users sitting at a desk for a long period of time.
• Tablet devices with touchscreens have a form factor that is comfortable for sitting and consuming content (reading webpages, watching movies, etc.), but entering information and creating content via touch-screen control is generally not as comfortable and convenient as with a desktop machine.
• Mobile phones (and similar devices such as portable music players) are usually used for short bursts of activity while on the go.

For more specialized applications, you might have a combination of software and custom-designed, special-purpose hardware. Examples include a machine that sells subway tickets, an automated teller machine, or an industrial thermostat control. If you are a designer for such a product, you may have responsibility for designing the form of the physical interface in addition to the software.

To give you an idea of some of the practical ergonomic aspects that you should keep in mind when designing for different devices, let’s compare desktop computers with touchscreen tablets:

• Tablet devices with multi-touch touchscreens are pleasant and fun to use from an interaction standpoint because you can interact directly with on-screen elements by touching them with your finger. Desktop machines (as of this writing) generally don’t offer touchscreens, as reaching your arm out to the monitor places strain on the arm and shoulder muscles and would quickly become physically tiring. Desktop setups thus rely on pointing devices such the mouse or trackpads. These pointing devices introduce a level of indirection, however: moving the pointing device moves a cursor on the screen.

• On desktop systems, there is a pointing device cursor (mouse arrow), whereas touchscreen devices have no such cursor. Some mouse gestures, like hovering the cursor over a control, thus have no counterpart in touchscreen systems. On both desktop and touchscreen systems, however, a text cursor (caret) appears when a text field receives the focus.

• While a mouse may have multiple buttons, and clicks can be combined with holding down modifier keys (Control/Alt/Command/Shift), touchscreens don’t offer as many options. When you drag your finger across the screen, is it to be interpreted as a scrolling gesture, or an attempt to drag and drop an object on the screen? Cut-and-paste and right-clicking to get a context menu are easy on a desktop machine, but on a tablet, such operations require double-touch or touch-and-hold gestures that are not always evident.

• Fingers range in size substantially; young children have small, narrow fingertips, whereas some men have very thick, fat fingers. Touchscreen buttons and icons thus must be large enough to accommodate “blunt” presses without triggering other nearby controls. In contrast, the mouse arrow allows pixel-precise pointing, and so buttons and icons can be substantially smaller on desktop applications than on touchscreen devices.

• When the user is touching something on the screen, the user’s finger and hand will obscure part of the screen, so you have to be careful about what you display and where, so that important information is not hidden. When pressing an on-screen button, the user’s fingertip will obscure the button being pressed. Because button presses don’t always “register”, users seek visual feedback to see that the button press worked, and so you either need to make the buttons large enough so that the animation of the button being depressed is visible, or you should give some other clue when the user retracts the finger to show that the button was pressed (maybe pressing a Next button makes the application navigate to the next screen, which is very clear feedback that the button press was successful). Auditory feedback, like a clicking sound, can also be useful as a cue that the button was pressed successfully.

• Mobile devices and tablet devices are often held by the user in one hand while standing, and so the user has only the other hand free to operate the touchscreen.

When designing a product, understanding the constraints and limitations, as well as the opportunities, of the hardware devices the software will run on will help you design appropriate and comfortable interactions.

• Functional requirements are the features your product will have, in terms of the functions, actions, and behavior it will support. For example, some functional requirements for a word processor would be that it support bold and italic type, that it allow documents to be printed, and that it allows images to be embedded in documents.

• Non-functional requirements are performance or quality constraints that are general or “cross-cutting” in nature. Non-functional requirements address areas such as performance, security, stability, capacity, and scalability. For example, an e-commerce website might be required to serve 100,000 users concurrently and provide a response time of 2.0 seconds or less.

The scope of your product and project is defined by the set of requirements that need to be implemented. Without careful management, additional wishes and demands will continually be added to the project’s scope. This phenomenon, known as scope creep, will threaten your ability to deliver on schedule.

Requirements should be stated in concrete, measurable terms whenever possible. For example, rather than stating that “the product must be easy to learn”, which is subjective and unprovable, you might consider a phrasing that lends itself to objective testing, such as “95 percent of users will be able to successfully process a standard passport application after the two-day training session”.

Some requirements are “definitional”: they result from, and form part of, your definition of what the purpose and market positioning of your product is. Other requirements need to be elicited from your users and other stakeholders.

Because usability problems tend to emerge when key issues like navigation, workflow, and transactions haven’t been thought all the way through, it is worthwhile spending time on thinking about these issues and explicitly designing and evaluating solutions.

Not everything can or should be decided at the very beginning; preliminary decisions will often have to be made which can then be changed or refined as the project goes on. However, some fundamental things are very hard to change once product development is in full swing, and so these things — what we might call the architectural design — should receive special attention early on in the project.

It is possible to describe an interaction concept in a formal specification document, and for large teams building large products, this can be a reasonable approach for recording and communicating the design to team members. But creating a formal deliverable is not the point, and nor is it the only way to document and communicate design decisions. Writing a specification is good if it forces the team to think through and decide on key issues, but a formal document can be difficult to write because many things, like the visual design, are very difficult to specify completely and accurately in writing.

A more agile approach that tends to be more successful is prototyping, in combination with some minimal, agile documentation. Prototyping can be a very effective way of trying out different design ideas and getting feedback through peer reviews and usability testing. A prototype alone cannot capture and communicate all of the design decisions and rationale, though, so lightweight written records can be used to supplement it.

What kinds of issues make up the interaction concept?

• A choice of one or more interaction styles
• The basics of the information architecture, which may include:
• Data model
• Behavioral model
• Glossary of preferred names
• Navigation and wayfinding
• Search and indexing
• A framework for interactions and workflow
• A transaction and persistence concept
• A visual design framework (essentially, the product-wide look-and-feel)

We’ll examine each of these in upcoming blog posts.

Some usability problems can be seen as violations of design principles. Here is how violating Donald Norman’s principles of usability can impair the user experience:

• Lack of consistency: An interface that exhibits inconsistencies in visual layout, labelling, behavior, etc. makes it harder for users to detect and learn patterns and form mental models. Inconsistencies force users to memorize and remember exceptions to rules, increasing the cognitive load.

• Poor visibility of controls: Frustration and lost productivity can result when users can’t locate the controls they are looking for, or when users are looking for means to carry out actions but cannot find appropriate controls.

• Poor affordance cues for controls: When controls don’t give visual clues as to how they can be operated, users must figure out what the controls do by means of time-consuming trial-and-error. Some controls may not even be perceived as controls, and some functionality may be “hidden” when the user cannot discover the means of activating it (for instance, a user may not realize that a context menu can be opened by right-clicking on an icon).

• Poor mapping cues for controls: When controls don’t clearly indicate what actions they perform, confusion can result when behavior does not match users’ expectations, or when users cannot find appropriate controls for actions they want to perform.

• Insufficient feedback: Without prompt and clear feedback, the user can be left wondering whether a control was properly activated and whether the action was successfully performed.

• Lack of constraints: Without constraints, users may be able to perform invalid operations, use controls in invalid ways, or enter invalid data. These problems can cause the system to enter an unstable, unpredictable state.

There are many other general problems that can contribute to a poor user experience. For instance:

• Unreliability, bugginess, flakiness, and instability: If the software crashes, or exhibits unpredictable behavior, it impairs the user’s trust in the software. The user may fear losing his work or having his data corrupted. The user has to waste time discovering and applying workarounds to avoid bugs.

• Poor performance: Lag, latency (delayed responses), and excessively long processing times are annoying and jarring because they interrupt the flow and rhythm of work.

• Disorganized, cluttered, or otherwise unappealing visual design: Unaesthetic, crowded, and poorly-designed screen or page layouts make it hard to find things, and are just simply depressing to look at.

• Conceptual model mismatching the user’s model: If the product’s view of the world or the domain (including things like terminology and processes) doesn’t match what users already understand, then users will have a hard time learning and conforming to the product’s alien way of thinking.

• Behavior not meeting expectations: Users can become disappointed when the product doesn’t work the way they expect.

• Excessive complexity: Too many steps and options and settings for seemingly simple tasks can be overwhelming. Complex products are harder to learn, and error rates will be high because users are more likely to make mistakes. The difficulty can cause the user to feel inadequate, incompetent, and embarrassed.

• Too much work: Users resent products that make them carry out repetitive, mundane tasks that could have been automated.

• Too much thinking: The product makes the user think too hard to figure out how to do things.

• The product makes it tedious or impossible to produce good quality output: For example, one diagramming tool I’ve used has no way to ensure that elements are aligned, and allows elements to be moved by two or more pixels, but not by one pixel, making it extraordinarily difficult and painstaking to create diagrams with aligned elements.

• The work that the product does is of low quality: For example, a paint program may render unaliased, “jagged” fonts, or a software development tool may generate code that doesn’t compile.

• Error correction is tedious: People make mistakes, and it shouldn’t be an ordeal to correct them.

To find usability problems such as the above, you should conduct usability testing on your designs, your prototypes, or your actual product. User observation is the most reliable way to discover where your users will have difficulties with your application.

There are many things that can cause users frustration and annoyance with software. The list of “don’ts” could become quite long, depending on how specific we get with particular problems.

Unfortunately, trying to capture and name the general things that make products enjoyable and easy to learn and use is a bit more difficult, and this list of “do’s” will tend to be much more general.

Firstly, we could say that a positive user experience is characterized by the absence of any of the problem factors that contribute to a negative user experience. If our list of “don’ts” includes things like unreliable behavior and a lack of prompt feedback, then a product probably doesn’t have a great user experience as long as these negative characteristics are present.

But we’d also like a list of “positive” characteristics associated with a good user experience, and the following list attempts to name some of these characteristics. Note that not all characteristics may apply to all types of products.

A product exhibiting a good user experience typically…

• is generally enjoyable and rewarding to use (and in the case of games, may even be addictive);
• enables high productivity and efficiency;
• enables the user to produce a good quality work product;
• enables and encourages the user to enter a “flow state”, i.e., a mental state of focus, concentration, and total immersion that engenders creativity, productivity, and satisfaction;exhibits acceptable performance (such as responsiveness);
• is visually appealing;
• is stable, reliable, and trustworthy;
• gives the impression that there is a logical, rational, intentional design behind it; and
• does not make the user feel incompetent, dumb, or embarrassed.

It should be noted that all of these are vague, subjective, and not easily measurable, and thus don’t lead themselves to easy checklist-style verification.

There are some cases where a product can have a rather poor interface, and yet users still rate their satisfaction with the product highly. This can happen, for instance, if the product facilitates enjoyable experiences, such as social interaction, or if the product is perceived as providing extraordinary value (especially if it is free). For instance, a free videoconferencing application lets geographically-dispersed family members stay in contact, and so even if the interface is poor, users may still highly value the application — it’s not so much the application that they’re focused on, but rather the emotional aspect of the social connection and interaction that the application lets them enjoy.

One traditional approach to designing and building software products was the waterfall model, where requirements are first gathered and written up in specifications documents. These are then handed off to designers, who create designs and write design specifications. These are then handed off to developers, who build the product. The product is finally handed off to testers, who verify that the product matches the specifications.

This sounds fine in theory — it’s a very logical, rational decomposition — but for large, complex products, this approach never really seems to work very efficiently. For complex projects, it’s never possible for analysts and designers and programmers to get everything correct and complete on the first try, and so waterfall projects inevitably tend to break down into a chaotic scene of documents being passed back and forth between groups for correction. And since software projects span months or years, it’s very frequent that the requirements will change during the course of the project, meaning that by the time the product is finally built and released, it may no longer actually meet the needs of the users and stakeholders.

An effective way of bringing some order to this chaos is to recognize that complex analysis, design, and development work is never done completely or correctly on the first attempt; it takes many iterations of reviewing, revising, and testing to get it right.

An iterative approach to design and construction breaks the project into many short, structured cycles of work. In each pass around the cycle — each iteration — the work products get better and better and more complete. An advantage to this approach is that you get a basic functioning version of the product available for testing very early on in the project, and this early product can be used to discuss and further refine requirements with the project stakeholders.

Attempts to illustrate an iteration of the design cycle usually end up looking something like this:

The Design Cycle

This diagram is unsatisfying, though: it suggests that the activities are separate and take place sequentially, and this is not always the case. There is often constant, fluid switching between the different activities, and team members will usually be working on different activities simultaneously in parallel.

In addition, the nature of different products can enable various different design approaches:

• For products with formal processes and very specific externally-imposed requirements, such as a tax calculator, requirements analysis and specification usually have to be figured out fairly thoroughly before detailed design can proceed.
• On the other end of the spectrum, products such as games have no real requirements — just about anything goes, design-wise — and so requirements analysis virtually disappears.
• Most products fit somewhere in the middle, and requirements analysis and design proceed together in a tightly meshed fashion. Sometimes requirements aren’t formally recorded at all, and instead the design is simply continually adjusted to match the new learnings about how the product should work. So in these cases, the Understand requirements and Design activities merge together.

And for products that lend themselves to rapid prototyping, often no formal design documentation is ever recorded. The prototype is the representation of the design, and so the Design and Build activities merge together.

The User-Centered Design approach recommends that you involve users in requirements gathering, and in the usability testing and evaluation of designs, prototypes, and the actual product.

In other blog posts, we’ll take a closer look at the activities in the design cycle. We’ll examine requirements analysis and validation, the process of design, prototyping, evaluating designs and prototypes, and conducting usability testing.

• Interviews with users
• Interviews with managers and other stakeholders (if applicable)
• Interviews with subject matter (domain) experts
• Questionnaire surveys
• Observing users…
• using your product or prototype
• performing their tasks without your product, either with a competitor’s product, or by doing the task manually without a technology-supported solution
• Analyzing website analytics data: User demographics, frequently-searched keywords, heatmaps, usage patterns, etc.
• Literature review: Academic research, third-party market research reports, etc.
• “Documentation archaeology” from past projects

Some user characteristics for your product might be chosen “by design” when you define your target market and product positioning strategy. For instance, by targeting a product towards children, you’re intentionally restricting the age range of the target user group to a certain range.

If you are making any assumptions about your users and target market, it is a good idea to test your assumptions. But research costs time and money, and so especially in smaller projects, you will have to weigh the cost-benefit ratio of improving the quality of the information you’ll be using for future decision-making.

A persona or user persona is a brief textual description of a fictional character who is representative of a stereotypical user in a user segment. The persona describes some invented personal details about the character, explains in general terms what they do with the product, discusses the context or environment in which they use the product, and mentions some of the problems, frustrations, and concerns that they might face.

You should invent a fictional name and a descriptive title for each persona; for example, Carol Jones, insurance adjuster, or Bob Davis, middle-aged man wishing to book a family vacation. To make the persona more tangible and memorable, you might also include a photograph (perhaps selected from a stock photo repository).

For example, a sample persona for a new word processing product might be as follows:

Example persona: Alice Smith, aspiring first-time novelist

Alice is 29 years old, divorced, and has a two-year-old daughter. She has a bachelor’s degree in English Literature from a state university, and currently works full-time as a marketing assistant for a major pharmaceutical firm. Alice sees herself as a very artistic person, and dislikes the fact that her corporate job offers no real opportunities to express herself creatively. She is particularly passionate about reading historical fiction, and so she now wishes to pursue her long-time dream of writing her own novel in this genre.

Because of her job and child-care responsibilities, Alice tries to get her writing done in small blocks either early in the morning, or late in the evening after she has put her daughter to bed. On weekends, she enjoys writing while sitting in her favorite coffee shop. She is frustrated it takes her a lot of time to get warmed up and into the “flow” of writing, and because she only has short windows of time to work on her book, she doesn’t feel that she is making very good progress.

Alice is currently using Microsoft Word on her MacBook laptop, but she is finding it difficult to organize her notes, plan out her plot structure, and generate an outline. She has character and plot notes and multiple chapters spread across multiple Word documents, as well as hand-written notes in a notebook and on various loose scraps of paper, and switching between these is becoming a hassle. She feels she could be more productive if she could just get a better handle on organizing all of her project materials.

She would like to have her novel published by a big-name publisher, but she knows that this is difficult for a first-time fiction author. She is considering self-publishing but has not had an opportunity to research what is involved, and she is particularly worried about the costs involved. She would also like to make her novel available on e-book readers like the Kindle, but she is unsure of how to convert her manuscript to an e-book format and get it listed on major booksellers’ sites like Amazon.com.

The advantage of personas is that they help your team develop a shared understanding of the requirements of each user segment, and they encourage empathy with the end users of your product. By bringing to life someone from each user segment, with a human name and face, designers can design specifically with that particular user in mind. When designing a task flow or a screen, you might ask, “How would Alice want this information presented?” or “How would Alice react in this situation?”

Personas can also help focus usability tests and evaluations. For preliminary evaluations of a prototype, tests could be carried out by somebody pretending to act in the role of the persona, or at least with that persona in mind. (Of course, it is preferable to involve real users from the user segments, but this is not always possible.)

You can also use the personas to prioritize the requirements. For instance, one release could concentrate on the core features needed by the Alice persona, and then next release could concentrate on another persona.

Personas are not without criticism; many people find the invention of fictional names and personal details to be highly gimmicky. Trying to represent a diverse user segment with a single persona runs the risk that the persona doesn’t accurately represent a large percentage of the members of the user segment. And if you try to write up personas without ever actually investigating or speaking to real live users, these completely hypothetical personas may have no relation to reality.

The following is a list of some of the characteristics you might want to know about each user segment. Not all characteristics are relevant for all types of product — some may only be appropriate for software used at a workplace, for instance.

• Age
• Gender
• Educational background
• Language and culture
• Computing skills
• Physical abilities and disabilities
• Domain-related knowledge and skills (e.g., accounting knowledge for an accounting application)
• Job experience and competence
• Place in the organizational hierarchy
• Attitudes, motivation, and morale
• Persistence, patience, confidence, problem-solving ability, curiosity, ability to deal with change, etc.
• Frustrations and problems relating to the user’s tasks or activities
• General sources of stress or anxiety (e.g., deadlines, performance targets, workplace competition)

Additionally, you may also give some though to the context in which your users will use your product:

• Physical environment (e.g., home, office, factory, vehicle, oil rig, on-the-go in an urban environment, etc.)
• Social environment (position within organization, relationship to other groups, political and interpersonal factors, degree of freedom, influence in decision-making, etc.)

Every individual is different, of course, and there is a risk of creating generalized stereotypes that doesn’t accurately describe many users in a user segment, but it is still worthwhile taking the time to think about each characteristic. For some of these characteristics, you might describe an approximate range and an average. For instance, bank tellers at a particular financial institution might range in age from 20 to 50 years of age, with the average age being 28.

For each user segment or role, you may want to write up a brief profile, which can then be reviewed and discussed with your project team. A profile for a user segment can be presented simply as a bulleted list with characteristics described in point form. Or, you might use a matrix to compare user segments side-by-side. Alternatively, you can represent user segments by means of personas, which we’ll discuss in the next post.