Garen's Blog

Avoid Joel Spolsky’s Icebergs by Sketching!

A coworker just sent me Joel Spolsky’s Iceberg Secret article, which is a great reminder about how people interpret visual designs / mocks / prototypes. Here’s my half sentence summary of the post: If the product looks like it’s done, people will think its pretty much done.

But we know that isn’t true. Just because a UI exists doesn’t mean anything under the hood exists. And that is why over the past few months I’ve taken to carrying around a sketchpad. Huh? Paper? Pens? What are they? I’ll tell you what they are: USEFUL.

Here’s why sketching interfaces / interaction designs floats my boat, at least for the first couple iterations:

1. It doesn’t look done. Because if it was done, it would be user-facing and on production.
2. It doesn’t look hard to change, so people don’t feel bad suggesting big (or small) changes.
3. People who you show it to can actually draw on top of it / make their own (they call this collaboration).
4. People don’t care about details / pixels, they care about the stuff they’re actually supposed to care about.
5. They’re quick, and your time is valuable.
6. You can still take a picture of a sketch and stick it inside a mock.
7. Paper doesn’t have a $350 licensing fee.
8. Street cred, and it helps people understand the idea of design as art.

Just yesterday I had a pretty loosely developed idea for a an interface element, so I printed out the existing high-fidelity visual mock and drew all over it. Then I took a picture and put the photo of the sketch in the presentation I gave. It worked awesome, because it encouraged discussing the intent instead of the details of execution.

Sketch away!

"From @nathansmith, a list of online wireframing tools: http://myBalsamiq.com http://Cacoo.com http://iRise.com http://LucidChart.com http://Pidoco.com http://ProtoShare.com"

https://twitter.com/#!/nathansmith/status/194854722115616768

"Whether you test your work on a regular cadence or only once or twice per cycle, the inevitable question that arises is what to actually test. We start to wrestle with the pressure of maximizing our time and money spent on testing and getting the most insight for that expense. Is it best to put a rough sketch of an idea in front of potential or existing customers or to wait until there’s a more fleshed out version to show? Should it be clickable (really clickable, i.e., working code) or a mocked up experience created using Axure, Powerpoint, Fireworks or any other tool?
~
The short answer is test everything. By “everything” I mean whatever you have ready regardless of its polish or fidelity. The challenge is to set your expectations about the feedback you’ll receive for each type of asset your present and what you will actually learn."

http://blog.usabilla.com/test-everything-you-got-regardless-of-its-polish-or-fidelity/

"A user might first notice your product in a search result, browse around the product for a minute, and then leave. They might come back, sign up, and then leave again. They might open an email from the product, come back, make a purchase, and leave. Each of these little stories is a way that people actually experience your product.
~
A product is not a set of screens — it’s the stories those screens enable.
~
If your team is not paying attention to these stories, if you’re thinking about each screen individually, then your minds will be in a completely different place than the people who are actually using your product."

http://www.designstaff.org/articles/story-centered-design-2012-03-22.html

"…encouraging a designer to develop multiple concepts first could be a way to improve the effectiveness and diversity of the ultimate design as well as helping team members feel more confident."

http://www.humanfactors.com/downloads/janfeb12.asp