Getting Real is all about starting from the user interface and customer experience and then building out. Visual design first, programming second. The more traditional process is starting from the abstract (documentation, diagrams, charts, etc.), coding a skeleton app, and then homing in on the real by finishing it up with an interface. We think that’s backwards.
Over the next few weeks I’ll be writing more about our Getting Real process, but I wanted to jump in by first talking about step 1…
Step 1: Don’t write a functional specifications document
Don’t write a functional specifications document. Why? Well, there’s nothing functional about a functional specifications document.
Functional specifications documents lead to an illusion of agreement. A bunch of people agreeing on paragraphs of text is not real agreement. Everyone is reading the same thing, but they’re often thinking something different. This inevitably comes out in the future when it’s too late. “Wait, that’s not what I had in mind…” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it — you even signed off on it.” You know the drill.
Functional specifications document are “yes documents.” They’re political. They’re all about getting to “yes” and we think the goal up front should be getting to “no.” Functional specs lead to scope creep from the very start. There’s very little cost in saying “yeah, ok, let’s add that” to a Word document.
Functional specs are often appeasement documents. They’re about making people feel involved. But, there’s very little reality attached to anything you do when the builders aren’t building, the designers aren’t designing, and the people aren’t using. We think reality builds better products than appeasement.
Functional specs are about making decisions before you have enough information to decide. They are about predicting the future and we all know how accurate that is.
So what do we do in place of a functional spec? We write a one page story about what the app should do. If it takes more than a page to explain it, then it’s too complex. If it’s simple and it takes more than a page to write it then we’re not writing clearly enough. This process should take no longer than a few days.
Then we begin building the interface — the interface is the functional spec. First with some quick and simple paper sketches, then directly into HTML. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground.
Bottom line: We want to build something we can all start looking at, using, clicking through, and “feeling” before a line of back-end code is written. We want to be in front of the customer experience for as close to 100% of the time as possible.
Article by Jason Fried: Getting Real, Step 1: No Functional Spec