Free Yourself From Documentation

I came across an interesting post by 37signals about eliminating documentation from the development process.

A quick excerpt:

It looks like a dilemma. You either:

  1. Produce design ideas at the pace of development (which is far slower, by definition of the bottleneck) or
  2. Freeze ideas in the form of documents, diagrams and requirements until they are ready to be thawed and consumed later.

I suspect #2 is what happens in a lot of firms. The throughput from design to implementation in those places is so low that pacing design with development doesn’t seem feasible.

At 37signals we’re firmly in the #1 camp. Designs go from concept to HTML (often in-app) without any deliverables in-between, and then from HTML mock to fully implemented feature in Ruby or JavaScript again without intermediate artifacts.

In general, I agree; documentation is ‘frozen’ and can quickly go bad. But I don’t like tying everything to the pace of development, and here’s why:  Sometimes during the design phase, I identify things that I don’t want to do. Or I change my mind about the business value of particular features. I certainly don’t ever want my developers to have to wait to have design finished. If design is tightly coupled to development, my developers are  implementing ideas that are not fully formed, fully explored or understood. This, in and of itself, will slow development. If you have a problem with implementation throughput, that may simply reflect a design problem, not an implementor issue.

For me, ProtoShare provides teams with an Option 3:  Allow designers, UX’ers and business stakeholders to do some of the work that 37signals gives to their developers:  figure out what really works through prototyping. So instead of building ready-to-eat frozen specs, you actually experiment, iterate and evolve your ideas. You assess business value more realistically than without a simulation, so that when your developers are ready to build, they are building your best ideas – with the highest business value.

One other reason I love ProtoShare – it allows your designers, UX’ers and business stakeholders to focus on the work. Your team can be creative, experimental and innovative. ProtoShare handles the documentation for you. All of your ideas, discussions, thought processes and end results are all available within a single repository. Your developers can reference prototypes, creative and discussions – the true source material of your design process. This is why some of our customers have called ProtoShare the ‘brain’ of their development processes.

So this is what I agree with in the 37signals article:  Less documentation can mean more productivity. Documented solutions quickly go stale. What I don’t agree with: slow everything to the pace of development. Instead, use ProtoShare to accomplish some of the design tasks that slow development:  experimentation, iteration, exploration. You’ll end up with better products, make the right decisions about what features to develop, and you’ll speed up your development process through clearer specifications, improved communication and reduced rework.

This entry was posted in Blog, Industry, Prototyping Benefits. Bookmark the permalink.

Previous post:
Next post:

Leave a Reply

Your email address will not be published. Required fields are marked *