A higher order of specification

User and Social Experience Design

While terms used by UX designers are often regarded as vague I believe that they should be considered a higher order of specification that collates and expands upon lower-level requirements.

I’m currently reading Sex, Ecology, Spirituality: The Spirit of Evolution by Ken Wilber, recommended to me by my friend Zara Choy which is where I learned about holarchies – the theory that everything is both a whole and a part, thus the amalgamation of things and itself part of something larger.

It’s an interesting theory and has certainly changed my way of thinking about the universe from a philosophical perspective but I think it has some practical applications too which dawned on me when I was thinking about the user experience of the fridge in our kitchen:

We bought a new fridge a few months ago; nothing wrong with the one we had – it’s only 18 months old – but it wasn’t big enough. So we upgraded to a larger fridge. One of the things I immediately liked about it was the improved temperature control that allowed you to intuitively control the temperature of the fridge or freezer from the one control positioned at head height.

However the one thing I don’t like about our new fridge is that the door doesn’t close readily. I push the fridge door and I expect the kinetic energy to finish the job, but not with this one. Something about the hinge design either intentional or flaw prevents the door from closing with a firm shove or holding onto the handle until the door is closed. If it was intentional then I suspect it might be to ensure the door is either closed or obviously open as a user feedback mechanism.

So while I was thinking about this I was thinking how we might describe the desired action of the door. We might specify the required door behaviour as being firm, or as being attracted to a state of being closed or not resistant to being pushed.

They’re terms people can easily relate to – it’s how they describe failures of technology. It’s also the way user experience designers might describe expected presentation and interaction.

Such terms are typically considered vague and wishy-washy. How does a developer or engineer implement firmness or humanistic behaviours?

But when considering all this in the context of holarchies I think there is a better way of looking at this.

I believe terms that describe behaviours and attributes such as responsiveness and helpfulness are higher-level collectives of baser specifications that include their child parts but also add something to it and so cannot be broken down into just those parts.

For example the human body is made up of cells which are made up of proteins … but “a sack of cells” does not mean the same thing as “human”. An igloo is made up of nothing but blocks of ice … yet throwing some blocks of ice together does not make an igloo.

Thus given the example of the fridge a requirement for a firm door action could be broken down into the design of the hinge, the weight of the door and the air pressure release mechanism … but by describing it collectively as “firm” you are combining those all parts that technically make up that behaviour but also add something to it through the very action of elevating it to a higher level of being.

In practice this ensures that, yes, while the engineers will need to tackle each of those parts as actionable engineering tasks that collectively they are part of something more significant and through consideration of that higher level of behaviour it ensures a consistent approach and singular outcome that rises above just being a hinge with a better action, a heavier door and a hole to release air pressure. It becomes a door that closes firmly when pushed. It can be a subtle difference in practice but it makes all the difference.

I’m working on a touchscreen kiosk application at the moment and recently spent a whole day on developing the scroll buttons. Why? Because I didn’t want scroll buttons that simply moved the page up or down by X number of pixels. I wanted buttons that were responsive, that felt right, that just worked.

If we think about such terms as having ascending the technical specifications then we can say that such “vague” requirements are comprised of actionable coding or engineering tasks but cannot be simplified purely down to that level without risk of losing some of the meaning and comprising the success of implementing that feature.

In the case of the scroll buttons making them “responsive” meant adding code that handled the user double-tapping on the button or tapping it while the page was still scrolling from the last press, handling end-of-page nicely including disappearing and reappearing at the right time and tweaking the scroll interval and timing.

Another important thing to approaching describing the behaviour and attributes of and interface like this is that things are often forgotten from the UI specification. Thus describing the scroll buttons as “responsive” means that even if the specification had omitted what should happen if the user taps the scroll button again mid-animation it can be implied through the aim of meeting that higher goal of making the interface responsive.

I think it’s important for both UX designers and developers or implementers to adopt this mindset that there can be higher and lower level requirements when it comes to describing how an interface, a product or a service and that both types of requirement are perfectly valid. We’ve all been working with product strategies and high-level business requirements for years but for some reason when it comes to user experience design such requirements are often dismissed as useless and not actionable.

Designers need to ensure that higher-level requirements can be broken down and should assist in that translation. Developers need to understand that higher-level requirements cannot be decomposed down to a lower level and mean the same thing.

// purecaffeine.com is a user interaction and UX design, social media and Government 2.0 blog run by professional Canberra, Australia web user interaction designer Nathanael Boehm, licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Australia License.

Related posts:

1. Style guides and UI implementation
2. I tried telling you gently …
3. Illustrated user scenario development techniques