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 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. 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 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 authenticity 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 allows for immediate feedbacks that can illicit real improvements.