currently interested in awesomeness and how to create it

Don’t throw that mock-up away

Are “throw-away deliverables” such as requirements, mock-ups, or use cases a waste of effort? Yes, said Ryan Singer of 37 signals as he illustrated their design process at this year’s WebExpo conference in Prague.

Is such advice applicable to people who do not work at 37 signals?

If you’ve worked for a corporate client, you’ll know that on any given software project, more paperwork is generated than actual code. Paperwork that has no value on its own. Would it make sense, then, to go lean and go from sketch notes directly to HTML / code?

Remember, we’re not talking about a startup project. Your team has 20 members and 50 different stakeholders. Get them build the thing now, no specs, just communication and craftsmanship.

I’ll say that even with the best people money can buy you won’t deliver.

The value of “throw-away deliverables” becomes apparent when you realize people have trouble imagining software work. It’s near impossible to visualize a complete application in your head unless and until you have taken several intermediate steps – and created a number of throw-aways in the process.

These intermediate steps are (roughly in that order but not necessarily so):

  1. Business requirements and Use Cases (what the thing does)
  2. Wireframes, mock-ups (how it looks)
  3. Technical specs (how it’s going to be built)

Visit Scott Sehlhorst’s series on requirements for a detailed information on how good requirements make better projects. Suffice to say, if you don’t say what you want, chances are you will not get anything or you will get something else than what you want.

Even if you and your team can read your customer’s mind, however, requirements still have a tremendous value for the people who write them.

Say it’s you who’s writing them. It opens your mind as you explore the problem domain and forces you to focus and express yourself clearly. Instead of saying, make me an app that processes invoices, which is a very lazy way of putting it, you’ll think about each action that has to be performed for an invoices to be processed, and in that process discover many, many requirements that would otherwise have gone unsaid – and, therefore, un-implemented.

Mock-ups, and product visualizations in general, are complementary to written requirements in that they illustrate, verify, and complement them. Most people are visual and a conceptual mock-up will let them think in terms of user interactions, instead of just objects and results. Graphic models alone can help create an app that does not just solve a customer’s problem but does it efficiently and perhaps with an added aesthetic flavor as well.

Then there’s the element of time.

For the sake of the argument, let’s stipulate your superb A team of ninjas and rock stars have read the customer’s mind and built a perfect app for your customer. A year passes by and you part ways with this customer. Then, a B team of ninjas steps in to continue your good work. Except, they are not telepaths and have nothing to go on except your source code. Your former customer has not documented their requirements and thrown those napkins away a long time ago.

Baaam! Good luck navigating this mess! (not that it’s your problem anymore but you could just as easily become a B team in another example)

As you see a well-produced set of ‘throw-away deliverables’ can help all parties involved in a software project. Yes, they are not valuable per se, just like a blueprint of your dream house isn’t. Now, would you try building it without it?

I will say that I envy 37s who can work this way. And there may be many other teams who are doing so, and maybe you can, too. The mundane, boring, and oft-criticized way of ‘getting there’ with a paper trail in your wake is, however, still the way for many more teams and projects and will continue to be for as long as making software is a hard, unpredictable process with uncertain results.

September 27, 2010 | Filed Under General, Software | 2 Comments