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 can 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 files 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 first before writing any code:
- The wireframe or prototype of the product can be an effective 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 that “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 first was just the smart thing to do.”
- Testing designs against customer or audience needs. Nothing beats getting feedback before you launch. In countless usability workshops 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.
- Raising money or interest from financial 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 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.
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...




