obso1337.org

In addition to talking about the KDE Usability Project at Akademy 2008, Ellen and I hosted a KDE HCI Workshop.

90% of what I do as a designer is to try and understand problems and solve them. There are several research and design methods I use as a designer which can be simplified and modified in a way that developers can use them as well. In my workshop session, I gave developers several participatory and non-participatory methods they could use to help make more usable software. Here are 6 methods developers can use to help improve the usability of their software. These methods offer options which need no users, require user participation, are useful for user research, or are helpful in design and testing.

What is User-Centered Design?

User-centered design (UCD) is a methodology which considers the user’s needs, goals, and tasks throughout the development process. Basically, you want to keep the user in mind while you are planning and creating a product for them. You try to answer the What, Why, and How by understanding the Content, Context, and Use of a product in terms of its users.

Many of you are familiar with this comic.

UCD is understanding what the user really needs. UCD is also more than just usability testing. Usability testing is simply one of many methods interaction designers and usability engineers use to help create usable products. There are two classes of methods we use in UCD, participatory and non-participatory methods.

Types of Design Methods

Participatory methods are methods that users have an active role in design and development. Users become design partners and are involved in the planning, design, and testing stages the development cycle. Participants can be current or prospective users. Participatory methods include usability testing, surveys, and interviews.

Non-participatory methods are methods where users are not actively involved in design and development. Designers and developers involved in the development cycle try to keep users in mind while they are creating a product. Non-participatory methods include creating user groups and personas, task analysis, and reviewing user interfaces.

You do not need user participation to do UCD

Once you have decided you want to do an activity to help you improve your software, you must decide what it is you want to do.

More traditional research methods help you answer questions you might have about a user group, function or configuration option, or different design solutions. Design methods help you get stuff done, by establishing a usability baseline (to see how much you improve), find usability problems to fix, and improve the overall design and usability of your software.

Interviews

Interviews are a participatory user research method, usually done early in the development cycle during the research and planning stage (but can also be used later as a way of assessing certain features or functionality). It is exploratory in nature; you are usually trying to gather information to help answer a question instead of trying to validate or prove something. The method itself is quite simple — you just talk to users. It is a good idea to focus an interview activity around a single question or topic you are trying to solve. This allows you to gather much more information about a single topic by following up with specific questions.

1. Think about the type of questions you want to answer, For example, “How do you configure X” or “What do you do when you need Y”
2. Create a list of participants to interview (try to talk to different types of users)
3. Write an “interview guide” which lists background questions for the user and your research question
4. Take notes on the interview guide, it will help you stay organized
5. Compile your notes and talk about the results with your project.

User Groups

Creating a list of user groups is a non-participatory user research method, usually done at the beginning of a development cycle. It is a simple activity which involves one or more contributors making a list of different types of users of their application. When you create your different groups, you want to consider different dimensions which can effect use such as experience, roles, tasks and activities, and environment. Although no user participation is required, interviews can help supplement information you don’t know about a particular user group.

1. List the types of users you think use your app by various dimensions
2. Think of descriptive names to give the different groups of user types you find
3. Write a one or two line description of the group
4. List the types of tasks you can complete in your app
5. Look at your user groups again and add/edit and group information
6. If more than one contributor made a list, compare your notes and create a single list
7. Share the results with the rest of the project

Surveys

Surveys are a participatory user research method you can use to ask a lot of questions and gather structured data you can analyze. They can be used to gather all sorts of data including user demographics, frequency of feature or option use, and other useful information. Be aware that mailing lists and forums may not have all of your different user types represented. Keep this in mind when you are recruiting survey participants and analyzing your data.

1. Make a list of functionality or options in your app
2. Create a web survey which asks users how frequently they user or configure each of the functionality or options in the list
3. Send the survey out to you current or potential users
4. Analyze the results and look at the data in terms of overall usage and usage per user type
5. Compare the results with your current user group data and how your app is designed
6. Discuss results with your project

Task and Screen Diagramming

Creating system diagrams of task and screen flows is a non-participatory design method. These diagrams provide a different way to view and understand processes and how complex they are (and should be). It is helpful in nearly any stage of development because it helps plan and document processes and functionality. Diagrams can be simple and drawn on a napkin, or very detailed and drawn in Kivio, Presenter, or Dia.

1. Pick a single or group of related tasks to diagram
2. Begin diagramming the different paths for completing a task. Start at a high level and add then add details
3. Analyze your diagram. How complex is the diagram? Is it appropriate for how difficult the task is?
4. Review each of your user groups. Does the task make sense for all the user groups involved?
5. Discuss your findings and ideas with the rest of your project

UI Walkthroughs

User interface walkthroughs are a participatory design and testing method which can help you test functionality or design options with real users. You literally “walk” the participant through the UI, with varying degrees of guidance depending on how functional the wireframes, prototype, or beta software is. This is a type of usability testing, but the goal is to get immediate feedback in the middle of the development cycle instead of waiting until a release to test your design assumptions.

1. Pick a single task or feature you want to test. More than one or two tasks will be too much for a single session
2. Package the test software to make it easy for users to install and test. Alternatively you can use screenshots instead of compiled code
3. Ask the user to perform a certain task without giving away too much on how to do it. Pay attention to what the user does and not says
4. Repeat for 4-5 users. You do not need many because you are testing designs and your own assumptions; you are not out to prove anything.
5. Discuss results with your project, and possibly make changes to the app depending on the results of the walkthrough

UI Reviews (aka Heuristic or Expert Review)

UI reviews are one of the most common activities I do as a designer. It is a non-participatory design method you can use to find usability issues to fix. There are many types of issues you can look for, the most typical include the 10 basic heuristics, guidelines conformance and other industry standards and best practices (ISBP). These reviews work best if 2 or more people review the UI; a single person will not find all issues in an application and it is always good to have a second opinion on a design option. Out of all of the methods presented, this is both the easiest and most difficult to do. Many low-level UI issues are easy to find and check off a list, but higher-level (more serious) conceptual issues may take experience and practice to identify. Also, since you may be able to identify something as “wrong”, but not necessarily why it is wrong, it may be more difficult to convince your colleagues that it should be fixed.

1. Choose a few tasks to help you step through the app in a structures way.
2. Look for issues relating to the 10 usability heuristics, interface guidelines, and anything that might look or feel wrong
3. Record each issue with a screenshot and description of the problem. Include ideas on how to fix the problem
4. Compile results with other reviewers and consider design fixes
5. Discuss results with the rest of your project and plan which issues to prioritize