Code by design

I’ve been struggling again lately with this idea of maintaining a balance between thinking and making, or, more concretely, between designing and coding. By ‘designing’ I’m talking about the work typically engaged in by a designer (wireframes, flows, comps), and by coding, I mean the stuff that you’d normally get a developer in to do. As you can probably tell from the week-notes, I’ve not been doing a whole lot of the former lately… which does seem a little odd, given that I’m supposedly in an MFA Design program.

But the more I code, the more I’ve come to realize that that there is probably a false dichotomy here. I find that coding, as a brain-requiring activity, is far from the antithesis of design. Nor can it be considered a “non-designerly pursuit” as designers might see it. Instead, I’ve come to see coding as a form of design.

I subscribe to Paul Pangaro’s definition of design as simply making purposeful decisions. And coding, especially in the early stages of a project, feels a lot like just that: you have to do things with intent, you have to be very methodical and critical about why you are doing things a certain way, why you are using x technique instead of y, even down to why you are naming certain variables the way you did. It’s because the decisions you make now will impact what follows—and you also suspect that these things aren’t easy to change later, so you’d better put some good thought behind it.

So, in short, coding does a good job of putting you in a very purpose-driven, very “designerly” frame of mind. When I’m coding, I find myself constantly asking myself things like, “Are you sure you want to call that database collection ‘recipes’? Or maybe we should use a different word because that’s not what the site is about…” Asking these questions gets me to consider possible outcomes, determine strategy, and clarify goals. And the amazing part is, these seem to be the same things that wireframes, userflows, and comps were made to do, too…

The ‘recipe’ database question was actually something I chewed on for a very long time as I stared at my code. And through all the marathon staring sessions, it finally hit me that I do not want to use the word ‘recipe’ at all on the website (that is, unless absolutely necessary, to refer to an actual recipe). Not only are there enough recipe sites on the web already, recipes are really not what the Hotpot experience is about. Rather, it’s about an intimate shared experience with other people, built around food-as-social-object (or rather, food-prep-as-social-process). The recipe, insofar as it’s a standardized, formalized and usually terse set of instructions for getting from point a to point b, misses the point entirely. With Hotpot, it’s not so much about the “How?” of food, as it’s about the “Who with?”

I decided to name that database collection ‘meals’ instead. It connotes togetherness, conversation, shared experience… all those things I strive to create for the users of Hotpot.

Perhaps I could have arrived at the meals-not-recipes conclusion some other way, through more traditional design means like a competitive analysis or through making charts like this. But at the end of the day, I still managed to make that decision, while actualizing that decision in the form of written code too.

That was a pretty simplistic example of code catalyzing design, but there are others too. Like figuring out data hierarchy leading to the idea of capturing and presenting a timeline of cooking memories, similar to the one on Path. Or discrepancies in logic leading to the realization that ‘badges’ (awarded at the end of cooking to an awesome partner) play a fundamentally different role from ‘stamps’ (added during cooking to mark a notable occurrence)—they were originally thought to be the same thing.

Could it be that coding isn’t all just about executing a pre-determined plan, thought up while ‘designing’, but that it actually is a part of the design process? Perhaps this is not the case in big honking companies that believe in employing people just to be code monkeys, but when you’re on a small team of multi-disciplinary members, or you are on a solo project, I think writing code could totally be part of the designer’s toolkit. It’s a great way of coaxing the brain into a sharp, questioning state, so one can be intentional and purposeful with every move; in other words, so one can design.