Design Tidbits

back Tidbits Overview

Tools for Design and Visualization

Simplification

Interaction Design

Screen Design

Hierarchies

Visual Design

Design Process

Web, Web Applications, Web Design

Performance

Miscellany

 

 

My Design Tools – Part I

By Gerd Waloszek, SAP AG, SAP User Experience – Updated: January 19, 2009

Prototyping | Paper | Whiteboards and Flipcharts | Image Files | Presentation Programs | HTML | Which Tool Do I Use When? | Final Word | References

Recently, I received several questions regarding the tools I use for creating user interface designs. In addition, I was engaged in some "quick-and-dirty" design projects, which involved redesigning applications, making design proposals, and creating prototypes. So, I thought it might be useful for the visitors of the SAP Design Guild to write down my "refreshed" experiences. In two articles I present a collection of tools, procedures, tips and tricks, which reflect my personal approach to user interface design. Hopefully, you will find some useful bits for your own work practice. Perhaps, these articles will inspire some of our readers to also tell the SAP Design Guild community how they approach user interface design.

One of the most important parts in my design work is to create design proposals in the form of design sketches, more elaborated screen designs, and prototypes. Therefore, this first article is devoted to these issues. In a second article, I describe how I use a small Website for communication with the development team and as a "protocol" of my work. I conclude the second article with a couple of image and digicam tips & tricks.

 

Prototyping

You can build prototypes in a number of ways, each having its advantages and disadvantages. See the articles "Using Prototypes" in the Design Tidbits and "Which Type of Prototype?" in the Editorials for details and points of view. See also the References for in-depth information.

My basic approach to prototyping is a mixed one: I use

  • Paper or a whiteboard for the first raw sketches of an application's user interface and navigation
  • Static images for redesigning screens or making design proposals for screens – often based on screen dumps from existing applications
  • HTML prototypes, either LoFi or HiFi (see below) for adding (limited) dynamics to the design proposals

As I will show below, there is a "natural" place in the design process for each of these tools.

 

Paper

Paper is probably the fastest and most flexible design tool; as I have rarely been involved in new design projects where a software product had to be defined from scratch, I am not an "experienced" paper prototype designer. Typically, I use paper for raw screen sketches, but usually not for more elaborated paper prototypes as promoted by several authors (see References).

For paper prototypes, there are a wide variety of "tools" available:

  • Paper and cardboard of different colors, Post-it notes
  • Sticky tapes, pens (permanent and non-permanent) and threads of different colors, transparent tapes
  • Erasers, scissors, glue, pins, water (for erasing), etc.

Paper prototypes have many advantages – I mentioned already the flexibility and speed. As everybody can create them, the users can, too. Thus, paper prototypes are a perfect means for letting users "co-design" a user interface: For example, after a user test you can ask users which changes they would make to the interface.

Example of a paper prototype

Figure 1: Example of a paper prototype

On the other hand, paper prototypes are "fragile"; they are easily "destroyed" by accident. I also experienced acceptance problems on the side of the developers – not on the side of the users. Paper does not seem to be the "language" that developers talk.

Simulating Navigation

If your application uses several screens, you can attach the paper mockups for the individual screens to a wall and connect them through arrows made from cardboard to indicate the navigational paths. Alternatively, you can use pins and colored threads (which should not be too thin) for the connecting lines.

If you are lucky like me, you or your company owns a digital camera, so that you can take snapshots of the design stages or variants. You can then distribute these images and use them in documents or presentations.

See my second article for some digicam tips and tricks.

 

Whiteboards and Flipcharts

A whiteboard is also useful for sketching screens and the navigation between them. "Redesign" is even faster than on paper. However, space is limited and you may be forced to erase intermediate stages. A flipchart is equally useful but erasing is not that easy and typically it is much smaller than a whiteboard. You can tear off the pages and paste them to the wall or a whiteboard.

While you can take the sheets of a flipchart with you, your sketches on a whiteboard may present a problem when you want to use them after the meeting. Often other people may want to use the whiteboard as well if it's in a public meeting room. So what can you do? Again, if you have a digital camera, you can take snapshots of important design states. But there is another option called "mimio". mimio is a small device, which can be attached to a whiteboard and records all pen and eraser movements (for details, see Virtual Ink's Website at www.mimio.com). As with a camera, you can take "snapshots" of important design states, and you can even replay the whole design process. In the end of a session, you can save the session in a proprietary file format, which creates small files because it is vector-based. If every member in the design team has the mimio software, which can be downloaded for free from the mimio download page (please, read the software licensing agreement first), he or she can inspect the files, change and annotate them, or export them to other file formats. We found some drawbacks when working with mimio, for example, you have to write clearly and to press the pens firmly against the whiteboard, but nevertheless it can be a very useful tool. Note that there is also a new "flipchart version" of mimio, so you are not restricted to whiteboards with mimio.

mimio connected to a whiteboard and a laptop computer

Figure 2: mimio connected to a whiteboard and a laptop computer (image taken from mimio Website with my own drawing)

There are also whiteboards on the market that can print their content. But these boards are expensive, heavy and typically tied to one room. In contrast, mimio or a digital camera can be used in any room with a whiteboard or flipchart.

Update: Steve Bang drew my attention to WhiteboardPhoto from PolyVision, a small application that cleans up whiteboard images taken with a digicam. I will return to this application in my second article, when I discuss how whiteboard photos can be improved.

 

Image Files

Image files are an intermediate step between designs on paper and more refined electronic prototypes, but in a different way than PowerPoint presentations. Typically, I use image files when redesigning existing screens, which I took screen dumps from.

First, I take a couple of screen shots from an application. Then, I redesign the screens in an image processing program, such as Adobe Photoshop. Typically, I use this approach in "quick-and-dirty" projects for discussions with the developers.

As the screens usually originate from "original" screens, they look like real application screens. However, they are rarely correct on the pixel level. There basic intention is to demonstrate a user interface design in a "realistic" setting. That is, most size constraints are taken care of. For example, such a screen would not be 120 columns wide if a real screen can only be 80 columns wide. A typical drawback of paper prototypes and sketches is that they give no clue on what really fits on a screen.

Annotating Images

Screen images are perfect for printing and annotating them. Using annotated images you can easily propose changes to the user interface and hand them over to the developer (make a copy for yourself, of course). This is far better than just telling the developer what you want to be changed because words are easily forgotten. It is also less work than doing the redesign yourself in a graphic editor. I would propose the latter only if the redesign requires a major restructuring of the screen and if it's hard to imagine the new design.

If you need to discuss your proposals with a larger team or with colleagues in different locations or even continents, better use an electronic medium for annotations and comments. Paste the images into a presentation program, such as PowerPoint, and annotate and comment them there - there is a large set of tools at your disposal for this purpose. Regrettably, HTML is too inflexible for annotating images fast and easily; you can only write a comment next to an image. So, if you prefer HTML pages as medium you can convert PowerPoint slides into images and include these in your HTML pages – but that's too cumbersome for me. Alternatively, you can save a PowerPoint presentation as a set of HTML pages. PowerPoint automatically converts the slides into images, places them on HTML pages and adds navigation buttons. Personally, I do not like the results because the images are scaled poorly.

See the second article for some image tips and tricks.

 

Presentation Programs

PowerPoint or similar presentation programs could be indeed the ideal prototyping tools because they offer a good compromise between paper and "electronic" sketches or prototypes.

Advantages

I see the following advantages in using a presentation program, such as PowerPoint. It ...

  • is fairly fast and flexible; for example, shapes can be modified and moved around quickly, text can be changed fast and easily – so layout changes can be made fairly fast
  • has all the "tools" for creating simple prototypes – you could even create a small library of screen elements
  • can include custom elements (via "insert object")
  • can demonstrate navigation via hyperlinks or buttons – this adds dynamics to the prototype
  • makes it still possible for users to "CO-design"; however, typically the UID will change the design (some users may know PowerPoint well enough to do this on their own)
  • lets you easily add callouts and comments to the design sketches – this is useful to indicating design problems or for proposing design changes
  • is convenient for demonstrations but can also be used for user tests (similar to paper prototypes where typically a UID plays the "computer")
  • can be used on PCs and Macs – no computer platform problems

Disadvantages

  • To my opinion, many graphic functions are cumbersome to use – at least I know of easier to use graphic tools...
  • The dynamics of the designs/prototypes are limited
  • It is hard to achieve an exact look of the application (except via importing images)
  • Image (bitmaps) scaling may be problematic, e.g. it may be hard to achieve consistent scaling over slides because PowerPoint tends to scale images according to how they fit on a slide

Potential Traps

  • If you use the presentation on another computer, make sure that PowerPoint is installed on it. To play safe, you can save the presentation as a stand-alone presentation. Alternatively, you can use the player software which can be downloaded from the Microsoft Website for free (so, be sure to have that with you).
  • If you include custom controls these may not be available on the target computer. So, either do not use them or have the respective elements ready if you use the presentation on another computer.

Collecting Examples

Presentation programs come also in handy if you want to collect and document examples. For instance, you may want to see how different magazines design news pages, which common design elements these pages use and what are some communities between the examples. So you simply go to the Web pages, copy the ones you find interesting to the clipboard (Alt-Print) and paste them into a presentation (typically one per page). Later you can annotate the examples – I mentioned this already – and show them to your colleagues for discussing them. Another example would be that you collect screens from SAP applications for comparing the different approaches to a common design problem (this may be the beginning of a standardization activity...).

You can alternatively collect your examples using HTML pages. Both approaches have their advantages and disadvantages – I discussed this a little bit above. There is one more point to observe: if you want to experiment with the screens or use them as the basis for a redesign you may find that they cannot be properly copied from the presentation – but see the second article for a workaround. If you use HTML pages instead you also have to be careful to create images that can be easily used for further manipulations (see the second article for details on file formats). So, whichever your approach is, I recommend to save the screen shots as image files first (I recommend to use the TIFF format with LZW compression), before you paste them into a presentation or change the format to GIF or JPEG (see the second article for details on file formats).

Further Applications

Presentation programs can also be used to draw application structures and other schematic diagrams. Often I draw the diagram in PowerPoint, go into presentation mode, take a screen shot and then resize and modify it in a graphic program for further use (maybe, this is due to the fact that Adobe Photoshop is weak in this respect...).

 

HTML

Let's return to prototyping. HTML prototypes require more or less knowledge of HTML – depending on the tools that you use and the desired accuracy of the graphic design. Using a WYSIWYG editor such as Macromedia Dreamweaver, Adobe Golive, MS FrontPage, or even MS Word you can achieve a lot – as long as you do not need to design accurate to the pixels. Usually, such a precise design would not be the job of a user interface designer or usability engineer. I do not recommend a specific tool (currently, I am using Dreamweaver), as each has its advantages and drawbacks. Use the one that you like most and which is the easiest to use for you.

For the following, I would like to distinguish between three types of HTML prototypes: Simple , LoFi and HiFi prototypes. Note that Hackos & Redish use a slightly different classification of prototypes. Especially, they have an intermediate-fidelity prototype which corresponds to the above-mentioned PowerPoint prototypes (also called "computer-generated" prototypes).

Simple Prototypes

The simplest HTML prototype that I use displays one screen image on each HTML page. The image as a whole then serves as link to the follow-up screen. This way you can simulate simple screen chains and get a first impression of the look of the application and the navigation through it. If you do this for a Web application you should crop the screen images to the content area of the browser window, otherwise you would have a "browser inside a browser" and might mistakenly click the wrong buttons...

You can refine the navigation and make it more flexible by using image maps for buttons, links, tabs, or other screen elements that cause screen transitions. Image maps allows you to implement transitions to more than one follow-up page. Most WYSIWYG HTML editors offer easy-to-use tools for creating image maps without having to recur to coding. Note, however, that this technique cannot cover all possible screen transitions, especially if there are certain conditions to be observed. If there are conditional transitions and not too many conditions you can simulate them by offering several links with text indicating the condition. This is no longer a "WYSIWYG" design but in most cases it will be sufficient.

Adding image maps and links to navigation buttons in a WYSIWYG HTML editor is straightforward

Figure 3: Adding image maps and links to navigation buttons in a WYSIWYG HTML editor is straightforward (here in Macromedia Dreamweaver)

Note that the image map technique is needed because the HTML page just includes one image – you cannot place links inside an image. A simple alternative would be to place a number of text links below or above the image.

The next two types, called LoFi and HiFi prototype only differ with respect to how much they try to imitate the final graphical design. Both types can use simple links and image maps only, or can be enhanced using scripting, such as Javascript. Obviously, you can make such a prototype arbitrarily complex, but I urge you to refrain from doing so. For most demonstrations a simple link-based functionality will do. There is no point in spending two weeks for programming a prototype, which is used for a 5-minute presentation only. A different matter is using such a prototype for user tests. But even in this case, a tester can play the part of the computer as is necessary with paper prototypes. Only stand-alone or remote tests, where users are on their own, would really require a more or less completely functional prototype.

Low-Fidelity (LoFi) Prototypes

A LoFi prototype uses simple presentations of screen elements for demonstrating the user interface design. Thus, it may look quite different from the final application. Hopefully, everybody realizes that this prototype is just a schematic prototype of the user interface so that discussions on taste etc. will not arise (which is an advantage of paper prototypes.). Complex elements can even be realized as images, because it is not the intention of the prototype to have the full functionality of the application.

LoFi prototypes are better suited to the earlier design stages where the interaction design is of primary concerns. They can be used for user test as well as for presentations. However, in the latter case you should caution the audience that the final application will look differently.

Example of a LoFi prototype with schematic

Figure 4: Example of a LoFi prototype with "schematic" design

I once created a simple Website, which served as instruction and screen elements library for creating LoFi prototypes. However, as most Websites do, it ended up unfinished...

High-Fidelity (HiFi) Prototypes

A HiFi prototype also tries to mimic the graphic design of an application or Website – more or less closely as possible. Therefore, such a prototype provides a far better impression of the final application. Developers can use it as a direct model of the application. This is an advantage as well as a disadvantage, because the prototype is rarely as exact as the developers believe. Thus there is the possible danger that the developers not only faithfully copy the right things, but also the errors or impressive features of the prototype. In addition, not always is the final design known timely and there may be changes to be made to the design. In addition, such prototypes typically invite the participants to engage in taste discussions instead of looking at the more abstract aspects of the prototype.

Example of a HiFi prototype

Figure 5: Example of a HiFi prototype which tries to imitate the final graphic design more closely

I use HiFi prototypes especially for "quick-and-dirty" projects where there is no time left for staying on an abstract level for long. HiFi prototypes are also useful in the later design stages for demonstrations and user tests.

 

Which Tool Do I Use When?

This question has the simple answer "it depends". There are many possible routes to a design proposal. Typically, there is a "natural" progression from the more simpler and flexible approaches to the more sophisticated and elaborated ones. The latter resemble more and more the final application but are far less flexible and require much more work. In each case you have to consider whether this additional work is justified with respect to the time and project constraints.

Below are two proposals how you can utilize the different tools and approaches during a design project.

New Design

Whiteboard -> Paper -> PowerPoint -> Screen Images -> HTML prototype

Reasoning: You start with very rough sketches on a whiteboard during group discussions. A small team may then create a paper prototype from the results and test it with users. As the design stabilizes, it may be useful to create an electronic version of the prototype for presentations and possibly additional user tests. Finally, when the implementation of the user interface comes closer, the development team wants a more "vivid" model of the application. So you create an HTML prototype; this prototype, can also be used for presentations, user tests and exploration of design alternatives, the latter, however in a smaller scale (i.e. the alternatives stay within the "basic" design).

Redesign

Screen Dumps -> Whiteboard/Paper -> Screen Images -> HTML prototype/PowerPoint

Reasoning: As there already exists an application or a partially implemented one, you make screen dumps to get to know it. After you have collected all the relevant screens, you may want to redesign the structure and navigation of the application on a whiteboard. As it becomes clear which screens will be used and in which sequence, you move over to the detail design of the screens in an image processing program. Finally, you create an HTML prototype as an "application model" for the development team.

 

Final Word

In a second article I present how I communicate with developers during a design project using a small Website. There I also give away some imaging tips & tricks.

 

References

  • Hugh Beyer & Karen Holtzblatt (1998). Contextual Design. San Francisco, CA: Morgan Kaufmann Publishers Inc. (for (paper) prototypes, see part 6 Prototyping)
  • JoAnn T. Hackos & Janice C. Redish (1998). User Task Analysis for Interface Design. New York: John Wiley & Sons. (for prototypes, see chapter 13 Prototyping the Interface Design)
  • Carolyn Snyder (1998). Paper Prototyping: Easier Than it Seems. Eye for Design (User Interface Engineering), Volume 5, number 5, p. 9-10.
  • Tara Scanlon (1998). Paper Prototypes: Still our Favorite. Eye for Design (User Interface Engineering), Volume 5, number 3, p. 2-4.
  • Virtual Ink Website (mimio): www.mimio.com
  • Download the PowerPoint 97 viewer from Microsoft
  • Thumbs Plus (Cerious Software Inc.): www.cerious.com (the current version is 6)

 

top top