Tag Archives: design

More on sketches and paper prototypes

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by
Reply

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, Perfume.com, 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.

Designing with paper

Posted on by
Reply

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.

Everything has its own name

Posted on by
Reply

I went to the client’s office with our art director and now he is ready to show various layouts to illustrate the project. He made some minor changes last night so we could not see them together. He opens the laptop and double-click cool.psd.

The colleague who develops the frontend sent an email containing the latest corrections requested by the company that will address the integration. Once unzipped the files, on the desktop appears the folder named WTF.

These are only two examples, but I could easily go on for hours and hours and never repeat myself. Ok_bis_def.zip, another_one.psd, today_i_lack_ideas.png: I have a whole literature of meaningless and embarrassing names.

Tired of spending days to rename the files and send them to different actors (if I still have time) I have developed a simple system of nomenclature which I try to apply and enforce.

The advice is to start as early as the wireframing phase, to continue during the graphic design up to the development of HTML pages. Each wireframe should properly be named before sending it to the art director, who is usually happy to keep the creativity for other tasks.

I’ve tried over the years different types of classifications, but the one that ended up being more effective is the result of a compromise between the highly informative content and ease of application of the rule.

A typical example of the nomenclature would be as follows:

  • HP010
  • PR010
  • CH010

The first two characters indicate the section of the site that the page refers to (in this case HP stands for the homepage, PR for product page and CH for the checkout), while the number indicates the sequence of the page within the section (HP010 may be the main homepage, HP020 a particular version for the Christmas period, etc..). I use tens as units because, if we find out that we forgot a template that “logically” has to be inserted between two others, we can include it (eg. HP015).

As you can see the rule is trivial, but for this reason is also easy to apply. It saved me a lot of time, but in particular it has allowed us to verify at a glance if all the template were made.