Posted by Kevin Lofgren.

As a team, we have been doing web development since Yahoo! consisted of two Stanford students in a trailer. In the late nineties, we recognized that the traditional approach to software development wasn't well suited for web technology or for the pace at which web projects must move. We also developed a few techniques that work really well, and we've combined the best of them into our own method - we call it the screen-back approach.

The screen-back approach is based on our belief that web development should start where the rubber hits the road - with the user interface. By this, we mean that the specific tasks that end users need to perform should drive the system design, not vice versa. And because people interact with websites and software products via the user interface, that's where development should start. It might sound like common sense, but this is not how most web development projects worked back then. And frankly, it's surprising to learn that some still don't, ten years later.

Typically, a software development project starts with a list of desired features. Before development begins, these features are described in great detail in a document. This document is then handed to an engineering team and they begin building the product. At some point the product is ready to test, and then you can finally begin to see how users interact with it. Inevitably, this is when you come up with lots of great new ideas - meaning additions and changes to the UI and to the functionality. This is where you run into problems - because the product has already been built, it's very costly and time-consuming to make changes. So you compromise.

The screen-back approach flips this model on its head. In a nutshell, the screen-back approach is a highly iterative method for designing user interfaces and capturing functional requirements for a web site or software product. The cornerstone of this approach is visual prototyping. A visual prototype is a working model of a system. From the user's perspective, it feels almost exactly like the real thing. It's clickable, meaning that the buttons work, and the user can perform pre-scripted tasks just as they would with the real thing. This gives you invaluable insight before the product is built. And, perhaps more importantly, you have time to make changes. It's hard in 2008 to remember how innovative this way of working was ten years ago. But for anyone else who was there at the time, if you try hard enough you just might.

Of course, one of the great things about web technology is that it allows for very clean separation of the visual (the front end or user interface) from the functional (the back end). This allows the functional and design team to work almost completely independently from the engineering team. It also provides for a clear hand-off point between product marketing and engineering - the visual prototype is that hand-off.

We build visual prototypes with rapid prototyping technologies such as browser-based languages, Adobe Flex and Flash, even Microsoft PowerPoint (shudder). With these tools, prototypes can be developed in days, even hours - not weeks. In fact, a visual prototype can often be developed in less time than it would take to describe the same features in a document.

There are many advantages to this approach:

• Changes, both big and small, can be made quickly - this allows for lots of testing and iterations
• Replaces text-based requirements documents with visual models, reducing the risk of miscommunication
• Speeds time to market - engineering and UI design can occur simultaneously
• Serves as a quality "handshake" between marketing and engineering organizations
• Cost-effective and efficient use of resources

Ultimately, your users will judge your application by what they see and experience - in other words, the screens. Why not start there and work backward?

kl