Rapid Prototyping
Why designing the user interface of a web app first makes more sense
A large percentage of web applications are being designed by developers 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 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.
Start learning how you can use Rapid Prototyping to get going.
Prefer to download the entire book now?
Download All 4 Chapters Free
Questions or Suggestions? Please let us know:
3 Myths of Specs
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...