UbuntuWiki:UsabilityInPractice

{{#ifexist: :UbuntuWiki:UsabilityInPractice/zh | | {{#ifexist: UbuntuWiki:UsabilityInPractice/zh | | {{#ifeq: {{#titleparts:UbuntuWiki:UsabilityInPractice|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:UbuntuWiki:UsabilityInPractice|1|-1|}} | zh | | }}

Most of this page is a taken from a swedish book called Usability in Practice. (Berndtsson & Ottersten, 2002) As such it isn't really adapted to special nature of open source projects. It's my expectation that this text will evolve into something more open source friendly as more experience with usability activities in an open source setting (hmm, that sounds like a good title for a dissertation...) is gained. Whether to adapt it to Ubuntu specific work flows, or create a new page for that, is open for debate.

I haven't put too much effort into translating names ans such, so don't hesitate to replace them.

Usability in practice

When designing for usability it's important to know a lot about the users, their goals, the context in which the the product is to be used, the goals of other stakeholders and probably a lot of other things I've missed. The keyword is know, any attempt at guessing will probably result in failure.

Thus a major part in design process is analysis and evaluation. Analysis of the situation, and evaluation of the results.

To ensure that this work gets done, and done right, it might be useful to divide the work and responsibilities among a few roles. Note that a role isn't limited to a single person, and a single person or group can have many roles.

Roles

Users

The users are identified in the target group analysis. Representative users from each target group are participants in usage testing and are members of reference groups.

Reference groups should be involved in design discussions and generally be consulted whenever the need arises, they are the experts on the context in which the product will be used.

It's probably a bad idea to rely too heavily on reference groups for evaluation of design though. Usage testing and target group analysis should be performed with users not involved in the development process.

Client

The client represents the desired and expected effects of the product and its use.

It is the client who is responsible for decisions regarding the goals, ambitions and resources of the project.

Usability architect

The responsibility for securing the usability of the product falls on the usability architect. This means declaring and defining the usability activities needed to meet the clients expectations, planning and coordinating those activities and managing the reference groups.

The usability architect needs to be part of the projects core team and work in close collaboration with the client, project manager, system architect and interaction designer amongst others.

Mapper/Requirements collector

The mapper executes interviews, leads workshops and executes target group analyses with the purpose of identifying and describing the users, their goals and the context in which the product will be used; determine the expected effects; identifying opportunities and threats; and prioritize among these.

It is the responsibility of the mapper to communicate the resulting knowledge to the rest of the team.

Interaction designer

The actual design to meet the assembled usability requirements is the responsibility of the interaction designer. All design decisions regarding the interaction between user and product belongs to the interaction designer.

The interaction designer should also educate developers, and other members of the team, so that they may correctly spot bugs in the interaction design, and identify them as such.

Graphics designer

The graphics designer translates the interaction design into a functional and aesthetically pleasing interface.

Test leader

The test leader designs, executes and analyzes usage tests.

Role distribution

The interaction designer should not be the same person as the mapper. The mapper usually gets an idea of a solution at an early stage that might make it hard to think of new and alternative designs when the time comes.

The interaction designer should not lead any usability testing as the bias towards the design might interfere when leading the user.

The interaction designer should not be responsible for the actual implementation of the design. As an implementer the bias toward simpleness is at high risk in interfering with the need for functionality.

The project manager should not be the usability architect as these two roles are naturally in conflict. The project manager is responsible for keeping the project on schedule, while the usability architect is responsible for identifying new demands and negotiate with the project manager for changes in the plan to meet the new requirements.

Usability activities

Requirements

Mapping of ideas

Through interviews and workshops the mapper collects the ideas and expectations on the effects and functions of the future product for different target groups.

At the end of this activity it should be known what the expected utility of the product is, who the target groups are, which effects usage of the product should have and other general requirements.

Target groups analysis

Users are grouped by their expectations and differentiating requirements. When the target groups have been identified they should be carefully analyzed and described so that future design decisions can be well founded, and high quality tests can be conducted.

The analysis can consist of interviews, questionnaires, observations, diaries and other activities. A big risk with interviews is that the user describes an ideal work flow instead of the actual work flow, it's simply impossible for humans to be consciously aware of all the important aspects of the usage scenario. Observations of the actual situation is thus essential. It's also important that the collected data isn't just hard facts about the user and the situation but that also soft values are captured.

When the analysis is complete the result may be presented as personas; one for each target group. The purpose of a persona is to describe a group of users as a single person, because it's much easier to design for a single user than a group of users. The description should be sufficiently detailed and complete, including name and photo, so that it's a believable person that the project team can get to know and get an empathetical connection to.

Select a primary persona such that a design satisfying this user will automatically satisfy the others. If this is impossible there might be a need for more than one product...

Use cases

A use case is a description of an interaction with the product. Use cases should first be described in an implementation neutral manner and later refined to contain implementation details as design decisions are made.

Expert evaluation

An expert evaluation is simply an analysis of an existing design to find usability problems using only theoretical models of the human system and scientific theories. See UsabilityTheories.

Usage test

Usage testing is a very simple method of validating designs. The test is conducted by asking users to perform some realistic tasks with a prototype while thinking "aloud". This kind of testing can be performed on paper drawings or other quick mock-ups, which makes it available early in the project and thus very cheap.