Advertise here with Carbon Ads

This site is made possible by member support. โค๏ธ

Big thanks to Arcustech for hosting the site and offering amazing tech support.

When you buy through links on kottke.org, I may earn an affiliate commission. Thanks for supporting the site!

kottke.org. home of fine hypertext products since 1998.

๐Ÿ”  ๐Ÿ’€  ๐Ÿ“ธ  ๐Ÿ˜ญ  ๐Ÿ•ณ๏ธ  ๐Ÿค   ๐ŸŽฌ  ๐Ÿฅ”

How design works

Michael Bierut on his design process, written in plain language that the client never gets to hear (but maybe they should):

When I do a design project, I begin by listening carefully to you as you talk about your problem and read whatever background material I can find that relates to the issues you face. If you’re lucky, I have also accidentally acquired some firsthand experience with your situation. Somewhere along the way an idea for the design pops into my head from out of the blue. I can’t really explain that part; it’s like magic. Sometimes it even happens before you have a chance to tell me that much about your problem! Now, if it’s a good idea, I try to figure out some strategic justification for the solution so I can explain it to you without relying on good taste you may or may not have. Along the way, I may add some other ideas, either because you made me agree to do so at the outset, or because I’m not sure of the first idea. At any rate, in the earlier phases hopefully I will have gained your trust so that by this point you’re inclined to take my advice. I don’t have any clue how you’d go about proving that my advice is any good except that other people - at least the ones I’ve told you about - have taken my advice in the past and prospered. In other words, could you just sort of, you know…trust me?

It is like magic. Reminds me of something Jeff Veen wrote last year on his process:

And I sort of realized that I do design that way. I build up a tremendous amount of background data, let it synthesize, then “blink” it out as a fully-formed solution. It typically works like this:

- Talk to everybody I possibly can about the problem.
- Read everything that would even be remotely related to what I’m doing. Hang charts, graphs, diagrams, and screenshots all over my office.
- Observe user research; recall past research.
- Stew in it all, panic as deadline approaches, stop sleeping, stop eating.
- Be struck with an epiphany. Instantly see the solution. Curse my tools for being too slow as I frantically get it all down in a document.
- Sleep for three days.

Like I said when I first read Jeff’s piece, in my experience, a designer gets the job done in any way she can and then figures out how to sell it to the client, typically by coming up with an effective (and hopefully at least partially truthful) backstory that’s crammed into a 5-step iterative process, charts of which are ubiquitous in design firm pitches.