UX and the Spaces In-Between

Kevin Richardson, Ph.D. / Thursday, October 2, 2014

I don’t spend a lot of time on Twitter. I have nothing against it, I just usually have other things to do. Recently though, a designer friend of mine, @mattbartholomew, tweeted something that got me thinking.

tweet

In the field of Ecology, these sorts of boundaries are known as ecotones – areas of transition between two relatively homogeneous areas. Look it up – it’s pretty cool. Literally, the word means, “a place where ecologies are in tension.” It struck me that this is where we, as UX professionals, should be earning our keep - identifying, understanding and resolving areas of tension. I say “should” because I see this not being done far too often. There are, I think, two reasons why many UX professionals are unable to see beyond the immediate problem and allow rich boundary areas to drive their designs:

    1. It’s an advanced skill that’s difficult to master
    2. Clients are satisfied with much less

While neither of these reasons absolve us, as a profession, from blame (insert grumpy old man yelling, “Hey you kids! Get off my lawn!” here), neither is the subject of this article so let’s put that aside for the moment. Let’s also put aside Usability – heuristics, guidelines and testing. Usability is a required microcosm of user experience but it isn’t what drives the profession forward. It’s the professional equivalent of ensuring that a restaurant meal is edible before being brought to the table. Necessary, yes, but insufficient to guarantee the creation of a gourmet dish.

What UX Should Be

I’d like to focus on what User Experience Design should be – the process of uncovering, coordinating and creating innovative and useful solutions that go beyond what users are able to describe or request. With regard to business systems, this means focusing our research methods and observational skills on understanding the spaces “between.” It does not mean simply collecting requirements as if they were sea shells washed up on the beach waiting to be picked up. The true value of our work rests with our ability to understand the nuances that underlie areas of business tension…workplace ecotones.

Where are these boundary areas? Look beyond where User A meets Application B. Areas of business tension exist at almost every user-system-process-environment confluence. Spend some time examining the point at which Application B meets Business Process C. Or where User A meets Physical Work Environment D. Or even at how User A is being forced to play the role of information conduit and translator in order to provide an interface between Application B and Application E. This is where things get interesting. This is where UX makes a difference.

Typical UX project in which the focus is on the user, the application and the interface.

                  clip_image002

 

Rich UX project includes the interesting in-between bits that drive innovation and usefulness.

all_factors

A Recent Example

Not too long ago I finished a project for an energy company client. Their request was simply enough. Could I take their existing application, which was used by their client’s employees to manage the purchase, sale, transportation and delivery of energy products (e.g., natural gas, oil, kerosene, etc.), update it with some new features and make it easier to use. Easy, right? A simple walk-through of the application was enough to suggest certain improvements to layout, IA and usability. I could have made those changes and called it a day. Everyone would have been happy and the resulting system would have been “good enough”…maybe even “great” (the client had a pretty low bar). However, it’s not the client’s responsibility to determine when my design is great (or even good enough) – it’s mine. After conducting contextual inquiries with users, I noticed several other useful pieces of in-between information:

  1. Energy product schedulers sat directly across from sales and purchasing to support physical communication
  2. Use of the application in question did not occur in isolation but rather as an integral part of a larger process that included both upstream and downstream software
  3. Certain tasks were calendar-dependent, others occurred regularly and a few could happen at any time (including after-hours)

Each of these points could have been ignored. Neither the client nor the users were asking for a design that addressed these issues but by incorporating them I was able to take the resulting application design from usable and good enough to, “We never thought of doing it like that!”

My Soapbox

The goal of user experience should be to improve the human condition through innovative design. By looking beyond the immediate and including those interesting boundaries, we open ourselves, our clients and their users to possibilities that reframe the original question and suggest new and unifying solutions. Anything less and we’re just not doing our job.

Feel like talking or want to know more? Surf on over to KR's LinkedIn profile.