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.

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.

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.

The 2008 web project managers’ census

In April the webzine A List Apart published the findings from a survey that – for the second year – tries to highlight patterns and behaviours among web job titles.

Last year I isolated some information regarding web project managers [in Italian] so it’s quite interesting to compare this hypothesis with the new findings.

There are several confirmations. A web project manager:

  • follows an educational path that usually starts in the programming field
  • usually works for small or mid-sized businesses
  • it’s 30 to 40 years old
  • works for a corporate more often than as a freelance

Let’s have a closer look at the findings.  Some questions are different from the 2008 so a direct comparison is only approximate.

Corporate versus freelance

Job title by workplace (2008)

This analysis was not included in the 2007 survey and it represents the percentage of web project managers that work for corporates rather than as freelances. Compared to the other job titles, a web project manager more often works as for a corporate rather than as a freelance.

This is not an unexpected finding and I’ve already answered to a similar question in the FAQ (Does the web project manager work for a company or is he a freelance?): in most cases a web project manager works for the company he manages projects for because the quality of the project depends on reciprocal people acquaintance. This approach is not profitable if the web project manager works as a freelance.

There are, however, situations in which the web project manager is a freelance; it works for one or more periods of time (usually semesters) in order to help the company in improving project management skills.

Percentage of web project managers

Job title (2007)

Job title (2008)

Looking at the 2 years there are not significant differences compared to the other job titles.

Quite impressive the “other” category, more than 1/4 of the total.

Job title distribution by organization type

Job title distribution by organization type (2007)

Job title distribution by organization type (2008)

The table shows the percentage of web project managers employed in different organizations (note that some categories have been merged with respect to last year).

The majority of web project managers (8.4%) work in small organizations.  This confirms a trend:  a web project manager most of the time works for a startup, an organization where frequent deployments and strict timing require a professional in charge for the achivement of the objectives.

Job title distribution by age group

Job title distribution by age group (2007)

Job title distribution by age group (2008)

There are not many differences between the two years. One is not born web project manager, but becomes a web project manager after some years of experience (usually when she is 30/35 years old).

Gender distribution by job title

Gender distribution by job title (2007)

Gender distribution by job title (2008)
There is a small increment regarding the role of females in web project management, and the same increment is shared by all the job titles, maybe an indication of the improved visibility given this year to the survey.

Percentage of job-title holders who earn salaries of $100k+

Percentage of job title holders who earns salary of 1000k (2007)

Percentage of job title holders who earns salary of 1000k (2008)

The trend of last year is somehow confirmed.

Perceived relevance of education by job title

Perceived relevance of education by job title (2007)

Perceived relevance of education by job title (2008)

There are some changes regarding the perceived relevance of education.

The fact that all job titles experienced an increase in satisfaction can be considered a sign that the question was better understood by participants than last year. In general, however, a bit more than 50% indicated as relevant their education, suggesting that there is room for improvement.

Job satisfaction by job title

Job satisfaction by job title (2007)

Job satisfaction by job title (2008)

The percentages increase a lot with respect of last year: maybe this is another case where the question was better understood.

Compared to other job titles, however, web project managers’ satisfaction increase in less proportion, leaving the top of the list.

It’s quite difficult to explain the reasons considering that the variation happened in just a year. Maybe the web project manager’s role, in some context, can’t find the room that it deserves.

But, on the other hand, it’s high time for the web project management to grow from a discipline that confine all the responsibilities to the project manager towards a source of leadership and vision.

Prelevance of blogging by job title

Prelevance of blogging by job title (2007)

Prelevance of blogging by job title (2008)

The web project manager is the tail-end when it comes to writing for a blog.

As suggested last year, the reason can be that it’s difficult to write regarding a job strictly related to human interactions and with many facets. Difficult, but not impossible. A pity.

Participation in formal training by job title

Perceived relevance of education by job title (2007)

Perceived relevance of education by job title (2008)

The web project manager is one of the job title holders that more take part in formal training. The percentage is close to the ones of professionals that are used to a constant training, such us usability and accessibility consultants.

This result can be explained by the heterogeneity of skills (managerial and technical) required for a web project manager.

Perceived skill gaps

Perceived back end skill gaps by job title (2007)

Perceived back end skill gaps by job title (2008)

Concerning back-end programming, less that 17% states to have some skill gaps. This result, compared to the other skill gaps graphs, confirms a trend: one becomes web project manager usually starting to work in areas close to programming, rather then design or marketing.

Web Form Design review

When I read on the Rosenfeld Media site that they published a book devoted just to web forms, I thought they exaggerated. I’ve always given form an important role in web design, but is it possible to write a whole book filled with patterns and suggestions without the risk of being repetitive and boring?

Luke Wroblewski succeeded in this task. You understand he succeeded because when you finish reading this book you’ll look at every form, designed by you or not, from another perspective.

The book covers every aspect of form design such as form organization, labels naming and alignment, input fields usage and my favorite, help text.

The approach of Web Form Design is very practical and you’ll find plenty of examples for different scenarios. Another good aspect of this book is that Wroblewski doesn’t present magic recipes.

How can we design good forms? Unfortunately, the right answer is a bit unsatisfying: It depends.

It depends on the business goals, user needs, and context of your forms. It may also depend on the issues or opportunities your usability testing, live site metrics, or other data sources illuminate. In other words, there isn’t just one right answer.

Fortunately, there is a way to go from the quintessential design answer of “it depends” to actionable solutions and ideas. We can do this by understanding the design considerations of the problem we are trying to solve. Design considerations are a combination of principles and patterns that provide a framework for finding appropriate solutions.

If you want to improve the way users communicate with you, this is the book to have. For more on form design you can take a look at this specific tag on my delicious library where you’ll find about 30 resources, some by Luke Wroblewski.

All the book’s illustrations are available free at Flickr and you if you buy the book fromt the publisher’s site, you can use the code FUCIWFD for 10% off.