Last month the folks from PeepCode visited our office and asked to record my design process. Geoffrey told me not to prepare anything. He said he’d show up with a sample problem and simply record whatever I did with it. The result is two 75-minute videos (Part One, Part Two) that show my thought process step-by-step, starting with paper sketches and then moving on to HTML/CSS.

The hard thing about demonstrating design is the sample problem. The problem should be simple enough that the details don’t bog down the audience, but complicated enough that you run into real-life conflicts and constraints.

Fortunately Geoffrey picked a really good sample domain. He asked me to design a UI for picking the top five finishers out of 200 participants in a pro bicycling race. The task was rich and interesting enough that we spent the first 75 minutes purely sketching and analyzing the approach.

The first video, Part One, covers the sketching process. A lot of good material came out of this section, including:

  • How to tackle a UI problem by dividing it into tasks that each have a beginning, middle and end
  • How to use sketching as a response to uncertainty, and when to stop sketching and move on to HTML
  • How to focus on the most natural solution so that people will intuitively grasp a design
  • How to focus your design process on conflicts and friction points, attacking them one by one until the design works

This video also gave me a chance to explain the UI design process through an analogy to software testing. Kent Beck’s Test-Driven Development had a huge influence on me, and I’ve always had trouble explaining the connection. In both videos I continually refer to setting up “tests” — specific things in the design that aren’t working or aren’t resolved — and then design against those tests until they “pass” (that is, until the problem goes away). This loose analogy articulates that tricky and hard-to-pin-down process where a designer continually moves their focus among pieces of a problem and along the way settles conflicts step-by-step in a constructive sequence.

I think the process will be interesting to both designers and coders. Designers can compare the process to their own, while coders can use the analogies to software testing to see design as an extension of concepts they already know.

In the second video, Part Two, I take the sketches and ideas from the first session and build them out in HTML and CSS. Along the way I dip in and out of Photoshop, explaining the time and place for each tool.

Part Two especially focuses on getting quick results in the browser. I sketch out dom elements, give them classes to communicate their purpose, and gradually decorate them with inline styles until the design comes together in the browser.

I would prefer videos like this to be free. But Geoffrey had the idea to begin with and his PeepCode team did all the hard work. I just showed up one Friday morning for a couple hours of design practice. So if the material is useful to you I hope you’ll support their effort and buy the videos at $12/each.

Here are the links:

  1. PeepCode Play by Play: Ryan Singer Part One
  2. PeepCode Play by Play: Ryan Singer Part Two

There’s also a 10 minute preview on the Part One page.

I hope they’re useful!