Down at the bottom of the screen was a little window where you could type simple English-like commands – things like go to card 2 or beep. Once you’d mastered those, you could add them to your buttons or trigger them at certain times, creating real interactivity. Pretty soon I was making little games and utilities. It was the coolest thing ever.

HyperCard’s Home Stack: Pure Nostalgia

HyperCard came with something called the home stack that opened when you first launched it. I looked at it and thought, This isn’t very useful. It shows up all the time but it doesn’t do much. So I made a better one. It included various utilities, and of course a rock-paper-scissors game. I made packaging and convinced the local Mac store to sell it for $7.

It sold two copies.

Since then I’ve worked on products with more than twice as many users, but the story remains the same. This isn’t very useful. This doesn’t serve people’s needs. Let’s make a better one.

In college I discovered a career for what I did: user interface design. And though the title has changed over the years – user experience designer, interaction designer, product manager, product designer, founder – the motivation hasn’t. Technology is confusing and doesn’t meet people’s needs. I want to fix that.

Eat Your Vegetables

These days, it’s fashionable to talk about audacious ideas. Paradoxically, it’s also popular to focus on ideas that can be built in a month.

In a post last year, Paul Graham listed Frighteningly Ambitious Startup Ideas and spawned a bumper crop of companies (though my favorites, Bring Back Moore’s Law and The Next Steve Jobs, don’t seem to have much traction). Wired’s cover story for February was 7 Massive Ideas That Can Change the World.

But I can’t help thinking we’ve skipped our vegetables and gone straight to dessert. We are insinuating ourselves into more and more of people’s lives, yet we haven’t managed to meet their needs in predictable, understandable, let alone enjoyable ways.

I watch people using their devices and I cringe. They get their single-click and double-click mixed up. They open an email attachment, update it, and then can’t understand why their changes aren’t in Documents. They try to set up iCloud and end up creating three Apple IDs. They miss out on all the useful things technology can do for them, lost in a sea of complexity, confusion, and techie-centric functionality. These things were supposed to be labor-saving devices, right?

Make no mistake: This is our fault. To begin with, we’ve created ever-more-inconsistent expectations over time. Consider single- vs. double-click. Easy, right? You single-click to select, double-click to open. Unless it’s a webpage. Or Apple’s column view, where selecting and opening are the same thing so it doesn’t matter. Well, for folders; for documents, it matters.

Anyway, it’s really easy to tell if you’re in a webpage or not so you know which convention to use. Just look at the top of the screen, on the left. It should say Firefox, or Safari, or Chrome. Oh wait, you’re on Windows. Look at the top of the window. No, the frontmost window. See, it has a bigger shadow than the others. Oh wait, you’re on Windows 8? Well, are you in Metro or not? Oh wait, they don’t call it Metro anymore. I forget what they call it. Do you see a lot of colorful flat boxes? What were you trying to do again? Hey, where are you going?

You may think I’m overcomplicating things for effect. I’m not. It seems simple to you because all that stuff is already in your head. When you switch from GMail in a browser, to Outlook on Windows, to Mail.app on Mac, you know which conventions change. You have what designers call a mental model, rooted in years of experience and history, that allows you to make the right call. Most people don’t – nor should we have to.

And these interaction details are the tip of the iceberg. We do a disappointing job of understanding what people outside our bubble are trying to accomplish. Let’s be honest: We mostly make products for ourselves. Later, when they’re successful, we start wondering how people use them. We do user studies and surveys and ethnographies and then ignore the results because it’d be expensive to fix and besides, they’ll figure it out, right? I mean, we did. We lack the comprehensive understanding we’d need to make real, substantive change, to make products that are both usable and useful.

Downward Arrow

Therapists sometimes use the downward arrow technique with their clients. It starts with the apparent problem and proceeds through a series of “why” questions to the underlying issue:

Client: “I get nervous speaking in class.”

Therapist: “Why do you get so nervous?”

Client: “I’m worried that I might say something stupid.”

Therapist: “And if you did?”

Client: “I would be so embarrassed!”

Therapist: “Why? What would be so bad about it?”

Client: “It would mean I’m not good enough.”

And so forth.

Product design requires a similar process: start with a design or feature question and dig down until you find the assumptions that underlie it:

Me: Why do you ask for a user’s password every time he downloads a free app?

Imaginary Apple Guy: For security.

Me: What do you mean by security?

IAG: Well, if someone gets hold of your phone, they’d be able to install apps without your permission.

Me: And what would be so bad about that?

IAG: The apps could do malicious things with your phone.

Me: But doesn’t Apple sandbox apps and review them for malicious behavior?

IAG: Sure, but a maliciously-installed app could connect to your Facebook account.

Me: And is the risk of that happening when your phone is stolen worth requiring a password for every install?

Note that the point isn’t to make me look smart, or simply to reveal flaws. By the end of that (fictitious) exchange, we’ve gone from an ill-defined concept (“security”) to a specific question that deals in user needs.

The Product Mantra

To answer such questions we need the fundamental, defining goals of our product. Who is it for? What purpose does it serve? It’s impossible to evaluate trade-offs otherwise.

When I was at AOL our illustrious head of Consumer Experience, Matte Scheinker, introduced the notion of a product mantra: a clear, concise description of your product. Critically, it must be specific enough to disagree with.

Using my own to-do app, Stky, as an example:

• 

  Stky

  Mantra A: Stky is a to-do app for naturally disorganized people. It keeps overload in check by having you reprioritize each day’s tasks anew.

• Mantra B: Stky is a productivity app anyone can use. Unlike its competitors it keeps you in control of your tasks and on top of your life.

Both mantras are accurate. But only Mantra A is specific enough to disagree with. Do disorganized people need a to-do app? Is daily reprioritization too much work, especially for such people?

Mantra B could describe nearly anything.

Now, suppose I’m deciding whether to add a new feature to Stky: multiple sticky notes. You could have your Work sticky, your Home sticky, maybe a Stuff to Read sticky, and the like. Seems useful, and certainly I’ve had users request it. Let’s hold it up to our mantras:

• Using Mantra A: Do we want to add additional management overhead to an app for disorganized people? Probably not. And if the sticky represents our daily list of priorities, doesn’t adding multiple stickies break the whole paradigm? Probably. So maybe it’s not a good idea.
• Using Mantra B: Well, multiple stickies means more control, right? And lots of people want it, and we want a product anyone will use. So I guess it’s a good idea…along with nearly any other idea.

Even better, this exercise almost forces us back into downward arrow. Why do users want multiple stickies? What are they trying to accomplish? Is that deeper goal consistent with our mantra? If so, is there another feature that would meet their need in a way that fits the product better?

Asking why and writing a mantra won’t magically give us insight into our users. But it will force us to form hypotheses, which can be tested against evidence in the world around us.

And the constraints we create via those hypotheses allow us to make choices. Because the great products, the ones we revere, are invariably the work of product teams brave enough to make choices. We marvel at Apple’s clean, usable design. We call it simplicity but it’s not that: It’s knowing what to keep and what to leave out and having the guts to disappoint some of the users all of the time and all of the stakeholders some of the time. Many of us already know that, but we can’t bring ourselves to choose when push comes to shove.

None of this is a substitute for user research. We still need usability tests, ethnographies, brainstorming sessions, click data, bucket tests, discovery, and all the rest. But in the absence of clear hypotheses and specific questions, user research is a little like the proverbial tree falling in the forest. Research tests our assumptions and tells us where we’re right or wrong; it doesn’t tell us what to build.

This isn’t the kind of audacious problem we solve all at once…nor do we have to. Every product that actually makes someone’s life better is a piece of the solution – not just for the life it improves, but for the designer who’s inspired by it, the team that decides to one-up it.

Make no mistake: This is hard stuff. It requires tenacity, and bravery, and empathy. It requires observing how people live their lives, and then handing them products that aren’t at all what they asked for. It needs more user-centered ways of doing bug triage and structuring development workflow. But as technology becomes everyone’s ever-more-constant companion I can think of no greater or more worthy challenge.

When I renamed my blog last year, I created a tagline: “We make stuff, for people.” It was meant to be funny, sure, but also to encapsulate everything I’ve said here. Technology is meaningless without people; yet, as technologists, we’re prone to forgetting that. We end up debating strange, empty questions. Does the world really need another photo sharing service? Is skeumorphic design good or bad? Is Ruby better than Python? None of it matters on its own.

It’s important to make stuff. But it only matters if we make stuff, for people.

Anything that slows down customers or gets in their way after they download your app is a bad thing. That includes sign-up/sign-in forms that show up even before potential customers can figure out if the app is actually worth using.

It’s a simple UX equation

This antipattern seems to be going away more and more as companies are beginning to figure out the following simple UX equation:

Long sign-up form before you can use the app = Delete app

However, a fair number of apps still force customers to sign up, sign in, or perform some other useless action before they can use the app.

Example

The application SitOrSquat is a brilliant little piece of social engineering software that enables people to find bathrooms on the go, when they gotta go. Obviously, the basic use case implies a, shall we say, certain sense of urgency. This urgency is all but unfelt by the company that acquired the app, Procter and Gamble (P&G), as it would appear for the express purposes of marketing the Charmin brand of toilet paper. (It’s truly a match made in heaven—but I digress.)

Not content with the business of simply “Squeezing the Charmin” (that is, simple advertising), P&G executives decided for some unfathomable reason to force people to sign up for the app in multiple ways. First, as you can see in Figure 1, the app forces the customer (who is urgently looking for a place to relieve himself, let’s not forget) to use the awkward picker control to select his birthday to allegedly find out if he has been “potty trained.” This requirement would be torture on a normal day, but—I think you’ll agree—it’s excruciating when you really gotta go.

Figure 1: Registration Torture: Sign Up/Sign In antipattern in SitOrSquat app.

But the fun does not stop there—if (and only if) the customer manages to use the picker to select the month and year of his birth correctly (how exactly does the app know it’s correct?), he then sees the EULA (Figure 2), which, as discussed in the previous article, End User License Agreement (EULA) Presentation (Boxes and Arrows January 2nd, 2013), is an antipattern all to itself.

Figure 2: Reading the EULA while wanting to pee should be an Olympic sport.

SitOrSquat’s EULA is long, complex, and written in such tiny font that reading it while waiting to go to the bathroom should be considered an Olympic sport, to be performed only once every four years. Assuming the customer gets through the EULA, P&G presents yet another sign-up screen, offering the user the option to sign in with Facebook, as shown in Figure 3.

Figure 3: Finally! Sharing my bathroom habits on Facebook has never been easier!

I guess no one told the P&G execs that the Twitter message “pooping” is actually a prank. They must have legitimately thought that they could transfer some sort of social engineering information about the person’s bathroom habits to “achieve and maintain synergistic Facebook connectivity.” I would have to struggle hard to find monumental absurdities from social networking experiments that are equal to this. I can’t imagine that anyone thinks “Finally! Sharing my bathroom habits on Facebook has never been easier!”

Assuming that the user is a legitimate customer looking to use the bathroom for its intended purpose, and not a coprophiliac Facebook exhibitionist, we may hope that he will naturally dismiss the Facebook sign-in screen and come to the next jewel: the Tutorial, shown in Figure 4.

Figure 4: Tutorial is a sub-par Welcome experience pattern. Here it is another impediment to progress.

SitOrSquat tutorial is an extra screen that provides very little value, other than impeding the use of the app for its intended purpose. (If you need a tutorial, I recommend a much more effective contextual Watermark pattern, which I discuss in Chapter 5 of the Android Design Patterns book.)

50 Taps and 7 Screens of Antipatterns

Note that the entire app outside of registration consists of basically four screens (if you count the functionality to add bathrooms!). However, if you include all the sign-up antipattern screens (including my initial failure to prove that my potty training certificate is up to date, as referred to in Figure 1), it takes seven screens of the “preliminary” garbage before the content you are looking for finally shows up (refer to Figure 5). If you count the number of taps necessary to enter my birthday, that becomes almost 50 taps!

Figure 5: The Glory of 50 taps needed to get through the Sign Up/Sign In antipattern in SitOrSquat app.

One of my favorite UX people, Tamara Adlin (who coauthored The Persona Lifecycle: Keeping People in Mind During Product Design with John Pruitt) wrote brilliantly: “For Heaven’s Sakes, Let Them Pee.” I believe that never before has this line been so appropriate. In the absurd pursuit of social media “exposure” coupled with endless sign-up screens, with heavy-handed “lawyering up,” P&G executives completely lost sight of the primary use case: letting their customer SitOrSquat.

Long sign-up screens detract from the key mobile use case: quick, simple information access on the go. Overly invasive sign-up/sign-in screens presented up front and without due cause will cause your customers to delete the app.

There is no reason to force anyone to register for anything

When deciding whether to force the customer to perform an action, consider this: If this were a web app, would you force the customer to do this? If you have Internet connection, you can save everything the customer does and connect it back to his device using a simple session token and a guest account. And even if you don’t (for example, while riding in a subway, using airplane mode, and so on), today’s smartphones have plenty of on-board storage you can use for later syncing with your servers when the mobile network eventually becomes available.

This means there is simply no reason to force anyone to register for anything, other than if they want to share the data from their phone with other devices. As a general rule, rather than forcing registration upon download or at the first opportunity, it is much better to allow the customer to save a piece of information locally on the phone without requiring that he log in. Wait until the customer asks for something that requires registration, such as sharing the information with another device or accessing information already saved in his account; at that point completing the registration makes perfect sense.

For example, imagine how absurd the Amazon.com shopping experience would be if the app asked you for your home address, billing address, and credit card upfront—before allowing you to see a single item for sale! Yet entering the home address (where would you like to have the items shipped?) and credit card (how would you like to pay for this?) makes perfect sense during the checkout, after the customer selects a few items and indicates she would like to complete the purchase.

Finally, remember that “Forms suck,” as brilliantly quipped by Luke Wroblewski in his book Web Form Design (Rosenfeld Media, 2008). Only ask for what you strictly need to proceed to the next step and omit extraneous information. (Effective mobile data entry controls and forms is a huge topic to which I devote chapters 10-12 of my upcoming Android Design Patterns book (Wiley March 11, 2013), now available on Amazon.com).

Conceptual Model: a Model for Users’ Mental Model

A conceptual model of an application is the model of the application that the designers want users to understand.  By using the application, talking with other users, and reading the documentation, users build a model in their minds of how to use the application. Hopefully, the model that users build in their minds is close to the one the designers intended. This hope has a better chance of being realized if the designers have explicitly designed a clear conceptual model as a key part of their development process.

A conceptual model describes abstractly — in terms of tasks, not keystrokes, mouse-actions, or screen graphics — what users can do with the system and what concepts they need to be aware of. The idea is that by carefully crafting a conceptual model, then designing a user interface from that, the resulting application will be cleaner, simpler, and easier to understand. The goal is to keep the conceptual model: 1) as simple as possible, with as few concepts as are needed to provide the required functionality, and 2) as focused on the task-domain as possible, with few or no concepts for users to master that are not found in the application’s target task domain.

Object/Operation Analysis

An important component of a conceptual model is an Object/Operation analysis: an enumeration of the user-visible object-types in the application, the attributes of each object-type, and the operations that users can perform on each object-type. Purely presentational and purely implementation object-types have no place in an application’s conceptual model because users will not have to be aware of them.

Objects in the conceptual model of an application can usually be organized in a type-hierarchy, with sub-types inheriting operations from their parent types. Depending on the application, objects may also be organized into a containment hierarchy, i.e., in which some objects contain other objects. Laying out these two hierarchies in a conceptual model greatly facilitate the design and development of a coherent, clear user interface.

This analysis can help guide implementation, because it indicates the most natural hierarchy of implementation objects and the methods each must have. It also simplifies the application’s command structure by allowing designers to see what operations are common to multiple objects and therefore can be designed as generic operations. This, in turn, makes the command structure easier for users to master: they must only learn a few generic commands that apply to many object-types, rather than a larger number of more narrowly applicable object-specific commands.

For example, in a well-thought-out application that allows users to create and manipulate both Thingamajigs and Doohickeys, when users know how to create a Thingamajig and want to create a Dohickey, they already know how because creation works the same way for both. Ditto copying, moving, deleting, editing, printing, etc.

Example: Object/Operation Analysis for a Simple Office Calendar App

For example, let’s examine an objects/operations analysis for a simple office calendar application. The objects, attributes, operations, and relationships might be as follows:

Objects: It would include objects like calendar, event, to-do item, and person (see Table 1).  It would exclude non-task-related objects like buffer, dialog box, database, and text-string.

Attributes: A calendar would have an owner and a default focus (day, week, month). An event would have a name, description, date, time, duration, and a location. A to-do item would have a name, description, deadline, and priority. A person would have a name, a job-description, an office location, and phone number. However, Events should not have byte-size as an exposed attribute, because that is implementation-focused, not task-focused.

Operations: Calendars would have operations like examine, print, create, change view, add event, delete event. Events would have operations like examine, print, and edit. To-do items would have more-or-less the same operations as events. Implementation-related operations like loading databases, editing table rows, flushing buffers, and switching modes would not be part of the conceptual model.

Table 1. Object/operation analysis for a simple office calendar application.

Keep it Simple

Sometimes it is tempting to add concepts to provide more functionality. But, it is important to realize that each additional concept comes at a high cost, for two reasons: 1) it adds a concept that users who know the task domain will not recognize and therefore must learn, and 2) it increases the complexity of the application exponentially, because each added concept interacts with many of the other concepts in the application.  Therefore, extra concepts should be resisted if possible. The operative design mantra with conceptual models is: “Less is more.”

A Conceptual Model Provides a Foundation for the App and the Project

The user interface design translates the abstract concepts of the conceptual model into concrete presentations and user-actions. For best results, the user interface is designed after the conceptual model has been designed.  Scenarios can then be rewritten at the level of the user interface design. Designing the UI from the conceptual model may expose problems in the conceptual model, in which case the conceptual model may be improved.

A conceptual model provides a foundation not only for the UI design, but also for the application’s implementation and documentation. It therefore plays a central role in the design and development of the overall product.

Summary: Six Benefits of Conceptual Models

Starting a design by devising a conceptual model has several benefits:

1. By laying out the objects and operations of the task-domain, it allows designers to notice operations that are shared by many objects. Common operations across objects make the UI simpler for users to learn and remember.
2. Even ignoring the simplification that can result from noticing shared operations, devising a user-model forces designers to consider the relative importance of concepts, the relevance of concepts to the task domain (as opposed to the computer domain), the type hierarchy of objects, and the containment hierarchy of objects. Having thought about these things greatly facilitates designing a user-interface.
3. A conceptual model provides a starting point for the development of a product vocabulary, i.e., a dictionary of terms that will be used to identify each of the objects and operations embodied in the software. This helps ensure that terms are used consistently thoughout the app and its documentation.
4. Once designers have a conceptual model for an app, they can write scenarios depicting people using the app to perform tasks, using only concepts from the conceptual model and terms from the vocabulary. For example, a conceptual-level scenario for the calendar application might be: “John checks his appointments for the week. He schedules a team meeting, inviting team members, and adds a dental appointment.” Such scenarios (which can be separated into use-cases), help validate the design in functional reviews. They can also be included in product documentation and training. Conceptual scenarios describe tasks and goals without revealing the UI-level user interactions required to achieve those goals, so they can be used as task descriptions in usability tests.
5. A conceptual model provides a first cut at the app’s object-model (at least for the objects that users will be aware of), so developers can use it to begin implementing the app.
6. An actively-maintained conceptual model supports a better development process. It can insure that all user-visible aspects of an application (functionality, terminology, UI, documentation, support, …) are consistent. By making the conceptual model the joint responsibility of all team members, the application can be made coherent. Both of these also reduce development resources by reducing rework.

Further Reading

•   Johnson, J. & Henderson, D.A., “Conceptual Models: Begin by Designing What to Design”, Interactions, Jan-Feb 2002.

•   Johnson, J. & Henderson, D.A., Conceptual Models: Core to Good Design, Morgan & Claypool, 2011.

The first thing your customers see when they download and open your app is the welcome mat you roll out for them. Unfortunately, this welcome mat commonly contains unfriendly impediments to progress and engagement: End User License Agreements (EULAs). Like the overzealous zombie cross-breed between a lawyer and a customs agent, this antipattern requires multiple forms to be filled out in triplicate, while keeping the customers from enjoying the app they have so laboriously invested time and flash memory space to download. This article exposes the culprit and suggests a friendlier welcome strategy for your mobile apps.

Antipattern: End User License Agreements (EULAs)

When customers open a mobile website, they can often engage immediately. Ironically, the same information accessed through apps frequently requires agreeing to various EULAs, often accompanied by ingenious strategies that force customers to slow down. EULA is an antipattern.

When and Where It Shows Up

EULAs are typically shown to the customer when the application is first launched and before the person can use the app. Unfortunately, when they do show up, EULAs are also frequently accompanied by various interface devices designed to slow people down. Some EULAs require people to scroll or paginate to the end of a 20-page document of incomprehensible lawyer-speak before they allow access. Others purposefully slow people down with confirmation screens that require extra taps. Truly, things in a torture department have evolved nicely since the days of Spanish Inquisition!

Example

Financial giant Chase provides a good example of a EULA. As shown in figure 1, when customers first download the Chase app, they are faced with having to accept a EULA even before they can log in.

Figure 1: EULA antipattern in Chase app.

What makes this example interesting, is that the same information is accessible on the mobile phone without needing to accept the EULA first: through the mobile web browser, as shown in Figure 2.

Figure 2: There is no EULA on the Chase mobile website.

Why Avoid It

The remarkable thing is not that the EULA is required. Lawyers want to eat, too, so the EULAs are an important component of today’s modern litigious society. Dealing with a first-world bank in the “New Normal” pretty much guarantees that you’ll be faced with signing some sort of a legal agreement at some point in the relationship. The issue is not the EULA itself—it is the thoughtlessness of the timing of the EULA’s appearance.

The app has no idea if you have turned on the mobile access on or have your password set up properly. (Most people have at least a few issues with this.) Therefore, the app has no idea if the bank can serve you on this device. However, already, the bank managed to warn you that doing business on the mobile device is dangerous and foolhardy and, should you choose to be reckless enough to continue, the bank thereby has no reasonable choice but to relinquish any and all responsibility for the future of your money. This is hardly an excellent way to start a mature brand relationship.

What should happen instead? Well, the mobile website provides a clue. First, it shows what a customer can do without logging in, such as finding a local branch or an ATM. Next, the mobile site enables the customer to log in. Then the system determines the state of the EULA that’s on file. If (to paraphrase Eric Clapton in “The Tales of Brave Ulysses”) the customers’ “naked ears were tortured by the EULA’s sweetly singing” at some point in the past, great—no need to repeat the sheer awesomeness of the experience. If not, well, it’s Lawyer Time. Consequently, if customers do not have Bill Pay turned on, for example, they don’t need to sign a Bill Pay EULA at all, now do they? The point is that the first page customers get when they first launch your app is your welcome mat. Make sure yours actually says “Welcome.”

Additional Considerations

Has anyone bothered asking, “How many relationships (that end well) begin with a EULA anyway?” How would Internet feel if every website you navigated to first asked you to agree to a EULA, even before you could see what the site was about? That just does not happen. You navigate to a website and see awesome welcome content immediately. (Otherwise, you’d be out of there before you could spell E-U-L-A.) When you use a site to purchase something, you get a simple Agree and Proceed button with a nearby link to a EULA agreement (not that anyone ever bothers to read those things anyway, especially on mobile) and merely proceed on your way.

If you can surf the web happily, taking for granted the awesomeness of the smorgasbord of information on the mobile and desktop, without ever giving a second thought to the EULAs, why do you need to tolerate a welcome mat of thoughtless invasive agreements on a mobile app platform?

Additional Information

You can find 70 essential mobile and tablet design ideas and antipatterns in my new book, Android Design Patterns: Interaction Design Solutions for Developers (Wiley, 2013) now available for pre-order at http://AndroidDesignBook.com where you can also sign up for the next free monthly Android Design Question and Answer session.

That’s right! I said it. For us (designers, information architects, interaction designers, usability professionals, HCI researchers, visual designers, architects, content strategists, writers, industrial designers, interactive designers, etc.) the term user experience design (UX) is useless. It is such an over generalized term that you can never tell if someone is using it to mean something specific, as in UX = IxD/IA/UI#, or to mean something overarching all design efforts. In current usage, unfortunately, it’s used both ways. Which means when we think we’re communicating, we aren’t.

Of course there is UX for us

If I was going to define my expertise, I couldn’t give a short answer. Even when UX is narrowly defined, it includes interaction design (my area of deep expertise), information architecture (a past life occupation), and some interface design. To do it well, one needs to know about research, programming, business, and traditional design such as graphic design as well. Once, to do web design you had to be a T-shaped person. This is defined as a person who knows a little bit about many things and a lot about one thing. Imagine a programmer who also understands a bit about business models and some interface design. But as our product complexity grows, we need P and M shaped people–people with multiple deep specialties. To design great user expereinces, you need to specialize in a combination of brand management, interaction design, human-computer factors and business model design. Or you could be part of a team. The term UX was welcomed because we finally had an umbrella of related practices.

Of course, we don’t all belong to the same version of that umbrella. We all bring different focuses under the umbrella, different experiences, mindsets, and practices. While we can all learn from each other, we can’t always be each other.

But trouble started when our clients didn’t realize it was an umbrella, and thought it was a person. And they tried to hire them.

It isn’t about us

If there is any group for whom UX exists now more than ever it is non-UXers. Until 2007, the concept of UX had been hard to explain. We didn’t have a poster child we could point to and say, “Here! That’s what I mean when I say UX.” But in June 2007, Steve Jobs gave us that poster child in the form of the first generation iPhone. And the conversation was forever changed. No matter whether you loved, hated, or could care less about Apple, if you were a designer interested in designing solutions that meet the needs of human beings, you couldn’t help but be delighted when the client held up his iPhone and said, “Make my X like an iPhone.”

It was an example of “getting user experience right.” We as designers were then able to demonstrate to our clients why the iPhone was great and, if we were good, apply those principles in a way that let our clients understand what it took to make such a product and its services happen. You had to admit that the iPhone was one of the first complete packages of UX we have ever had. And it was everywhere.

Now five years later, our customers aren’t saying they want an iPhone any more. They are saying that they want a great “experience” or “user experience.” They don’t know how to describe it, or who they need to achieve it. They have no clue what it takes to get a great one, but they want it. And they’ll know it when they see it, feel it, touch it, smell it.

And they think there must be a person called a “user experience designer” who does what other designers “who we’ve tried before and who failed” can’t do. The title “user experience designer” is the target they are sniffing for when they hire. They follow the trail of user experience sprinkled in our past titles and previous degrees. They sniff us out, and “user experience” is the primary scent that flares their metaphorical nostrils.

It is only when they enter our world that the scent goes from beautiful to rank. They see and smell our dirty laundry: the DTDT (Defining The Damn Thing) debates, the lack of continuity of positions across job contexts, the various job titles, the non-existent and simultaneously pervasive education credentials, etc. There is actually no credential out there that says “UX.” Non! Nada! Anywhere. There are courses for IxD, IA, LIS, HCI, etc. But in my research of design programs in the US and abroad, no one stands behind the term UX. It is amorphous, phase-changing, and too intangible to put a credential around. There are too many different job descriptions all with the same title but each with different requirements (visual design, coding, research being added or removed at will). Arguably it is also a phrase that an academic can’t get behind. There aren’t any academic associations for User Experience, so it’s not possible to be published under that title.

Without a shared definition and without credentialed benchmarks, user experience is snakeoil. What’s made things even worse is the creation of credentialed/accredited programs in “service design” which take all the same micro-disciplines of user experience and add to it the very well academically formed “service management” which gives it academic legitimacy. This well defined term is the final nail in the coffin, and shows UX to be an embattled, tarnished, shifty, and confusing term that serves no master in its attempt to serve all.

“User experience design” has to go

Given this experience our collaborators, managers, clients and other stakeholders have had with UX; how can we not empathize with their confused feelings about us and the phrase we use to describe our work.

And for this reason UX has to go. It just can’t handle the complexity of the reality we are both designing for and of who is doing the designing. Perhaps the term “good user experience” can remain to describe our outcomes, but user experience designer can’t exist to describe the people who do the job of achieving it.

Abby Covert said recently that the term UX is muddy and confusing. Well, I don’t think the term “user experience” is confusing so much as it’s a term used to describe something that is very broad, but is used as if it were very narrow. There is a classic design mistake of oversimplifying something complex instead of expressing the complexity clearly. UX was our linguistic oversimplification mistake. We tried to make what we do easy to understand. We made it seem too simple. And now our clients don’t want to put up with the complexity required to achieve it.

Now that the term has been ruined (for a few generations anyway), we need to hone our vocabulary. It means we can’t be afraid of acknowledging the tremendous complexity in what we do, how we do it, and how we organize ourselves. It means that we focus on skill sets instead of focusing on people. It means understanding our complex interrelationships with all the disciplines formerly in the term UX. And we must understand that they are equally entwined with traditional design, engineering and business disciplines, communities, and practices as they are to each other.

So I would offer that instead of holding up that iPhone and declaring it great UX, you can still use it as an example of great design, but take the simple but longer path of patiently deconstructing why it is great.

When I used to give tours at the Industrial Design department at the Savannah College of Art and Design (SCAD) I would take out my iPhone and use it to explain why it was important that we taught industrial design, interaction design, and service design (among other things). I’d point to it off and explain how the lines materials, and colors all combined to create a form designed to fit in my hand, look beautiful on my restaurant table, and be recognizable anywhere. Then I would show the various ways to “turn it on” and how the placement of the buttons and the gesture of the swipe to unlock were just the beginning of how it was designed to map the customer’s perception and cognition, social behaviors, and the personal narrative against how the device signalled its state, what it was processing, and what was possible with the device. And I explained that this was interaction design. Finally, I’d explain how all of this presentation and interaction were wonderful, but the phone also needed to attach a service to it that allows you to make calls, where you can buy music and applications and that the relationships between content creators, license owners, and customers.

At no time do I use the term “user experience.” By the time I’m done I have taught a class on user experience design and never uttered the term. The people have a genuine respect for all 3 disciplines explored in this example and see them as collaborative unique practices that have to work intimately together.There is no hope left in them for a false unicorn who can singularly make it all happen.

Flow is a concept popularized by Mihály Csíkszentmihályi. It describes the ineffable state between boredom and excessive difficulty in which time disappears and you are pleasurably lost the execution of a task. In the game design community, it’s a well understood and desirable state that most designers strive to create.

Because this state is so desirable, both for productivity and for pleasure, many application (web and mobile) designers are starting to try to design for it as well. This is a daunting task. First, all humans are different. This means in identical situations I hit flow at a very different moment in the ease-to-difficulty continuum than you do. Secondly, flow is extremely easily to disrupt. Have you ever been in the middle of writing where words are finally flowing out, then been interrupted by a cat/child/roommate/coworker jumping into your lap? Did you lose the precious thread? Then you know exactly what I mean, as does the cat/child/roommate/coworker who got the brunt of your wrath. Thirdly (and perhaps most importantly) the application designer has far less control than game designers over challenge and skill, the two key levers in creating flow.

A more straightforward goal is to create the conditions for flow and to design to minimize interruptions. Designing for ease-of-use may be more than difficult enough, and designing for flow an unnecessary extra struggle. Just because something is wonderful doesn’t mean everything should have more of it (e.g. think of salt). For applications where users spend a lot of time in the app, designing for mastery is the better design goal.

Appropriateness of Flow

Consider your application. Is it used daily? Hourly? monthly? When it is used, how long does a session last? Flow can only be achieved in situations where mastery of the toolset is possible, and the user need not consciously think about what they are doing. They must be using the tools repetitively until they have acquired such a skill that allows them to work as if the tools were an extension of their body.

Most sites that are used irregularly, from shopping for cars to choosing a gym, will never be mastered by the users. Instead, they will be used only briefly to accomplish a goal. If you are a travel site aimed at consumers, it’s unlikely they are going to use your site over and over until they reach a zen-like state while doing price comparisons. Exceptions exist, sure. There may be the travel junkie who runs the flight costs endlessly and tweaks to find the cheapest ticket. But you probably want to optimize your site for the family planning the annual August outing first. Even that travel junkie is probably going to be plenty happy just to find a cheap ticket to Belize rather than luxuriate in manipulating the flight from Wednesdays to Fridays just to watch the prices fluxuate.

Conversely, word processing, numbers crunching, and alien shooting are all activities where mastery of the tool set increases the user’s effectiveness and enjoyment when using the tool. In such cases, flow is not only possible but desirable.

Ease-of-use

You have been hearing about ”ease-of-use” for ages under the rubric of usability. For most web applications, from ecommerce to online banking, this is all you need. For applications where you need more than simple usability, such as photo editing or blogging tools, you still must get ease-of-use right. Even in games, where some tasks should be hard to accomplish in order to create pleasurable challenge, designers still make the fundamental usage easy. For example: seeing what level you are on, how many lives you have, how much gold/points/reputation you have is all bundled up in the HUD. HUD, or heads up display, is the bar that keeps your status in front of you in the same place all the time, so you can flick your eyes over to it to mark progress. This is a paragon of ease-of-use, and many productivity apps would greatly benefit from a HUD.

Mastery

Mastery is a common game concept; it’s what makes much of game play fun. Everyone knows that amazing moment when you suddenly are riding your bike perfectly balanced, playing a song on the guitar without watching your fingers fret, or typing your thoughts without trying to remember if you hit the Y with the right or left finger. You feel so powerful and in control! This is mastery.

In games, that elation is doled out across levels. As you master one complicated set of patterns in Dance Dance Revolution, you are spoon fed the next harder one, so each step of mastery releases its own high. Flow occasionally happens just as you are about to be gobsmacked by the next level.

To design for mastery, you have to map the user journey, and consider how to move them from one stage to the next.


Image 1: I have always loved this diagram from Amy Jo Kim‘s classic Community Building on the Web : Secret Strategies for Successful Online Communities

Such a long user journey is not needed for every site. If you sell curtains direct to consumer, you may just need people to find and buy a curtain. Novice is as far as any user has or wants to go.

But if you sell curtains to interior decorators, you definitively want to figure out how to move them from novice to regular. Every site has its own user journey to plot out. Mastery is critical if “regulars” or “engagement” are in your strategy deck.

Once you know what the stages of the player (user) journey are, you can plan for mastery. For example, for Facebook mastery might be about moving users from novice to regular. Facebook wisely makes sure you are connected to your social network (finding people to connect to is hard!) and then can easily interact. A regular might hop on two or three times a day, check their stream for funny/interesting posts, respond to notifications for games and check for personal messages. A leader might help less tech savvy members of the family get on Facebook, and figure out how to upload pictures. An expert… well you know them. They run groups, have a business page, and generally get Facebook to do things you didn’t think it did.

With productivity apps like word processors, mastery appears when a user uses a keyboard shortcut to cut and paste rather than the menus. Users can get by without the advanced tools, but those tools are waiting, perhaps hidden, for when the user is ready to move a bit faster. If you have ever visited you accounting department and watched them use excel, you know what I mean.

But consider this: while both Facebook and Microsoft word offer power tools, this is completely different than Dance Dance Revolution which increases the difficulty of the basic activity each time you play. Just imagine what writing a letter would be like if every time you opened Word the buttons and menus were completely rearranged. (It’s bad enough when this happens once every year or two).

Flow

Image 2: Challenge vs. Skill

Finally, mastery leads to flow. If you followed the wikipedia link at the beginning of this article, you know now that flow is hard to achieve. An activity gets a little too hard, or a little too easy and it’s all over. One enters flow when the challenge level is appropriately matched with the skill level.

With most productivity apps, the challenge and skill are both provided by the user, and thus the designer has little control over flow, except to prevent or interrupt it. Let me illustrate.

I originally wrote this article in WordPress. I use WordPress a lot; even more than Microsoft Word. I could be considered a regular now. When I wrote my Eleganthack blog post, Why You Should  Speak, I was in a flow state. I knew exactly what I wanted to say, and all I had to do was craft the sentences. Although two hours went by, it felt like 15 minutes.

But writing this post has been more of a struggle, even though I originally wrote it in WordPress. I knew I wanted to write about why flow was a potential chimera, but I wasn’t sure why. I was writing at least as much to figure out my ideas as to express them. And I popped in and out of flow, stopping to check twitter, write an email, and even debug a WordPress problem. The challenge of expressing myself kept bouncing between arousal and anxiety, only occasionally hitting flow. And there is absolutely nothing WordPress could do to help me with it.

WordPress could certainly kick me out of flow, though. If they popped up an autosave dialog, or the mechanism to allow me to insert a picture was too many steps, I’d lose my train of thought and flow might have been hard to recover.

In games you see more of a partnership between the designer and the user to create flow states. The user masters skills, the game monitors that mastery and ups the challenge. In badly designed games, the challenge will increase so sharply the user is thrown into anxiety and will quit. Or conversely, the challenge is insufficient and the user wanders away in boredom. Collision Effect is an example of an app often reviewed as being incredibly fun by experts, but having too steep a challenge curve for casual players. Boring games are a dime a dozen, and I’m sure you’ve uninstalled your fair share.

In excellently designed games, the game lets the user move between arousal and flow perpetually. In addition to Dance Dance Revolution, you have the wonderful Kinnect game Dance Central. World of Goo (iTunes, Android) has a terrificly smooth progression in difficulty, becoming deliciously hard at the end. And who hasn’t played (and gotten a little obsessed with) Angry Birds?

So: Design for Flow?

If you are a game designer, it’s a must. Pleasurable extended play relies on the player bouncing between the arousal and flow states (occasionally dipping into anxiety and resting in relaxation). But if you are an app or web designer, I recommend instead focusing on ease-of-use and mastery. Consider flow as you design, but only to make sure if the user manages to achieve it you don’t disturb it. Otherwise, you may find your software flung across the room, just like the cat who jumps on the keyboard mid-composition.

No cats were harmed in the writing of this post. Unless looks can kill.

Afterword: I cannot resist commenting on the state of relaxation. Many people find Farmville’s appeal completely incomprehensible. But the chart shows high skill and low challenge not as boredom, but as relaxation. I would argue that completely mastered skills work the same way, such as knitting or Let’s Create! Pottery. In the case of Let’s Create Pottery, you can move back and forth between challenges and relaxing unstructured creation once you have mastered the basic throwing and decorating skills. I think lazy relaxed play is much underrated in both the game and web design communities.

Christina Wodtke is continuing to explore the overlaps between game and web design, as well as what it takes to make great products at Eleganthack.

“It’s easier to resist at the beginning than at the end.”

Leonardo Da Vinci

Some of Leonardo’s projects failed because of their execution. The strange tale of Leonardo’s “Kitchen Nightmare” plays out like a Shakespearean “comedy of errors” where a visionary designer’s experiments all work perfectly to extremely disastrous results.

In an article for the Big Design blog, I wrote about the Five Sketching Secrets of Leonardo Da Vinci, where it seemed like everything Leonardo did was successful. This, however, is not the case.

Once upon a time, the Duke of Milan asked Leonardo Da Vinci to help his kitchen staff prepare an extravagant meal for a large dinner party ^[1]. Leonardo was well known for his dietary practices (he was a strict vegetarian) and his many inventions (parachutes, tanks, gliders). So, Leonardo set about to see how he could innovate in the kitchen.

Seeing several opportunities before him, Leonardo created several new innovations:

• Developed a series of conveyor belts in the kitchen to bring food to cooks faster
• Created a large oven to cook food at higher temperatures than normal (at the time)
• Designed a sprinkler system for safety, in case a fire broke out
• Invited local artists to carve individual entrees into works of art for guests to eat

As you can guess, it was Leonardo’s “kitchen nightmare.”

When Works As Designed Still Fails

Imagine this scene in your own kitchen.

A designer comes over to “help” you cook dinner. He creates a conveyor belt in an already crowded kitchen. You have never seen or used the new oven that cooks faster than what you have been using for years. The designer installs a sprinkler system, which further crowds the kitchen. Finally, the designer invites 50 or so artists to build edible art for the guests. Your kitchen is super crowded. You feel impending doom at the chaos that has invaded your kitchen.

Disaster strikes!

The comedy of errors begins with the conveyor belts running too slow. With a quick adjustment by Leonardo, the belts run faster. Soon, the food piles up. The belt needs another adjustment.

Next, the new oven works as designed, but the cooks burn the food, using this unfamiliar oven. Besides burning the food, the new oven causes a small fire. Naturally, the sprinkler system is used. The sprinklers works perfectly, but it ruins most of the food.

Finally, the artisans carving the food are too slow. The guests, who were promised an extravagant dinner, are starving. Most of the guests go away hungry.

The Duke, of course, was embarrassed and angry. Leonardo was publicly humiliated.

Three Lessons for Designers

Leonardo’s “Kitchen Nightmare” offers several lessons for designers. I will talk about three lessons here:

1. Do not be afraid to fail
2. Use positive judgment to explore the value and benefit of ideas
3. Do not underestimate the importance of executing your ideas

1. Do not be afraid to fail

First, do not be afraid to fail. Da Vinci was using conveyor belts long before the Industrial Revolution. He was experimenting with higher temperature for cooking, developing his own oven, and using artists to improve the presentation of food. Leonardo developed a sprinkler system, which contains the fundamental design still used today.

When faced with a task of preparing an extravagant meal for the Duke of Milan, Leonardo was inspired to improve the current state of technology in the kitchens of the day. He was not afraid to fail. Leonardo was no “Iron Chef.” And, he failed in a spectacular way. Again, do not be afraid to fail. Leonardo was not.

The fear of failure is a great barrier to creative thinking. You learn from your failures. Leonardo puts it best:

“I have been impressed with the urgency of doing. Knowing is not enough; we must apply. Being willing is not enough; we must do.”

Leonardo Da Vinci

Fear of failure stifles your thinking. Fear of failure keeps you thinking inside the box. You can learn from failures. You can think creatively.

2. Use positive judgement to explore the value and benefit of ideas

Second, use positive judgment to explore the value and benefit of ideas. Consider yourself as the Duke of Milan, who was just publicly humiliated by Leonardo’s “innovations”.

• Would you take the time to notice the value and benefit of conveyor belts, new ovens, and sprinkler systems?
• Would you think about the creative concept of using edible art designed by local artisans for your guests?

The answers to both questions is, most likely, no.

When faced with new ideas or failure, we are quick to judge things negatively. We fail to explore lessons learned. We fail to see the benefits and values within new concepts. We do know the Duke publicly humiliated Leonardo for his “kitchen nightmare.” Ironically, the Duke’s own army could have used the same technology (conveyor belts, ovens, and sprinklers) to build more weapons faster. Instead, the Duke scoffed at these new innovations because he was embarrassed.

When you are faced with a new idea in the future, use positive judgment first by asking your “self” a few basic questions.

1. What are the benefits and values of this new idea?
2. In what ways can this new idea work?

As designers and UX professionals, you want stakeholders to consider the value, benefits, and novelty of ideas before quickly dismissing them. Using positive judgment first when a new idea is introduced leads you to explore potential ideas and consider alternatives. You do not quickly jump to the most common design solution, newest technology, or known design pattern.

“The greatest deception men suffer is from their own opinions” is a famous quote from Leonardo Da Vinci. In this lesson, Leonardo want us to consider the novelty of new ideas rather than our initial, negative reaction, where we judge all the reasons an idea will fail. When you use positive judgment first, you balance your tendency to quickly react to new ideas.


3. Do not underestimate the importance of execution

Third, do not underestimate the importance of executing your ideas. Leonardo made significant inventions for one dinner party. The inventions did work as designed. The conveyor belts moved the food. The oven cooked at a higher temperature. The sprinklers put out the fire. The cooks (ie users) were not ready to have three different inventions at the same time. When you add 50 or so artisans, the kitchen gets very crowded, very fast.

Execution is critical.

Leonardo’s Kitchen Nightmare was brought upon by Da Vinci not following his own advice:

“Experience does not err. Only your judgments err by expecting from her what is not in her power.”

Leonardo Da Vinci

First, consider how the story of Leonardo’s Kitchen Nightmare might be affected by just following modern UX best practices. Leonardo could have started with the 5Hs and W to get better understanding of his design problem. He could have developed personas for the cooks, artisans, servers, the host, and the dinner party attendees. Leonardo could have done some usability testing with the cooks and artisans, where he could have tested out his assumptions with real users.

Second, consider how Leonardo’s execution was seemingly affected by some poor project management practices. Leonardo introduced three new inventions (conveyor belts, sprinking system, and new ovens), as well as new people (the artisans) doing additional activities (carving food). Leonardo was a poor project manager. He added new features and tweaked existing ones, which only added to scope creep. Clearly, Leonardo had planned on doing too much with his project.

Finally, consider how the execution of these kitchen ideas were affected by Leonardo himself. Leonardo was famous for procrastination. For example, it took him many years to complete “The Last Supper”. When you look at the body of his art work, you will discover only a small set of completed masterpieces. From an execution perspective, we see only one resource (Leonardo) for all these ideas. Leonardo was overthinking and underdelivering on his promises, which is a nightmare on any project.

Conclusions

Leonardo Da Vinci did not always succeed. When he failed, it was a spectacular failure. It was a living nightmare. Leonardo may have said it best:

“It has long since come to my attention that people of accomplishment rarely sat back and let things happen to them. They went out and happened to things.”

Leonardo Da Vinci

His failures still show us lessons from Leonardo.

Do not be afraid to fail, as you learn the most from your attempts. Judge new ideas with a positive viewpoint to explore the value and benefit of potential ideas. The execution of a new idea can be as important as thinking it up.

You can design like Da Vinci.

1 Gelb, Michael. How to Think Like Leonardo da Vinci: Seven Steps to Genius Every Day. Dell, 2001.

The best products don’t focus on features, they focus on clarity. Problems should be fixed through simple solutions, something you don’t have to configure, maintain, control. The perfect solution needs to be so simple and transparent you forget it’s even there.

However, elegantly minimal designs don’t happen by chance. They’re the result of difficult decisions. Whether in the ideation, designing, or the testing phases of projects, UX practitioners have a critical role in restraining the feature sets within our designs to reduce the complexity on projects.

Why you should reduce complexity in scope

Over-designed and complex products typically stem from a ‘more is better’ philosophy. Expanding the feature count beyond what’s truly needed is perceived to increase the overall value. Essentially, increasing scope has connotations of giving your audience flexibility. Equally, reducing scope implies you’re limiting your customers.

If we begin to discuss scope as complexity, instead of flexibility, it changes the conversation as it reinforces there’s a correlation between the two. Indeed, they’re really the same thing. Complexity is scope. Every new feature creates additional guesswork. To put it bluntly, increasing scope means there’s more opportunity to screw things up.

As well as making things more difficult upfront, unnecessary features set up additional complexity with future releases. This is because the user interface groundwork early in projects establishes constraints. We have to live with the consequences of our initial design decisions through future iterations. So a tight focus on features early on is crucial. The alternative, trying to solve too much too soon, means initial design decisions become high risk.

As well as reducing the technical complexity, an elegantly minimal feature set clarifies the proposition of your product and simplifies the experience for the user. Any feature that doesn’t help solve problems for your audience should be thought of as a distraction, an unnecessary obstacle that undermines the value of your product.

Properly defining scope

Where to define the scope isn’t easy. Different users will have varying requirements. There’s also the grey area, where removing functionality can result in a drop in the value and revenue of your product.

Also, simplifying a design to reduce it’s perceived complexity doesn’t always work and can create significant barrier for users. A good example is financial software, where the user interface is built around tasks which are inherently complex.

However, simply because a task is complex doesn’t create an excuse for designing a complex user interface or user experience. We should architect solutions around how much control is truly needed. Truly exceptional experiences are crafted when complexity is removed whilst the level of power and control is maintained.

Preventing scope creep

Once your initial scope (or the level of complexity you’re comfortable with adopting) has been defined, the best approach is tackle one feature at a time. Design the first iteration around the most critical and well understood problem.

From this approach additional features can often feel like a simple and natural extension, an easy way to make extra revenue. Despite the sometimes low cost of designing additional features, there are hidden costs.

Unnecessary features are a distraction for developers and designers. They draw people away from optimizing the little details or other things you could be doing to help your existing customers. They also dilute the core proposition of your product and the prominence of the most important features.

Clearly understand what new features you need to add and what the implications of developing them are. Classify features into mandatory and nice to have and the put all the mandatories through a review to ensure they really are mandatories. Ultimately, you have to accept there’s a gray area where, as you strip out features, the expected revenue will fall.

Why you should reduce internal design complexity

Complexity cannot simply be expressed by feature creep. It can still exist within a minimal viable product, as features themselves can behave in unnecessarily complex or unconventional ways.

Despite successfully restricting a tight constraint on features to an elegant minimum, we need to think about the complexity of the features themselves. This can lead to instances where the most appropriate remedy to internally complex features is an additional feature.

Here’s an example. On a recent project, a client insisted on an autosave function for a particular part of an interface when the addition of a save button would have made the interaction and its outcome much more intuitive to the user (as testing later confirmed).

The increased complexity of expanding the scope of the minimum viable product was offset by the decreased internal design complexity of aspects of the system’s technical and user interface.

So, a minimal feature set doesn’t necessarily translate into a simplified user interface. Cumbersome interactions or poorly designed user journeys can easily offset the benefits of removing unnecessary features. Equally, it’s sometimes necessary to expand the system’s scope to to reduce the internal design complexity of certain features.

“What happens to user experience in a minimum viable product?”, by Ryan Singer, http://feltpresence.com/articles/9-what-happens-to-user-experience-in-a-minimum-viable-product

“The Dirtiest Word in UX: Complexity”, by Francisco Inchauste, http://uxmag.com/design/the-dirtiest-word-in-ux-complexity

“Uncertainty and Scope”, by Ryan Singer, http://feltpresence.com/articles/4-uncertainty-and-scope

“How Instagram Stays in Focus”, by Joshua Porter, http://bokardo.com/archives/how-instagram-stays-in-focus

“Flashback: Every time you add something you take something away”, by 37signals, http://37signals.com/svn/posts/2917-flashback-every-time-you-add-something-you-take-something-away

Managing internal design complexity

Managing ‘internal design complexity’ relies upon a paradox. The phrase implies the complexity of any given single feature. However, the significance of ‘internal’ complexity is not constrained to a single feature. Managing internal design complexity requires us to assess the solution at two levels simultaneously. Only through critical end-to-end analysis of the solution can we make a similarly effective judgement about whether any single feature is as simple as it can—or crucially—should be.

When looking at a feature set and deciding what can be safely eliminated without endangering core goals, reductionism is a double-edged sword., Taking the simpler view inherent in the ‘Minimal Viable Product’ mentality will result in cleaner, easier, more elegant and achievable designs. No less regularly, however, the process of reduction blinds us to unseen compromises in the functional simplicity of the solution as a whole.

The broader, zoomed out view may actually guide us to adding function to a feature here or there, all in the service of simplicity at the more general level.

Take the above example of the autosave function: the complexity of correctly intuiting the behavior of this single feature is one thing. Adding a function to the feature reduces the chance of the feature being misunderstood or misused. Beyond that, however, it would also have ensured that the instance of counter-intuitive behavior does not set precedents for how the wider solution is perceived.

This is the paradox: you can have the most elegantly minimalist feature set imaginable, but you will not attain simplicity if you don’t apply the principle of simplicity both holistically and flexibly. Features that are simple in isolation can become a contagion.

Conclusion

A core difficulty with discussing complexity and user interfaces is that it’s easy to misclassify the level of complexity. It’s a qualitative concept. As such, it’s important to keep a check on the subjective nature of our discussions. We have to be aware that complexity can only be reduced to a particular point, past which designs can lose both their utility and appeal.

It’s also not whether a design approach is more or less complex. The issue is that we’re talking about the experience of the system, not a quantitative measure of complexity. Ultimately, to determine the impact of scope complexity and internal design complexity across the overall user experience, complexity needs to be understood within a context.

The result is that many of the discussions on complexity and simplicity are polarized around whether or not complexity is an additive property. But, perhaps there’s nothing wrong with that, you should have a clear opinion on the products you make. Software should have your personality ingrained within it.

It is an honest question: how smart are your users? The answer may surprise you: it doesn’t matter. They can be geniuses or morons, but if you don’t engage their intelligence, you can’t depend on their brain power.

Far more important than their IQ (which is a questionable measure in any case) is their Effective Intelligence: the fraction of their intelligence they can (or are motivated to) apply to a task.

Take, for example, a good driver. They are a worse driver when texting or when drunk. (We don’t want to think about the drunk driver who is texting.) An extreme example you say? Perhaps, but only by degree. A person who wins a game of Scrabble one evening may be late for work because they forgot to set their alarm clock. How could the same person make such a dumb mistake? Call it concentration, or focus, we use more of our brain when engaged and need support when we are distracted.

So, what does a S.T.U.P.I.D. user look like?

Stressed

“Fear is the mind killer”, Frank Herbert wrote. Our minds are malleable and easily affected by their context. The effect of stress on the brain is well known, if not well understood. People under stress take less time to consider a decision thoroughly, and they choose from the options presented to them rather than consider alternatives. Stress is often due to social pressures. Car salespeople know to not let a customer consider an offer overnight, but pressure them to buy right away.

Tired

Tiredness is one of the largest causes of industrial and motor vehicle accidents. Interfaces used by tired people should take into account their lowered sense of self-awareness and number of details that the user is likely to miss. A classic example of an interface used by sleepy people, the iPhone alarm clock is typically set right before bed. Unfortunately, it doesn’t ring if the phone is set to vibrate, the default state for many people. When a user sets the alarm, it would be useful to override the vibrate feature, or at least remind them that it won’t ring.

Untrained

Training for enterprise applications is more often discussed then enacted. Users are thrown at an application with a manual and a Quick Reference Card. Applications that are not designed around the user’s workflow have to explain their conceptual model while they are being used: “where” things are stored, how to make changes, who to send things to.

Complex systems that are used infrequently are a particular problem. In the design of the automated external defibrillator, it is assumed the user may have no knowledge of the science or training on the device, and will be using it in a chaotic, stressful environment. The frequency of use should drive design. Yearly processes, like doing your taxes, should assume that the users have never done it before. In rarely used interfaces, customization is likely to be less useful, but a comparison to previous year’s entries is very useful as they remind the user what they did before.

Passive

More important than the user’s mental model of an application is their mental attitude toward the task. Someone sitting in the front passenger seat of a car may have the same field of view as the driver, but unless they are focused on it, they will not remember the path driven. Nothing reduces effective intelligence faster than doing a boring task against one’s will. When a user is passive, complexity becomes insurmountable. Games aimed at casual gamers know to keep the interaction model simple, using a flat navigation and avoiding “modes” (e.g. edit vs view).

Independent

User centered design is a powerful approach because it recognizes that there are many reasons people use a system. Airline booking sites are used to buy tickets, but also to see if the family can afford to go on vacation. The designer should recognize that they cannot solve every problem, but should give users the tools to help themselves, to work independently of the application’s intended method. In internal enterprise systems, the top user request is often “export to Excel”. This often reflects that the system does not meet the user’s needs. Excel empowers the user to do ‘out of the box’ actions. It is the API to the real world.

Distracted

People are multi-tasking more than ever, whether it is simply listening to music while driving or playing Farmville while watching TV. Effective multi-tasking has been shown to be a myth, but it is a popular one. Paying “partial attention” to multiple activities has significant impact to your perception of an interface. Users are often said to be on “autopilot”, clicking on things by shape, rather than reading the text. An interface cannot rely on the user having a clear and consistent working memory across multiple screens. The task and details must be re-stated at each step to remind the user the step they are on and what they need to do. Frequent, automatic saving of user entered data is essential, especially as connections can time out.

Help S.T.U.P.I.D. users by designing S.M.A.R.T.

Start-ups often experience a shock when they emerge from the hothouse of heads-down development. Their intended customers barely have time to listen to their idea, let alone devote time to explore its features. The contrast between a small group of friends working intensely together on a single project with the varied needs and limited free time of their customers can be a disheartening experience.

Projects often fail not because the idea is bad, but because the value their service will provide is not easily understood. The question I ask my team is “What problem, from the user’s point of view, are you solving?” It has to be a problem the user knows they have. If the problem is not obvious to the user, in terms they understand, the solution doesn’t matter. Focusing on the problem keeps a project from drifting into fantasy requirements: solutions looking for a problem.

Design teams often use themselves as model users, but they are almost the perfect storm of differences between themselves and the users.

• They know the product exists and what it is supposed to do.
• They understand the internal concept, including its past and future ideas.
• They care, personally, about the product. Their success depends on it.

The user has none of these things. The user knows nothing about the product, doesn’t understand the concept, and doesn’t care.

What can be done to make S.T.U.P.I.D. users S.M.A.R.T?

Simplify

Why are simple apps popular these days? It is not that people don’t like features, it’s because instant comprehensibility trumps powerful features. In the old search engine wars, Google may have had a better search algorithm, but they became known for having a simpler design. Yahoo and others tried to become portals, losing sight of the users primary goal. I advise people to “Design the mobile version first” to help them focus on the key user benefits.

The down side is that any successful project expands and adds features to address additional user needs. What starts out as “Writer for iPad” can end up as Microsoft Word. Simple is not always better, but keeping the new user in mind helps find the right balance.

Memorable

An app is only as good as the user understands it. That starts with the name – is it cute or does it explain what it does? Is it “pidg.in” or “Automatic Mailbox”? The iPhone / iPad apps’s television ads were effective sales tools, but also trained a generation by simply showing them in use. Each step of a workflow is subject to delays and distractions. Ecommerce sites know to reduce links during the final checkout process. With complex transactions, the risk is greater that the user will have lost their focus. Remind the user what they are doing in big title text. Focus on delivering Clear and Consistent messaging and instructions, for example, adding side notes like Ally.com’s password guidance.

Accept Autopilot

Standard design patterns are good, but they also throw the user into autopilot. It makes sense to break them for critical decisions. The hard part is determining what a critical decision point is. Observing user behavior, customer service records, and identifying risks to the user’s data are good clues. If something is simple enough that the users are mostly on autopilot, for example installing software, make the default action a single click.

Recovery

The dark side of users on “autopilot” is that they will regularly make mistakes by not paying attention. Mistakes are generally not obvious to a system, but it is good practice to highlight destructive actions and enable recovery. Capture data in little steps. Saving form fields instead of form pages, prevents large data loss. It’s a good idea to highlight and ask for confirmation on big, destructive changes, like deleting a database. “Undo”, common on computers, but slow to come to the web, enables the user to recover from errors.

Gmail lets users undo moving a message to the trash.

Gmail also let you restore your contacts if you accidentally make a large, destructive change.

Test in realistic situations

There is an essential flaw in the two-way mirror usability test method. In the interest of copying the form of the lab-coated scientist, these rooms create an artificial aura of “science”. But as ethnographic research can tell you, real world usage is so different as to make the test questionable. It selects for a test population that is free in the middle of the day, motivated by $50, and M&Ms, puts them in an unfamiliar environment with a personal guide to focus on a specific task with no distractions. This is about as unrealistic as it gets.

In reality, the same person may have a child on their lap and only 10 minutes to look up a flight. The fact that an ecommerce session may expire after a few hours is trivial for some, but significant for people who only have a few hours a day to use the computer. “Universal Design” is a great approach, because methods to help specific disabilities tend to be useful to the general public.

Testing should go beyond the user interface and cover the basic business model. The Apple iTunes video download “rental” is for 24 hours. Unfortunately, people tend to watch movies at the same time each day, for example, after the kids go to bed. If your kids wake up, you have to finish it earlier the next day. Would it have killed them to make the rental 27 hours, so parents could actually use it?

Design for the right level of Effective Intelligence

Effective intelligence obviously varies across situations. People are ingenious at figuring out things they really want, but the simplest task is insurmountable to the unmotivated. Both scenarios are solvable, but an application that makes the wrong assumptions about its users will fail. (Interestingly, this study suggests that easier-to-use design can affect the user’s perception of difficulty, and encourage them to complete the task.)

One should adapt their strategy to the user’s desire and the problem’s complexity. Here’s an unscientific matrix for effective intelligence with software interfaces.

This matrix compares the amount a user desires to complete the task versus the complexity of the task to that user type. Different user types will have different measures of complexity, so one might create several matrices.

Low Desire, Low Complexity – The goal here is to finish these tasks as fast as possible. Follow standard design conventions, seek to eliminate steps.

Low Desire, High Complexity Complex – Tasks that the user doesn’t want to do are a danger zone. Can the problem be reconsidered or eliminated?

High Desire, Low Complexity – The easiest quadrant.

High Desire, High Complexity – This is the most interesting quadrant. A self-training interface, (integrated help, training modules) can get the user started; they will often take it the rest of the way. Video games often have a “training” level to train the user on basic skills like moving around.

Get Smart

Effective Intelligence is a helpful concept in the design toolbox. User research and testing are the best ways to know your users, but knowing what may limit a user in reality helps design ways to make them smarter.

Like this article? Want to keep Stephen’s wisdom close at hand? Download the handy, cubicle-friendly, 61kb PDF to hang on a nearby wall and you’ll always remember to design SMART.

Expertise significantly impacts how we seek information online. Just as novice and expert photographers prefer different tools, so novices and experts behave differently when searching for information. Understanding these differences will help us design better search interfaces for both groups of users.

h2. There are experts, and then there are experts

User expertise exists on two levels. If you’re an avid photographer, your domain expertise in photography will be quite high: that is, you’ll be familiar with the terms and techniques of the trade. Each of us is likely a domain expert in a few areas, and a complete novice in others. A second aspect is technical expertise. Familiarity with how computers, the internet, and search engines work significantly impacts how users seek information. Consider these personifications of each quadrant of expertise:

* *Angela Baer*, since completing her MFA at Pratt 5 years ago, is quickly building a reputation as one of New York’s up-and-coming fashion photographers. In the office connected to her studio, Angela edits her photographs on two large monitors and top-end computer. She delivers the edited shoots electronically to her clients, and regularly updates her online portfolio and blog. Angela is highly proficient using her computer, and when it comes to photography, she’s a domain expert.

* Though officially retiring over 10 years ago after a successful career in banking, *William Hayes* still sits on the board of a number of financial institutions. From his Elizabethan cottage on the Kent coast, he uses a 5-year old computer to exchange emails and access financial reports, though he prefers doing business on the phone and keeping up with the world though The Financial Times. While William is a domain expert when it comes to finance, his technical expertise is lacking.

* 18-year-old *Fane Tomescu* helps run an internet cafe in Braşov, Romania. Having saved for over a year, Fane recently came across a car that he’s considering purchasing. But when the time came to arrange car insurance, Fane had no clue how things worked. He asked his parents and friends for advice, and then spent several hours comparing providers online. Fane is a technical expert, but when it comes to insurance, he’s a domain novice.

* *Claire Jones* is a 9-year-old from Colorado Springs. Her school is holding a science fair and Claire has decided to build a model of the solar system using styrofoam balls suspended with string. Having left her science textbook in her locker over the weekend she was meant to start building the model, Claire used the internet to lookup information on the order, size, and appearance of each planet. Though she did eventually find what she was looking for (with her parents help), Claire would be considered both a technical and a domain novice.

While either dimension of expertise is valuable, users are most likely to succeed when both are present. There are, however, a number of design guidelines which can help both novices and experts succeed in their pursuit of knowledge.

h2. Novices Orienteer

Image 2: An orienteer at the 2010 World Orienteering Championships in Trondheim, Norway. Photo by Torben Utzon.

Wayfinding is a challenge as old as humankind, but the discipline of orienteering originated in the Swedish military in the 1800s and is now a sport practiced throughout Scandinavia. Equipped with a map and compass, participants navigate between control points spread across many miles, making tradeoffs between distance and difficult terrain as they strive to complete the course in the shortest amount of time.

The strategies employed by novice users seeking information resemble the sport of orienteering. [1] Users with low levels of domain and technical expertise, typified by Claire Jones, share three main characteristics.

h4. Short queries

Novices tend to enter queries that use about half as many words as experts.[2] Domain novices (like both Claire and Fane Tomescu), feel particularly unsure of which terms to use.

h4. Many queries

Novices perform more queries than experts, but look at fewer documents. Although they frequently reformulate their query, technical novices often suffer from an anchoring bias [3] and make only small, inconsequential changes.

h4. Going back

Novices are much more likely than experts to hit dead ends and seek to get back to a previous state.

These behaviours result in an orienteering-like strategy where novices “test the waters” with a short, general query, quickly skim the top results returned, and immediately reformulate the query based on their improved knowledge of the subject. [4]

h2. Design considerations for Novices

There are a number of design considerations which can help novice users succeed at orienteering. In particular, novices need help formulating their query, refining their query, and backing out of trouble.

h4. Autosuggest

As-you-type suggestions can help users get off on the right foot when they’re uncertain what to search for. Research has shown [3] that users are more capable of choosing a viable option from a list than they are of composing a question out of thin air. Autosuggest provides an opportunity to help users express specific terms (such as airports or stocks), and to suggest queries that other users have performed in the past.


Image 3: Autosuggest on Etsy.com

h4. Related searches

After users have performed an initial search, they may still need help refining the query. A list of related searches can help the user break out of their anchoring bias and help them arrive at the optimal set of results.


Image 4: Foodily.com place related searches on the same line as breadcrumbs

h4. Avoid zero results

If the user is presented with no search results, he may be disheartened enough to give up his quest. Avoid zero-result screens if possible. Tools such as automatic spelling corrections and query expansion (using synonyms and lemmatisation,[5] for instance) can help.


Image 5: Amazon.com’s handling of zero results

h4. Breadcrumbs

Because novices tend to take wrong turns, they often need help navigating back to a previous state. Breadcrumbs are an ideal solution because they communicate both the user’s current location, as well as how to go back.


Image 6: Breadcrumbs on Zappos.com

h2. Experts Teleport

Image 7: In Star Trek, crew members of the USS Enterprise stand on transporter platforms to be beamed down to a nearby planet.

While novices orienteer, experts teleport. Akin to being teleported to a precise but distant location, users with high domain and technical expertise like Angela Baer tend to jump directly to their final destination.

h4. Longer queries

Experts enter longer, more specific queries than novices. Domain experts like William Hayes often rely on their vocabulary of specific terminology, while technical experts such as Fane Tomescu are more likely than novices to use formatting techniques such as quotation marks in their queries (87% of experts compared with 47% of novices according to a 2000 study [1]).

h4. Fewer queries

Experts usually amend their queries less often than novices and move forward with a higher degree of confidence.

h4. More Documents Examined

Experts tend to review more documents and follow a greater number of links within those documents. Domain experts are especially adept at quickly determining whether or not a given document is useful.

In essence, experts often construct queries using numerous highly specific words which act to teleport [6] them directly to a destination, cutting out the query reformulation often practiced by novices. After having arrived at a destination, experts are then likely to explore the surrounding territory.

h2. Design considerations for Experts

Designing for experts involves facilitating their teleporting behaviour, helping them get to their destination as quickly as possible.

h4. Advanced syntax

Technical experts like Fane are often willing to learn special commands in exchange for having greater control. Commonly supported operators include AND, OR, and quotes for searching for exact phrases.


Image 8: Wolfram Alpha is designed to understand domain-specific terminology and return computed answers.

h4. Keyboard shortcuts

Keyboard shortcuts can also increase the speed of interaction. Google, for instance, allows users to press the up/down arrow keys on the keyboard to traverse results, and press return to go to the URL of the selected result.


Image 9: Google places a caret beside the currently-selected result.

h4. Filtering & sorting

Experts are more likely to engage with advanced sort and filtering controls than novices, including operations such as selecting ranges, filtering by format, or excluding certain terms (e.g. everything that includes “apples” but does not mention “oranges”).


Image 10: Getty Image’s Moodstream lets users search for stock photos using sliders.

h4. As-you-type results

As-you-type completion interfaces most often display query suggestions to users. However, another use case is to present actual results in the autocompletion interface, enabling users to skip the search results screen altogether and go directly to a specific document.


Image 11: Rather than suggesting terms to search for, Nutshell returns search results directly without needing to go to a separate page.

h4. Result table of contents

Providing links to the top destinations within a result can reduce the number of steps required for the expert to reach his destination.


Image 12: Google sometimes provides links to the top-level pages within a given site.

h2. Yin and Yang

While novices and experts practice two very different approaches to information seeking, it’s important not to overemphasis one at the expense of the other. As illustrated by the ancient Chinese symbol, understanding the behaviour of both novices and experts can help us design more informed, balanced search experiences.

The author would like to thank Cennydd Bowles for organising the UK writer’s retreat during which this article was written, as well as for the editorial guidance that he provided.

h4. References

[1] Vicki L. O’Day and Robin Jeffries; “Orienteering in an Information Landscape”:http://www.hpl.hp.com/techreports/92/HPL-92-127.pdf

[2] Christoph Hölscher & Gerhard Strube; “Web Search Behavior of Internet Experts and Newbies”:http://www9.org/w9cdrom/81/81.html

[3] Marti A Hearst; “Search User Interfaces”:http://searchuserinterfaces.com/book/sui_ch3_models_of_information_seeking.html#section_3.5

[4] Morten Hertzum and Erik Frokjaer; “Browsing and Querying in Online Documentation”:http://www.cparity.com/projects/AcmClassification/samples/230570.pdf

[5] Christopher D. Manning, Prabhakar Raghavan and Hinrich Schütze, “Introduction to Information Retrieval”:http://www.cambridge.org/us/knowledge/location/?site_locale=en_US , Cambridge University Press. 2008.

[6] Jaime Teevan, Christine Alvarado, Mark S. Ackerman and David R. Karger; “The Perfect Search Engine is Not Enough”:http://people.csail.mit.edu/teevan/work/publications/papers/chi04.pdf