musings

UI Stockholm Syndrome

By Kyra Edeker
projekt202

Stockholm syndrome: Noun: Feelings of trust or affection felt in some cases of kidnapping or hostage-taking by a victim toward a captor. Are you holding your users hostage?  Is your application so hard to learn that users are afraid you’ll change it?  Do they not make any adjustments to the app out of the box or after they get their basic needs met for fear they “might break it”?  These kinds of interfaces often have loyal user bases who have been kept in the room long enough to learn to get along with the application.  But products with long, steep learning curves risk alienating new users. The accumulation of lost time spent on regular tasks cuts into efficiency and makes the tool vulnerable to new competitors.

I love it just the way it is.

Usually hostage-taking applications are mission-critical production apps – they’re running supply chains, medical billing or banking transactions.  They’re tracking parts, DNA or versions of a document used by ten people.  Some applications have such a large market-share that they’re difficult to migrate from, such as the Microsoft Office Suite.

These applications take users a long time to learn – weeks, sometimes months, and even longer to get it working the way they want it to.  Once a user has learned the app, they are beholden to it.  They’ve spent days understanding it and contorting to its ways.

It’s not uncommon in our user research to spend an hour watching a user struggle with a product and then profess a love for it.  They say “Don’t change it!  I like it the way it is!”  They are hostage.  They look lovingly on a challenging interface because at this point it is all they know.

It calls for an intervention.

You have to start by finding out what’s working and what’s not.  This goes far beyond reviewing support issues and feature requests.  Have you watched both new and current users work with the product?  Use in-depth research to guide you.  This user research is not taking users at their word, but rather looking deeply into their environment, tasks and behavior to arrive at new solutions to old problems.

Based on this research and company and market conditions there’s usually a choice: make tactical changes that incrementally improve the product’s core workflows; or, go for the bigger risk and potentially larger win – change the way people fundamentally interact with your tool.  This may be changing the navigation paradigm, moving key tasks to mobile platforms, or automating data collection and connection on the backend so tasks are eliminated entirely.

If you go for the big change you need buy-in from the top of your organization that they will support and fund the changes through the major design and development effort required.  Stakeholders must also know that they will have to ride out the initial howls of disbelief from users who are pried from the clutches of the existing system they spent so much time learning.

Let your existing users know that changes are on the way.  Give them a chance to accept their upcoming new life outside the confines of the current application.  Use existing communication channels to talk about how the changes will make users’ lives easier.  If there is a public user community, it may help to release the new version to a small group of champion users who can spread the word that the new system is not only not the end of the world, but a big improvement.

As with treating Stockholm syndrome, it may take some time for long-time users to let go of what they’re used to. If you’ve done the right research and prioritized users’ needs, the ease of use will quickly win over existing users, while opening up the application to a wider audience who expects to use a tool, not be hostage to it.

Iceman and Leftover Parts

By Mark Power-Freeman
projekt202

A friend and I spent a few hours on a recent weekend assembling a spinning compost bin. We’re both old hands at the “assemble it from a flat pack” approach to modern homemaking, having logged hundreds of Ikea-person-hours over the past five years. We’d planned well for the process: we had a clean, broad, flat surface on which to lay out all the parts and build the bin; we had all of our tools selected; and there were no children around to run off with the instructions or swallow the smaller pieces of the kit. It still took us a while to put the thing together, but it was with great pride that we placed and attached the final part and spun the drum. Then I glanced at our staging area and noticed that we had more than a few left over parts. I don’t mean the extra fasteners and tidbits manufacturers sometimes include as an acknowledgement that tiny screws will make the jump to hyperspace and escape the moment you look away from them.

No, rather than courtesy extras, we were left with pieces that looked important to the composter’s structural integrity and operational capacity. I spent a good (well, not exactly “good;” more like “bad”) twenty minutes re-reading the instructions to see if we’d missed a step. Everything checked out, and the bin didn’t feel unstable, so we considered ourselves done with the project.

But every time I’m in my backyard now, I eye the bin with growing suspicion.  I’m convinced that a vigorous spin is going to crack it open and send all the decomposing vegetables, straw, and exotic wildlife tumbling through the air to “top dress” my face and clothing. I can’t help but wonder if I’m simply not as skilled at kit-building as I believe.  I also think there’s functionality that the bin will now be lacking because I didn’t use all of the pieces.

I’ve noticed something similar in many of the applications I use on my computers.  A subset of the available tools permits me to do the many things I need to do, but a non-trivial number of buttons and functions lie there unused. I’m not worried about wireframes and design documents falling apart mid-presentation – although I’m sure many of us have had just that happen.

Instead of structural integrity or lack thereof gnawing at my sense of accomplishment, I feel a nagging doubt that I’m not quite the expert that I think I am with the tools I use to do my job. It’s kind of like the time Emma Frost was trapped in Iceman’s body, and she discovered that, far from being a character of limited worth, he was one of the more powerful mutants in the X-Men; he simply hadn’t been using his powers to their fullest extent. When he regains controls of his body, Iceman is depressed to see how far below his potential he’s been living.

So could I be using Illustrator, for example, to take over the world if I knew more? Maybe. As a designer and sci-fi fan, I’m generally optimistic that the future will bring increases in my power level if I apply myself.  On the other hand, I’m also certain that I don’t want users of anything I design to look at an array of un-clicked buttons and menus and worry that they’d done something wrong or that they hadn’t done as much as they could have.

A prevailing belief in the design industry holds that we should reduce visual noise to help people focus on the things they need to see, and years of experience have shown me the importance of this rule. I now believe there’s an additional emotional dimension that defines this principle as well. Too many buttons and features can make a screen ugly enough to cause a full grown adult to wince; clutter can cause a novice to be put off by perceived complexity; andan abundance of functions can make an expert doubt her level of expertise when components go unused.

As designers, we want all of our users to feel like experts. In an ideal world, every user would have time to play around with an application and explore its full suite of functionality. I trust that while most of us couldn’t point to the ideal world on a map, we know it’s pretty far from our current coordinates. Our challenge, then, is to ensure that our users look at all the pieces in the kit and know exactly where they go and how to use them: we want folks to compost happily without crossing their fingers and preparing themselves physically and emotionally to dodge flying orange peels and anoles (or their respective digital facsimiles).

I’ll keep you posted on how the compost bin fares. Thanks for reading!

Interface Design Wushu

By Mark Power-Freeman
projekt202

Among the many, many parallels between my development as an interface designer and Bruce Lee’s development as the creator of Jeet Kune Do is our understanding of and relation to the things that form the core of our respective disciplines. Bruce Lee once said about his study of the martial arts:

Before I studied the art, a punch to me was just like a punch, a kick just like a kick. After I learned the art, a punch was no longer a punch, a kick no longer a kick. Now that I’ve understood the art, a punch is just like a punch, a kick just like a kick.”

I went through something similar with interface design. I’ve been using computers in one form or another since the first grade, and for a long period, a button was just a button, a screen was just a screen, and a computer was just a computer. Nothing special — just silicon, plastic, and glass that could be as stubborn as a mule and only marginally less dirty.

Once I got my nice, shiny degree in design and I discovered “the art” of design, I looked at every interface with the zealously critical eye of a new convert to any philosophy or practice. A button wasn’t just a button, it was the summary and endpoint of all the user’s hopes and dreams and needs. The screen wasn’t just a screen, it was the window into the computer’s soul, the means by which the device and the user shared a gaze and meaning. <Insert Bruce Lee-esque kiai here.>

With several years of design under my belt, I’ve come back around to realizing that it really is all simple stuff. A buttonis just a button. Sure, it has button dharma, and my job as a designer is to help it fulfill its duty, but the act of clicking it is not some profound event that creates multiverses depending on the path it actualizes. (Or, is it? I will now ponder the chain of events that occurred in the universe where I clicked “Reply” instead of “Reply All” that one time….)

So, ultimately, I think as designers and developers, we all come to the same realization that Master Lee did: significant outcomes arise from a chain of simple actions. The trick is to figure out the arrangements of simplicity that give us our desired complex outcome so that we can replace the word “Jeet Kune Do” with “Interface Design” in the following quote from Master Lee:

Again let me remind you, Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one’s back.