More on sketches and paper prototypes

After “Designing with paper” in which I present the method I use to create prototypes with the help of paper sketches, other resources have been published that further explore this topic.

The Messy Art Of Sketching UX from Smashing Magazine goes into detail, illustrating the main techniques:

  • color to highlight the importance of certain sections
  • sticky notes while creating tool-tip, popups and modal windows
  • photocopies to make sketches a generative process

4 ways to prototype faster collects in a short article what I would suggest on this subject:

  • start the process working with paper
  • adopt a single software to create prototypes, not a selection of tools (Photoshop + keynote + Balsamiq + Dreamweaver)
  • look for a solution that can also produce the functional documentation
  • use tools that help you share your work

5 Sketching Secrets of Leonardo da Vinci presents some suggestions on how to improve the sketching process by looking at the works of Leonardo da Vinci. The comparison is perhaps hazardous, but not the suggestions:

  • make different sketches in order to create different perspectives of the same concept
  • complete the sketch with notes that help clarify the context and the elements that are not easily deduced from the single interface
  • the purpose of the sketch is to be criticized; the process is collaborative
  • the solution to a problem can come from different fields
  • learn how to categorize and save your work, so you have a database of alternative solutions

Behind the scenes of a project

You can’t imagine how much I’d like to write on this site regarding the details of designing and building an online project, especially one that involves large and many different professions.

But I won’t do it.

I won’t do it not because I do not want to share what I learned in those 15 years of work.

I won’t because I can’t.

I can’t because the first thing I am asked to do during my consulting activities (and, in the past, as an employee) is to sign a non disclosure agreement that states that I can’t share the details of my work.

If don’t want to judge if signing clauses of this kind is an effective strategy, but I regret not being able to share experiences and practical case studies that are difficult to find reading books. The reality is often different from what we read in academic texts.

Proposing non disclosure agreement, however, is a vice that propagates with a certain speed. If until recently this was a problem of larger companies, more and more often I hear friends and colleagues who are asked to sign an agreement of this kind, even for projects of a few bucks.

But that’s not what I wanted to discuss today.

There are indeed lucky ones that are not afraid to share their experience in detail, as in the case of the BBC.

An example is the redesign of the weather section of their website, which has been masterfully described by the team: BBC Weather Design Refresh in Pictures. Why masterfully?

  • Because they illustrate the entire design process and not just a part
  • Because they host graphs and charts (like the one on the 5W – Who, When, Why, Where, What) that open full screen, so you are able to read everything with no secrets
  • Because they list the parts of the old site they have deleted, and the reason
  • Because they are not ashamed to show that everything comes to life from sketches on paper (see Designing with paper)
  • Because they state their vision and how to reach it
  • Because they stress the importance of icons and infographics in a project of this type.
  • Because they knew that describing in detail the complex redesign would have attracted the (inevitable) criticism of those who prefer the previous version (see comments 12 and 13)
  • Because they write the names of agencies and partners who have helped in the design of the site, instead of keeping them hidden (perhaps by signing a non disclosure agreement, just to return to the opening theme)

The fact they share their experience in detail probably derives from the fact that the BBC is paid for by users’ taxes and this is a way to show how the networks is using this money.

It would be nice that the Italian Rai could do the same, but given the quality of the projects they are perhaps in the previous phase, in which they have yet to learn how to effectively design a site.

Designing with paper

For some months now I am using with satisfaction a different tool for the design phase that follows the definition of the online strategy and precedes the creation of prototypes. I take a sheet of paper and hand-made sketches which can then be shared and evaluated together with the User Experience team.

Nothing new or that I had never tried, but I believe it is a practice too hastily abandoned because considered unprofessional.

Two readings helped me change my mind: Paper Prototyping by Carolyn Snyder and the recent Prototyping written by Todd Zaki Warfel and published by Rosenfeld Media. Both texts provide excellent tips on how to build prototypes with the paper and the book by Carolyn Snyder also explain how to use these prototypes for real usability test sessions with users.

I don’t prototype with paper. Paper helps me to design in the form of sketches the interface and the interaction of different ideas that can then be evaluated, rejected, selected with the team UX. It is therefore a quantitative approach, which aims to produce in a very short time several sketches that can then be analyzed by the team and criticized without the fear of having wasted hours or days of work. Each sketch should take no more than half an hour to be drawn.

I find the use of paper effective also when working with remote teams: I scan it and the sketch can be shared with the rest of the world.

Normally I do not use a sheet of white paper, but I do use a simple template that include the browser interface and some guidelines (for example, the most common resolution). On the Internet you can find dozens: I personally am very happy with the work of UIStencil (the template is available in PDF format).

The different designs are then evaluated together with the rest of the US team and usually put on a wall or blackboard.

Zaki Warfel in Prototyping summarized how this process should take place.

PT001: Figure 2.1

Diagram of the iterative design and critique process. Warfel, Todd Zaki. 2009. Prototyping: A Practitioner's Guide. New York: Rosenfeld Media. http://www.rosenfeldmedia.com/books/prototyping/

It is, as you can see in the diagram, an iterative process.

Sketching is the generative part of the process, whose objective is to propose different ideas without paying attention to details or inconsistencies (fast and furious).

The purpose of the critique phase is to find, among the different ideas, the best. The one that created the sketch lists the strengths while your teammates highlight gaps and require further investigation. This phase should last only a few minutes, because the details will be taken into account during the process of creation of real prototypes.

It’s at this point – that is, for prototyping and usability testing with users – that i abandon the paper. I prefer in fact to use tools to simulate a little more in detail the transitions of a typical web page, such as Ajax interactions. In this sense my favorite tool is Axure RP: it’s expensive, but allows you to create real prototypes rather than wireframes, on which the paper still wins.