What advantages does sketching a user interface on paper have?

Question

Why would I spend so much time on sketching my user interface on paper before designing it in Interface Builder/Visual Studio/Dreamweaver/wxWidgets/etc... ?

Can anyone explain me why we should do this?

Do you do this?

Thanks in advance.

Answer 1

It would be better to design UI's in a software like Photoshop rather than drawing it on paper.

Reworking will be easy.

Answer 2

Sketching it outside the development environment allows you to focus on the usability of the UI instead of being distracted by exact pixel positions, naming etc.

Answer 3

I'd recommend balsamiq mockups over paper - similar purpose/result but faster and can be emailed.

And the reason to do it that way rather than in IB/dreamweaver is primarily to avoid customers thinking it is finished when you show it to them. But IMO it also aids creativity and experimentation since it is a lot easier to change around.

Answer 4

Paper sketching is:

• fast
• easy to change
• gives a great overall look and feel
• reduces all the variables down to the basics
• easily collaborative

Answer 5

The paper sketch forces you to think abstract / toolkit agnostic ( a "Button" instead of the toolkit's Button widget) and avoids the temptation to immediately begin writing implemtation.

Side note: I think Balsamiq is pretty snazzy

Answer 6

I always carry around a small paperback notebook, but I don't always carry around Interface Builder. It's much quicker for me to jot down interface ideas on paper than it is to a full blown app.

Aside from just quick sketches, I still do full mockups on paper. As drawing is kind of tedious, it forces me to make my designs as minimal as possible (chances are you'll only draw what you absolutely need for your UI to work well, and that's exactly how your UI should be in the first place). If you're using a designing tool like Interface Builder, it's fairly easy to jam in as many buttons as you please.

Answer 7

It's useful to have a hard paper copy of your ideas. I file things like this away to watch the evolution of a project, and sometimes looking back allows you to get back on track if you start creeping off in another direction.

Answer 8

The best answer to this question is the same as the question of why write concept art for a game. It gives you a feel for how the UI is at a basic level and can help you see design flaws quicker. I disagree with some of the other posters regarding using computer applications (like photoshop or mspaint) because I feel that it can get you stuck in the logistics of the UI. Drawing the UI is meant to get you away from the logical design. to be simple and to give you a feel for the UI. If you are using the computer (at least in my case) you start getting distracted by the "backstage" of the UI, instead of focusing on the UI itself.

It all depends on the person however. I have others that don't get distracted. You have to find what keeps you focused on the purpose.

Answer 9

A few reasons:

1. It's fast and dirty. You can draw a few boxes and names in five minutes while reviewing your users' requirements.
2. Your audience understands it's fast and dirty. Instead of getting into discussions like "Can I have the bullet in cornflower blue?" you can talk about whether the right pieces are even on the paper.
3. It's unfinished. In the early parts (first ~50%) of the design process, the 'design' is really just a sounding board for people to bounce ideas off of. Making it look too 'finished' quells discussion of possible solutions, and instead fixates discussions on whether this design is good or bar.
4. You're not too attached to it. It's just a piece of paper. Which is as it should be early in the design process; major things may need to change.
5. It's democratic. During your design review (you are reviewing your design with the team, right?), everyone feels like they can contribute, even if they aren't technically capable or aren't the one with the mouse. (Note that this doesn't mean everyone's opinions end up with the same impact on the design! You want to let people express their opinions and insights.)
6. It's inherently persistent. You don't have to remember to save off a copy or whatever. Just pin the paper to your wall.
7. It's extremely simple to annotate. Just write on it. Or use Stickies.

Paper has its place. It's not the solution to everything, but it sure helps people work together.

Answer 10

Simple answer: if you want to change/redesign it you can start over quickly or rub it out. Redesigning something on screen can take quite a bit longer.

Answer 11

For a game data editor, I needed a good design for some tabular data. So I sketched it out in various states on some A4, and could take it out and around to show some people in the 'hood, see if they "got" it.

They did in the second iteration, which I then coded.

So yeah, for the less-than-obvious (wherever that line may be), I really like paper prototyping.

Answer 12

I don't think I've seen it covered above, but one HUGE benefit is that almost everyone knows how to work paper and pencil.

If your client is having a hard time communicating their input to you then it's easy-as-pie to slide them the pad of paper and pencil. If you give them the mouse and (insert your UI designer of choice) then you'll probably get a dumbfounded look.

You're getting paid to design and code it for them, not to read their minds. Making them show you your thoughts is always a good thing :)

Answer 13

You think in a domain specific way if you use a tool. When you need a out-of-the-box UI (say coverflow) u can't use any contemporary tools... When u are designing a tool that's going to use the existing tookit, i would suggest u to directly use IB, VisualStudio rather than using VISIO or wxWidgets.

Answer 14

I like to start in low fidelity, for all the reasons mentioned previously (thanks esp to Alex Feinman), then move up the chain toward an HTML-based prototype. As a project progresses, I may produce increasingly higher fidelity artifacts: sketch on a pad or whiteboard; rough out in Word or Powerpoint; drop into layout graphics using Photohop; code into (x)HTML, with or without the branding. The specific choices depend on the project... its complexity, the tech level of the customer representative, whether issues seem to focus on form or function, etc.

If you are designing as a team, a whiteboard is especially helpful for early discovery of visual layout requirements. This can be photographed and rendered into Photoshop or HTML to accompany written business requirements, and then presented to the customer representative to communicate your team's understanding of the overall functional requirements of the software.

If you need to collaborate remotely, I would suggest a wikki where things can be worked on by a team and a history of changes is retained.

Remember, the customer is likely to need the UI visuals to understand the software functionality, so exposing UI design to the customer early in the process can save time and money all around.