There is this common element in user interfaces on every device and on every platform. Here’s how it goes: You press a button or a link or some piece of UI that does “something”. The next thing you see is a small dialog box asking you “Are you sure you want to do [that something]?”. If there were a hall of fame for irritating dialog boxes, this one would be its first inductee.

Here’s the inner monologue running through my brain when I encounter one of these in the wild: “Am I sure? Well of course I’m sure. I just clicked the button. Did you forget already? Are you having some sort of memory overload? Did I not look serious when I pressed that button? Or is there a big problem where users are accidentally clicking on that button so you need to confirm their intent a nanosecond after they request you do something?”

You get the idea.

Here’s why software developers put in the “Are you sure…” dialog (or as I like to call it — the CYA dialog). Invariably, there are things that you can do in software that make changes. Sometimes permanent changes. And sometimes permanent changes to your data. So… before the software will perform a destructive action on your behalf, they want you to be sure of the implications of your decision. This is a fine thing when you’re erasing a hard drive. In fact, if you’re about to erase a hard drive, or delete an account, feel free to put in multiple CYA dialogs, and move the buttons around so nobody can click them accidentally by rote. But in the normal cases, stop asking me. Just do as you’re told.

Now, we recognize that there are certain situations that are less potentially dangerous than erasing your entire hard drive, but still could cause heartache for the user if performed without the user being aware of the full implications of their decision. And there are steps to mitigate this:

• Undo. If the action is going to destroy some data, just save a copy of it, so after the action is performed, the user can un-perform that action. Yes, this is more work. Yes, this is a pain. But you are delivering safety and confidence to your user.
• Limited time undo. Let’s say that maintaining the ability for the user to undo their action isn’t impossible, but really expensive. Give them a limited time after completing the action. You could give them one chance post-destructive action to undo it, OR, give them a time limit (24 hours?) to undo their action, and then the changes are permanent. There are lots of minor variations on this scheme.
• Eliminate the functionality. That’s right. Just get rid of it. If the functionality is so dangerous, perhaps your users can live without it. Is there another way to solve this problem? Do users really need this particular feature? Etc.
• Better messaging around the action. If this information is so important that you need to put it in a dialog… just put it up front around the button in the first place.

Software that’s filled with scary warning messages is not a product that anyone falls in love with. They may use it, but they won’t love it.

It used to be enough that a piece of technology existed. It used to be enough that now we could do something we couldn’t do before. Whether it was adding up a column of numbers, or WYSIWYG editing of a document, or listening to music, or editing a movie, or the web! But creating new categories of software is a hard task. It’s happening less and less. And the number of entrants in each category is only increasing. This is the sign of a maturing (and saturated) industry. What to do with the 72nd app in an existing category? How will anyone notice your new to-do list app? Or your amazing new word processing software? Will anyone pay attention to yet another social network?

Have no fear. There is a weapon in your arsenal that you can use to attack this problem. That weapon is design. And don’t worry, using the weapon effectively is hard enough that merely knowing that design is the answer is no guarantee that of success.

The key in distinguishing your software experience is expressing focus through design. And the first step is answering the question of “why”. Why are you making a new app in this already overpopulated category? What makes you so much better? You don’t have to prove that your better empirically. You don’t have to have a longer list of features. What you need to do is believe in your heart that your solution makes the competition look like antiquated garbage, and then convey your belief through the magic of focus and design in your experience.

Does your product do something better than the competitor? Then build your entire identity around that advantage. (e.g. the iPod vs. every other MP3 player in existence when it was launched. And what did the iPod do better? It played music better. It did this by eliminating features and distractions and focusing on the main reason you bought the device in the first place.)

Does your product turn their liability into your advantage? Then lead with that. (e.g. GMail’s near unlimited storage vs. the constant hitting of storage limits on Hotmail and Yahoo Mail.)

Does your product simply look ten times better than the competition? (e.g. Flipboard vs. every RSS reader that was out there.)

Let’s take a look at Flipboard. Flipboard had less content than the competition, less customization than the competition, ran on fewer platforms than the competition, and yet made the competition look terrible. And even in terms of design, Flipboard had less. A few standard templates, simple clean typography, and one simple animation. The flip. It’s not fancy. It’s not technically challenging. It’s not even necessarily coherent with the visual design. It’s just simple and to a certain degree — arresting (because nothing else did featured this animation so prominently). And yet, the reaction to it is visceral. Because it was different. And what did Flipboard do? They made it the centerpiece of their identity. It’s in their name. They even counted “flips” and claimed it was a meaningful statistic to show off about.

What is the flip? The flip is Flipboard’s “signature moment”. We’ll cover these in detail in another chapter, but you should understand, this simple animation done in the context of all their other focusing decisions makes Flipboard stand out.

Having a hard time knowing how to differentiate yourself? The answer doesn’t seem obvious? Break the rules. Reverse your assumptions.

This doesn’t always work, but it’s a good method for getting your creative thinking going. Want to make a web encyclopedia that competes with the printed versions? Don’t have a huge expensive staff? What if anyone could edit it? Anonymously!

Want to compete with a relatively simple to use blogging platform with millions of users (Blogger)? What if you made a blogging platform that was even simpler (Tumblr)? Or how about one that was even simpler than that (Twitter)? Or how about one that’s way more powerful (WordPress)?

There are no right answers here other than to avoid the assumptions that govern the current winner in your category like the plague. The things that made them successful now constrain their growth. They have an audience that likes their focus. Your job is to come up with a truly different take to peel off users for whom their solution doesn’t quite work.

Visual design is another area where you have an opportunity to say something different. And again, some of the best distinctive visual design is a result of the kind of thinking we discussed above. Let’s take an example for the consumer products world – Smartfood Popcorn. At the time, retail snacks simply didn’t come in black bags. Period. “It just isn’t done.” When someone utters those words, that’s the smell of blood — and you’re a shark. It’s not that you should recklessly pursue things that aren’t done. Because sometimes there are good reasons they’re not done. But, often, there’s some small notion you can cultivate from those assumptions to help you stand out. Smartfood shipped in a black bag. The world didn’t end. People bought it. People ate it. Smartfood succeeded.

Think great visual design needs to be expensive? Take Minecraft or Doodlejump. In an age of videogames costing tens of millions of dollars to produce… In an age where video game graphics look almost like Pixar films. These two games were produced with relatively low-tech graphics. Minecraft went super low-res with pixelated cube graphics representing every object in their world, and Doodlejump was literally that — a bunch of hand-drawn doodles jumping around on your screen. They looked like anyone could have drawn them. Both are hugely successful, both stood out, both were not considered state-of-the-art visual design.

Applying great design in the context of tight focus is what makes things stand out. Getting specific and niche is not a liability, it’s a tool to let you distinguish your product in a crowded marketplace.

And don’t worry, if you succeed, you can always expand your focus later and become the sprawling all-encompassing market leader that you’re now trying to unseat.

We do this all the time in life. We start with a broad idea and make it more specific. It’s natural. It’s normal. It’s healthy.

“Want to go out? Food or a movie? What type of food? Which restaurant? What night? What time? Where will we meet? What should we order? etc.”

And yet, when we have larger teams working on software projects, we often try to plan things out in advance in way too much detail. Now, we know that many teams have taken a much more agile approach over the past few years. But many teams haven’t. And it’s usually the larger tech teams, where lots of people are working on a project, and managers have been put in place that suffer from this disease.

On larger projects communication gets harder. And so people try to formalize communication and get more disciplined about change. Because change without proper communication can cause work to be thrown away and time to be wasted. And yet, When you make the process more brittle, the process itself tends to fight against change and agility. And change is good, even when it causes previous work to be thrown away. Sometimes, especially when it causes previous work to be thrown away. (Cue the masses cheering for throwing bad stuff away.)

We can already hear the objections: “but this is change for change’s sake”? This is the response people give when they don’t agree with the reason for the proposed change or with the change itself. (And honestly, sometimes change for change’s sake is not a terrible thing given our customer’s short attention spans and tendency to get bored.) But that said, if you’re on a team that’s optimized around leadership and trust, then change should be welcomed when it comes from a trusted colleague.

So how do we iterate and make change in a software development process? We call it, the loop.

Think of a big concentric circles, or even better, a spiral, where with each loop we get closer to the center… we get closer to detail and ultimately to reality. At the outside of the spiral we’re just talking and brainstorming. Then we’re sketching on whiteboards. Then we’re drawing wireframes — maybe with little hints about how the software should function in certain cases. In the meantime, maybe we’re experimenting with visual collages to come up with an aesthetic. We narrow it down to one visual direction. Then we’re drawing a set of visual elements that look like user interface elements. We’re experimenting with color. At some point the visual language feels coherent, and the wireframes are telling a story of the software’s interaction. Next, we’re applying the visual language to some subset of the wireframes – they look like real user interface screens. We know how the software will feel. In the meantime, the engineers have started coding. Maybe they’ve focused exclusively on the back end. Or maybe they’ve built the front end based on the wireframes without a visual treatment knowing they’ll apply that on top once it’s done. After all, the wireframes should have accurately defined 90% of the elements on screen even though their presentation isn’t decided yet. By this time, the detailed mockups (visual language applied to the wireframes) and the code are ready to engage in a full on slow dance. Holding each other close, tight, and in rhythm. The coders are now implementing the comps in code. And as time marches forward, and we get closer to sharing that software experience with the world… the software is coming to life. It was in our heads, and now it’s living and breathing and being touched and succeeding and sometimes failing. And we’re tweaking it, and changing it, and pinching here, and tucking there. It’s not quite what we imagined back on the whiteboard, but it’s somehow, even better. Each loop gets clearer, sharper, and has progressively more detail until the code itself is the sharpest picture that can exist of the experience because it IS the experience.

That’s what happens. And when everyone is focused, and excited, it’s like magic.

Celebrate the fact that you’re making software and not a skyscraper. It’s the only reason you get to take shortcuts like this.

And these shortcuts, the things that didn’t happen, in some ways they are the most critical elements to making this work:

• There were no written “specs”. The wireframes and visual design exercise was the closest thing there were to specs. Engineers work directly with user experience designers when there’s not enough detail. Either the engineer has enough experience to fill in any missing details in the right way, or the engineer and the designer work it out on the whiteboard as the engineer codes. There are also no testers complaining about the lack of specs. This is because the engineers are writing their own tests. The fewer people that work on a part of the product, the fewer people need to know how it works and what the intentions are for the behavior. We’ve worked on enormous projects where there were detailed specs, meant to be updated with every single change. I’ll tell you now… other than possibly in rare cases in software written for the Defense Department, THIS NEVER HAPPENS. The specs never get updated with every detail. And if they’re off by a little but, they might as well not exist at that point. Dream all you want, it won’t happen.
• Of the spec-like things that were created — wireframes, etc., nobody went back and updated them when changes were made in later stages. Once you agree on a stage that it feels right, the team moves forward. Never backwards. Whatever stage you’re in becomes the spec. And finally, the code is the spec. It’s the living breathing document that dictates reality. Not some piece of paper, or a sketch.
• Everyone understood that in the early loops there were lots of details not covered. And they understood this because they were details that could be determined later. For example: the wireframes DO need to detail the global organization of the app’s functionality and what affordances a user will use to switch between those major areas. But the wireframes DO NOT need to detail what happens when a user types in the wrong password. We know what happens. They get an error. Is there room for improvement in the password error experience? Sometimes. At some point do an engineer and a designer need to collaborate to design and execute that experience? Yes. Can that be done in a sidecar fashion? Yes. You may ask, how do you know which items are important, and which aren’t in terms of when they need to be defined in the process? Well, the worst answer we could give is: experienced software creators just know. A better answer is this: for situations where there are tried and true solutions, for situations where the design is encapsulated in the experience and doesn’t affect a bunch of other areas, for situations where we’re not trying to make this a signature moment of the experience: for these situations, they can probably be deferred to later in the process without much of a ripple effect. We’re sorry this answer is so vague. But those of you who’ve made software before know this.

But the big question is why? Why do are the above elements NOT part of the iterative process?

The race to create a great user experience, to have a team be in sync about creating something wonderful and define the right details at the right point in the process is a delicate balance. We don’t live in a world of unlimited resources. (And even if we did it would only paralyze us from making anything anyway.) We also don’t live in a world where people love debating tiny details that should be trusted to small groups. We live in a world where these projects need to exist in a reasonable time frame with quality and distinctiveness. And you must eliminate some of these brittle and constraining tendencies in large project software development in order to make something great. Otherwise you end up with something mediocre delivered in twice the time. And nobody wants that. Not even the government.

Less is more.

Everyone says this. It’s now a cliche. OK. But it bears repeating, and understanding.

One of the secret advantages of making software in these modern times is the ability to ship that software to real customers early and often. Those users are a treasure trove of explicit and implicit feedback helping you find your way through the opaque box that is the software product development process. You can listen to their compliments and complaints as well as watch how they actually do and don’t use the product. And you get to constantly refine your plans as a result.

But… there is one thing that can get in your way — not shipping often enough. Not shipping is kryptonite to making customer feedback a regular part of your process. We often say that constraints force creativity. Constraints also force clarity.

“I didn’t have time to write a short letter, so I wrote a long one instead.” –Mark Twain

Your job as the product design leader is the find the one thing — the single thing your product needs to do well. Some people call it the minimal viable product. Some people call it your main scenario. Call it what you like, but it is the one thing you will deliver in v1. And within that scenario you will further constrain your investment to the fewest components that make your delivery distinctive.

It is common for technology product professionals to fret over not having enough features. “If features 1-3 don’t get everyone excited, shouldn’t we add features 4 and 5?” It’s human nature to want to maximize your chances for success. The thinking goes as follows: the more stuff you put in there, the more opportunity you have to resonate with a customer. But this model breaks down quickly. Think of the delicious and unassuming pizza. Let’s keep it simple and just put pepperoni on it. But what about people who don’t like pepperoni? Let’s add anchovies. And for vegetarians? How about pineapple! Do we need to ask how many people will want a pepperoni/anchovy/pineapple pizza? Some maybe, but not many.

But even worse than turning off your customers with things they don’t need or want is the distraction you provide from the core of what you are. If you’re going to make an incredible pizza — certainly a crowded market — you better make sure your simple cheese pizza is out of this world. No toppings necessary to make it clear that your pizza beats every other pizzeria in town. If you can’t create that baseline and make an impression, then you’ve already failed and no amount of toppings will save the day. In fact, the toppings just add confusion and distraction from your identity and your core value.

And let’s say that your base pizza was in fact amazing, but your anchovies were subpar. The more complexity you added to your pizza, the harder it is to discern what people liked and didn’t like. While the anchovies were the issue we might think it was the pepperoni, or the pineapple, the sauce, the cheese, the crust, etc. Teasing apart the whys and wherefores of customers’ negative (and positive) reactions can be challenging. The simpler you keep it the better.

And finally, what if you had to invest in a new slicer to get your pepperoni just the right thickness, but it turns out that your customers don’t like pepperoni. (Unlikely we know, but go with it.) Turns out you didn’t just cloud your customers impression of your product, but you now have infrastructure investments and cost sunk into functionality that you really didn’t need in the first place.

Find the one thing. Do it well. And then, with each successive release you get to add little bits here and there and see how customers respond. Maybe this week we’ll do a sausage special. If it sells well, maybe we’ll incorporate it into the permanent rotation. If the sausage required special infrastructure, maybe we’ll do it manually to start because we’re not sure it’s gonna be a hit. Once it’s a hit we can invest in the special sausage-making equipment. You get the idea.

In addition to learning about delivering less to your customers you’ve now also learned a bonus lesson: pizza analogies are almost always useful in illustrating important concepts.

One thing you constantly need to concern yourself with as a User Experience Designer is the “cognitive load” at every point in your experience. “Cognitive Load” is a fancy term for how much thinking the user has to do to parse through all the crap you’ve jammed onto the screen in front of them. “Less is more” is a cliche but that doesn’t make it any less true in this case. We often think we’re helping the user by putting more options at their finger tips. But our brains are constantly skimming what’s in front of us trying to find the one thing we need. The more there is to skim, the harder it is to find the one thing you want.

Now this is easier said than done because how do we figure out what to show and what to hide? Our best avenue here is to try and understand what the user does most of the time in this place. Show that one thing, and mercilessly bury everything else. But even if you’ve won that battle, how do you expose the items you just hid? If you’re designing software for devices with pointers – mice and trackpads, then your best friend is “hover”. Move that cursor around the screen and whatever you hover over has a little doodad that shows up inviting you to discover more about what that object can do. Macs and PCs have right-click (or contextual) menus. Those are really fantastic as they require no affordance at all on the screen. They have a universal entry point right on the mouse. But right click menus are used by a stubbornly smallish percentage of your users. So unfortunately they don’t really solve the problem universally. And even worse, putting the little doodad on the screen when you hover is becoming less and less possible… why? Touch screen devices have no hover state.

Touch interfaces are wonderful. Touch something and do it. Manipulate it with your actual fingers without the inconvenient intermediary of a trackpad, except… the touch screen has no idea where your finger is until it touches the screen. And by that time, you’ve “clicked” or in the parlance of the new UIs – “tapped”. Now, one might argue that some clever engineers will make use of that front facing camera on your phone or tablet, sense where your finger is and reintroduce the “hover” concept back into the UI and we’ll be all set. And to be honest, the engineers don’t even have to be all that clever. This has been done. There were tablets with pens that had a hover state. Move your pen tip around the interface without actually touching the screen and the cursor goes with you. Press down on the screen and you’ve “clicked”. Another variation has touching the screen turning into one big hover state and pressing the pen down (or the screen itself clicks in the case of finger use) and you’ve “clicked”. We’ve tried all these, and with love and respect to the people that have tried this, they all suck. None of these options will become mainstream user interface metaphors. And if they do, our claim is that they shouldn’t.

So what are our options in the touch universe for hiding those commands that we need handy but would like to remain out of the way?

• Litter the screen with doodads. This is not a great choice, but it can do the trick. If your screen doesn’t have that many affordances in the first place, adding tasteful, subdued little glyphs throughout that the user can tap on to reveal more options is a respectable choice. Of course, visual design is your friend here to make the doodads as innocuous as possible.
• A variation on the above option is the master doodad. On first use you show all the doodads along with an overlay showing that the way to turn them on is using a master doodad that’s always available on screen. It’s a little indirect, but if you’ve got lots of stuff to hide, and can use the master mode switcher consistently it may not be a terrible approach.
• Scroll margins. The folks at Twitter realized that people would instinctively drag scroll their list of tweets to reveal tweets above the latest. And that’s exactly where they put their “Refresh” command. Just pull the list downwards and it reveals the refresh functionality. This is a really sweet bit of user interface design and a happy confluence of factors. The UI is hidden, but shows up as a result of what users will do instinctively without being taught. This is a great approach if the stars align, but often they don’t.
• Tap and hold. This is the leading candidate right now to replace the right-click button on the mouse. It’s not awful, but it doesn’t feel smooth in the pantheon of all the other touch gestures you use.

One more candidate for exploration is pinch and zoom. This is the gesture that Apple brought to the world to scale photographs on your tiny phone screen. Pinch and zoom reveals more or less of the photograph depending on which action you’re taking. It’s pretty straight forward. Everyone knows it. What if you could pinch and zoom on other objects, not just photographs. We admit, it’s a leap, but we’re in favor of trying a world where pinch and zoom is a standard gesture users use to discover what’s “in” any object they see on the screen. Perhaps it will be too obscure and be relegated to the hall of underused power user functionality, but we think there’s a shot. Especially. if a really popular app tries it.

In the meantime, the options above will have to suffice for now.

Mainly though, even though on touch screens the options aren’t superlative to hide affordances, burying rarely used functionality is still a key technique to lighten that cognitive load on your user. And that makes everyone happy.