This blog post is based on a speech by Bill Buxton at BostonCHI last year, and on Matt Ritter's notes from the event. He spoke on design sketching.
You don't have to sketch with pencils, by the way. You can sketch with words and find yourself unconstrained by visual space; it's a different sort of freedom.
These are somewhat disjointed notes that happen to be grouped into sections. They are not meant to be coherent in the least.
Sketching as communication
Sketching is extremely important and fundamental to ideation. They communicate the emotion, feeling, and intent of a design, not necessarily its specific geometry. If other people look at your drawing and come up with different words to describe it than you thought they would, redraw the sketch.
If you don't sketch, how do you communicate?
If you don't sketch, how do you get to know your design space?
Be honest about your level of polish.
If your idea is rough, draw your sketches roughly; never use a higher resolution than required. The way you render your sketches telegraphs to others how finished your idea is and what order of critique they should be making; "move that 2 pixels to the left" versus "I don't think you need the entire back half of that car." This is one of the advantages to paper prototyping - not only is it fast and cheap, it looks fast and cheap and people give high-level, low-detail critiques of the overall idea instead of nitpicking on the shade of a button.
Everything is n+1
In an ironic self-referential twist, many old sayings are nearly identical when you look at them. "Everything old is new again." "There are no new stories." The design equivalent is that there are no companies that regularly do something from scratch. "All other products are n+1," Buxton said. Doing a project from scratch is exceedingly dangerous because they're inherently unpredictable.
It's easy to fake a wizard.
"If Dorothy doesn't see the wizard, it doesn't matter that he's there." There's no reason to make things more complicated than they need to be. Sometimes, extremely low-tech solutions can be cost-effective. Extremely low-tech solutions, with some cleverly placed people to fill in the gaps, can create a rich interaction - think about the classic example of "speech recognition software" usability testing where the software is really a person typing in the back room.
There's a difference between having a rich interaction and a rich data model. The MVC framework is particularly good at illustrating this. You can have a glorious AJAX-y front end with buttons and whirling things and funky graphs running entirely off the output of a single CO2 meter. Or thousands of tables, thousands of student data points, grades, comments, classes - all funneling out to a single green light on your screen that says "diploma" or "no diploma."
Less than five and you're fired
Come with multiple designs. "If a designer comes in with less than 5 viable designs, they will be fired on the spot." This reveals the obvious answers and lets you push for more, emphasizes that there's often no one right solution, and makes the tradeoffs of the problem space clearer. More importantly, it allows you to step back and take critiques more objectively. If you associate one design with one person, it's hard to separate critique of the design with critique of the person; defensiveness results despite everyone's best efforts. If you've got more than one design, you can mix and match tradeoffs, and it's about the ideas, not the person who's bringing them in.
The designer-engineer relationship
If you're running a business, Buxton says you should let your designers shine - to which I would add "but make sure your technical underpinnings stay in place." Never lose sight of the reason you're making something; to help others. It won't help them much if it's not created to fit their needs, their price tag, their usage habits - but it also won't help them much if it isn't made, isn't functionally prototyped.
Sketching and prototyping take different people to do. Prototyping should be done in parallel. I'm not sure what this means yet - is sketching the exploration of an idea, and prototyping the exploration of the implementations of that idea? I have the nagging feeling that designers and engineers speak fundamentally different languages that happen to use many of the same words; I want to run around in both worlds and see how they compare.
The need for dialogue between engineers and designers was made very clear to me in Osaka after spending many hours talking with product designers - they giving us advice on how to improve our artwork and presentations, we looking at their designs and giving them suggestions for manufacturability, materials and devices they might consider in order to actually get them to functional prototype stage. Engineers don't have to learn Maya and designers don't need to learn structural mechanics, but they need to be able to talk to one another, and they need to do it.
Let your creative people be creative. Engineers don't thrive under the supervision of pointy-haired bosses. Similarly, let your designers lead themselves. Designers and engineers should help each other, not be fettered by each other; don't make the engineers build unreasonable things, but don't constrain designers to only "make pretty" what the engineers toss them.
Learn from the masters
Reproduce the work of the masters. "Without the experience of the past, we've got no shot at designing the future." (Hands-on learning without innovation, Matt noted. "You've got to couple it with a healthy dose of reflection in order to make the work really yours," I added.)