Design for Visualization

SoViz is a method I have developed and employed for creating visualization software that incorporates participatory design methods into the visualization design process. The rationale for this is that most existing models of visualization design describe what should be in a visualization but not how the visualization design process works. Thus, SoViz is an attempt to explicitly describe the steps involved in visualization design and to support the creation of new visualizations by incorporating user-centred design activities into the prototyping and development process. The SoViz approach emphasizes SKETCHING and DESIGN PATTERNS as major methods of refining user interface design requirements at design time. My dissertation describes the research that led to SoViz and a case study of its use. The short version below is a summary of its key features, follwed by an overview, generated in Wordle.

The SoViz Design Process

The key design activities in SoViz are design sketching and incorporating existing visualization design knowledge using any visualization expertise that is available from members of the design team, supported by visualization design patterns. Design sketching is simply what it sounds like: using paper and pencil to create and share design alternatives to different parts of the visualization. This is designing in the trenches, though! No fancy technology, shared whiteboards, or drawing tablets (though these could be used). The process is more important that the tools used. Design patterns are a collection of solutions to common visualization design problems. Here’s a short summary of the different stages of the SoViz process, which generally follows most accepted approaches to iterative, user-centered software engineering:

Requirements gathering

involves discovering functional requirements, data requirements, and usability requirements of the software. It may employ common techniques such as dataflow diagramming, entity-relationship modelling, task analysis, and personal interviews to capture knowledge for use in the process of designing the new system.

Design Activities

consist of many iterative participatory Information Visualization design sessions. During these roundable, workshop collborations, stakeholders in the design team share their conceptions of the design problem. Using the key requirements discovered during the previous phase, participants use SKETCHING to explore the design problems and possible solutions. This is the key moment when DESIGN PATTERNS are most useful. Working out the different design problems with sketching leads to a better understanding of which data components and manipulations are most important. Design patterns show how to overcome many of the design problems with different visual abstractions, interactions, and layouts.

Prototyping

starts with these refined requirements and a set of specifications which are used for coding. Ideally, prototypes are produced by software engineers who have been part of the design activities and who will therefore be familiar with the designs which have been proposed. The technologies used for the software (e.g. operating system, programming language, database, etc.) are not specified by SoViz, as these details should be selected by the software engineers.

Evaluating

the prototype(s) follows the standard usability assessment approach. User feedback, usability testing, QA, and other evaluations can be performed on the funtional prototype. Using sketching and design patterns, the strengths and weaknesses of the prototype are identified in further design sessions. New design ideas are proposed for the next iteration of the prototype. Because this can be construed as additional visualization design activities, the diagram above shows this is an iterative process, with evaluation leading to further design work until a decision is made to release the visualization software.

This model has been used to develop several visualization systems and prototypes. The exact approach used will of course, have to be tailored to the development processes and culture of the organization, but any use of sketching and design iteration has been shown to be useful. The find out why, read on.

About Sketching

Why do we use sketching to create visualizations? The main reason is that visualizations are by their nature visual beasts, and to create them, it is important for the entire design team to explore alternatives by collaboration using visual sketches. We don’t use sketching software, but rather employ the time-honored method used by studio designers, architects, and artists to create design solutions: papers, pens, and pencils. Sketching is useful because it allows a designer’s ideas to be visually shared with the group, instead of remaining locked up inside the designer’s head. This means that everyone is free to embellish upon, modify, or reject aspects of the proposal. Visual elements of the user interface can be adjusted and manipulated. Different suggestions can be described so that everyone has a common understanding.

There is a good deal of research that supports using sketching as a design method. And of course, professional designers have been using this technique for a long time indeed. However, its importance has rarely been discussed in the area of software engineering. But people are starting to emphasize its importance. Notably, Bill Buxton has shown how designers can use sketching as an important tool in the software and product engineering process. He has pointed out six (he’s now up to eight) useful things that sketches do during the design process and based upon my research I find that they apply to visualization design too. Sketches are useful because designers can use them to:

  • invite comment, commentary and discussion

  • suggest alternatives to design problems

  • explore the aspects of a design problem

  • question preconceptions about the problem or forces which are acting upon it

  • propose solutions

  • provoke others to think about a problem from another designer’s perspective

But don’t just take my word for it!

Some of these benefits are supported not only by the extensive experiences of professional designers and engineers, but also by scientific research. Some studies have suggested that using sketching allows designers to think about a problem differently. By moving the problem from inside the mind to the external world, designers can free-up mental resources, particularly working memory. Seeing external representations allows new connections and associations to be made. Visuo-spatial and metaphoric calculations can be made by comparing the physical aspects of a design. For example, seeing the placement and orientations of various user-interface widgets allows for decisions to be made about proximity, relationship, grouping, etc. These cognitive benefits of sketching combine to enhance creativity and problem solving about the design problems at hand. See my dissertation for further details about why sketching is beneficial and the experimental studies that have studied this.

About Design Patterns

Design patterns emerged from the field of Architecture, primarily through the work of Christopher Alexander and his collaborators. Though they’ve had mixed results in the built environment, they’ve been widely adopted in the software engineering community. Design Patterns are most useful because they facilitate the design process in situations where expertise may be lacking or unavailable. People involved in designing software visualizations are very often involved in designing systems, even though they may not know about the solutions that others have already grappled with. Experts are in short supply! This is where design patterns can be helpful. They provide several helpful benefits because they:

  • Contain known solutions to problems that others have already encountered and solved. Why reinvent the wheel when someone has already done it for you? Drawing upon the experiences of others reduces the time needed to solve a problem.

  • Are context sensitive. Design Patterns, unlike guidelines, are specific to problems that occur within a particular context. For example, if you are designing for 3D zooming, it’s helpful to have a 3D navigation method. Design patterns for 3D take this into account and present options that are not relevant to a 2D scenario.

  • Are inter-related. It’s often the case that several patterns can be used together to address a design problem. Each design patterns presents both a solution and other patterns which may be relevant in a particular context.

  • Improve organizational memory by storing solutions in a well-known resource. For example, Yahoo! has used design patterns to solve user-interface problems with a step-by-step approach. Challenges that others have already encountered are recorded by design patterns and can be referred to as a source of inspiration and recognition.

  • Allow end-user participation because they are written in plain language. End users are not likely to be familiar with software engineering methods and system. Design patterns can allow them to participate in the design process without having previous expert systems design knowledge. Patterns can give end-user participants a voice.

Patterns have been used extensively in software engineering circles for these and other purposes. The classic overview (mainly aimed at a software engineering audience) is provided by this book. There are also many conferences and workshops aimed at helping people to use patterns for systems design.