Breadcrumbs: where you are or where you've been?

I had an interesting discussion with a colleague about breadcrumbs recently. He was doing some work on design patterns and the issue of breadcrumbs came up. The initial pattern proposal basically mirrored Jakob Nielson's recent article on breadcrumbs. In other words, breadcrumbs should show where a user is in the navigation rather than showing them where they've been. As Nielson puts it, "Breadcrumbs should show the site hierarchy, not the user's history."

Of course, the obvious problem with this is that many sites are not hierarchical. So Nielson immediately follows up the statement above by saying, "For non-hierarchical sites, breadcrumbs are useful only if you can find a way to show the current page's relation to more abstract or general concepts." Further proof that confidence is often more persuasive than knowledge, I suppose.

The interesting question from my point of view was whether Nielson's pithy, unambiguous guidance applied to web applications. In most web applications, users don't navigate directly to sub-pages in the application (one of the primary benefits to hierarchical breadcrumbs, according to Nielson) , applications are often not hierarchical (for example, they include tasks), they discourage the use of the browser Back button (which Nielson think removes the need for history), and there are often omnipresent navigation panes that assist users in understanding where there are in the object hierarchy.

For example, let's say I'm in the process of performing a multi-step process like checking out of an online store. As part of this process, the application provides the option to leave the main task path to perform other actions (like creating a profile). How would a hierarchical breadcrumb trail work in this case? Not at all, as far as I can tell. If the user chooses to leave the profile creation task and return to the checkout process, should they use the Back button? Perhaps, but provided a breadcrumb trail that allows the application to handle the move has obvious benefits.

Perhaps breadcrumb patterns are more complicated than they first appear.

Blaming developers for usability problems

I'm sure there are plenty of situations where a developer makes a design decision without the proper skill/knowledge/thought/information and the decision worsens the usability of the product. It probably happens all the time. But to be honest, I think way too much attention is focused on solving this problem. In books and articles I read, there is often a sometimes unstated assumption that if we could just get developers to understand the fundamentals of design a bit better, they could make better decisions and usability would dramatically improve. I don't buy it.

The developers I work with are smart, conscientious people with a decent working knowledge of design... at least good enough to recognize design problems, but perhaps not solve them. They want to do the right thing. They appreciate that usability is important. And they take pride in the quality of their work. The problem is that good design is often harder to contain than bad design. Not always, but often. And developers have VERY strong incentives in place to make their code deadlines. So they are put into a position where they can either miss their deadline to do the better design or they can make their deadline to do the worse design... and all the external incentives say to choose the latter.

And this isn't always the wrong choice. Features DO matter, and spending extra time on design lessens the number of features you can do. Clearly, there's a balance.

But I tire of this assumption that bad design happens out of ignorance, especially the ignorance of developers. I think that's the exception to the rule.

Book review:"designing the obvious" by Robert Hoekman, Jr.

I recently finished Robert Hoekman's new book, "designing the obvious: a common sense approach to web application design". I enjoyed the book and thought that Hoekman had some good insights into what it means to produce quality design, though I also had some disagreements and found some of his advice to be of limited value in the domain of enterprise software.

One of the things that liked best was the section on "understanding users". This has long been a pet peeve of mine -- while obviously good designers needs to understand their users, I've often felt that running usability tests on design were of limited value. And I think the issue is that we often ask the wrong questions. Hoekman has a great summary of this problem:

For example, if I were designing and building an application used to track sales trends for the Sales department in my own company, my first instinct... would be to hunt down Molly from Sales and ask her what she would like the application to do. Tell me, Molly, how should the Sales Trends Odometer display the data you need?

I would never ask my father the same type of question. My father knows next to nothing about how Web sites are built, what complicated technologies lie lurking beneath the pretty graphics, or the finer points of information architecture. He wouldn't even be able to pick a web application out of a lineup, because he doesn't understand what I mean by the word application...

What my father does know is that the model rockets he builds for fun on weekends require parts that he has to hunt down on a regular basis... If I told my dad he could buy these parts online, he'd be interested. If I asked him how the application should filter the online catalog and allow him to make purchases, he'd look at me like I was nuts.

Molly from Sales would likely do the same thing.

Molly has no idea what your software might be able to do, and she almost certainly doesn't have the technical chops to explain it.

I think this is a great point. We need to understand our users and we need to understand how they use the product (or use our proposed new designs), but we should not be asking them to design our product. We're the professional software designers - we shouldn't abdicate our responsibilities onto the user. It's nice to see Hoekman saying that in print.

I also liked what Hoekman had to say about turning beginners into intermediates. Basically, the biggest proportion of most products' user base is the "perpetual intermediate". Someone who has learned just enough to get by, and has no plans to ever learn more. One of our goals is to help beginners reach this stage. WAS does quite a bit in this space, perhaps most notably in our "Command Assist" functionality in the console, which allows people to transition easily from using the console to using scripting.

The only major problem I had with the book, and it's not all that major, is that it was written with an assumption that bad design happens out of ignorance for many of the principles he is espousing. That people are not doing things the right way because they don't know the difference between the right way and the wrong way. Clearly, this is sometimes true, but I think it's the exception to the rule (at least it is the exception when there are professional usability people involved in the project... and the audience for the book seems to be professional usability people). The simple fact is that there is a cost associated with improving the design of a feature or a product. Designing things well takes more time and people. It usually means that the system is taking on more of the complexity from the user, which requires more coding and testing. Everyone wants good design, but when push comes to shove, I think many of our customers would admit that if better design means fewer features and longer time to market... well, it's not a no-brainer that better design should win the day. It's a balance. Sometimes better design is the right answer, and sometimes time-to-market pressures are too important to lengthen the release cycle to include an expensive, iterative design phase. Being able to tell the difference between those cases is the trick, and not an easy one. But the point is that the "obvious" design techniques that Hoekman discusses are already common design techniques in most shops... when there's time to do them.

But overall I thought it was an excellent book, especially for people who are trying to go from beginner to intermediate in their design skills. It's well-written and engaging, and that counts for a lot.

Is simplicity a valid goal?

There's been an interesting discussion happening within the online user experience community recently on the virtues of simplicity (or lack thereof). Legendary Don Norman kicked off the debate in an essay titled "Simplicity Is Highly Overrated". Excerpt:

Why is this? Why do we deliberately build things that confuse the people who use them?

Answer: Because the people want the features. Because simplicity is a myth whose time has past, if it ever existed.

Make it simple and people won’t buy. Given a choice, they will take the item that does more. Features win over simplicity, even when people realize that it is accompanied by more complexity. You do it too, I bet. Haven’t you ever compared two products side by side, comparing the features of each, preferring the one that did more? Why shame on you, you are behaving, well, behaving like a normal person.

Basically, Norman's argument is that people say they want simplicity, but when it comes time to make a purchase decision, they go for features.

Joel Spolsky followed up on Norman's essay with some thoughts on his own experiences, specifically that people often confuse simplicity with aesthetics. Excerpt:

Devotees of simplicity will bring up 37signals and the Apple iPod as anecdotal proof that Simple Sells. I would argue that in both these cases, success is a result of a combination of things: building an audience, evangelism, clean and spare design, emotional appeal, aesthetics, fast response time, direct and instant user feedback, program models which correspond to the user model resulting in high usability, and putting the user in control, all of which are features of one sort, in the sense that they are benefits that customers like and pay for, but none of which can really be described as “simplicity.” For example, the iPod has the feature of being beautiful, which the Creative Zen Ultra Nomad Jukebox doesn't have, so I'll take an iPod, please. In the case of the iPod, the way beauty is provided happens to be through a clean and simple design, but it doesn't have to be. The Hummer is aesthetically appealing precisely because it's ugly and complicated.

Not surprisingly, not everyone thinks simplicity is overrated. On Scott Berkun's blog, he provides a defense of simplicity. Excerpt:

It’s easy to confuse success with quality, and both articles discount our secret inability to make satisfying choices. We are attracted to things with more features, that cost less, or come in larger quantities, despite our inner suspicions that we’re likely to complain about those purchases soon after. We date people, eat food, take jobs and buy products for superficial, misguided reasons all the time. We’re easily seduced, and every marketer knows we always have been and always will be.

But we shouldn’t confuse the success of feature-laden crap as a signal for the irrelevance of simplicity any more than the success of Rocky IV and Burger King signaled the irrelevance of good film-making or fine dining. It just means there are gaps between what we need, what we want, and why we buy, and that the masses are by definition less discriminating than the niches of people with refined tastes for a particular thing.

Berkun is basically arguing that there is still a place for simplicity, even if most folks don't give enough thought into their purchases to look for it. He also concludes by saying, "Simple design doesn’t mean brain death: it means being being as simple as necessary to achieve a great experience for a group of people, but no simpler."

When it comes to enterprise software, I think this discussion is even more relevant. Those of us in user experience often here the calls to deliver "simplicity", whether we're working on a small troubleshooting utility or highly available, performance-tuned, enterprise-capable application serving capability. "Make it simple!" we're told. This has long been one of my pet peeves, and the articles above touch on my beliefs, but don't quite capture them. Ironically, in his defense of simplicity, Berkun comes closest to capturing why I think "Make it simple!" is a mistaken goal. I think that saying "...as simple as necessary... but no simpler," is another way of saying "simplicity is NOT the goal."

Let me use an extreme example to make my point. Let's say we could create an application server product tomorrow that is so simple that all it requires is an on/off switch (I believe this can be done through the use of pixie dust). We release it and everyone raves about how simple it is. Until someone tries to use it and asks, "Uh, it was really easy to turn on, but I need a way to actually deploy my application." Well, okay, so we add a button for installing an application. That's not too bad, just one more little button. Still simple... and then someone says, "Great, I have my application running. Now I have an update to the application. What do I do?" Well, we could add another button for updating an existing application, but why bother? The product would be much simpler if we just have the user create a new server and install the new version of their application on it -- then we don't need to add another button!

Obviously, that would be a terrible decision. Why? Because creating a simple product is not the goal. The goal is to create a product that allows users to achieve their goals... and sometimes those goals are complex. Especially when it comes to enterprise software. If a customer has a goal of trying to maintain the value of their legacy systems by creating external services on top of the old systems that can communicate with newer systems, an on/off switch is not what they are looking for.

Obviously, unnecessary complexity is a problem, and IBM needs to do a better job of eliminating unnecessary complexity. But not because simple = good and complex = bad. We need to reduce unnecessary complexity because it interferes with a user's ability to achieve their goals. Simplicity, in and of itself, is not particularly relevant.

Side note: Of course, the challenge for the user experience engineer is that a feature that adds unnecessary complexity for one user is absolutely critical for another, so providing the features necessary to allow users to achieve their goals while also eliminating unnecessary complexity sometimes makes me feel like a circus contortionist. But that's a topic for another day.

Tech Talk with Mom: Explaining what I do

Me: ...as I've explained before, I'm the Lead Architect for User Experience for the WebSphere Foundation.

Mom: That's nice, dear.

Me: Uh, thanks. Basically, I try to improve the usability of software products. Usability and user experience or pretty much the same thing. It's also known as human factors, user-centered design, outside-in design, human-computer interaction, consumability, interaction design, user engineering...

Mom: You engineer users?

Me: Well, no... okay, so that might not be the best term.

Mom: So your job is to make things simple?

Me: Exactly!

Mom: If making things simple is your goal, why do you have twenty different names for what you do?

Me: Have you ever played Whack-a-Mole? It's the same basic idea.

Mom: Uh huh.

Me: Anyway... we have a team of usability professionals who work on IBM WebSphere products to help simplify the design. We have teams of developers who write the code, and we work with them on new features that are going into the product.

Mom: Why can't the developers do their own design?

Me: Well, they can. They do. There are different types of design. First there's the design of the code itself. Developing code is difficult work, they need to figure out the best way to design their code to anticipate future enhancements and extensions, they need the code to perform well, they need their code to work with the other hundred developers in their organization, and so on. On top of this, developers are constantly being asked to pick up new programming models and languages. It's a tough job.

Mom: If you aren't a developer, how do you know how tough it is?

Me: I hang out with developers, and they love to talk about this stuff when they've been drinking. They think it attracts the ladies.

Mom: Does it?

Me: Not so much. Though I've seen the "polymorphism" line work a few times. The point is that developers design the code, but our team focuses on the user interfaces. Developers often are asked to design user interfaces as well, but it's tough for them to do.

Mom: Why?

Me: The biggest problem is probably a conflict of interest. Developers everywhere are under intense pressure to get their code done as fast as possible.

Mom: That's dumb.

Me: Well, not completely. Remember, we're talking about developers here, not normal people. They actually like to write code. They're like kids drawing pictures in kindergarten -- you need to know when to take away their crayons. But more importantly, by definition the developers are intimately knowledgeable about the inner workings of the program, which makes it very difficult for them to put themselves into the head of a user who is just getting started. It's very difficult for people to remember what it's like to not know something.

Mom: So you're saying that your ignorance is actually a job skill?

Me: Exactly!

Mom: Your father will be so proud.

Me: So even though it might seem like a strange system, it's actually setup so that different people have different focuses... the developer wants to get the code done on schedule, the usability person wants the design to be simple, the tester wants the code to function reliably, the guy in marketing wants every new requirement in the product by next Tuesday... and then by all of us working together, we try to achieve the right balance between all the competing interests.

Mom: You're not going to start singing Kumbayah again, are you?

Me: Dad says I have a nice singing voice.

Mom: He also thinks Gilligan's Island is the funniest show on TV.

Me: Good point. So... it's tough for developers to focus their attention on creating usable user interfaces while juggling all their other responsibilities as well. But there's another piece to what we do - we test our designs with users before the product ships so we can know that we've done a good job. That way we're able to catch a lot of problems that otherwise wouldn't be noticed until after the product ships. So basically we work as customer advocates, sometimes based on actual customer feedback, sometimes via general customer knowledge, and sometimes by just making sure that the customer needs aren't forgotten in the push to get the products out the door.

Mom: So you're ignorant about the code, and when you don't know how to design something, you just go talk to customers?

Me: Pretty much.

Mom: And they pay you for this?

Me: It's a great job, yeah. But it's not really as easy as it sounds. Even though we're not developers, we need to develop a good technical knowledge about our area if we really want to contribute decent design. Plus there's different design guidelines depending on whether you're designing for a web application, a website, an installed program, an installation process, a command line interface, a scripting interface... and so on. It takes experience to tell the difference between a minor design issue that will be mildly confusing for users and a major design problem that will cause hundreds of support calls. Designing usability sessions so that you get actionable results is a unique skill. And understanding the right balance between customer requirements, usability concerns, marketing needs, schedule pressures... these are things that never get easy. And that's not to mention trying to understand the impact that things like SOA or open-source software or new programming languages will have on the product's usability priorities in the future. See? So that's what I do.

Mom: That's nice, dear.