Complex is better than simplistic

Courtesy of Joe Lamantia, I found Dan Ward's "The Simplicity Cycle". It's a quick read, it's free, and it's insightful... all good things. It basically centers around the graph to the right, which represents a product lifecycle.

The idea is that you start in the lower left hand corner, which is "simplistic" in the sense that it's simple because it doesn't do much. As new features get added, complexity increases but so does "goodness" because the user can do more stuff.

But then at some point you reach the middle of the graph and things get interesting. It's basically the complexity "tipping point", because now when you add more stuff (a.k.a. complexity), goodness starts to go down because users are unable to consume the additional complexity. The only way to increase goodness at this point is to decrease complexity.

That's the gist. I recommend reading the whole thing to get the details.

I like this for a couple reasons. First is that it suggests that complexity is not inherently bad. I couldn't agree more with this. Designers who think "simplicity" is the goal of design live in a different world than I do. I also like that Ward uses the term "unnecessary complexity", which is a favorite phrase of mine. Just because complexity isn't inherently bad doesn't mean that there isn't plenty of unnecessary complexity in most software.

I also like that it helps answer the question, "Hey, my product is complex AND successful, so why should I worry about design?" There's a limit to how many features you can add to a product before they become self-defeating. When your customers start to request features that are already in your product, it's a safe bet that adding even more features is going to be trouble.

So I think the graph represents a very useful concept, and makes it easy to understand.

Of course, like most concepts, if we starting poking on it we can find limitations. For example:

• Most products have problems with unnecessary complexity, and that is NOT what the complexity axis is measuring - but I would fear someone walking away from the graph thinking that complexity in general is not something to worry about until you get to the middle of the graph.
• Ward points out that reaching the bottom right of the graph is not the end of the story. The curve just starts back up again. But in reality, what happens is that different parts of a product are probably following their own paths - some in simplify mode and some in add feature mode, so a single line doesn't really represent a whole product.
• The place where complexity becomes too much is different for different users (and sometimes radically different). So the graph is really representing the perspective of one user group.
  

But these are just nits, because I think Ward's goal was to use the graph to present the concept, not to create a formal process or an accurate depiction of every variation under the sun. And it does a good job at that... the concept is useful and the book introduces it quickly and easily.

iPhone user experience presentation

Courtesy of Usability News, I found this slideshow about user experience created by the team that helped design the iPhone. This is nothing new to UX practitioners, but it might be useful when selling UX to stakeholders.

UX Roadblock #17: Development tools and frameworks

In every software release, there are always resource constraints. It's an immutable fact of life, like the sun rising in the east or your toast falling butter side down. There's not a lot of value in complaining about it... and pretending that your work should be done without regard to resource constraints or ship dates will lower your credibility.

However, even if we accept that resource constraints are a fact of life, it still can be the case that these constraints are inappropriately impacting the user experience. In other words, resource constraints are an issue for everyone in every discipline, but sometimes the impact on one area is out of whack with what other areas are facing. One way in which this can happen to user experience is via bad development tooling and frameworks.

Development tools and frameworks are intended to make developers more productive. When done poorly, they can create a situation where developers are more productive if they follow a single path, but any deviation from that path results in a huge development effort. And deviating from that path is often requested by the UX team. This can result in mind-boggling conversations like, "Sorry, I can't change the label on that button... the framework is giving me the label, and I would need to custom code the entire page to change it." The trick is to recognize when a developer is feeding you a line of crap to avoid extra work versus when there really is a tools/framework issue. Or both!

As an aside, one area where I've repeatedly seen this issue is in the area of product installation tooling. These try to make things easier by giving the developers a bunch of common install functions for free. But it's often an all or nothing proposition... you either use the common function EXACTLY or you have to start from scratch. So there's a resource cliff. A minor design change creates a huge impact on the development sizing. So as a designer you get stuck with accepting a bunch of minor irritating behaviors because none of them individually are worth throwing out the free behavior.

As with most roadblocks, we UXers often have to live with them rather than remove them. Removing the roadblock in this case obviously means choosing new tools or creating better frameworks. Sounds good, and worth fighting for, but that doesn't happen overnight. In the meantime, what can we do to detour around the roadblock? Here's my advice:

1. Learn everything you can about the tools and framework so that you know exactly when you are designing something that will force extra effort. Don't rely on the developers to tell you.
   
2. Only design "outside the framework" when it matters. This builds on #1. If you ignore the framework when doing the design, you'll run into situations where you are deviating from the framework randomly, out of ignorance, which causes unnecessary battles with development or forces developers to spend their time on things you don't really care about. When you deviate from the framework, make it count.
3. Build an expectation into the development sizing effort that deviating from the framework is normal. This builds on #1 and #2 - they give you credibility so developers know that you aren't being a hardass for no reason. You want to avoid a situation where any deviation from the framework is considered "extra" work that needs to be separately contained. Assume there will be some deviation upfront, and size accordingly. This is also the key to removing the roadblock altogether - the cost of sticking to the framework needs to be exposed via the sizings.

When good design means bad usability

I ran into an interesting usability issue recently. I was trying to cancel some magazine subscriptions through the Magazine Service Center. The Magazine Service Center is basically a scam, though a legal one. Their business model is basically to give people free subscriptions to magazines, then automatically start charging for them after a year has passed, and make it as difficult as possible to cancel them.

When you call them to cancel (which of course can't be done online), you are never given the option to speak to a human. After navigating through the list of options to get to the cancellation prompts, they won't give you a list of magazines that you are currently subscribed to. You have to say what magazine you want to cancel, then they repeat it back to you, but the response comes back garbled so that you're not sure whether it's right. I said, "National Geographic Explorer" and they responded, "You said, 'Fghwhpfft', press one if that is correct". I tried this several times with the same unintelligible response before just assuming they'd figure it out and moving on.

Then the fun really starts. They say they want to "confirm" you decision to cancel. They say that you still have a few weeks left on your subscriptions. There's a fee for canceling. If you don't cancel now, they'll waive the fee. And they ask you to confirm that you want the fee canceled. In other words, to confirm that you want the magazine canceled, you have to respond "NO". When you select "No", they go through it again, to "make sure they understand", and you once again need to select "No" to confirm the cancellation of Fghwhpfft.

So the question is: Is this bad design? It's completely unusable. But it's completely unusable on purpose. It's completely unusable in order to meet their business goals. And, to be honest, it's unusable in clever ways, not by accident. Someone spent a fair amount of time and thought to design the system in a way that maximized the user's failure rate.

Of course, this brings up ethical issues. I doubt many UXers have to make these types of decisions - choosing between good usability and good business. Fortunately, the two are almost always aligned. But in subtle ways, I think it does appear. Such as how easy should it be to migrate from your product to another vendor's product? Users want to avoid vendor lock. Business goals don't always agree.

I'm trying to think of other examples, but I'm drawing a blank.

I've been out of grad school for 12 years....

... and out of undergrad for 17 years.

So isn't it about time that I stopped having these "Omigosh! The final exam is today and I forgot to attend class all semester!" stress dreams? My subconscious is stuck in the early '90s.

Maybe if I updated my music collection with some post-1995 tunes it would help.

Nah, too risky.

Life without mouse clicking

A colleague forwarded this link to me - http://www.dontclick.it/


It's a browser interface that completely removes the need to click the mouse button.

I'm not sure that there's a problem worth solving here, but it's an interesting exercise.

Unsuccessfully buying a laptop at Best Buy

My wife needs a new laptop. We went to Best Buy. We found the laptop we wanted, with all the right stuff on it, at a price that we felt was reasonable. Just one minor issue. Like most laptops, this one idiotically had 1 Gig of RAM to run Vista Home Premium, so we needed to upgrade it to 2 Gig.

Me: "How much is a Gig of RAM for this laptop?"

Best Buy Employee: "About $120."

Me: "Sounds good. We'd like to get this laptop, but we want to upgrade from 1 Gig to 2 Gig."

BBE: "Okay, that'll be an extra $240."

(pause)

Me: "Uh, sorry... I just need 1 extra Gig of memory. That's $120."

BBE: "No, the laptop has 2 memory slots. Right now it has two 512MB memory cards in them, so you'll need to buy two 1 Gig memory cards to get to 2 Gig."

Me: "Riiiight... but I don't need the two 512s, which cost $120, so it's still only a $120 difference."

BBE: "No, you're buying the laptop as is, so the two 512s are your's, and to upgrade you need to buy the two 1 Gigs for $240."

Me: "And then I just throw away the two 512s?"

BBE: *shrugs*

Me: "You do understand that you've just lost this sale, right?"

BBE: *shrugs*

Always one year removed from incompetence

As my wife will happily tell you, I have many, many faults. For example, I am incapable of finding the ketchup in the refrigerator. My wife can talk on the phone, make a craft, help the kids with their homework, and watch Oprah at the same time... I can watch a bad movie for two hours and not notice the house is on fire. My fashion sense has not changed or improved since I discovered jeans and t-shirts in second grade.

And I consistently hold my own opinion in higher regard than it deserves.

On the bright side, I eventually recognize that I was an idiot... it just takes about a year. Then I look back in horror at how incompetent I was. This became a yearly rite of passage for me - marveling at my newfound wisdom compared to the previous year. It was nicely validating for awhile, until I started looking ahead and wondering what I was doing now that I'd be embarrassed about next year. Takes all the fun out of feeling superior to... er, myself.

Looking back over my learning curve to date, one thing that strikes me is that in addition to simply learning through mistakes and casual chaos, I've always worked with a team of user experience professionals, and they are the ones who have helped me grow into the proud, just-beyond-incompetent UXer that I am today. I don't think you can overestimate how important that is - UXers who are isolated on development teams are almost doomed to stagnation, IMO. For those folks, the only way to avoid this fate is the virtual UX team on the internet. Bravo to all the UXers who make the net a vibrant community from which to learn.

Which brings me back to my original point - what am I going to learn over the next year that is going to make me feel incompetent now? I'm not sure (if I knew, I'd just go ahead and learn it now), but it's very likely that I'll learn it from someone on the internet. Not in one place on one day... in a hundred blog posts and comments and articles and research, all providing a tiny piece of the puzzle leading to the next minor epiphany.

I'm looking forward to it. In the meantime, I'll just have to make do with what I've learned so far. And ask my wife to find the ketchup for me.

UX Roadblock #48: Sexy Requirements

There are a thousand different ways to manage requirements and plan a release. One of the all too common methods is to make a list of the biggest, most important requirements and rank them from top to bottom based on "customer need". Of course, "customer need" can mean anything from "an executive already promised this to a customer" to "marketing thinks this feature will enable us to get into a new market". If you've been on a team that used this method, you know what happens... people learn that the best way to get your favorite requirement into the product is to make it as big and sexy as possible. Because once you have the ranked list, sizings are done and once the resources run out you've got your list of in-plan requirements. If your requirement isn't near the top, now matter how easy it is to do or how great the ROI is, it won't make it in.

This is a bad method for lots of reasons, but it particularly hurts the user experience. First, the overall user experience is made up of a ton of small interactions, and often the best way to make improvements is to fix a lot of small issues rather than add some groovy new "user experience feature" while leaving the small issues alone. Those small issues add up quickly. But comparing any of the small fixes to one of the big sexy requirements makes the small fix look optional.

Second, this type of process encourages a "feature-centric" view of release planning. The discussion naturally becomes focused on which of two features is the most important... and tends to avoid the discussion of whether either feature is the best way to spend those resources. Making the existing features better gets lost in the mix.

If you are stuck in this situation, you might not have the ability to force a wholesale change to the process (which is what is ultimately needed). If that's the case, here's some pragmatic advice on how to get around this particular roadblock (based on my own experiences):

1. Create a big sexy requirement that is a collection of UX improvements and try to tie the individual improvements into a single theme that will sound good to release management, like "Decrease customer time-to-value through out-of-box-experience improvements". Of course, you'll know that this is really just a bunch of little improvements, but by combining them together by theme you'll be able to better compete against the new feature requirements.
   
2. Work with release management (and product management) to create "buckets" of resources that are dedicated to particular release objectives, then prioritize within the buckets. And, of course, make sure one of the buckets is dedicated to user experience. This is easier than it sounds because (almost) no one thinks user experience is unimportant, and at a theoretical level it's easy to convince folks that some percentage of effort in a release should go towards improving the user experience... the problems arrive when those well-meaning people are forced to choose between a new feature that some customers genuinely want and improving the user experience. By creating separate buckets, it removes that forced choice.
   
3. Partner with the folks who are working on one of the big sexy new features that is likely to make it into plan and persuade them that there are a number of user experience improvements that ought to be tied to the requirement. One reason this technique can be so successful is that adding user experience items to the new feature can make it even more sexy, so the people pushing the new feature are motivated to work with you. The downside to this is that unlike the first two techniques, tying the UX improvements to a new feature constrains your choice of which UX improvements to tackle. You have to pick things that relate to the new feature, however loosely. Of course, if your choice is between getting nothing done versus getting your second or third choice done, it's still an easy decision.

None of these actually removes the roadblock, they just help you get around it.

grokdotcom: Better "usability" isn't always the answer

Howard Kaplan over at grokdotcom has posted a little rant about usability. For example:

About a month ago, I had the opportunity to speak to a group of Usability professionals. The theme of my talk was getting them to raise the bar within their industry; to become true advocates for consumers like they should be. Yes, consumers, not "users". B2B, b2C, self-service, e-commerce, video, web2.0, no matter the focus of your site, or whether a nickel changes hands, your audience consumes the content you provide and engages with the experience you've planned.

And a littler later:

I often challenge people to come up with positive associations with the term user. I'm still waiting for one positive response. Sure, I've heard "Mac user" and even that falls flat given the very real problems with technology — yes, even with Macs — that rear their ugly head at the most inopportune of times.

This is interesting on several levels. First, I find the crusade against the term "user" to be deeply amusing. Howard wants positive associations with the term user? Okay. How about the thousands of times when a usability professional has been in a meeting and said, "We can't do it that way because our users will never figure that out" (or words to that effect). It's an internal industry term that is perfectly useful, and is not in anyway derogatory in the way it is used... quite the opposite. 90% of our job is to treat users with respect... and the other half is to make users happy.

I also find his use of the word "consumer" to be interesting. I would argue that "consumer" is not a synonym for "user". In fact, at IBM we use a term called "consumability", which is not the same as "usability", though there's clear overlap. Consumability is concerned with the front end of user experience. How does a potential customer find out about a product or its features? How easy is it for them to acquire the product? How much does it cost? How easy is it deploy and maintain? How much additional training is needed to be productive? As you'd expect, the is a clear intersection between marketing and user experience in issues of consumability. On the other hand, it's important to remember that in large enterprises the person who chooses to buy a particular product is often not the person who uses the product. Which leads to differences between consumability and usability. For example, price is a good example of something that I would consider critical to consumability but not a factor in usability. Likewise, providing optimizations to increase the productivity of expert users is something that is important to usability but not a factor in consumability.

Later, Howard says:

What brought on this little rant? Our friends across the pond at E-Consultancy came up with a list of their hall of fame "User Experience gurus" based on a survey of their audience. Our esteemed founders, Jeffrey and Bryan, were selected for the list. Flattered as Jeffrey and Bryan were, those who've followed our work over the years know our collective disdain for the casual use of the "guru" label these days.

In case you didn't read Robert's post from last week, where Jeffrey suggests that we marketers need to "get over" ourselves, it should give you some context. A few days later — while, as Jeffrey put it, the woman behind the counter at his local Starbucks still didn't know who he was despite all the publicity – another list came out with an amendment to the E-Consultancy list where both Seth Godin, and Eisenbergs were left off. This new list was created by David Armano, who runs the widely popular Logic + Emotion blog. (If you haven't read David's stuff, his manifesto is what converted me into a regular reader. Although I often disagree with his approach, Logic + Emotion comes highly recommended.)

David's perspective in removing Seth, Jeffrey & Bryan was that they're too much in the marketing camp to be considered "User Experience". My question, though, is this: "Would you prefer to have the experience designed by a top Information Architect but never planned with a deep understanding of the audience's needs? Or would you prefer to plan the experience according to human motivations, then adjust the architecture to match?"

I think you know my answer.

My answer is that it is not an interesting question because both approaches would be broken. I would also say that one of my frustrations is people who think that the "user experience" of a product is the responsibility of the user experience team. It's not. It's everyone's responsibility... including marketing. Just like the "quality" of a product is not the responsibility of the test team. So I fully acknowledge that marketing has a central role in user experience. That doesn't make marketers into user experience professionals though - it's still a different skill set. It's the collaboration between the skill sets (and many others) that creates a good user experience, so trying to figure out which skill set is easiest to drop is not a useful exercise, IMO.

Supporting browser back buttons in web apps

Simple question. If I'm using a wizard in a web application (and the wizard has a Back button) and I click the browser's Back button instead of the Back button supplied by the web application, should the behavior be the identical?

Simple question, but the answer? Ugh.

There's a lot of discussion on this topic on the web, but interestingly the focus of much of the discussion is how to get users to stop using the Back button. Whether it be by providing them with back buttons in the app, adding breadcrumbs, or disabling the back button altogether. This strikes me as quite an odd solution to the problem.

At the same time, there are times when the back button is clearly inappropriate. If I have just finished clicking "Finish" in a wizard and I'm taken to a "Okay, here's what just happened" page, clicking the browser's back button is not a good thing.

But if the web app itself supports a Back button, why should it not also support the browser's Back button? And, if you agree with that, let me ask the next question. Should you be able to click the browser's Forward button and have it work like the "Next" button in the wizard?

My head hurts.