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.

Meetings and multitasking

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.

Everything has its own name

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

3 things I learned presenting with slides

I am not a professional speaker at conferences: I do it on my spare time and usually no more than twice a year. But there are some things I learned and that I want to share with you. No, I’m not talking about using a Presentation Zen or Slide:ology approach because, as it was clear to the audience of Better Software 2010, the last conference where I spoke (on Recruitment 2.0, in Italian), 90% of the presentations already got rid of bullet points in favour of photos and terse contents. I am referring to a “parachute plan” in case something goes wrong and to avoid misunderstandings with the audience. Here are my suggestions:

  • 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.

Web project managers’ world

Sam Barnes, a web project manager based in Windsor, had the great idea of organizing a series of interviews with some web project managers.

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.