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

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.

Learning from one’s mistakes

Some projects fail. Once I received this email from one of our clients:

Good morning [account manager] and Antonio,

we want to express our disappointment regarding your behavior and the work done.

We believe that the many requests and modifications we are asking you are a direct consequence of your work. We refer, in particular, to the fact that we asked you a_b_c while you proposed us d_e_f. You can agree with us that in this way our objectives were not met. We are now in the process of putting online a product that is quite different from the one that we wanted.

Our criticism is based on the lack of suggestions and ideas from your side – experts in this field – and on your attitude of mere executors.

Shocking, isn’t it?

A message with such a tone isn’t a bolt from the blue, but rather a direct consequence of an email sent by us in which, rudely, we ask the client to allow us to close the several activities in progress and to stop adding new ones every couple of days. Obviously this is not the right approach. It’s just the last in a series of errors that, from both parties, characterized the whole project.

Before analyzing what has gone wrong it’s important to put the project in its context:

  • the first meetings with the client were held  a year and a half before this email;
  • the project covered the creation of a web site with features such as booking, searching, non-standard e-commerce procedures, and with a link to an external and proprietary information systems for price lists and address books;
  • the site was meant to substitute the previous version, built by our agency;
  • after the requirements analysis phase and several brainstorming sessions, we presented a working prototype containing the main features of the project.  The client was given the opportunity to experiment with the prototype for some weeks;
  • the total effort estimate was 350 man-hours.

The client, even if it doesn’t seem so by reading the email, has been involved in every step of the project

  • the gathering of useful elements for the project were based on a series of meeting where the client set his expectations;
  • we developed a working prototype of the application, sharing every detail with the client;
  • we chose to split the project in about 5 parts to shorten the deployment and let the client test the various functionalities

These seems to be solid basis for building a valued product. The email we received, however, is not on the same wave lenght: our client is unsatisfied, convinced this is not the product he wanted and expresses doubts regarding our expertise. How can this be possible?

If we take a deeper look at what happened, however, we can easily notice that many mistakes were made, on both parts. Here’s a list with the most important ones:

  • Mistake #1: you need a brand new site – It all started when the client expressed some perplexity regarding the site currently online. The site was fine after all, but there were some bugs (above all there were usability problems, especially of interface coherence). At this point the client is persuaded to redesign the whole site and he is promised a better, more usable, faster one. Maybe it was not necessary a complete redesign.
  • Mistake #2: it will cost you 100. No 300. Let’s make a deal: 200 – Without any analysis a first estimate sent to the client is far from the truth. Having developed the previous version doesn’t necessary mean that estimation for the redesign is easier. The real estimate is three times the first one, the client is astonished and we agree on a price that disappoints both parts.
  • Mistake #3: a phantom, not a client – We did not stress enough that we needed their help and approval throughout the project lifecycle. Approving a prototype meant to the client that the development phase was just a boring activity with no decisions to be taken on their side. We did, to be honest, included an estimation of their effort in the project documentation, but it was not enough. We waited weeks for an answer, sometimes.
  • Mistake #4: client contacts not motivated – To succeed, everyone involved in a project has to master communication skills, especially the project manager and the people on the client side that relate with her. That didn’t happen. The project was assigned to a freelance that didn’t succeed in answering doubts and questions and evaluate proposals. When you are in such a situation raise your hand before it’s too late.
  • Mistake #5: software is intangible so you can change it till the last minute – Even if it’s possibile to evaluate a change in the specifications, this has to be seen as an execption, and not a rule. The project seemed ready to be put online, but not on the client’s mind.
  • Mistake #6: the site doesn’t do what i wantThe site doesn’t have to behave as you want, but as your user want.