Chris Johnston

Since xDD terms are all the rage right now, I think I will introduce another one: Interface Driven Design. And by Interface I don’t mean the kind that Java classes implement. I mean the kind that humans use when interacting with a computer.

The idea is very simple, all GUI based software projects–software that real people interact with–need to start with the design of their interface first before any coding begins. And that interface needs to act as the blueprint for everything that is developed. If there is no place for it in the interface then either the interface needs to change or the feature is dropped. In addition, you know that you are finished a feature when that part of the interface works.

The design of the interface serves two purposes:

1. It helps to focus the business requirements gathering process and give form to what the client wants and
2. It guides all development going forward.

The last very important point about interface driven design is that the designers should never go away once coding begins. They are as important to the project as developers, business analysts or quality assurance people are. Their job is far more then simply drawing pretty pictures and making the screen usable, although, the latter point is still a very important part of their job.

Interfaces need constant tending. They are like little children that, when not watched, get out of hand and loose focus. It is the UI designer’s job to keep everything in line and ensure that the interface stays true to the original project vision.

One problem is that many developers do not see the importance of designing good usable interfaces to their software. “It can be added at the end once all the real work is done”, they say. But this is false on several different levels.

First, without an interface, how do you know what the customer wants? they may ask for a registration screen, but without having worked through the exercise of designing that screen and showing it to the client, how do they know what information should be on that screen?

Second, the interface is very lightweight and can be changed easily and quickly. it can also be change many times before a decision is reached. Paper and pencils are very cheap. So by starting with, and returning to, the interface, you keep the project highly Agile. By the end of the design exercise, the client knows what they want and the result is clearer requirements for the developers. Both sides win.

None of this is new to me. Parts are taken from 37Signals, the group that created Basecamp and Backpack and parts are loosely taken–and possibly misrepresented–from a talk that I attended on Behaviour Driven Design. The gist of the talk was to start with the interface. To start with what the client needs and derive your requirements from it. Whether that interface be a computer screen or a laser etching.

This point has been driven home to me over the last several weeks. I am working on a small Ruby on Rails project. I have a general idea of what the app is, but I have neglected to do wireframes or sketches of the interface. As a result, development on the project has slowed. This is because I don’t have a clear idea what is needed and what it will look like to the end user. I am now going back and creating sketches of every single page and creating static HTML to go with each sketch.

This will give the project focus and really guide the development as I work to implement each feature in the HTML mockups. Once the interface works, I can then go back and figure out where new features fit and what they will look like.