Programming or Design – Which Comes First?

Over the past few years, Mike and I have come up with a pretty good design and development process.  I think the new Detailed Image site is proof of that. I mean, we built a pretty awesome e-commerce platform from scratch in less than five months while still performing most of our day to day responsibilities.

It always interests me to hear how other companies do things, especially because we’re starting to learn that we do things different than most.  It’s not that our way is necessarily better or worse, but just that we solved the problem our way, which happens to be different.

The other day I read Jason Fried’s post recapping the first two months of 37Signals new development workflow.  A little background:

Instead of working individually in isolation as we had in the past, we’re breaking into small teams of three (two programmers, one designer). We’re keeping the teams intact for two months at a time. During those two months, the teams will work on four separate iterations, two weeks each. The goal is to drastically cut down scope, set short fixed deadlines, and focus on improving our products.

This is a really interesting concept, albeit one that won’t apply directly to us for a while. As the post goes on to explain though, certain aspects have worked well and certain aspects haven’t. One of the issues was that the development team was waiting around to get started while the design team finished the interface:

Lesson: Design needs a head start
Since we believe in designing the interface first, we ultimately found it made sense for the programmers to take on a few small tasks or bug fixes on the first Monday, Tuesday, and Wednesday of an iteration while the designer was working on the UI for the first big feature of the iteration. This way no one was sitting around waiting for design to be ready before they could begin. With short two-week iterations there’s no time for anyone to sit around waiting for step one before they can start on step two.

Now, here’s where it gets interesting. We do that a little differently. It isn’t that the interface is done first and then the programmer comes along and programs the features into the interface. It’s not two rigidly separate events. To us, the interface is a much more fluid thing that is integral to each step of the design and development. We design the interface first, but we don’t actually build it first. We build a basic interface structure as we program, and then complete the full aesthetically functional interface only after the programming is complete.

Whew that was verbose. Maybe this explains it better: on any new site or feature, our process goes something like this:

  1. Mike and I meet and create the user interface and wireframe the site structure. This usually is done on paper, but we’ve also done simple HTML mock-ups or Photoshop mock-ups. The goal isn’t to build anything that will actually be used, it’s to quickly (within a few hours) reach an agreement on a uniformed vision of the UI. We do a lot of talking, pointing at examples of other sites on our monitors, drawing quick sketches, and using Firebug to quickly hack up existing sites and see how ideas might turn out.
  2. I go off and program the feature. As I program, I lay out the basic interface and create the basic styles in the stylesheet, using our interface sketches as my guide. My focus is on creating something that works.
  3. Mike then creates the graphics and finishes off the design. His focus is to take something that works and make it as visually pleasing and as user-friendly as possible on every single browser.

So in our situation, it’s the designer who is always tailing the programmer, and not the other way around.

I really started thinking about WHY we do this and why it works?  Here’s what I came up with: functionality is not dependent on design as much as design is dependent upon functionality.  In other words, the design can only be it’s very best when there’s a functional site for it to work with.  Whereas, the functional site can still be at it’s very best with almost no design whatsoever (hence the basic interface framework that I put in place).

Does that actually make sense? I think it does…

Mike sees how it works and how it functions and can try it for real instead of speculating.  As long as we have a basic interface and structure agreed upon, I don’t benefit from having design done first. But Mike definitely does benefit from having the functional development complete.

I guess this only works given a few assumptions:

  • Both the designer and programmer are web-savvy enough to create user interfaces (in my opinion, both have to be capable of doing so to be good at their jobs)
  • Your programmer is reasonably proficient in HTML and CSS, enough so to build the basic interface to test their work before passing it along (I am not nearly as good at CSS as Mike is, but I’m getting better and I know enough to set things up in a way that saves him time once he starts designing and expanding upon it).
  • The programmer does both the client-side and server-side programming. For instance, I do all of our Javascript and XML, in addition to the PHP. To me, this makes sense because I’m making AJAX calls and it seems simpler to have me doing that entire process.
  • The programmer is experienced enough to notice any interface flaws or feature flaws early on, and if necessary stops and starts the planning process again (occasionally this happens to us and it just takes one more meeting to straighten things out, although it’s becoming more rare the longer we do this)

I’m not really trying to prove a point here. Just that what works for 37Signals and other companies isn’t what works for us, which is interesting to me. For any small team of two I think our process definitely warrants some strong consideration.

4 comments on Programming or Design – Which Comes First?

  1. Dave says:

    I almost always do two things before I work on a design (and this is fresh in my head because I’m currently working on a new site now).

    First I’ll create a sitemap of the pages that will exist on the site. Then within that I’ll create essentially a high-level breakdown of the elements that need to exist on that page. For example if it was a product page for a store it would need to have price, picture, share button, etc, etc.

    Then I may do some quick wireframing on paper just to get an overall idea of how the big things can get laid out on the page. Then I’ll go and try and basically do an exact mockup in Photoshop of how it should look once completed. It’s easier for me to do this, have a completed page, and then go and code it (or send it out to get coded) instead of playing around in a browser. Doing it all in Photoshop makes it faster to move elements around within pixel precision. That way when you code, you’re simply HTML/CSS sketching exactly what you know you want. Elements can be modified down the line of course, but it’s important to me to have a finished-looking product before touching any code.

    That being said, I would consider myself way more of a frontend designer than a developer. I have the ability to take a pre-existing application and then skin it with a design I’ve done/coded…but I don’t really have the capability to program new functionality. I would love to have the experience working hand in hand with a programmer to do everything custom, but for now I just sort of know where my limits are, and design accordingly.

    • Adam McFarland says:

      Thanks for sharing Dave. Sounds like you’ve got a pretty good process. Mike likes to do the Photoshop mock-ups for major redesigns too for many of the same reasons.

      When we “wireframe” we do the same sitemap process that you’re talking about. I think everyone probably defines it slightly different, but I tend to refer to wireframing as both a relatively detailed sketch of the page layout itself and also a sitemap layout of how the pages interlink. At times I’ve even used a huge piece of poster board to do it. It’s one of my favorite parts of the process. I’ll have to scan one in and do a separate post about it sometime.

  2. […] don’t always agree with the way they do things – just last week I wrote about how our development process differs from theirs – but I really just love their authenticity. Their core business values align with mine. They […]

  3. I liked the comment of Dave. Also, i work in the same First Design then code. It makes everything quite simpler for the future process.

    Here’s I came to know the process of coding first and designing second is. Programmer here have no experience in designing and they just code the functionality with their own mind to achieve the things that has been requested by client. This way it’s making difficult for designer to design after the html+php code has been implemented because the modules of each section has been placed according to programmers choice and not consulting with designers. Programmer tells designer to make a design for this page that page and blah blah.

    Would you please tell me What should i do? (I’m a designer) I always have to screw the design that programmers has made & when i modify the things it doesn’t comes output as i want.

Leave a Reply

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

Commenting Rules

I'm honored that you found this post interesting enough to leave a comment. Before posting, I have a few ground rules:

  • Please keep your comments as relevant to the post as possible.
  • No personal attacks or any other nastiness.
  • Your first comment is subject to my approval.