Good design: driven, but not constrained, by specifics
From a set of notes by Chris Heathcote on Donald Norman’s new The Design of Future Things:
We’ve been taught to design systems for a purpose – preferably one purpose – collected through use cases and designed against them. Use case collection never really includes crazy ideas or tries to foretell unexpected and unplanned uses. Good design, in my mind, is designing enablers or tools that include the use cases given, but have breathing room, rather than designing strictly to the use cases. It could be said that this reduces usability, and it often does, but with the flipside of user value.
Too-narrow design is a substantial risk for Agile projects. Part of the reason for making a ubiquitous vocabulary part of the everyday project conversation is that it keeps people’s heads a bit in the problem domain, not just in the solution domain. That gives them leave to think in terms of more-general tools rather than whatever makes this story’s tests pass.
Refactoring is another technique that helps, since it tends to push the code toward generality. But it can’t be taken far enough, I think, unless there’s explicit slack in the project pace. You need breathing room to refactor, get an idea from that refactoring, use that idea to think again about the problem, and put the results of your thinking to some sort of test.