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

Related posts

• Designing with paper
  The creation of sketches made of paper is a quantitative approach that allows you to quickly evaluate and improve different solutions for the design of a service Continue reading →...
• 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 … Continue reading →...

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.

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.

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.

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.

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.

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.

Related posts

• 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 … Continue reading →...

This video contains an apt metaphor regarding the work of a web project manager: coordinate many projects at the same time with varying percentages of completion and communicate with many different actors.

The same happens during meetings. The project manager has to deal with the meeting agenda making sure that all cables are connected and that the network is working, taking notes to prepare the meeting report, and of course bringing the coffee from time to time. The risk is to forget important details.

And since in the past I forgot many details, I learned to use some tricks, especially for internal meetings.

I try to write and forward the agenda in advance via email. Spending 15 minutes to list the main points to be discussed during the meeting allows you to clarify both the arguments that deserve to be addressed and the order in which you are going to present them. It may be useful to use a projector so that the agenda is accessible by everyone. In fact, if the meeting lasts one hour and after 40 minutes you are still discussing the first 2 points out of 10, you should be worried. Advance the agenda, but do not expect everyone to read it. And ask for any other topic to add.

When I can, I record the audio of the meeting. No matter how much you developed your ability to handle multiple tasks simultaneously, there is still a limit. Instead of taking notes, managing the conversation and browse slides at the same time, try to understand whether it is possible to record the audio. Apart from asking permission (do not do it without permission) you don’t need much more. Almost certainly you will be there with a laptop, that means you can easily record the audio from the internal microphone (I use Wiretap Studio for Mac), but you can also use a portable recorder or phone applications.

Even if you are very good in note taking, knowing that you have a recording in case of doubt has no price. I listen to the recorder audio using ExpressScribe, a freeware that allows you to easily control the playback speed from the keyboard, so you can write down the salient points of the conversation. If you want to know more about this topic, I suggest you to read an interesting article written by Sam Barnes for his blog.

If audio recording is not an option, you can ask a colleague to help you in taking notes, so you can compare them at the end of the meeting.

In any case, do not wait too much time, otherwise it will be almost useless.

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.

• Build two different themes – You prepared your slides and tried them some days before on your office projectors (maybe waking up half an hour in advance so nobody could see you). But, when you present, you notice that the quality of the projector lamps is very poor and some contrasts are difficult to read. This is a problem especially for presentations that don’t make use of white bullet points on black backgrounds (or viceversa) but slides with sentences spread in different positions or text put over a photo. The risk is that the “special effects” you spent your nights on are invisible to your audience and that they can’t connect all the dots of your speech. Prepare two set of them (you can use both Keynote or Powerpoint) so that a version is highly contrasted. If, once on stage preparing, you find out that it’s difficult to read your slides, you can easily switch to the highly contrasted theme. Sure, you can use high contrast from the start, but chances are that if you spent hours refining your work, high contrast could not have the impact you wanted. In this way, you have an easy backup strategy. Moreover, you don’t have to prepare two themes every time, because once you define the theme that satisfy your needs, you can use it for whatever presentation you like.
• Put you Twitter username on every slide – When I was on stage at Better Software, the audience begun twitting excerpts from my talk. Unfortunately, one tweet contained a wrong username (avolpon instead of AntonioVolpon) and the following retweets and new tweets all preserved the non-existant username. So, if you can, if it doesn’t “ruin” your design, reserve a space where you repeat you Twitter username on every slide, and don’t limit this only to the first or last slide.
• If you build a story, wait for your audience – I am a big fan of Made to Stick, and since I read it I try to build a story in every speech I give, when it’s possible (at Better Software I presented my various job opportunities, starting from the military service). Be very careful if the story is mandatory to understand the meaning of your talk. If so, and your presentation starts after a break, or if the audience can choose among different concurrent sessions (and so needs to move from a room to another), I suggest you not to insert the story in the very first slides, but to (reasonably) wait for most of the people to enter and have a seat.

There’s also one with me. In the 30 questions I address many topics, more or less serious, from the tools that help in the web project management discipline to the reasons the site works fine in all browsers except your client’s one.

Related posts

• 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 … Continue reading →...
• Web Project Management FAQ
  This article contains answers to several questions I receive regarding web project management and can be considered a sequel to what I wrote in Introduction to web project management. It’s a starting point. If you think that there are some … Continue reading →...