Rapid PrototypingWhy designing the user interface of a web app first makes more sense

Developers are designing a large percentage of web applications, and it’s costing the companies that build them more than they know.

A few years ago I was at a web design workshop where the speaker was advocating the idea of treating the web design as a visual technical spec

for development teams. His suggestion was to design the user interface first and make it so clear that the developers would be able to write the

supporting code using only these screenshots as guides, thus avoiding written technical specs entirely. A concerned participant, apparently from

a Fortune 500 company, interrupted with the comment, “If we didn’t write technical specs at my company my entire team would be on the

street.”

The intensely visual nature of the web means that functional specs are generally a waste of everyone’s time. They cost time and offer no guaran-

tees that the presentation of functional elements will be interpreted correctly. The problem is that simply writing down a technical process does

not ensure agreement about how the tool will actually be experienced by the end user. Getting everyone on the same page literally requires pic-

tures.

Part One...................................................................................................................

Why Designing User Interfaces Are More Important Than EverThis design driven reality has become a popular theme in web app blogs and conferences. A host of websites and guides have sprung up to edu-

cate startups and development houses about the advantages of a design-first development process. Vocal protagonists like Tom Peters, Seth

Godin and Jason Fried are even suggesting that enterprise level development teams need to embrace the idea that engineers can no longer dic-

tate how a customer-focused web tool will be designed and developed.

The problem is that technical specs disenfranchise the very people that will determine the success or failure of the application. The customer

very rarely has any input when the spec is written and the user interface designers are sometimes the last to see the product before it is pushed

out the door. In today’s light speed economy it’s often too late to retrofit the tools with feedback from the customer or usability experts. Launch-

ing a complete product often get’s blindsided by unfavorable customer feedback. As the erstwhile business philosopher Mike Tyson once said,

“Everybody has a plan until they get hit”.

In subtle support of this philosophy and in contrast to the bloated technical teams of the late nineties we’re now faced with an explosion of very

small web companies with a desire to stay small. Small teams that can’t afford the luxury of architects and senior engineers are turning to their

designers. By all accounts startups in the Boston area are engaging designers to engineer their web products. Last months’Web Innovator’s

meeting announced several new web apps barely out of beta testing. From first looks it was impossible to tell what part of these apps were real

and what was just HTML presenting an interface aimed at testing audience reactions.

This back-to-front development process is allowing these companies to speed up the development process and reduce the cost of development.

What’s surprising is that by giving the designers the lead role the engineering teams are happier. Far from being angry or jealous of the de-

signer’s rise to fame, engineers are embracing the idea. Bob Allard, CEO of North Andover, MA based Extension Engine, supports this. “Rapid vi-

sual prototyping gives my offshore development team a fool-proof tech spec that cuts about half the planning and development time out of the

project. That gives us more time to develop new clients and grow our business.”

Part Two...................................................................................................................

The Advantages of Designing Before Architecting Your Web ApplicationTraditional programming processes often put the developers in the lead role resulting in apps that were bloated or misdirected. Let’s think about

the cost of programming for a moment. Nobody will argue that the architects and senior engineers are the most expensive part of any develop-

ment team. The process of writing code is also expensive because the real output could only be measured once the tool or app is functional.

Bugs and mistakes require constant QA regardless of the project size. On the other hand design is a relatively short and inexpensive process that

can be measured immediately. Photoshop files or HTML wireframes are easy to change and improve upon. Screenshots also cut across language

barriers and subjective opinions.

There are other advantages to designing the product first before writing any code:1. The wireframe or prototype of the product can be an effective sales or fund raising tool. Beverly based print facilities

management startup, Archimedia Solutions Group, was able to close a deal with a key client based on their HTML prototype before they

had to invest in months of programming. Archimedia’s CEO, Mark DiPasquale commented “Our bootstrap budget forced us to think of

ways to get customer buy-in before we committed to a long-term development cycle. Designing the UI first was just the smart thing to

do.”

2. Testing designs against customer or audience needs. Nothing beats getting feedback before you launch. In countless usability work

shops we have seen how clients have their assumptions tested in ways they could not have imagined when they were writing their specs

or scope documents.

3. Raising money or interest from financial partners. PowerPoint can only go so far to convince your partners that they should part

with good money. A full prototype not only shows that you have thought your web business through from beginning to end but also

demonstrates exactly how users will interact with each page or functional element.

Although design has always been a core element of good business, it generally gets treated like the red headed stepchild by the technical teams.

Adding a user interface is tantamount to adding lipstick to the pig. Technical planning seems to be embracing design and its positive impact can

be seen in the number of early stage businesses using this technique.

Part Three...................................................................................................................

The Slow Death of the Tech SpecThe technical spec as we know it is dead. In a world of intensely visual design we have to ask why we still need to write massive documents to

describe web products that real people will use. Huge improvements in bandwidth, processing power and software efficiencies combined with

precipitously lower costs in design and development demand a new approach to building web apps and websites. The time has come for the

designers and developers of web products to follow the example of architects, product designers and manufactures, and adopt the prototype

first approach.

There is general agreement amongst all of the teams I have worked with that the more difficult and complex a project the more likely there will

be problems. Conflicts arising from time, resource, and budget mismanagement can be attributed to one of two problems – not having the right

team members onboard or using an overly complex process. This is not to say that conflict is to be avoided at all costs. Constructive conflict that

leads to better understanding is perfectly acceptable. Our goal is not to stop smart people from debating conflicting ideas but rather to reduce

the friction that prevents them from executing those ideas.

Removing the friction from the project design and development process starts with understanding that only a single objective can prevail. De-

sign projects that attempt to achieve multiple objectives are doomed to endless meetings about priorities and resource allocation. Priorities are

a distraction. A simply elucidated objective is the only priority and therefore discussions about priorities are avoided. Lack of a single priority

comes from attempting to address too many issues at once and this more than often happens when we start writing down specifications for a

project. It’s too easy to add another list of features of another use case in a spec document.

It’s necessary to mention here that if you have a team of A+ players assembled and you reduce many of these problems from the start. To borrow

Jim Collins Good to Great lexicon it’ll be far easier to get the bus heading in the right direction if you already have the right people on the bus.

However, in the real world of designing web applications you will sometimes be inheriting other resources from vendors or partners, which

make the requirements of a simple design and development process even more important. This simple process is prototyping.

Once the priority of a project is established the team should immediately move towards visualizing that idea. This can take many forms but we

have found that whiteboards and large pieces of paper work wonders to get everyone on the same page. We do not suggest a brainstorming

session or the creation of a spec writing team. Nothing slows down the creative process like a sixty-page document complete with spreadsheets

and appendices. Written specs tend to become a territorial battle for the authors because of the time invested in writing them. A technical spec

for a web application can take weeks even months to prepare.

Arguments for detailed specs include the need for writing use cases. The problem with this argument is that neither the person writing the use

cases nor the person using the proposed functionality is part of the development process. Disenfranchising the very people from the design

process is as bad as a politician developing legislation for communities they’ve never visited. Use cases are extremely artificial. They lack the au-

thenticity of the real world. Composite use cases are even worse. They attempt to combine several characteristics of a customer profile or user

segment into a single model. Use cases can’t refute assumptions like real people. Building a prototype so real people can test and scrutinize it al-

lows for immediate feedbacks that can illicit real improvements.

Part Four...................................................................................................................

How to Build a PrototypePrototypes are also energy efficient. Almost all the work that goes into a prototype gets integrated into the final product. Recycling work is one

of the best ways to simplify the development process. Large spec documents are one of the biggest drains on the team’s resources and energy.

Unless you are building the space shuttle it’s always better to start with sketches and mock-ups before even thinking of writing an unwieldy

spec. Sketches can quickly become mock-ups and prototypes, which accelerate the design and development process.

Step-by-Step Process:

1. Use paper or whiteboards to sketch your ideas for the new web site or application

2. Use any Use Cases or Personas you might have to test your assumptions. Keep in mind that if you are designing a web application that

you won’t directly be using, e.g. designing for a client, you’ll need use cases. If you will be using it yourself then you can probably test your

own assumptions though critical analysis of your own activities.

3. If you are using paper sheets (highly recommended) we suggest you make a time line of pages that the user will have to go through to

complete a functional set of steps. For example, if you are designing a registration process make sure you design each step and all

possible states, i.e. ideal, error or sample states.

4. Once satisfied with the sketches transfer the drawings into Photoshop or Illustrator as wireframes.

5. Render the wireframes with the necessary color palette to identify possible design or aesthetic conflicts.

6. Code the pages and link appropriate pages together in the way they will be used.

7. Start testing the design with objective feedback from individuals and groups not vested in your design or design process.

Simplifying the design and development process does not translate to being simplistic. Just because a project strives to be simple does not

mean it can be achieved without critical thinking and hard work. Can you really engineer happiness? No, but you can remove the things that

slow you down and you can align the elements to improve the changes for a happier team. Removing the need for tech specs for web projects

saves time and energy resulting in a happier and more motivated team. As challenging as a no-spec world might seem to you the pros outweigh

the cons 10-to-1 and ground the entire process in reality. Try a low spec diet and watch the fat disappear.