This is especially prevalent on the web, where switching costs are so low. For users, it’s so easy to hit the back button and go to a competitor, that getting people in the door and attached is a key part of grabbing some market share. Seems like common sense, huh?

Well, you’d think. Unfortunately, a majority of products on the web don’t do a great job at getting users in the door easily. Instead, they present users with arcane signup forms, difficult setup flows, and generally a whole bunch of pain. This generates much griping among the team, who start reading articles about conversion rates and tweaking the colors of buttons in a desperate attempt to lure more people through the elusive conversion funnel. Generally, this misses the point grossly, dooming the innocent product to a life of anemic adoption, and potentially, complete failure.

So, what’s going wrong?

It has to do with something I call the “Incline of Death”. The Incline of Death is a moment in a product adoption lifecycle where pain overcomes perceived trust and value, causing the user to bail out – too little trust, too much pain.

Illustrated, it looks something like this:

This sketch shows the problem. As a user progresses through time, experiencing your product for the first time, they’re balancing two different emotional states: trust/value and pain.

As they get to know your product, and they start to perceive real value from using your stuff, their trust rises along what I call the “Curve of Value”. This curve has awesome staying power – make it high enough (by providing a whole bunch of value), and people will be much more likely to stay around.

In the dashed box, you can see the danger zone. This is the Incline of Death. The Incline of Death occurs when the amount of pain experienced by a user rises before the Curve of Value kicks in. Trust is low, pain is high – people bail out (unless they’re forced to use it, as with company expense reporting software and about any government product).

The Incline of Death claims many lives on its silent and insidious quest to sink new products. Many companies don’t even realize it exists, until they interview potential users and hear the string of curse words attached to their brand name. Ouch.

So, we know the Incline of Death is out there. What can you do about it?

You can beat the Incline of Death in two ways:

• Move the Curve of Value up in time
• Flatten the Incline

Moving the Curve of Value up in time means demonstrating value and establishing trust before requiring much work on the user’s part. Comprehensive demos, easy trials and no-account-setup strategies are ways move the Curve. With all of these, it means somehow engineering a way for the user to derive real value before having to experience setup or commitment pain. And no,  a page of screenshots labeled “Tour our Product” doesn’t count – you need to provide real and lasting value to really move the Curve.

Another technique commonly used to help move the Curve of Value up is gradual engagement. Gradual engagement allows a user to begin using your product with the smallest possible commitment up front, for example, by removing sign up forms and letting users jump in immediately (with signup coming later, after value has been demonstrated).

In short, find a way to demonstrate value quicker. Even if you can’t flatten the Incline of Death, moving the Curve of Value up can give users the will to fight through the pain.

Flattening the Incline of Death means redesigning setup to reduce the total amount of pain. Removing form fields, delaying the collection of certain types of data and completely removing setup altogether are some ways to flatten the Incline. Often, flattening the Incline is much more difficult than moving the Curve of Value up. Stakeholder positions and business culture can sometimes demand certain amounts of setup complexity, and in some instances, the product itself requires a certain degree of setup to work at all. In those instances, stretching the Incline out (basically flattening it by stretching it) by breaking setup into steps (with value-based feedback and encouragement) or moving advanced setup into interior areas of the product can help. For instance, if a user is signing up for an email account, let them choose a username and get started. Delay advanced setup – adding friends, contacts, etc. – until later in the product lifecycle (or at least offer it, and let a user skip).

The fact is, sometimes you simply can’t make setup less complex. As Tesler’s Law of Conservation of Complexity states, there’s an inherent amount of complexity in interactive systems. The only option is to either move complexity from the user’s perspective to the system’s (by automating tasks, using intelligence, etc.) or by stretching complex task flows out over time, reducing the shock users experience at any given step.

When it comes down to it, flattening the Incline of Death is mostly about restraint – what pain can you delay, until after the user has already experienced enough value to put up with it?

The Curve of Value and Incline of Death are critical pieces for product adoption. We’re more likely to forgive something for causing us pain when we trust it. Master this, and you’ll massively increase your chances that people start using your product.

For those not familiar, here’s how it works (at least, here’s how the ones in Tampa I’ve been to have worked…): a mass of food trucks descends on a location, usually a big parking lot or field. These food trucks line up and open for business, with hoards of people coming out to sample their wares.

The last one I attended in Tampa was great, except for one thing: the experience was terrible.

As I walked around the rally, I was trying to get my head around what made the experience bad. It was in a beautiful area of South Tampa, on a gorgeous day, but there was something that was making it less than ideal.

Then it hit me: food portion sizes. The food portions were too big!

Let me explain: At a food truck rally, the implied goal is to circle a bunch of food trucks to allow attendees to see and taste food from food trucks around the city. The problem is, when you’re serving entree-sized portions, no one samples. At that point, there are at least a couple main issues that make the experience bad:

1. Entrees mean longer lines: because entrees are usually cooked-to-order, the experience doesn’t scale. Each person generates X minutes of prep time, which doesn’t enjoy much economy of scale to speed things up. At the rally gets crowded, lines get longer, and frustration increases on the part of attendees.
2. Entrees don’t lend to sampling – the entire point of a rally like this: this is really my biggest beef, because I’ve seen this violated at food festivals as well. Vendors serve meals, not samples, meaning attendees end up going to a single place (or maybe two, in the case of a couple, but the waiting time is doubled, or you’re separated from your partner for some bulk of time, decreasing the quality of experience). If the point of a rally or festival is to allow attendees to sample food from various vendors, then serving entree-sized portions completely flies in the face of the reason the festival exists. For attendees, the benefit of a rally – a variety of vendors in one location – is completely removed. Put simply, I’d be better off finding a food truck the next day, and just driving to where it is to order.

This experience is broken, and it goes for food festivals as well (the recent John’s Pass Seafood Festival in St. Pete comes to mind). For a successful food festival/rally experience, the focus need to be on allowing attendees to sample, meaning vendors serve smaller portions that are potentially pre-prepared, thus shortening lines and widening the breadth of total allowable food samples.

There are a myriad of ways to solve this problem: serve preprepared samples, allow remote ordering via mobile with pickup notices pushed to a phone (someone want to build a food festival app for this?), put servers in the crowd delivering samples for cash on the spot, create multiple smaller tables around the trucks to increase order efficiency, etc. Whatever the solution is, it has to involve smaller sample sizes, period.

So, next time you’re at a festival or rally, take a look at the experience. Note whether they’re really gearing the experience toward allowing attendees to sample, and how line lengths are dealt with. These are the kind of service experiences that can be made remarkable, if we just give it a little more thought.

When we all started jumping onto the web in the mid-to-late 90s, it was exciting – the new frontier. We rushed through the Dot Com bust, inventing entire new ways of interacting with each other (Myspace, Facebook, Twitter) and creating an entire ecosystem to support our lives that never existed before. From then, up until now, it was pretty exciting.

But now, it’s getting boring. We’ve moved from a pioneering spirit to one full of static and parity. With the economic downturn, companies reduced spending on web-related projects, often stripping them down to merely content repositories and distribution channels.

Additionally, the web has decontextualized much of our daily life. As we sit down in front of the computer (the way the vast majority of people still consume the web throughout their day), technological support of our human context has been framed up inside a plastic black bezel. Put bluntly, so much of our web experience is stripped of sensory experience. Our sense of touch is mostly limited to the glazed tops of keys and a curved mouse (or even worse, a flat touchpad). Our sense of smell and taste are completely removed from the experience, and even our sense of hearing is limited to a few forms of media-based audio: mostly that of videos and music, piped through to us on demand as we continue the quest toward our fattening consumption of various media.

Yes, the web has become a stale experience, comprising mostly of social support frameworks and heaps of consumable media. As user experience designers, our job has mostly been to try to create a nicer facade for these compartmentalized experiences. While momentarily exciting, the caffeine rush is temporary: an exciting world of technology, progress and complete social change, neutered down to headers, blocks of text and sexy real-time error delivery in forms. Boring.

I know this sounds rather dark and pessimistic, but I want to look at this as an opportunity to call technologists and businesses to action.

I know a bunch of brilliant – and I mean brilliant - technologists. People who astound me with their understanding of how code and machines work. These folks can code anything, making any machine do their bidding. What a waste to spend that talent building another sidebar component for a CMS, or making Ajax work quicker to validate a form.

As we look toward the future, I want to challenge technologists and businesses to look outside the web. Yes, the web is always going to play a role. Yes, mobile will probably always be around. But, let’s look further. Let’s look at how technology can make the bus riding experience better. Let’s make the TV experience better. Let’s make the furniture shopping experience better. And, let’s do it not using more mobile apps to add a layer of augmented reality on top of our world – let’s fundamentally change how we do things, by leveraging technology in more boundary-breaking ways.

So, next time you sit down and code another header or incrementally improve the way a slideshow transition works on a mobile device – ask yourself this: are you really using your talents and vision to their fullest extent? While, yes, someone has to take care of these details, I believe they’ll be taken care of as a natural part of a larger innovation picture. If you find yourself bored with the web, get off the web and build something in the real world.

Apps really aren’t anything new, but the idea of a lightweight piece of software that extends the functional possibilities of the device it lives on is remarkably exciting – especially when considered outside of a phone or computer context. For a few years now, we’ve seen a move from computer-based apps to mobile and tablet apps, and with it, an entire new economy has emerged.

Now, think outside these devices. Using the application metaphor – lightweight software applications that extend the functionality of the device they live on – it’s easy to see that applications, and the operating systems that support them, will eventually move more ubiquitously across all consumer devices.

Take your car. Today, cars are still fairly basic: the mechanical components needed to facilitate transport (wheels, engines, etc.), a set of gauges to monitor the operation of those components (speedometer, temperature sensors, oil pressure gauges, etc.) and luxury accessories (radios, padded seats, A/C, etc.). If you think of the car not as a self-contained device, but as a platform or OS, how might applications play a part?

It’s possible you’d have an oil change app, running on the screen mounted in the dash, monitoring oil quality and alerting you to changes in oil chemistry makeup and oil change intervals (complete with in-app advertising for local oil change specials). Or, you might have a weather-aware A/C app, which uses GPS to monitor local weather conditions and adjust internal climate control (and engine efficiency) settings automatically. In a more active sense, you might have a travel companion application that monitors your travel progress, automatically booking hotels and finding food based on user-customizable preferences. These are pretty simple examples, but the point they illustrate is exciting: soon, the car will be a platform for a host of applications that extend the driving experience.

Going inside the house, how about your dishwasher? Can it act as a platform for applications? With an open OS on the machine, a developer might build a water saver app, allowing you to interact with the digital interface to customize your washing cycle. Or, analytics packages might report back on the wash details, including efficiency of cleaning (automatically adjusting for the next load based on an infrared scan of food debris on plates?).

Anything you can think of that has electronic components – cars, dishwashers, coffee machines, TVs(!), stereos, sewing machines, curling irons, watches – can become a platform for applications. All it’ll take is a forward-thinking manufacturer, an easy-to-use OS and development framework, and a marketplace for consuming the apps, and we’ll be there.

The era of the dumb machine is coming to an end. The era of the app – of almost infinitely extensible devices  - is quickly approaching. Better get designing…

Earlier today, I read a Facebook wall post about “hating corporations”. As I watched the comments unfold, it became clear that the people arguing the point had specific items they didn’t like, whether it’s employee treatment, lobbying, bad customer service, etc. I don’t intend to take a side in this argument, but instead want to point out an observation: your argument is much more powerful when you’re specific.

See, when you say “I hate corporate America”, no one knows what you mean. That phrase – corporate America – is made of so many different components, that it’s ineffective (from a communicative standpoint) to simply call the entire thing vile. When you begin to tease out specific component – “I hate how large companies tend to be less personal to their employees”, “I hate the fact that large companies lobby to gain market share” – you’re now dialed in close enough to enact some kind of meaningful action. Generalities, while emotionally seductive, don’t make good action plans.

The same is true in a business context. Take design: saying “I hate 3 column layouts” or “I can’t stand Android applications” isn’t productive. These statements only entrench a generalist mindset that doesn’t lead to progress – it’s the technology equivalent of prejudice. Saying “3 column layouts are too cluttered for me – I don’t like that the viewer has to navigate three horizontal panes of content simultaneously” is much more productive.  Now you know the problem to solve: manage clutter. (I’m not arguing against 3 column layouts, and in fact, that entire statement I made may be totally false. It’s only an example, so don’t clutter the comments with flames about layouts.)

Here’s the point: if there’s something you don’t like, be specific! Blanket generalized statements – whether in business, design, politics, or anything else – aren’t productive. Yes, they market well, and they fit nicely on bumper stickers, but do better than bumper sticker arguments…argue something worth talking about.

When you start with a goal – “We want to improve XX for people”, you allow your organization the freedom to research and explore the best solution, coming up with many ideas, in search of the best one (or combination of them) to achieve the goal.

It’s easy to come up with ideas, and there are many failed ones out there to attest to the ease of coming up with them. It’s much more difficult – but paradoxically safer – to come up with a goal, and be more open to what the solution might look like.

As a former developer (both front- and back-end), I enjoy a unique perspective on how the user experience-developer relationship goes. There are hundreds of things I’d love developers to know about user experience design, and this list represents a sampling of some of the more important things I want developers to keep in mind more often:

1. People expect online interactions to follow social rules. Credit for this goes to my friend Susan Weinschenk, who covers this point exceptionally in her book 100 Things Every Designers Needs to Know About People. When people interact with a website, application, or any device, they expect that interaction to adhere to the same rules that govern in-person interaction.

   Feedback is a great example. If a friend of yours walks up to you on the street and says “Hi!”, what’s your response? Generally – unless you’re a psychopath – you respond immediately in kind, saying “Hi” back. What if, instead, you stared blankly at them for 15 seconds before responding? An awkward moment, huh?

   This happens all the time online. See, every interaction is really a conversation. We say something by taking an action, and we expect the interface to respond in kind, continuing the conversation. However, too often, users are left wondering if a website or app is actually doing anything. While the computer is off processing information or retrieving data, the user is left in the cold, staring awkwardly at the interface, wondering if it’s ever going to respond. The lesson? Just like in real life, provide feedback to users about what’s happening, just as you would in a real-life conversation.

   The same goes for all social rules. Be kind and humane in how you talk to users. “Invalid Data” is language a computer users…”Hmm, that doesn’t look quite like an email address. Mind checking it for me?” is how people talk to one another. Follow social interaction rules when building interfaces.

2. People care about goals, not tools. At the end of the day, people care about getting things done and getting on their way. No one uses your software for the pure joy of it – they use it to accomplish a goal. Assuring that you’re developing a website or app to support that goal is one the keys to developing better experiences. Tools, while useful, get in the way if they’re not directly contributing to the completion of a goal.

   Jared Spool talks about goal time vs. tool time in this article, and it’s a great read for anyone putting together an interactive experience. Goal time is time that moves a user forward toward the completion of …you guessed it, a goal. Tool time is time that doesn’t move them forward, but supplements (and possibly distractions from) the goal time. As Spool notes, decreasing tool time and increasing goal time is a surefire way to assure your users achieve higher quality results, which means they’ll love you more.

   The lesson is this: as you’re building a website or application, gut check things you’re creating: does this element or feature really move a user forward toward a goal, or is it a tool masquerading as a goal-time element? Eliminate as many things that don’t keep users moving ahead. These might be extra form fields, customization controls, or other items that don’t move a user forward, but simply distract from the larger goal.

3. Fewer choices make life easier. In a famous study, Sheena Iyengar tested the paradox of choice using tables of jam. The study aimed to understand how choices affect decision making, and resulted in a remarkable finding. It went something like this:

   The study involved a table of jam at a busy grocery store. During the day, the table rotated the selection: sometimes 24 jars of jam were available, other times, only six. During the course of the day, more people bought from the table when only six jars were available, rather than when 24 jars. The finding showed that more choices actually inhibit decision making, not expedite it.

   When you’re designing a website or application, less is more. Resist the urge to add more features, more options and more layers into the product. As you pare away these items, users have an easier time making decisions, and are ultimately more successful.

   As you’re building something, remember this famous quote: “A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away” - Antoine de St-Expurey

4. 10 minutes of sketching will save you 10 hours of development. Every developer knows the pain of having to scrap a large chunk of code, just because a product manager or designer changed the requirements. These requirements changes aren’t typically the work of an A.D.D. manager – they’re the result of poor shared vision between all the players on the project.

   Underscoring the importance of planning first, Frank Lloyd Wright said this: “You can fix it now on the drafting board with an eraser, or you can fix it later with a sledgehammer.” Implicit in this quote is the idea that fixing problems before they’re built will save large amounts of money and time later down the road.

   Too often, products are built first, and planned second. Agile, with it’s “produce immediately” mentality has allowed the development process to get lazy with planning, and it’s unfortunate. This isn’t to advocate for a waterfall process, which also has moments of waste. When you go to build something – be it a screen, a form or an app, do yourself a favor: sketch it first and share it with the entire team. Erasing lines is much cheaper than deleting code.

5. User experience work makes your life easier, not harder. Designers and developers love to pick on each other. Having worked in both roles, it’s easy to see why – the differences between the two groups couldn’t be more polarizing. User experience design work, however, doesn’t make the development process more difficult and time consuming (if done well). Instead, it allows developers to do more of what they love: write great code.

   Great UX work up front helps define the product, work through difficult process, flow and experience issues, and identify a set of items to be built. Instead of leaving a developer with a vague idea of the product to be built, great user experience designers carefully work out the details, relying on developers to carry out the technical aspects of the conceptual design. Like an architect and contractor working together, a UX-developer partnership results in better end products, and a project process that both groups enjoy.

For example, on the web, a website typically features navigation across the top, or down the lefthand side. Generally, a logo in the upper lefthand corner links to the homepage. On a door, the knob is on the unhinged side, around hand height. These patterns and standards help us to use these objects without needing to relearn them. They’re essentially cognitive shortcuts that allow us to get thru the world without being disoriented all the time.

Occasionally, however, these patterns are ignored, and the resulting artifact (be it a website, a house, or a bag of tortillas) doesn’t work as well as it should.

Enter the bag of tortillas. Last night, as I was making dinner, I opened this new bag of tortillas and went about my business:

I didn’t notice anything strange immediately. That is, until my wife got home. Upon seeing the bag of tortillas, she remarked: “Uh, why did you open it on the wrong end?” I thought that was odd, as it certainly appeared correct, opening on the top.

Upon further inspection, however, she was right. The top of the package (that I had now removed) featured this warning:

My immediate reaction was that it was printed upside down, but that’s not the case, given the “Open Below” wording. In any case, I rendered the bag unsealable, completely going against the manufacturer’s (and designer’s) intent.

So, what went wrong?

This is an excellent example of a design pattern being violated. Think of a pattern as a recommended way of solving a specific problem, in this case, how to put together tortilla packaging. This pattern would recommend the following: large product logo on the front of the packaging with an opening across the top. Clearly, the designer went against this standard, put the opening on the bottom of the package, and left the user (me) to stumble into danger.

Here’s what we can learn from this:

1. Design patterns and standards help people understand things. There are millions and millions of design problems out in the world. Everyday, we struggle to find the best way to structure something or solve a specific problem. Luckily, many of these problems have been solved well, and we should utilize those solutions when appropriate. Like putting the navigation across the top of a website, putting the opening of a product packaging across the top is a standard solution that users have come to understand. Violating this pattern without ample redesign of the entire context results in confusion.
2. Users don’t read. We’ve heard this time and again, and it continues to ring true. Even with warning text across the top of the packaging, I proceeded to mindlessly rip into it without pause. The reason? It appeared to follow a standard pattern, so instead of using up extra cognitive energy to process the text, my mind opted for checking out and moving right into opening it. Never make the mistake of thinking you can simply fix poor design with a label or instructions. Our brains will take the lazy way out.
3. Form implies function. When designing anything, the form of that object carries with it certain meaning. An item like the tortilla package carries with it all the past expectations and memories of other objects that look just like it. Because it resembles so many other packages we’ve seen before it, we assume it operates in the same way. Remember that the form of something carries with it underlying assumptions, and assure that if you change how a user interacts with it, you change the form appropriately to communicate the new interaction typology.

Design patterns and standards help us understand the world. They provide us with proven frameworks for solving common design problems, and their repeated use teaches users to expect things to work in a certain way. While being innovative is certainly desirable, recasting these patterns needs to be researched and designed carefully, so that our users aren’t left ripping things apart.

For more on design patterns for the web, check out these resources:

Yahoo Design Pattern Library
Welie Design Pattern Library

Getting started is easy. Simply let us know a bit about what you’re working on, and we’ll get back with you quickly to give you an idea of how we can help. It’s always no obligation, so there’s no risk to you.

They call things the wrong name. They have a vision of the structure of your organization that is different – sometimes radically so – than the truth. The act in irrational and unpredictable ways. And guess what? It’s OK.

The trap companies fall into too often is trying to correct the user. “That’s not really what that department is called”, “That’s not the language we use here” are the all-too-common cries of stakeholders innocently protecting the institutional structure and language. The problem with doing this is that trying to teach a user the right way to think rarely ends up in the intended goal. Instead, users get confused, projecting those bad feelings onto the brand that was simply trying to preserve it’s organizational purity.

The key to preventing this? Stop insisting that people use your terminology and structural metaphors, and instead, design how the user thinks about you. You’ll use incorrect language (organizationally, anyway), and it’ll eat at the operations-manual devotees in the organization, but ultimately, it’ll get you where you want to be: a positive relationship with your customers – one that will be much more likely to result in some type of transaction.

So, next time you’re quarreling over how to label something or how to structure the information on your site, resist the temptation to reach for the manual. Instead, listen to how people actually talk about you, and cater to them. After all, if you can’t communicate with your users effectively, all your branding work is for naught.