Adobe MAX 2008: Lazy Innovation

I'm finally making good on my promise to expand upon some of my experiences and thoughts about the sessions that I participated in at Adobe MAX this year. The first, which really got me thinking, was Lazy Innovation: Strategies for the Design of Innovative User Experiences. Here is the description of the session provided by Adobe:

When engaging with applications, users essentially want to complete their tasks with a minimum of difficulty and friction. In this entertaining presentation, the Adobe Consulting User experience team will explore this "doctrine of laziness" as a means of identifying opportunities for innovative user experiences.

Speakers: George Neill, Jerome Doran

The primary premise of the session was that we, as user experience designers, should observe and anticipate the shortcuts that our users may find and provide those as the primary paths in order to provide the most efficient and usable interfaces possible. In addition to this, there were several tips for how to "think outside of the box" when designing these solutions. These are a few of the key points that I wrote down in my notes and would like to explore:

1. Interview users in their own space.
2. Assumptions are restricting.
3. Keep it simple.
4. Don't stop at the first solution.

Interview users in their own space
Most of the usability studies or user interviews that I have performed have been in environments completely unfamiliar to the users. In these situations, you have to count on the users to verbally explain what they do in enough detail to allow you to read between the lines. You also have to assume that they aren't leaving any part of their routine out, which is probably too much to ask. If some workflow is so "routine" that they do it without even thinking about it, how likely are they to mention it? Yet, any task that they perform without thinking is *the* most important aspect of that workflow.

To illustrate this point, the speakers displayed a photograph of an end user at her desk. Arrayed around her were the tools she used to do her job day to day including her hand-written mechanisms for keeping track of data that the software she was using either did not provide or did not provide in a way that was usable to her. This alone told the user experience designers much of what they needed to know to correct the issues in the current application and create a workflow that would alleviate the need for these hand-written systems.

Assumptions are restricting
You could say "duh" here, but I was trying to look at it on a deeper level. For example, is it always a good idea to follow the "proven" design patterns? I think that *starting* from design patterns is always a good idea, but what if there are easier ways for this particular user group to navigate the system or complete a task? If we always assume that the design patterns should be followed, we may never get to those better solutions. And to get more general, assuming that something is not technically possible can pose severe limitations on innovation. I very much enjoy working with a development team that is willing to explore some of the more out-of-the-box user interface solutions in the interest of a better user experience.

Keep it simple
This also seems obvious, but I have to say that it may be one of the problems I encounter most on projects. The business wants to cram every single last feature request into the software no matter where it falls on the end user's priority list. In a recent project, I have designed features that emulate some of the most complicated office software products available (Outlook, Word, Excel). In interviews with users, these were requested, but of lower priority to some of the more simple features. On the development side, they were extremely complex to design, develop and make usable. At the end of the day, these features created unnecessary complexity in the user experience, not to mention the amount of time involved in designing and developing them to be even remotely usable. When prioritizing features these should be the first to go. Simple software is easier to use.

Don't stop at the first solution
Ok, this one might turn into a little of a rant. From the creative perspective, I *know* that one should never stop at the first solution to any problem. Pushing past it is what gets you to the innovative solutions - the real goal in any kind of design. However, it seems that no client ever wants to *pay* for the time it takes to do so. They all want innovation, they just want it in the time it takes to use an existing template (all but impossible). It happens sometimes, so maybe that attitude has been falsely reinforced - a designer might reach a stroke of genius on the first try. Given that remote possibility, how do we sell the time to our clients in a way that they will understand? I hate to post a complaint without some suggestions for resolution, but this is one that I am really stuck on.

What do you think?
I'm really curious. How do you approach innovation in user interface design while retaining usability? The most usable interface is one that the users are USED to, but there's not much innovation in that. How do you introduce new concepts? How do you convince your clients that it is important to allow time for innovative solutions? Are those solution even "all that" or should we just stick with the familiar?