Archive for May, 2007

Paper prototyping for the genius designer

May 31, 2007 by Prabhath Sirisena | Tags ,

It’s very convenient for us designers to think that we always know the best way to do things. Genius design, explained aptly by Dan Saffer in his excellent book, is probably a favourite method among web designers, especially in today’s web-two-point-oh environment of quickly-hacked web apps. After all, there’s only so much you can do with a web interface, and so much of it has been done before, it must be quite difficult to get anything wrong!

Yet we manage to get things horribly wrong with startling frequency. And almost always the reason could be traced back to lack of proper user input in the early stages of design. In a rare productive meeting yesterday, a Client shattered all our assumptions and injected a good dose of common sense in to our heads when he pointed out some glaring flaws in the design of a web application we were developing. In addition to saving us a lot of wasted effort and significantly improving the usability of the interface, that meeting also reminded us of the importance and usefulness of paper prototyping.

What on earth is a list?

This particular web application facilitates online recruitment, and a primary function involves an employer (the user in this instance) picking suitable candidates from a pool of applicants, and adding them to “lists”. For example, if the user wants to hire a designer, she would create a list for this purpose and add candidates to that list. In our design, the list name was independent from the actual job title: she could just create a list named “my hot list” and add people, and set the job title for that list later.

In true Getting Real fashion, we had the interfaces done first. We started explaining the above process to the client (who, fortunately, fits the role of the user perfectly), using a set of crude wireframes:

Lankitha: First, the user creates a list-

Client: Hold on, what’s a list?

L: That’s just a place for you to add candidates, like a folder in your computer-

C: Why is it called a list then? Why not folder or something?

L: Because it’s not really a folder; it’s a list of candidates

C: Er, OK…

L: So, the user creates a list-

C: Hold on, this is confusing… What on earth is a list?

It went steadily downhill from there onwards. Our first reaction was to be defensive: after all, we had put a considerable amount of effort in to designing the process and the interfaces, and before we could even get started, we were faced with a stumbling block. Surely the client was wrong?

It took a couple of minutes to realize what was happening. Paper (or, in this instance, on-screen) prototyping was already paying dividends.

Paper prototypes to the rescue

Highlighting our mistaken labeling was only the beginning. We continued with a different label and along the way found out several other problems too. At the end of the session we realized that a major overhaul of the process was called for, and a number of changes to the interfaces were in order.

Cheap yet effective

I wouldn’t call what we had a usability test: it turned out to be one by chance. But it did show how simple and cost efficient usability tests could be carried out for projects that have budget constraints and tight deadlines. People like Jakob Nielsen have been harping on this for years, but the true value of simple methods such as paper prototyping can only be understood once you do it and see the results for yourself.

Live redesigns

Another advantage of paper prototyping is you could make quick changes based on user input and see how the new interfaces are received. Since paper prototyping happens at the beginning of a project, the cost of throwing away is minimal. In fact, almost always you’ll have to throw away your first few attempts. That’s a very small price to pay for the guaranteed improvements in usability.

Towards the end of our session, the client was the one talking and sketching, and we were the ones listening. Much of the upcoming revamped design of the application would be directly from the sketches of our client rather than our genius designers.

Test early, test often

Our attempt at genius design wasn’t a total failure: a lot of other sections of the application were readily accepted, and some are already implemented. But, we’ve learnt our lesson from this meeting: the genius designer is a myth. Unless, of course, you’re Jonathan Ive.

As Steve Krug says in Don’t Make Me Think, testing one user is 100 percent better than testing none. Our first test wasn’t even intended, but surely it won’t be the last.

Coping with Copy

May 3, 2007 by Mahangu Weerasinghe | Tags

If you’re a copywriter who can’t seem to work with others, you’re not alone. Lots of writers out there struggle everyday in having to work with teams. In giving their words the highest priority, they often forget that they are a part of something that is bigger than just themselves and their copy. In this vein, I thought I’d share a few tips with you, a few points that will help you get along better with the team you are working with.

Your designer is not three years old.
Talking to a friend of mine who works in the art department at an ad firm, he said that what annoys him the most is when copywriters treat him like an infant. In general, I think this is a big complaint among designers everywhere. As a writer myself, I believe that your copy briefs should never tell the designer what to do or how to do it. In the very least, your visual suggestions should be the beginning of a conversation, not the delivering of an order.

Instead of suggesting,

A yellow background with black lettering and a white border.

Try saying,

I feel a light background with dark lettering would suit this best. What do you think?

You will need to edit, and re-edit – it’s your job.
Part of being a good writer means you think that your work is flawless. Of course, it’s also essential to know at the back of your mind that it is not so. Authors have editors, reporters have editors, and you have an editor as well – yourself. When your manager sends back some copy saying he’d like some edits, don’t take it personally. In fact, these changes are often not corrections to mistakes you’ve made, they’re just slight shifts in tone and voice as required by your team.

You will never have total creative license.
This is the real world. If you want total freedom, it’s best to start penning that maiden novel. Out here, there are deadlines to meet, clients to please, and someone, somewhere is going to ask you to be a little more formal. When this happens, don’t take it personally – it’s not an indictment on your talent, just a little reminder that Tolkien didn’t write corporate copy. Though being creative is an essential part of being a good writer, knowing when to draw the line is a skill that is far more valuable.

Coming to terms with these three points helped me a lot during my first few years of writing professional copy, and my hope is that they will help you too. Good writers are born, not made, and though nobody can teach you good writing, you can unteach yourself bad writing. Live, learn, and write – never stop learning, never stop writing, and when you find something new, share it with others. There are too few of us not to.