Rapid Prototyping Why designing the user interface of a web app ﬁrst 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 ﬁrst 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 oﬀer no guarantees 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 pictures.
Part One ................................................................................................................... Why Designing User Interfaces Are More Important Than Ever This design driven reality has become a popular theme in web app blogs and conferences. A host of websites and guides have sprung up to educate startups and development houses about the advantages of a design-ﬁrst 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 dictate 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 retroﬁt the tools with feedback from the customer or usability experts. Launching 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 aﬀord 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 ﬁrst 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 designer’s rise to fame, engineers are embracing the idea. Bob Allard, CEO of North Andover, MA based Extension Engine, supports this. “Rapid visual prototyping gives my oﬀshore 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 Application Traditional 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 development 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 ﬁles 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 ﬁrst before writing any code: 1. The wireframe or prototype of the product can be an eﬀective 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 ﬁrst 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 ﬁnancial 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 Spec The 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 eﬃciencies 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 ﬁrst approach. There is general agreement amongst all of the teams I have worked with that the more diﬃcult and complex a project the more likely there will be problems. Conﬂicts 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 conﬂict is to be avoided at all costs. Constructive conﬂict that leads to better understanding is perfectly acceptable. Our goal is not to stop smart people from debating conﬂicting 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. Design 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 speciﬁcations 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 artiﬁcial. They lack the authenticity of the real world. Composite use cases are even worse. They attempt to combine several characteristics of a customer proﬁle 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 allows for immediate feedbacks that can illicit real improvements.
Part Four ................................................................................................................... How to Build a Prototype Prototypes are also energy eﬃcient. Almost all the work that goes into a prototype gets integrated into the ﬁnal 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.
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 satisﬁed 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 conﬂicts. 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.