Fundamental design and user interface guidelines

Slicer 3: User-Centered Design Guidelines

Wherever possible, we are encouraging a user-centered design approach for Slicer3's application and software modules. That approach is built on five principles:

1. Understand who your users are, what they need, and how they work.

2. Engage users in your prototyping process.

3. Refine your implementation iteratively with user feedback.

4. Provide documentation that describes your module, its status, its features and how to use them.

5. Monitor and address feedback on software bugs and usability problems.

Value and benefit:

In OSS efforts operating in a research setting, software development is often driven principally by feature requirements (a feature-centered design approach) in service of advancing research. Mature tools often evolve from software prototypes designed to test an algorithm, or they’re created for use in a particular research laboratory by experts familiar with the algorithms and their parameterization. Usability issues are often approached at the time a tool is translated out of the laboratory, long after design and implementation decisions have hardened the underlying technology and the way it’s exposed to users. Asking “what do the users think?” at this point will likely expose the need for significant re-design and re-engineering that a project can’t afford and developers don’t want to think about.

So, while establishing a clear set of technical requirements is paramount for a tool intended to reach a broad audience and to have a strong impact on scientific research, it’s not necessarily enough! If the software isn’t easy and satisfying for people to use, the tool’s use can be limited or can vanish when a more satisfying alternative becomes available. This outcome minimizes the utility of a team’s or individual’s contribution, and diminishes the impact of a project’s sponsoring agencies or institutions. Sometimes, adoptive user communities spend valuable time drafting and maintaining their own local versions of training materials for unfriendly tools (keeping instructions in binders in the lab, on local wiki pages, etc.) to train new users and support ongoing use. This outcome transfers (and multiplies) the time-cost from developers to users – what the development team saves by designing software tools without engaging users, users must spend later by providing in-house training and support.

Slicer3 Design and Usability Goals

Following the simple design philosophy outlined in this document should avoid those typical pitfalls and promote the following goals:

• Users will learn to use your module faster, because its interface will be understandable and interface elements will look and behave in an expected manner.
• Users will be able to accomplish their tasks by following an appropriate and satisfying workflow, or a curiosity-driven exploration, at an appropriate pace.
• Your module will be accessible to users at all levels (novice, intermediate and expert).
• Your module will have a nice look & feel that fits within the 3DSlicer environment.

Modules that hit these marks should maximize the reach of a developer’s research, design, and programming effort, offer contributing agencies, institutions, and individuals the maximum impact for their investment, and provide the user community with cutting-edge functionality that they find satisfying to use. The Slicer community ultimately leaves the choice about design and implementation process to contributing developers, and the recommendations in this document are not enforced. Since we believe that incorporating user-centered design will improve Slicer overall, the process we are promoting is light-weight and flexible, so that developers may adapt it to fit their environment and project timeline.

How to Apply these Recommendations

Read through the recommended practice described below; it probably won't surprise you. Most of the strategies it promotes are quite common in commercial software development efforts, where unhappy users leads to an outcome easily measured. Think about how the process will fit into your project and your project timeline. The basic pattern is scalable, so you can apply it in a manner appropriate to your application.

Recommended light-weight user-centered design practice

1. Define your Target User Communities

The most basic requirement of a user-centered software design practice is a thorough understanding of who the target audience is. Our Slicer3 development funding designates the following communities to be among our core user groups, though the package is used in many other scenarios as well. In design and development of Slicer’s codebase, we're targeting these core communities, but we welcome and encourage input from any others.

Core User Communities:

• (NAC) Longitudinal and multi-channel dataset analysis
• (BIRN/NA-MIC) Individual and group analysis
• (IGT/AMIGO) Real-time control and tracking in the operating theater
• (IGT) Neurosurgical planning and guidance

Types of Users:

• Algorithm researchers (who work within 3DSlicer's development environment and with associated toolkits)
• Biomedical engineers (who rely on 3DSlicer's interactive enironment and scripting capabilities)
• Application scientists (who use 3DSlicer as a desktop application and turnkey system)

Many people in our user community fit two or three of these categories. The application you are developing may target a different audience, so a first step is to decide who your core users will be, and whether additional communities are likely to become active users of your software. Make a list of these communities as a “framing device” and post it where you’ll periodically encounter it. Often times, the list will grow as your project progresses. This crucial information will help you to identify potential user-collaborators from whom to seek information and feedback, can expose additional technical requirements, and will frame how your software’s functionality should be exposed and communicated.

2. Assess the Needs of your Target User Communities

Once you’ve identified your target audience(s), take some time to develop an understanding of how each distinct community will use your software. This step is essential for meeting both the technical and usability requirements of a user community. Every user group is unique; empirical study is the only approach to a good understanding of your users – how they think about what they do, how they accomplish their work and what sets of needs reside within that framework.

A user-centered design approach considers people’s background and experience, needs and skill levels, tasks that must be accomplished, the environmental conditions, pressures and risks under which users work from the beginning and throughout the design process. With this information framing your design and implementation, you’re very likely to develop a software product that’s more appropriate and usable for your target community, and promote both its potential reach across applications and the longevity of its usefulness.

It’s most likely that you’ll find your future users very happy to spend time talking with you about their research, what their current tools and workflows are like, the technical challenges they present, and what kinds of tools might address them. You may understand these things at an overview level, but the richest information is often revealed in the details; it’s almost always worth spending time to listen. Moreover, this discovery process often reveals new ideas that you may want to include in this or another project.

Here are some simple suggestions for gathering information about your users’ needs:

• Before you begin coding or even designing, make appointments to sit with eventual users of your software, observe how they work and understand their workflows; this small investment will help you better understand how your module can support that workflow and be easy for your target audience to use. You already know a lot about the technology you’re developing. This step represents an opportunity to learn how to translate your plans into the world your users inhabit. Try to talk with users from every community that may eventually want to use your software module: identify commonalities that can lead to generalizations in your design, and differences that will require accommodation in your design. In addition to observing work settings and workflows, ask salient questions and listen carefully to responses. Find out things like:
  • what challenges your users are trying to solve;
  • what stereotyped workflows they use;
  • what tasks consume a lot of time and what are notable obstacles;
  • under what kinds of physical conditions are these tasks being performed;
  • what level of stress and what risk is involved during their work;
  • what kind of record keeping is required during their work;
  • what other software do people use;
  • what do they like about other software and what don't they like;
  • what new features do people need and might people like to have; it’s often useful to classify these in two ways: from the user’s point of view, critical needs, future needs, blue-sky wants; and from your point of view, easy, challenging, not tractable. Clear collaborative project workplans with matching expectations can result from such a simple derived chart;
  • what kind of application information (parameters and settings) is recorded;
  • and how are users trained to use new software packages.

• If you already have a technical proposal or a set of technical requirements to develop for this group of users, wait to address its details until after you understand their story to avoid biasing the exchange.
• It’s very important to learn your users' language: application scientists may talk about things differently than computer scientists and algorithm developers. Find out how your target user communities talk about what they're doing and make your interface compatible with their terminology.
• If you are performing a needs assessment but you’re not the primary developer, take the time to report your findings to the developer team face-to-face – many a written report does not get read and considered. It could be very frustrating for the users who contributed their time and expertise (and embarrassing for you) if their input is ignored.
• Absolutely credit contributing users on the project. Depending on the extent to which their time and effort helps to shape the final product, it may be appropriate to make them co-authors, or at least to acknowledge their contribution.

What if your target user community is not local, and you can’t travel to spend time with them? If in-person interviewing isn’t feasible but you have collaborating users, you can use online meeting services (like WebEx) in combination with telephone conferencing to learn quite a bit. While there’s a disadvantage to not being there in person, certainly some information gathering is better than none. The issue of remote user assessment and usability testing in distributed development efforts is currently an active research topic. So, share what works and what doesn’t work with us and others – your experience will be valuable to this and other efforts.

What if you have no access to an appropriate user group? One thing you can do is to post a brief description of your project, and a sketch and description of your interface to slicer-users@bwh.harvard.edu, our user mailing list. You can ask for feedback on the design and the functionality you are exposing -- you may discover suprising applications for your work and get some useful input that way. Otherwise, we presently have no other formal infrastructure to support your design and implementation process. As the Slicer3 effort develops, we hope to provide a list of current well-qualified challenges (in terms of technical and usability requirements) to guide developers interested in becoming active participants.

3. Create and Test Design Mockups

This is a step often skipped in open source efforts, but the process described below can strengthen the match between your creative interface ideas and the users’ stake in the final product. So rather than creating a design to meet requirements derived in the previous process step and jumping straight to implementation, consider developing a design prototype and refining it with your users’ input. Even one round of interaction is very likely to generate interface improvements. Some things to test as you go are:

• Is the design reproducing known usability problems? Read through the existing application interface user feedback for Slicer2 and Slicer3 linked below. Also check for usability reports listed below on specific Slicer2 modules that may be relevant to your work and check your design against them.
• Do early prototypes promote discussion and modification? Start quick and dirty, and refine your design with user input. Start with flexible, non-precious initial mockups that invite discussion and easy modifications (sketches, whiteboard drawings, or paper prototypes are great) and change it with user participation. Starting with well-thought-out or highly crafted designs will cause everyone to resist making substantial changes, even when they’re clearly called for.
• Are the interface’s layout, representation, behavior, and workflow appropriate? Work toward a good interface layout, double-check that the terminology and iconography is appropriate, and step through the behavior of the interface to make sure it behaves in an intuitive and appropriate manner. This activity can be accomplished in as little as one meeting per target user group (though it’s best to take as much time as you need and can afford).
• Does the interface accommodate all target user communities? If you are trying to generalize the layout or terminology in your GUI to satisfy several different user communities, note these compromises so users understand your reasoning and decision making based on their input and are encouraged to participate in determining a good solution.
• Does the interface accommodate different levels of expertise? Remember that most people who use your software will likely be intermediate-level users. Your design should strike a balance to ensure you support the workflow of intermediate-level users while making your software as easy to learn as possible for novice users, and as convenient to use as possible for expert-level users.
• Is the design simple and likely to be stable? Design principles from best practices in software development are absolutely applicable to interface designs: Simplicity in design should be a key goal, so keep it simple; and try to arrive at a stable design that hides information – when underlying implementation details change, a user doesn’t have to learn how to use a new interface.
• Will the interface accommodate an expanded user base? Even if you're adding a command line module to support the work of your own laboratory, remember that you may eventually want to share the code and new end-users may need help to understand the meaning of parameters and suggestions for reasonable values to try. Make your help appropriately detailed, and take care to give parameters that will be assigned widgets in the GUI intuitive names.
• Does the interface conform to the Slicer3 style guidelines? Check our human interface and style guidelines to work within Slicer3 style conventions; try not to deviate from these recommendations in your GUI and keyboard interface.

4. Implement and Test with User Feedback

Once a design is finalized, implement and test. Incorporating sessions to evaluate collections of your module’s features before the interface is hardened will help you to catch any problems that were overlooked in prototype. Try to test one or a small set of features at a time – this keeps the impact on everyone feeling low, and helps to get very focused feedback each time you engage people.

• Check our coding guidelines for developers so the programming style conforms to Slicer3 community conventions.
• During your development process, sit down at appropriate junctures with as many users as you can (and as many different datasets), and give them some specific instructions about what they’re testing, and remind them how this subset of functionality fits within the module’s larger feature set and workflow. Even a few brief, focused testing and feedback sessions will likely strengthen the usability of your software.
• Keep a notes on these user-testing sessions in your notebook so that the process can be included in publications.

5. Document and Maintain your Code

To make sure the software remains accessible for beginning and intermediate users especially, use Slicer’s documentation tools and practices:

• Comment your code appropriately so that doxygen generates a good description of your code for developers who want to use or extend it
• Create a description page on Slicer’s wiki that describes your module, and links to any additional information that users or developers may want to consult. Use this template , and link it from Slicer’s documentation wiki page .

To maintain your software:

• Check Slicer’s bugtracker periodically to see if any problems with your module are being noted by users. Software bugs obviously get the highest priority, but usablity issues also important to address.

User feedback

We are collecting feature, conventions and resource requests from application users and software developers. Appropriate entries from Slicer2's bug tracker and Slicer3's bugtracker will be periodically added to this repository also. All usability problems should be reported there.

Usability Sessions

• Application GUI sessions
• Editor Module sessions
• Fiducials functionality

Notes on OSS and User-Centered Design

OSS projects express their own distinct cultures, and each likely presents an unique and interesting climate in which to launch a user-centered design component. For the Slicer3 effort, we're developing a new user interface within a very active OS development environment which has adopted the "Extreme Programming" methodology. Developers communicate and work collaboratively via local meetings, weekly t-cons, a dedicated wiki, intermittent programming meetings, using shared CVS and Subversion code repositories. At the start of this project, no usability studies have looked at earlier versions of Slicer, or any of its many individual components. A coarse style guide exists in the form of a limited preferred-use widget set, and conventions for color-coding, fonts, GUI layout, providing help, tooltips, and documentation. Members of our small usability team are also members of the Slicer developer community, and have worked with and developed software explicitly for members of Slicer's user community. As such, we're starting this effort with a good understanding of both of these communties, and a strong sense of the core values of the Slicer effort and the software artifact.

As an open source software effort and artifact, Slicer has a unique compound characterization; it's an extensible platform for research and development with a fairly consistent coding style; an interactive end-user application with high-performance C++ image analysis and rendering and a fairly consistent user interface, and a supported mechanism for translating emerging tools rapidly from re search laboratories to both user and developer communities.

Culturally, as in many OSS efforts, most of Slicer's underlying architecture and user interface have been developed by a large community over time, lead and framed by strong technology vision, but without a coupled interface/interaction design and usability effort.

Recently, OSS projects such as GNOME, KDE, Mozilla and OpenOffice.org have had notable success in incorporating usability teams into their efforts. While the typical role of interface designers and usability experts in the development of commercial products is well known and very deeply coupled, the manner in which a user-centered design effort can interact with and productively shape OSS development remains a challenging topic.

For example, in industry, usability experts are involved in development before coding even begins, and their designs strongly shape the form, behavior and etiquette of a software product throughout its development cycle. Many open source developers enjoy coding for themselves, as part of a distributed working meritocracy, developing according to their own -- and often excellent -- intuitions. While the success of projects like GNOME inspire interest in collaborating to promote both technology excellence and usability, no standard prescription extists yet for how to implement that collaboration.

We can look at the GNOME project as a case study: In March 2001, Sun Microsystems performed a three-day GNOME usability study (Smith S, Engen D, Mankoski A, et al., "GNOME Usability Study Report", Sun Microsystems, July 2001) and results were subsequently presented at a GNOME users and developer's conference (GUADEC). The study recruited a dozen technical, business and creative professionals with computer experience, but none with GNOME. Participants were tasked with logging in, commenting on the desktop, customizing the desktop and managing files. Their report categorized and itemized important feedback from participants, and offered design recommendations. (note: link to study). This presentation marked the first time many GNOME developers became aware of the user community's experiences with the software.

Shortly afterward, a usability team was formed within the project, tasked first with developing a set of guidelines (now the GNOME Human Interface Guildelines, HIG 2.0) against which GNOME applications are checked for conformance prior to release. The team also introduced a usability keyword for bug reporting so that usability-related bugs could be properly tracked and assigned. Other OSS efforts have formed usability teams too (i.e. KDE Usability Project and Mozilla UI Sector) and have published their own usability studies and sets of usability guidelines (i.e. KDE Human Interface Guidelines). (note: link to guidelines).

Strategies for building open source software tools that users love to use can still be greatly improved. Some of the following issues are noted as current challeges for advocates of usability in OSS efforts (Benson C. "Meeting the challenge of open source software usability", Interfaces 60, Autumn 2004):

• Encouraging a thorough understanding of the core user community;
• Having a usability team consult more deeply in the development process;
• Adopting distinct ways to regard and address usability and functionality bugs;
• Developing OSS tools that automate generation of guideline-compliant interfaces for developers;
• Creating convenient oportunities and mechanisms for users to comment on usability issues;
• Finding ways to share and consolidate experience among usability teams across OSS projects;

To address the last issue, some useful resources exist, notably openusability.org, which has a useful bibliography linking to usability discussions, relevant articles, news, guildelines and published studies. Openusability.org is a professional meeting ground for open source developers and usability experts, and clarifies very simply the benefit of their collaboration: "There are many Usability Experts who want to contribute to software projects. And there are many Developers who want to make their software more usable, and as a consequence, more successful."