A colleague pointed me to a nice article by Sue Davis about writing for the public, and among the suggestions was the idea of timeboxing feedback: “If you don’t, the polishing process can be never-ending and you risk delaying getting the content to your users.”

Timeboxing is really valuable not just for getting feedback, but also for designing solutions more generally. In my last post I wrote about choosing the right time to start solutionising, and some time ago I mentioned timeboxing regarding the research phase of a project. We can bring both ideas together here. If we compress “the research phase of a project” down to “the research phase of a single feature” then timeboxing is a respectable way to decide when to stop generating ideas and start being specific about the solution.

We can also use a timebox to specify the whole process, from “let’s start thinking about this” to “now we’ve specified our solution”. For example we might start on a new piece of work and quickly decide that we’ll spent an hour generating some ideas, then four hours pulling out from those ideas a more specific solution.

Perfectionists might object to this. “After all,” they would say, “if you’re limiting time on your idea generation then you might miss some great ones. And if you’re limiting the time on specifying the solution then you could easily miss some crucial details.” But we would not be deterred. We would understand that a specification is rarely perfect, so it’s just a matter a of how much imperfection we accept. And while it’s true that more time will perhaps yield more ideas or more detail we would hit the law of diminishing returns. And of course let’s not forget Sue Davis’s comment—there is an opportunity cost, too.

Timeboxing our work when finding solutions is very valuable, and much more acceptable once we accept that we can’t achieve perfection.