Recently, I’ve been writing and talking a lot about the concept of a single feature release. It’s a simple and effective technique for shifting one’s approach to UX design (that is, if your approach is a more traditional variant) to one that integrates more seamlessly (and, likely, also more successfully) with how Agile teams build software.
Agile, in general, is about looking at the same problems and challenges traditional design teams face in fundamentally different way, sort of like those HSBC ads. This radically different viewpoint, in turn, leads to radically different actions.
The Single Feature Release technique is very much aligned with this. When looking that the same old long list of features that the client wants implemented, instead of asking “what might be a design that would unify all these features into a whole experience,” one instead asks “what is one, or maybe two, features in this big list that alone would create a whole experience?”
The feature(s) for which the answer to this question is “Yes” are your Single Feature Release candidates. Designing the first release of your product for just those features will, of course, be faster than trying to design the whole product. In turn, you bring development further upstream, which goes to the very core of an Agile approach to making software, and brings with it many many of benefits.
Rather than repeat them all here, check out my post on the topic at Crisp’s blog, where I discuss this idea in more detail.