The problem with sketching
This past June I attended UPA’s 2007 conference in Austin, Texas. The keynote was given by Bill Buxton, Principal Researcher, Microsoft Research. The focus of Bill’s presentation was on “sketching”, a timeless core tool for creative design, that in software design is often bypassed in favor of high fidelity digital design tools. He presented two points regarding sketching that made a strong impression on me:
- No higher resolution than required to communicate the intended purpose/concept
- Resolution of the rendering does not suggest a degree of refinement of the concept that exceeds its actual state
(directly from Bill’s presentation)
Since the conference, I’ve been evangelizing this concept internally to my team (product design) as well as to product management and development. But I’ve hit a few snags in the fast paced world of software development. Namely:
1) High fidelity sells, low fidelity is dismissed
With many projects facing complex priorities, deadlines, demands from the sales team, and countless other inputs, rough sketches are often not compelling and are easilly overlooked or dismissed. A picture is worth a thousand words, but only if the picture is pretty. I constantly push back on higher resolution early on, but without higher resolution often the project doesn’t get started in the first place. It’s as if a high resoluton rendering is needed to inspire interest only to be trashed and reworked through the correct sketching process once the project gets moving.
2) High fidelity communicates a solution, low fidelity communicates a work in progress (which is good for exec’s, but problematic for development)
Here’s one that’s a little controversial (until you understand what I’m really trying to say). Low fidelity (rightfully so) communicates an unfinished design; a work in progress. And as Bill states, this is what you want… if your audience is marketing or decision-making executives. But with development it can be a little tricky. When we present something polished looking to development, even if it’s not completely fleshed out, their reaction tends to be “that looks awesome – when can we get this from you so that we can plug it in.” When we present a sketch or something rough, the reaction is often to go and try to do it themselves. In some situations this could be a good thing, and may be exactly what Bill is advocating for — the roughness promotes others to think and contribute their own ideas instead of assuming it’s already done. But in some cases unfortunately, it doesn’t promote collaboration — development just picks up the ball and runs with it without ever looking back. Yes, I know, it’s a problem with process and culture. But if it exists, it exists, and until it has been fixed, it throws a wrench into the design-sketching process.
These are good issues, but not simple ones. But here are a few thoughts:
(1) High fidelity sells, low fidelity is dismissed
Yes. I think that any of us who have been in the business for any length of time have encountered this. And yet, does this invalidate the process of sketching? I don’t think so. Perhaps it just means that things are a bit more complicated.
First, the audience for the sketching process is mainly designers themselves. It is part of design thinking. The problem identified emerges in communicating with others, not amongst designers.
But what about communicating with engineers and management, for example? Well, my second point would be to look at what other design disciplines, such as industrial design. Here, they have developed a distinct visual vocabulary, generally referred to as presentation drawings, as the vehicle to communicate to others during the design process/cycle. The challenge, which I have not properly addressed in either my book or my UPA talk, is what such a representation would/could/should look like. (My only apology was that I was already trying to do too much and had to finish. Sorry.)
My third point would be to recall the quote from Alan Kay that I repeated twice in my book, and certainly once in my talk: it takes almost as much creativity to understand a good idea as to have it in the first place. The implication that I draw from this is that as designers, a significant part of our creative talent must be allocated to helping others who we interface with understand the language that we work in (i.e., such as sketches) and at the same time, find ways to communicate our thinking/work to them such that it is comprehensible and effective.
Finally, I refer back to your August 8th blog where you make the point, “everyone thinks they are designers?” Well, if they perfer unfounded and poorly considered high-res renderings over sketches that are approriate resolution for the state of the understanding of the problem, then we need no better proof that everyone is decidedly NOT a designer.
We have to understand that they are not, and apply our creative juices to designing our way around and through this reality. Products are not the only things that designers have to design.
Now we turn to your second point:
2) High fidelity communicates a solution, low fidelity communicates a work in progress (which is good for exec’s, but problematic for development)
I have touched on some points relevant to this already (I hope). But I think that the problem that really underlies this particular issue is a really broken aspect of the development process. That is, in software in particular, almost all of the design takes place during construction. No sane person building a complex house or office building would have the architect, structural engineer and financial manager start on the same day that ground was being broken by the construction engineers. It would be patently absurd. Yet this is how literally every software product is built. And then the poor usability folks are asked to weave the proverbial silk purse out of this horendous sow’s ear.
The real problem that gives rise to the point that you make is that the user experience team (usability and design) are not there working with a systems architecht (the equivalent of the structural engineer in conventional architecture) and the business planner, well before the engineers who are going to buid the product (if it’d creative, financial and engineering designs pass the green light), are assigned to the project.
For anyone that challenges me on my assertions here (such as the extreme or agile programming crowd, for example), then demonstrate to me that there are software companies that can consistently and repeatedly create successful new (as opposed to n+1) products in house. Until someone can show me this, where there is not a clear and explicit design phase prior to green-light, then we all have to admit that something is broken.
I am happy to have someone demonstrate a different approach that works, other than adding a design phase up front.
But the status quo is broken, we cannot afford for it to continue, and it is totally unreasonable to expect usability and desin professionals to make this crap usable, if we are not given the chance to practice our craft at the front end and ensure that the thing is designed for usability and the desired user experience right from the start.
Hmmmm. I seem to have gotten worked up there. Perhaps I should now slink off back into the north Canadian woods where I came from.
Cheers.
In my (limited) experience, the difference is less between management & development, and more between literalists & theorists. The literalists, whether they’re in mgmt or dev, just don’t make the leap between a medium-resolution sketch and a final product. When talking with them, it’s either got to be very polished or very rough, or else you end up in pointless debates about Arial vs. Verdana. The working cycle with dev is long enough to figure out the right balance, but it’s usually a one-shot deal with the executives. If even one decision-maker is a literalist, the design almost has to be polished, because literalists won’t give the go-ahead to a $100K+ project based on a paper sketch.
Once a project is approved, I’ve had good luck with making dev sketches that are very detailed in some aspects (like showing how all the items align and the exact location of buttons) and putting all the colors in pink or using random images, to show that some TBD decorative element will be there. Many of the developers I’ve known have been good at pulling out abstract ideas from a design, but demand hand-holding on even the simplest UI elements. My impression is that this is less about actual than perceived abilities, but the fact remains that elements tend to work beautifully but be somewhat randomly placed if I don’t specify them.
In my experience it is impossible to test a concept (with end-users) without sketches (paper or low-fi prototype). Unless you choose not to test the concept itsself before testing the design then you can go for a high-fidelity design early on.
Then again it would be a shame if you find out the concept is not working when you’ve already made a design. I think that can not be sold.