Is 'Useful' the New 'Usable?'

I have recently written two separate pieces that are starting to converge for me. One was a guest blog at Usabilla.com: Useful, Saleable, Buildable: The Role of UX in Defining Requirements.  The other was a column in UXmatters.com: UX Dimensions of Conflict

In the first, I mention that I have been shifting my design focus from being usable to being useful. In the second, I discuss the risk of innovative design versus conventional solutions. I wonder if I am becoming the IKEA of user experience, looking for products that are functional, reasonably attractive, but most important, easy to ship and warehouse.

And I'm wondering how I feel about that.

Useful and/or Useable

Let me start by differentiating these two terms.

• Usable has to do with attributes like user-friendly, intuitive, learnable, error-tolerant, etc. Essentially, how easily does the design help the user meet the goal of the design?  For example, a print dialog can be very usable if it enables a user to make all the right decisions and efficiently provide the required inputs to print a document.
• Useful has to do with does the feature serve a goal of the user? Let's go back to the print dialog example. If the user doesn't want to print documents, if instead the user wants to export them as .XML files, then the print dialog is not very useful.

I think we would all agree that useful and usable are not mutually exclusive, but I definitely see where I spend most of my effort on useful, whereas not that long ago it seemed most of my effort was on usable. And I think it has been an appropriate shift.

I know that sounds heretical, but hear me out. There are some dynamics in my world that have made this a logical transition:

• I work for a company that has a well-defined style guide and philosophy for its UIs.
• I work in an engineering group that has a designated library of UI widgets.
• My engineering group uses Agile as its development methodology.
• I work with UI developers who are well-grounded in principles of HCI.

My interaction design is pretty well bounded by compliance and the widget library at our disposal. So there is not a lot of wiggle room for interaction design decisions--and interaction is at the core of usability.

Being Agile means that to a large degree the building of it is the designing of it. Couple this with the fact that I work with talented UI developers who have a finite bag of widgets, and I really should not waste a lot of time defining interactions they can build faster and better than I can design.


So most of my energy is spent at the front end defining scenarios and sketching wireframes that help encapsulate what the user wants to do. So when I put a calendar widget on a wireframe it tells users and stakeholders "Yes, we will accommodate the fact that you want to set date parameters around this feature." It tells the developer, "Use your stock date selector here."

In an ideal world I would circle around and do usability testing to see if all of this was usable, but I rely on our staying compliant with corporate guidelines and industry practices and the skill of the developers to reduce our usability risk. Usability is becoming a triage victim of the new economy--but largely because its risk is getting low for all of the reasons I've stated. It is a better business decision for me to worry about are we building a product the user will value, i.e., find useful, rather than are we building interactions that will be usable.

Innovative versus Conventional

OK, notice there is no and/or on this one--I went all the way to 'versus.' Yes you can have both, but it is like the treble/bass knob on your radio. The more you have one, the less you get of the other. Here, the trick is balance. I am particularly sensitive about this because I think the kind of environment I have been describing does not naturally stimulate innovation. Technology constraints, widget library limitations, and the tight time-boxing that comes with Agile means I probably will not do a lot of revolutionary interaction design. In fact, I argue in my UXmatters column that innovation can often work against usability. Users know and understand conventional interactions such as radio buttons, text fields, calendar widgets. Change those rules and you introduce usability issues.

So when should you bother with innovation?

When usefulness demands it! I just had my socks blown off this week by something that came out of the Watson Center for Research. Let's just say it was a very innovative way to have users interact with the UI. It so happened that it can be applied to a problem I'm trying to solve around helping users navigate through complex risk components that have a lot of interaction with each other. So why am I now (uncharacteristically) willing to go to bat for a UI that can't be built out of our standard widgets and which will initially befuddle the user due to its novelty? Because it will be so damn useful!

I really do believe the landscape has shifted and UX professionals should be focusing on usefulness. We can't ignore usability, but we do need to be sensitive to where usability risk is getting mitigated by well-thought out style guides, practices, pre-developed widgets, and skilled developers--and make good business decisions about putting our efforts further upstream in designing products that are useful