Part One
Why Designing User Interfaces Are More Important Than Ever
This design driven reality has become a popular theme in web app blogs and conferences. A host of websites and guides have sprung up to educate startups and development houses about the advantages of a design-first development process. Vocal protagonists like Tom Peters, Seth Godin and Jason Fried are even suggesting that enterprise level development teams need to embrace the idea that engineers can no longer dictate how a customer-focused web tool will be designed and developed.
The problem is that technical specs disenfranchise the very people that will determine the success or failure of the application. The customer very rarely has any input when the spec is written and the user interface designers are sometimes the last to see the product before it is pushed out the door. In today’s light speed economy it’s often too late to retrofit the tools with feedback from the customer or usability experts. Launching a complete product often get’s blindsided by unfavorable customer feedback. As the erstwhile business philosopher Mike Tyson once said, “Everybody has a plan until they get hit”.
In subtle support of this philosophy and in contrast to the bloated technical teams of the late nineties we’re now faced with an explosion of very small web companies with a desire to stay small. Small teams that can’t afford the luxury of architects and senior engineers are turning to their designers. By all accounts startups in the Boston area are engaging designers to engineer their web products. Last months’ Web Innovator’s meeting announced several new web apps barely out of beta testing. From first looks it was impossible to tell what part of these apps were real and what was just HTML presenting an interface aimed at testing audience reactions.
This back-to-front development process is allowing these companies to speed up the development process and reduce the cost of development. What’s surprising is that by giving the designers the lead role the engineering teams are happier. Far from being angry or jealous of the designer’s rise to fame, engineers are embracing the idea. Bob Allard, CEO of North Andover based Extension Engine, supports this. “Rapid visual prototyping gives my offshore development team a fool-proof tech spec that cuts about half the planning and development time out of the project. That gives us more time to develop new clients and grow our business.”
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...




