User Experience Go Away

by:   |  Posted on

There is no UX for us

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, Mastery and Ease-of-Use

by:   |  Posted on

Recently the web design community has been eating up the secrets of game design. The Gamification trend merely borrowed simple game mechanics, from badges to progress bars. But now designers are looking more closely at core game design principles like design for flow and mastery, blending them with our old friend, ease of use. But how many of these techniques are relevant for more everyday sites, like ecommerce and productivity apps?

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.


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 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.

Amy Jo Kim's player journey helps you decided what the key mastery points are
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).


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.

Leonardo’s Kitchen Nightmare

by:   |  Posted on

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

Leonardo Da Vinci

Leonardo lookin suave

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.


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.

Complexity and User Experience

by:   |  Posted on

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.

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.

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.

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,

“The Dirtiest Word in UX: Complexity”, by Francisco Inchauste,

“Uncertainty and Scope”, by Ryan Singer,

“How Instagram Stays in Focus”, by Joshua Porter,

“Flashback: Every time you add something you take something away”, by 37signals,

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.


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.

Are your users S.T.U.P.I.D?

by:   |  Posted on

Are your users STUPID?

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?


A subtle reminder like this would have saved me a few weeks ago.“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.


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.


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.


Nothing reduces effective intelligence faster than doing a boring task against one’s will.

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).


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.

…The top user request is often ‘export to excel’…. Excel empowers the user to do ‘out of the box’ actions. It is the API to the real world.


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…. The user knows nothing about the product, doesn’t understand the concept, and doesn’t care.

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?


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.

Help the user remember WHY their password is failing


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 “” 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’s password guidance.

If the user has but one hard drive, why ask?

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.


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 lets you recover items from the trash.

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

An excellent example of protecting the user from their own mistakes

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.

There is an essential flaw in the two-way mirror usability test method…. It selects for a test population that is free in the middle of the day, motivated by $50, and M&Ms.

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.

Effectiveness matrix

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.

Maxwell Smart. It's a pun on... Oh forget it.

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.

One-sheet thumbnail

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.