Docs-driven development?

A customer sent me an email asking for a poll feedback functionality for UXWizz (a self-hosted analytics platform). A poll is, for example, a simple question form with a Yes/No answer. The answer should be saved into a database when submitted.

When adding a to-do takes longer than fixing it

Initially I wanted to implement it as a feature within the product, but I am strongly against adding features that are not core to the product (analytics). Realizing that this is really easy to implement, I thought it might be better to simply create a page in the docs explaining how to do it.

That was easy!

It took less than an hour to create the poll widget and tutorial.

You can check out the HTML/CSS/JavaScript used for the Polls in the docs.

Docs-driven development

The best part now is that if I ever decide to include this snippet as an actual feature within the product, I just have to copy the code described in the documentation.

This has other benefits too:

• It keeps the product lean as you can decide to only include a specific feature when it proves to be useful for a larger audience
• You can test/improve a feature with a small subset of users, without having to actually add the code to your product

I saw some references to "docs-driven development" across the web, but their philosophy was different, it was more about correctly documenting existing or planned features (similar to TDD).

This might even work in other domains, for example physical products: teach the customer, in your user manual, specific ways in which they can use or enhance the product. If enough customers do that, then optimize for that use-case. I do I think though that this works best for products targeted towards technical or DIY people.