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.

How to improve the purchasing process

I’m lucky. During the recent years I had the opportunity to work in the design and implementation of some of the most important Italian e-commerce websites.

It is interesting and instructive to work for an e-commerce website, because it’s not an end in itself, but it’s a support to the sale process and must not only work, but should work well, very well.

For those working in the field of user experience, an e-commerce website presents unique opportunities to propose and implement improvements to the site and check the result immediately.

Among the different areas of an e-commerce site I like to get to work on the checkout process because it represents a real challenge where each text, label, button must be filed and polished. The checkout process is composed by features that perform the dual purpose of proposing to the customer precise information about what it is supposed to do and to receive information on how she prefers to complete the purchase.

I think that performing multivariate testing sessions on a checkout process is an experience that every user experience specialist should have the possibility to try.

I planned several times to write about the checkout process with regards of user experience, but the topic is complex and an article of few paragraphs (or a chapter in a book) are likely to trivialize or don’t allow to appreciate the details and strategies that need to be addressed in designing a checkout process that works in all its aspects.

Even writing one or more checklists as a reference (I love checklists) makes little sense if they are not accompanied with a detailed document.

That’s why I prefer to present two interesting reports that analyze in detail the checkout process.

The first is E-Commerce Usability Checkout, written by Jamie Appleseed and Christian Holst of the Baymard Institute. It is based on sessions of usability tests that involved 10 users browsing 15 e-commerce sites: 1-800-Flowers, AllPosters, American Apparel, Amnesty Shop, Apple, HobbyTron, Levi’s, Newegg, Nordstrom, Oakley,, PetSmart, Thomann, Walmart and Zappos.

The result are 63 guidelines grouped into 6 categories (data input, copywriting, layout, navigation, flow, focus) that in 140 pages deal with a wealth of examples, both positive and negative, regarding the checkout process. Some guidelines are definitely known to those involved in user experience (such as the design of forms, a topic dealt with detail by Luke Wroblewski in Web Forms Design), others are perhaps less obvious.

It’s a pity that only few of the many examples are devoted to the cart page, since it is closely and logically related to the checkout process and so it’s perhaps the most important of the whole process.

Interesting it’s the inclusion in the appendix of a 4-page checklist ready to print.

The report costs $ 78.

The second study that I want to present is E-Commerce User Experience, vol. 4: Shopping Cart, Checkout and Registration written by Amy Schade and Jakob Nielsen of the Nielsen Norman Group. The file is one of a series of 13 other e-commerce reports, but it is sold individually for $ 98.

And it’s money spent well, because the authors do not skimp guidelines and examples, so that the report covers more than 300 pages full of screenshots, tables, in-depth analysis and best practices.

In this case the report is based on a previous version made in 2000 that has been updated with the results of user and eye tracking testing based in several European, American and Asian cities.

Compared to the report of the Institute Baymard, that of the Nielsen Norman Group is more thorough and therefore certainly requires some effort to be studied in all its parts. Often the most interesting indications are not so much in the guideline itself, but in the details presented in the text.

The report can’t however be defined boring to read, since the authors often quote the expressions used by the users during the test (just to give you an example: “That’s really a pain in the ass”).

Which one of the two reports buy? If it does not scare you to study more than 300 pages, the report of the Nielsen Norman Group is certainly thorough and detailed, but if you are interested in a briefer report, but still rich in examples, and a with a handy checklist ready to print and apply, the report of the Institute Baymard represents an excellent alternative, which also allows you to save a few bucks.

Recruitment and social networks

Two reports, published by Jobvite, analyze the relationship between social media and recruitment, with special regards to the American job market.

They are 33 essential recruiting stats and Job Seeker Social Survey 2011. In short:

  • 55% of the companies surveyed plan to invest more resources in the next year for recruiting with social networks
  • more than 80% of companies use LinkedIn, but just 30% of job seekers is in LinkedIn
  • 89% of the U.S. companies surveyed indicated their willingness to use social networking as a tool for recruiting
  • LinkedIn is confirmed, with 73% of usage, the largest social network in terms of recruitment, followed by Facebook (20%) and Twitter (7%)
  • 2/3 of the companies surveyed have hired thanks to social networks

On the same topic there are two interesting infographics published by Mashable, the first with suggestions on how to protect and improve the professional online presence, the second presenting the results of a survey based on recruiters and the relationship with social networks.

And, speaking of statistics and surveys, I remind you that also this year A List Apart published one for anyone who works with the web. Starting from the results of a previews survey, in 2008 I tried to give an interpretation to better understand the role of the web project manager.

The clone of documents war

A web project manager produces different kinds of documents including analysis, presentations, benchmarking, debrief, even wireframes. I work for many different companies and it happens that i am asked to use ready-to-use templates with institutional logos, colors and fonts.

This is where the battle begins. If it usually takes a couple of hours to produce the documentation, trying to make it fit into the template that was handed to me is often a titanic task.

The problem is that it is not, in most cases, a real template, but a clone of documents that have been emptied of content and with no trace of formatting guidelines.

Font type and size have not been made as document styles, but they have been applied to the text whenever necessary. And even if styles were used, they were only for the main text and (perhaps) for a type of header.

This approach is inefficient for several reasons:

  • every time you insert a new element, such as a title, you have to copy its style from the previous one
  • you lose the “semantics” of the document: headers should be as that because the information is specified in the document, while in these documents they are headers simply because the font is “bigger” than the one used for normal text
  • quality will degrade over time: the first two documents will comply with the standard in some way, the next will lose almost all the formatting
  • it is not possible to apply the styles at a later time, for example in the case of documents already produced; they have to be re-edited item by item

This occurs with Word documents, but not only. Powerpoint and Keynote also suffer the same problem. Rather than invest a half a day to create the master slide which can then be applied in each presentation, it is considered a simpler approach to create a presentation with some slides which are then copied and pasted over and over again.

Whenever I can I ask for the clients their “template” before producing documentation, so that I can check how they are made. If the quality is not satisfactory to me, but the number of documents that I plan to write is small, I still use these templates to produce the documentation.

But if have to write many documents, I usually prefer to invest some hours to completely rebuild the template. The operation usually takes me a couple of hours (in case of a presentation a little more), but it is time well spent, especially for me.

On the surface, compared to the template that was handed to me, nothing changes. But the work of producing the documentation is surely reduced.