Boxes and Lines Over Bullets and Arrows: Deliverables That Clarify, Focus, and Improve Design

Boxes and Lines over Bullets and Arrows: Deliverables that Clarify, Focus, and Improve Design Rich Fulcher Bryce Glass Matt Leacock Senior UI Designer Senior UI Designer Senior UI Designer America Online America Online America Online [email protected] [email protected] [email protected]

Abstract The representations we choose for UI design affect both how we think about the design and how others understand it. Concept maps, wireframes, storyboards, and flow-maps speak to different audiences at different stages of the development cycle. This presentation provides examples of these documents and a toolkit for producing them.

Introduction User interface specialists do not work in a vacuum; they rely on others for product definition, organizational support, and implementation. The success of any software project depends upon workers with different areas of expertise joining together to build a product. The same documents that assist a UI designer in analyzing and managing design can be valuable for communicating the state of the design to other team members. At different stages of the software design cycle, these stakeholders need to know different things about the design, and therefore different styles of documentation are appropriate. In this presentation, we will focus on four sets of tools for visual representation that we have found particularly valuable in communicating design within the product team. We believe that these tools can give design a greater voice in product development, and ultimately a better opportunity to serve the end user by introducing user-centered design methodologies.

A few words about the audience for design deliverables Typically, when designers and usability professionals think of audience, they think of the end users of the products. In this paper, we refer to the audience of coworkers responsible for all stages of product delivery, from definition to implementation. Although many of the roles we mention are familiar, a few can vary widely from between organizations. In our experience:  product managers are responsible for strategy, direction, and definition of a small number (typically less than five) of products; to the rest of the organization, they are often seen as the key representative for a product. They informally lead the multi-disciplinary product team and are often the final decision makers for issues that arise.  business owners typically manage a market segment which supports many products and are accountable for partner and advertising relationships, as well as product promotion, launch strategies, and success metrics.  project managers (aka producers) facilitate team communication, manage schedules and meetings, track issues, etc.

Download Our Slides, Templates, and More We’ve made the slides and examples associated with this presentation available for download at http://www.leacock.com/upa2002 Concept Maps A concept map represents key concepts and relationships within a given context. The nature of the relationship between concepts is described propositions: two or more concepts linked by words describing their association. These propositions may be simple (“people ask questions”) or compound (“people ask questions of a source to get information.”)

Fig 1: A concept map.

Audience and benefits of concepts maps Concept maps seek to capture the mental model of users and evolve from research with end users and domain experts. For the product team, a concept map defines a common reference vocabulary for the product that will be employed throughout development to foster shared understanding. Product managers can also benefit from the concept map’s ability to cleanly encapsulate business or technology models. By formalizing the knowledge of team members, concepts maps help bring team additions up to speed with the project, and reduce the damage done if key individuals leave the team.

Tips for effective concept maps  Be precise with the language used in a concept map — the less ambiguity, the greater the shared understanding.  Start drawing your map at the beginning of your analysis, and redraw it frequently. With each addition or refinement, there is the opportunity to discover new relationships between the concepts.  Make use of some organizing principle to manage the complexity of the concept map. We recommend making a smaller set of key concepts and a set of dominant propositions more prominent; this enables the reader to get a sense of the general structure of the map, allowing them to delve in to greater detail as needed.  Validate your final concept map with all of your collaborators to see if it still captures their understanding. Wireframes and Storyboards A wireframe is a rough layout of a specific user view, addressing the positioning of information and controls within a view, including clustering, ordering, and hierarchy. It is a skeletal view of an interface that seeks to organize the content of one specific view without being distracted by branding, visual design, and other concerns. A storyboard uses a sequence of wireframes all following a particular scenario in order to illustrate a sample series of interactions. In the same way a film director would use storyboards to show how the key shots in a sequence will relate to each other to form a whole experience, a UI storyboard highlights the key interactions that will correspond to a user’s experience of a particular task.

Fig 2: Left, a wireframe. Right, the same wireframe in the context of a storyboard.

Audience and benefits of wireframes and storyboards Wireframes are often the first tangible fruits of design work following time spent in research and analysis. As such, they are often of high interest to fellow team members. For product managers and business owners, the wireframes begin to show the vision for the product; the wireframes can help facilitate the buy-in process with the larger organization. Engineers and technical writers can infer the general number of views and complexity of the product, which is important for creating their work estimates. Visual designers can see the skeleton they will flesh out and start their explorations. Additionally, the wireframes can be placed in front of test users. Storyboards extend the vision of the wireframes into a larger sense of the user experience — they go beyond the “look” of the wireframes to speak to the “feel” of the product. By telling a clear story focused around a legitimate user task, they become especially valuable to share with executives and serve as a useful introduction to the product for new team members and external stakeholders.

Tips for effective wireframes and storyboards  Use wireframes to generate low-fidelity usability test prototypes (even paper testing works) to get user feedback before engineering effort begins in earnest.  Iterate through versions of wireframes quickly. Wireframes can be produced quickly using pen and paper, but vector-based drawing packages such as Illustrator, Freehand, or Fireworks can also produce malleable wireframes. Make use of wireframes’ flexibility of fidelity; start simple, but increase fidelity as you iterate.  Use wireframes to compare different design solutions and alternate directions at low cost and effort. Changes to the design are still very “cheap” at this point, but will become more and more costly the further into the development process they occur.  Be sure to choose a representative and compelling scenario to illustrate as your storyboard. Put the focus on new views and interactions, and abstract away (or gloss over) familiar behaviors.  Segment your storyboards based on distinct user tasks instead of creating a single, comprehensive, end-to-end storyboard. For each task, show clear entry and completion steps.  Don’t rely on a storyboard to speak for itself — detail context and user motivations in text beside each wireframes. Flow Maps A flow map demonstrates the navigation and high-level behavior of a product. It draws together all of the available wireframes and shows the paths between them. It can show conditional behaviors and indicate trigger points for backend processes.

Fig 3: A portion of a flow map. Inset: full flow map with portion highlighted.

Audience and benefits of flow maps A complete flow map details the scope of the product; it is a final inventory of all of the distinct views to be built by engineering and documented by technical writers. Product managers, business owners, and QA can validate the completeness of the design solution through the flow map: each use case and product requirement should be fulfilled by walking a path through the flow map. In our experience, exhaustive flow maps become rather large when printed; we typically print flow maps onto poster-sized paper 3’ tall by 6’ or more wide. As a result, a flow map is usually posted in a space common to the team, and becomes a natural gathering point for the team. A large map can be understood at different scales: some may just look at the overview of a flow, while others may focus in on a portion of a single wireframe.

Tips for effective flow maps  Do your best to manage the complexity of large flow maps: organize wireframes into clusters related by the task they support; use color-coding and clear labels; use “jumps” to avoid excessively long flow lines.  Employ a standard visual vocabulary for your flow maps and include a legend that explains it.  Show navigation for all key page elements. Handle recurring navigation components such as high-level menus, sidebars, etc. via callouts so you don’t need to repeat them in every wireframe.  Hang a full-size flow map in a common area and encourage your team members to write on the flow maps. Have a maintenance strategy — plan in advance how frequently will you print updated maps.

Detailed Mockups and Functional Specifications A detailed mockup provides the visual fit and finish for a wireframe, taking it into a state fit for production. It includes final visual design, coloration, branding, and iconography, as well as the exact sizes and spacing of elements. A functional specification details all the behaviors associated with a particular view. This includes default values, value ranges, how controls respond to each other, error conditions, etc. — anything that is necessary to fully define the functional behavior of the interface. Audience and benefits of detailed mockups and functional specifications Detailed mockups and functional specs form a de facto agreement among the team as to what is being built: we will create these views; they will look like this and behave like this. These documents should describe the product fully so that engineers can build it, technical writers can document it, and QA can test it. The detailed mockups should fully specify the visual design of the product, and will be valuable for product owners seeking final product approval from business owners.

Tips for effective detailed mockups and functional specifications  Detailed mockups should leave nothing to the imagination: clearly call out sizes and spacing, distinguish between system and graphical text.  Don’t just show the “best case” in a detailed mockup or functional spec — carefully consider maximum field widths, and character counts. Pay attention to edge cases: empty or full containers, beginnings and ends of sequences, and error conditions.

Conclusion We have found that much of the strength of the design deliverables we have discussed comes from their inter-relations; work done at one stage of the design can be re-used and refined in the next. The relationships between these tools, and other more familiar tools we have not discussed, is shown below. This is admittedly an idealized view, and few projects will make use of all of these methods; budget, schedule and audience typically dictate the breadth of design effort.

Fig 4: A concept map for UI design deliverables UI professionals are often looking for ways to give good design practice and feedback from user testing greater influence in an organization. We have found success in using the tools described above to achieve these aims; a success we attribute to their usefulness for our coworkers.