3 Myths of Specs
Technical specs are a hangover from the days when you had to architect the back-end first. This was primarily because the bandwidth and hardware running the web could only deal with small amounts of information at a time. Now that we have more bandwidth we can design with the experience in mind and consider the application and data architecture afterwards.
Myth One - 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. If you are a small design team or are working on a project that will be less than three to four weeks of development we suggest jumping right in and start designing without writing any spec documents.
Myth Two –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. We live in a culture where that more complex the discussion the more important people think it is. This could not be further from the truth. Simplicity is the most challenging goal for any designer. Any documentation that makes the designers job easier should be held above any complex documents.
Myth Three –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. Involve the key design members in your development process from the very beginning. Think like Steve Jobs or Richard Branson. Ask yourself whether they would launch a product or service without discussing the idea with their designers first.
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...




