paper prototyping for fun and profit
More than four weeks have gone by already, but I haven’t found time until now to finish writing about the fun we had at one of the fortnightly meetings of the local open source usability group over here in Berlin. We got introduced to the concept of paper prototyping. A simple concept that works impressingly well. All you need is some paper, a pen, a scissor and users.
The idea is to let the user design the user interface. Users will probably not come up with the best possible UI, more likely they will not even come up with a good UI. But watching a user doing the design gives you a very good idea of what the user expects from the user interface.
We tried paper prototyping on a dialog that is currently being developed for GIMP. Up until recently, import of PDF files used to be done by the postscript plug-in (which in turn calls ghostscript). But there’s now a new plug-in being developed that imports PDF files using poppler. We started our paper prototyping session by making a list of tasks that are supposed to represent typical use cases for importing a PDF into a raster graphics application like GIMP. Not sure if I remember everything correctly, but I think this is close to the list we came up with:
- You need the cover image of a PDF document in print quality.
- From a PDF, you need a couple of images, which are found on page 4, 5, 6, 17, 18, 23 and 42. The pages should be imported large enough to be printed in 20 cm width at 300 dpi.
- You are preparing a web site and need thumbnail previews of all pages of a PDF document. The thumbnails should be 100 pixels high.
We picked one of us to be the user. You should of course use a real user, preferably repeat the whole procedure on a few of them. The user is presented with the tasks, one after another, and is asked to describe the user interface she would expect to perform the given task. Here’s where the paper comes into play. Draw each of the UI elements that the user wants to see on paper and cut it out. Then ask the user to place these snippets on a piece of paper serving as the dialog window. It will probably need a few rearrangements before the user is happy with the design. Together with the user, check that the use case can be nicely handled with this design. Then look at the next task. Either start from scratch with a new sheet of paper or modify the existing design to fit the new use case.
So here’s a blurry example of what we came up with at some point:
Please excuse the very poor quality of this photo taken with my cellphone. I will try to remember bringing a camera to the next meetings.
Of course this process should be repeated with more users. But during the iterative process of designing this dialog, we already learned a lot about the user’s expectations and what user interface elements will work and which won’t. Interestingly, the current state of the PDF import plug-in already comes pretty close to what our test user expected:
The page selection at the top of the dialog uses a GtkIconView. The rectangle selection mode of GtkIconView is perhaps not ideal for selecting consecutive pages but at least it’s fully keyboard navigatable and provides a user interface that is easy to understand and is also used in other applications. The previews help a lot when one needs to select a certain page. This is definitely a huge improvement over the postscript plug-in in GIMP 2.2.
What we also learned is that the widgets that are currently being used to specify the size/resolution of the import (as found in the lower part of the dialog) don’t work. Our test case requires that pages are rendered in a certain width, given in physical units for a certain resolution. Most users don’t want to enter a size in pixels here. All they know is that the image needs to be printed later at a given size and resolution. According to several people I talked to, this is not an uncommon task. Some changes will be needed in this area.
Paper prototyping is fun and it is easy to do. Give it a try the next time you need to design a new dialog or think about how to improve an existing user interface.
August 24th, 2005 at 2:39 am
Interesting. What you describe is quite different from the way I’ve used paper prototyping. I use it as described in this Jakob Nielsen article: The designer (not the user) creates paper mockups of one or more possible UI designs, and then uses the mockups to perform usability tests with a group of users.
August 24th, 2005 at 3:09 am
Matt, you are right, there are different ways to use paper prototyping. I should probably have mentioned that. Just as you said, paper mockups can be used to experiment with different user interface ideas.What I described can be useful earlier in the design process where it helps to get an idea of the user’s expectations. It can also help to verify that the use cases make sense and actually reflect the user’s needs.
Also, the border isn’t exactly that strict. The user interface designer may of course support the user in the process of designing the UI by proposing alternatives. The dialog design then becomes a collaborate effort between the user and the user interface designer. The nice thing about paper is that it makes it easy to just try a few things.
August 24th, 2005 at 3:05 pm
Looks interesting. I think maybe there is potential to do something more consistent with a Print dialog, would make sense to have the same kinds of widgets and layout for selecting the pages ranges if at all possible.
August 25th, 2005 at 2:11 pm
There’s a good book on Paper Prototyping by Carolyn Snyder, for anyone who’s interested in this side of usability testing.
August 26th, 2005 at 6:43 pm
Ja, hat echt spass gemacht!
August 26th, 2005 at 10:42 pm
[...] gust 26th, 2005
Und weil heut schon so´n Flogtag ist: Noch’n Link zum Paper-Prototyping Workshop: Hat nämlich viel Spass gemacht [...]
August 27th, 2005 at 6:13 pm
Not sure if you notice this, but the paper is oriented to reflect the fact that most(all?) screens are wider than are long, while the screenshot displays the dialog that is taller than wide. There is less vertical real estate, so making it wider than tall should probably be on your priority list.
I also think the actual import process shouldn’t cement the size/resolution! Save that for when the user invariably resizes the image and then finally prints. Keep the image as close to native as possible, instead using some kind of ‘low resolution’ proxy for on screen manipulation. In other words, keep the imports as high res as reasonably possible up until the document is rendered for print; then you can resample for your target output device.
August 27th, 2005 at 6:22 pm
[...] better than a good example. This was posted as the team that is going to make GIMP usable. Paper Prototyping by guys that really don’ [...]
August 27th, 2005 at 6:53 pm
Glad to see this happening. May I suggest you do something about the “Ok/Cancel” buttons though.
Put verbs on your action buttons, not abstract confirmations. “Import/Cancel” would work, for example.
August 27th, 2005 at 7:54 pm
The GIMP Having Fun with Paper Prototypes
Paper prototyping is growing in popularity as folks learn about how flexible it is. A recent example is what the GIMP designers are doing with their PDF import capability, which recently was slashdotted.
I talked about our 16 years of paper prototypi…
August 27th, 2005 at 11:10 pm
[...] uo; Logo Even More Paper Prototyping It seems to become popular: Sven and Antenne already mentioned it in their blogs. Now A [...]
August 28th, 2005 at 2:37 am
The OK button should be on the left, like most other dialogs designed for maximum usability. Most languages read from left to right (except Arabic and a few others), so the button that will be used most of the time should be the first one the user sees as she or she scans from left to right looking for the desired button.
August 28th, 2005 at 3:57 am
The OK button placement debate is one that shouldn’t be tackled with this dialog box. It’s a GNOME stroke of genius / problem that needs to be addressed on a global level, lest you start having some dialog boxes with the buttons around the ‘wrong way’.
Personally, I agree with you that in that the Windows OK button placement is standard, and that most users read left-to-right. There’s the counterpoint, though, that it’s easiest to click the button in the corner, instead of the button-in-the-corner-and-left-a-bit.
I do disagree with your “like most other dialogs designed for maximum usability” statement, however. Mind providing some examples (without ignoring the rest of the post)?
August 28th, 2005 at 6:46 am
I also think the actual import process shouldn’t cement the size/resolution! Save that for when the user invariably resizes the image and then finally prints. Keep the image as close to native as possible, instead using some kind of ‘low resolution’ proxy for on screen manipulation. In other words, keep the imports as high res as reasonably possible up until the document is rendered for print; then you can resample for your target output device.
This will not work. PDFs are vector-based, not raster. They do not have a “native resolution”, meaning they can be rendered at any resolution.
August 28th, 2005 at 7:28 am
Um, well, it depends on how you define “import”
When you import, say, Word documents, you are translating from Word -> Native
So when you import PDF; are you doing a straight PDF->PDF import (though I would have expected more of the terminology, ‘cut and paste’)? Or do you do a PDF->native import?
Because when you select text from one document to place in another, it’s usually called ‘copy and paste’
When you select PDF from one document to another, why is it import?
August 28th, 2005 at 9:39 am
When I can’t decide which side to put the OK button on, I put both in the upper right corner of the window, with OK on top and cancel directly beneith it. If I’m including a help button, it goes beneith the cancel button with a bit more space than between the OK/Cancel combo. If there is an Advanced button, it would go on the lower right corner.
With regards to the text of the OK button, “OK” is considered standard, but “Import” is more intuitive for the untrained user. Contextually speaking, usability is probably not affected unless both an OK button and an Import button are included, which is highly not recommended.
August 29th, 2005 at 3:17 am
The placement, and naming of buttons in a dialog is not a simple thing. Different platforms have different conventions/guidelines. Take the following two links to the respective guidelines from Apple and Microsoft:
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_17_section_6.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch14e.asp
I personally think that Apple’s guidelines make much more sense from a usability point of view. (The action button would be labelled “Import”, and placed in the lower right corner, any “dangerous” buttons would be visually separated from the safe options)
However, if you’re writing a Windows app (or a cross platform app like the GIMP) you need to trade off between usability and consistency with other applications on the same platform.
Should you follow the guidelines of the platform you are running on (and have a different layout depending on platform) or have the same consistent interface on all platforms?
August 29th, 2005 at 10:06 am
GIMP 2.4 will place the dialog buttons according to the user’s preference, or rather according to the way they are put on the desktop the user is running GIMP on. We would have done that with GIMP 2.2 already but the API that is needed to achieve this has only been added with GTK+ 2.6.
See also http://bugzilla.gnome.org/show_bug.cgi?id=166678
August 30th, 2005 at 5:01 am
Prototipos de Papel y Gimp
Para quienes no lo conozcan, Gimp es el editor gráfico estrella del mundo open source. Para ser honestos, lo tengo instalado desde hace un tiempo de forma permanente luego de varios intentos infructuosos, pero ya lo estoy usando más consistentemente…
September 28th, 2005 at 3:09 pm
Wow, that import dialog is better than almost everything I’ve seen so far in this area, but I was actually a little disappointed by the way users have to select a range of pages.Many new users (and even long time users) don’t know about the CTRL-Key and how to use it to select multiple object. So, what do you think about the idea to add little checkboxes below the preview images? This way users could tick the checkboxes to select multiple pages. I reckon that’s a lot more obvious than the CTRL-Klick thing.
September 29th, 2005 at 9:32 pm
Selecting multiple pages isn’t really a frequent operation and since the Ctrl/Shift key behaviour is common to so many widgets, I don’t see a point in cluttering the user interface with checkboxes. Especially since it would mean abandoning GtkIconView and reimplementing all this on our own.
November 20th, 2005 at 4:27 pm
> Selecting multiple pages isn’t really a frequent operation and since the Ctrl/Shift key behaviour is
> common to so many widgets, I don’t see a point in cluttering the user interface with checkboxes.
> Especially since it would mean abandoning GtkIconView and reimplementing all this on our own.
Agreed. If anything, you should leave GtkIconView to implement the checkboxes (if ever), to keep the widget appearance standard across different programs. :S
August 9th, 2007 at 6:17 pm
this is really cool…
on a totally unrelated note, what’s the name of the comic in the screenshot?
It’s my childhood’s favorite and i’d been looking for it for like forever but can’t really remember the name. Oh, of all the places I’ve looked for, who would have thought it might come from a work-related blog…
March 18th, 2008 at 5:01 pm
Some time ago, I had the same Idea: why not let the customer do the design. When it came to pen and paper I noticed that most of my customers could not imagine what their ideas would look like on screen / web. So i developed a prototyping application on my Acer C300XMi (notebook w. touchscreen). Using my application the user can easily drag&drop the Interface without loosing the ability to “scribble” directly on screen. Later i added a Hitghres Webcam to capture paper scribbles and now i have the perfect on site prototyping companion.
April 10th, 2008 at 5:31 pm
[...] que me encontré con este post de Sven Neumann, un desarrollador de Gimp, que relata el proceso de desarrollo de una interfaz específica para Gimp usando técnicas de prototipado en papel, o paper prototyping. El ejercicio es particularmente atractivo si consideramos que se invitó a [...]