Rss

Again with The Six Steps

About 10 minutes into Java Posse 241, an unconference session on design, Joe Nuxoll almost pulls the usual “developers talking design” chat into a breathtakingly new perspective. Really close. Picking up on an anecdote about 37signals’ creation of Rails as a tool for what they wanted to do, he points out the idea of going back to first principles:

  • What do I want to accomplish?
  • What can I do that will accomplish that?
  • How do I do that?

He points out that not everything has to be a webapp or a library; that there could be a human process that’s more practical (cheaper, effective, etc.) than building something electronic.

And then the conversation goes another direction. But this so reminded me of Scott McCloud’s exceptional metaphor and discussion of “The Six Steps” of the creative process, in Understanding Comics. McCloud presents a linear progression of choices and concerns:

  1. Idea/purpose – What am I trying to accomplish?
  2. Form – What form will my effort take (a comic book, a website, etc.)
  3. Idiom/genre – How do I address the recipient (fiction vs. nonfiction, online community vs. news site). McCloud says this is “the ‘school’ of art, the vocabulary of styles or gestuers or subject matter.”
  4. Structure – How the work is arranged and composed, “what to include, what to leave out” (the latter being a far more important choice than is often realized).
  5. Craft – The actual work of getting the thing done: problem solving, use of skills, etc.
  6. Surface – The immediately-perceivable traits, like polish or production values.

What’s perhaps most breathtaking the first time you read Understanding Comics is McCloud’s narrative which portrays the reality that almost nobody starts with step 1 and proceeds to step 6. In fact, it’s far more common to go backwards: to see just the surface gloss of something and try to mimic that, with no understanding at all of the decisions that inform the rest of the work, and how they depend on each other.

In our realm, this pathology is highly obvious. If McCloud’s version is a kid tracing Wolverine onto lined notebook paper and declaring “I can draw as well as a professional!”, then surely our equivalent is the UI “skin”, like the hackery that can make a Windows or Linux desktop look like Mac OS X, but can’t change the fact that everything below the surface is built up with the respective ideas of those operating systems.

This is why I’m convinced Linux can never succeed as a desktop OS. When I used GNOME as my desktop for a year back in 2001, I commonly complained that the desktop gave me at least a dozen places to set my visual theme, but setting the damned clock still required me to jump into xterm and do sudo date -s ... I haven’t used it since then, but I wonder if they’ve even gotten inter-application copy-and-paste working (to say nothing of drag-and-drop). McCloud’s narrative shows genuine artists eventually working all the way back to step 1 or 2, asking “why am I doing this”, and proceeding forward, making informed and purposeful decisions about idiom, structure, and craft. It’s hard to imagine the Linux community having the wherewithal and discipline to see through such a process, when they’ve proven themselves willing to fork their code at the drop of a hat (or, more accurately, the outbreak of a Kirk-versus-Picard flamewar). The result is something that’s so baroque and self-contradictory it isn’t even necessarily ideal for hackers, and there’s little hope of this community ever deciding to build something their moms can use.

A lot of projects make bad choices of “form”, and doom themselves from the start. In the 90’s, there seemed to be people who believed that every activity worth undertaking should be done in the form of a startup company. As it turned out, fairly few endeavors are well-suited to that approach.

Today, we see people falling over themselves to make everything into an iPhone app, even when it’s not appropriate. If most of the value of your project comes from data provided via servers you own or operate, it’s likely that a webapp is more appropriate than a genuine iPhone app. Clever use of iPhone CSS can produce webapps that behave much like native apps (the Facebook webapp is still as good as its App Store equivalent), can be updated for all users at any time, and can be adapted to other devices without starting over at square one (compare to the challenge of rewriting your iPhone app for Android, Blackberry, Windows Mobile, etc.).

If anything, many of the great iPhone apps are heralding a resurgence of the “productivity app”, which Broderbund founder Doug Carlston defined to Tim O’Reilly as “any application where the user’s own data matters more to him than the data we provide.” Any iPhone app worth writing is going to involve some significant user data, whether that’s classic user data like their mail, their files, audio they’ve recorded… but also data as simple as where the user is when they run the app. After all, the hundreds of thousands of records in the the restaurant-finder app’s database is useless to me; what matters is finding what I like that’s close to where I am. In other words, the data has no value until it gets those crucial inputs: where I am and what I want to eat.

Now here’s an interesting mental exercise: where would what we consider to be “design” fall in McCloud’s six steps? At first, I made a cursory decision that it was just part of step 5 (craft), as it was part of the doing of the work. That’s clearly wrong, as what we think of as design (and I’m mentally considering varying creative exercises I understand, like book writing, screenwriting, TV production, podcasting, software development, etc.) clearly encompasses the step 4 (structure) decisions of how to arrange the content. And it probably touches on step 6 too: deciding whether to use the brushed metal or plain UI look, whether to shoot in SD, HD, or on film, is a design decision as well. But would we consider step 3 (genre/idiom) to be part of design? I think not. I think that’s a decision that precedes design, one that informs just what it is we’re going to be designing (a educational game versus an electronic series of lessons, historical fiction versus documentary, etc.).

Still, I think it’s important not to make too early, too easy assumptions about the major decisions at the front of the process. “Why am I doing this” is the most important question to ask yourself: it shouldn’t be skipped.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.