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:
- 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.
- 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.
- 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 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.
- When Skills Accidentally Get Stuck in Time
- The Inside Scoop Behind The New SportsLizard
- HTML5 or Native Apps? Why We Chose HTML5 for LockerPulse. Plus – Our Awesome New Shirts
- On the LockerPulse Blog: Making HTML5 and Responsive Design Work for Web Apps Like LockerPulse