Defining “Good Enough”

One of the things I mentioned at the recent UXPeople conference was the need to agree “Good Enough” up front for any agile project that requires experience design. Now, before you go scanning to the end to read the answer, you might want to know that I don’t have one. Yet.

So this is more about my thinking and reasoning so far.

In any agile project, the team aims to be continually delivering software. That can be through client reviews at the end of your two week, three week, or longer “sprints” if you’re using something like scrum; at the end of each task in Kanban; but usually using some sort of continuous build as the foundation. From a UX point of view, you are working on the functional design and creative execution of individual features that you will share with the developers to get built. Exactly how you actually do this doesn’t matter right now, but I will write and talk about it in the future. It is, however, important to remember that what gets reviewed and signed off is the software. Anything else you create along the way is transient ephemera.

As part of this feature focussed sign off process, how do we ensure and maintain an appropriate level of quality for the functional design and creative execution? I know if I talk to a creative, then anything less than their idea of perfection is not good enough (I say “their idea” because this varies hugely according to the talent of the individual). I know some product owners would also aim for perfection. I also know some who don’t care.

In a developer-land without UX you can quite quickly and quite easily decide whether or not something is suitable for release. Let’s be slightly simplistic here, Good Enough to release is usually described in terms of number of bugs. For example, this can be anything from no priority one bugs and x% of outstanding priority two bugs resolved, to zero bugs at all (say for healthcare or military applications). So Good Enough is completed functionality with a bug constrained definition of quality.

In the world of agile software development, the product owner is king, but even if you have a number of stakeholders you face the same problem. We need to manage expectations of creative and functional design quality with the product owner (based on time and resource availability) and the corresponding creative and functional design ambitions of the UX people. We have a process that delivers chunks of an interface in incremental stages. However, one poorly (or excellently) executed but prominent piece of work can completely define (destroy) the perception of the product.

It seems to me that we need some kind of benchmark to evaluate the finished software as Good Enough from a UX perspective. And that needs to be locked in on day one, agreed across the whole team as the expectation for “Good Enough”, and unambiguous enough to actually be useful, usable and constructive. It may change (up or down) and if the standard goes up, then there will be a trigger (and justification) to refactor.

There are several ways you could measure quality after the fact. You can do usability tests on the finished product. You can plan to “refactor” the look and feel at periodic intervals due to design evolution. You can check that things match the definitions of intermediate artefacts (wireframe documents if you do them, Photoshop files etc). But how does this help you when you are in the flow of producing the product?

I’m struggling with defining an answer. I think there’s interesting mileage in The Kano Models that Andrew Harder was talking about in the session after me. Right now, I’m just trying to frame some thoughts around how product designers work to differing standards of “good enough” and how, from the outside looking in, I perceive those. The first angle is thinking about the value properties of different types of products:

The Farm Tractor: Supremely practical and functional. Versatility and performance completely override traditional notions of “beauty”, but there is still a sense of style and visual impact that they manage to create.

The Toyota: Pragmatically well constructed, but doesn’t excel in any particular arena or feel particularly special. Definitely not going to be winning any beauty pageants, but similarly not horribly offensive to the eyes.

The Dyson: Stand-out functionality but with a unique, innate beauty – but with a love it / hate it twist.

My second slant, is thinking about multi-brand manufacturers. The diversity of the VAG group is interesting here. They seem to have a spectrum of quality of engineering / monetary value / beauty / performance. Skoda is your basic, functional brand. Seat is a bit more performance oriented, but still not expensive. VW is solid engineering and quality. Audi is the crown jewel of exclusivity, beauty and speed.

Now, how do you apply this to Software Experience Design. That I need to think some more on…