Free

Creating Web Apps Without a Spec

Read the book online:

Part 1Part 2Part 3Part 4

Part Four

How to Build a Prototype

Prototypes 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.

Previous
 

3 Myths of Specs3 Myths of Selling

Myth 1: Always write a technical spec

Technical specs are relevant and necessary when you have a huge project with lots of teams involved. In today's design and teams are much smaller and agile. Writing a spec before sketching out the work-flow is very often a waste of everyone's time.
More...

Myth 2: Technical Specs have to be long and complex to be worthwhile

This is one of those quantity vs. quality issues that designers face all the time. A 100 page document is not better than a 20 page document. Additionally, a document that contains only sketches and wireframes is not less important that the document with spreadsheets and heatmaps.
More...

Myth 3: Requirements need to be gathered by a project manager.

Disenfranchising the very people that will be working on the design project by excluding them from the early requirements gathering process is insane. Systems work best when the people that are using them are involved in building them to.
More...