Slightly more than 140 characters about design, written to temporarily distract myself from thinking about a term paper.


When you start talking about a web project in front of an empty whiteboard, how do you start filling the empty space?

Do you draw sketches of pages? Do you draw entity relationship diagrams, data flow diagrams, lists of high level requirements or system diagrams? Do you fill the empty space with sticky notes to make storyboards? Do you do something else, or all of the above? Does it depend on your audience?

Over time I feel like I’ve developed a real preference for (or perhaps a bad habit of) sketching the web pages themselves. This is a bit weird because, as you can tell from this website, I’m not a designer. I see myself as a software developer…although honestly these days I’m more a student of the archive who happens to dabble in software development. Hey, it’s a good life.

At any rate, it would be much more natural for me to talk about the data that’s on hand, or the data we want to have on hand, entity relationships, modeling, flows, databases, formats, standards, frameworks, indexes, APIs, URL patterns, etc. So why do I have this preference for bad drawings of the pages we’d like to have?

Part of it comes from the agile brainwashing experience I’ve had, where you put something barely working in front of a mostly underwhelmed person who wants the thing already, in order to get feedback, figure out how to improve what you have, and what to do next. Individuals and interactions over processes and tools.

The main challenge here is finding the right individuals who are willing to spend enough time being underwhelmed to imagine something better, and to help design the thing. But really it’s more than just agile.

I think the reason why I prefer bad sketches of pages over all the technical details is because of who they privilege. These pictures of pages privilege the people who will be interacting with the thing that is being built. The developer who gets to go in and make lots of implementation decisions has enough privilege. The conversation about what the application needs to do is what’s important. What, not how. The developer needs to be decentered and the work needs to be humanized.

Websites are used by people. Hopefully someday your website is going to be used by people. Who are those people and how can they help you make this thing? When you’ve got an emtpy whiteboard try to start by drawing the thing that doesn’t exist yet, and talking about it. See where things go from there.