Refactoring for TDD and interaction design

In TDD, we follow a rhythm of “test-code-refactor.” This basic pattern is useful in all aspects of product development. The basic idea is to avoid building something based on what you think it might need to do in the future. Instead, we build for today, but then constantly look for ways to reconfigure what we’ve created to make it more general, more flexible, more useful. This process is called refactoring. In code, it helps us to build reusable components that are suitable for assembly into complex systems without having to guess which components are needed (or how they should work). In effect, the specific examples drive the spec for what the general pieces should look like.

The same process works in Interaction Design. The temptation is try and build a toolkit of general pieces, which can be assembled into many kinds of final product. This rarely works, because it is hard to build pieces that work optimally for diverse uses without damaging each use case (which leads to mediocre or compromised results). Much better is to infer the right toolkit by searching for commonalities among actually-built experiences.