Inflict bad UX on users you secretly hate

About a year ago at a conference, a programmer came up to me for some advice about an unfortunate user interface he’d built. It was a pretty miserable affair: a combination of displaying too much information and offering too many choices, while at the same time burying the one thing that the user actually wanted to work with. It was full of classic UX – user experience – mistakes and usability problem, and I suggested the usual suspects: go back to user stories, develop some use cases, try to figure out what the users actually need.

That did not go over well. I’d assumed that the programmer was still working on gathering feedback, since he was asking me to look over his design. So I was surprised when he mentioned that it would be difficult to make changes to it, because it had already been rolled out and his users were using it.

That’s when I decided that this was a devious supervillian who secretly hated his users. Or, possibly, just a thoughtless jerk—I couldn’t really decide for certain without seeing his secret lair. (Hint: If he has a secret lair, it’s probably the former.)

My point is that if he did hate his users, then inflicting bad UX on them was a perfect way to make them really miserable.

You can’t just add usability at the end of the project

You’d be surprised at how often programmers are completely unaware that they have serious UX and usability problems. Just a few days ago, someone told me, “Our users are using our software, so we don’t have any usability issues!”

One of my favorite sayings is that there are only a few ways to do something right, but a million ways to do it wrong. Usability is no exception. And one problem with user experience and usability is that it’s not always easy to diagnose UX problems in software that you wrote. Good UX is designed in from the beginning; bad UX can show up at any point along your project.

That’s why an approach that I like for fixing usability problems is to concentrate on the team, not just the software. Here are a few quick questions to ask yourself. If any of these situations sound familiar, you might have usability problems:

  • A user is explaining what he needs you to build. Halfway through a sentence, you stop him and say, “That’s great! I know exactly what you need.”
  • The first thing you did on your new project was start up the form or page designer in an IDE and drag controls onto a window—before talking to any of the users.
  • You’ve gotten halfway thorough a project without knowing the name of anyone outside of the programming team who’s going to use the software.
  • When you deliver the first version of the software for users to test, it’s the first time they’ve seen the GUI.
  • You find out that there’s an entire feature that your users aren’t using… or a feature they don’t even know about.

If any of that sounds familiar—or, even worse, if you’re now pissed off at me because you don’t see what’s wrong with any of those scenarios—then you should definitely consider getting some UX help right now. (I’d offer to help you myself, but I’ve got my hands full with my own projects!)

One of these days I’m going to start an organization called PeTU: Programmers for the Ethical Treatment of Users. We’ll set up a protest outside the office of any development team that inflicts bad usability on their unsuspecting users. For the sake of all our sanity, please stop inflicting bad UI on unsuspecting users! If you don’t, I’ll have to stage an outlandish, somewhat juvenile protest outside your office.

Q&A: How to succeed in business analysis without really trying

Hi everyone! We’re back from a summer break — no, not to go off to some vacation paradise. We were crunching away on our next big O’Reilly release, Head First C#. We’ll post more about it as we get closer to publication which, according to its Amazon page, is due out in just a couple of months.In the meantime, we’ll keep the new posts coming for our regular readers. We love you, readers! And we especially love readers who send us questions, because, as it turns out, Jenny and I get a lot of great questions sent to us. Here’s one we got a few days ago:

Dear Jenny and Andrew,

I’ve been told by a couple of people “business analyst” positions were safe locally in the near future. I found “Applied Software Project Management ” on the internet. I’m currently trying to improve some of my skills, in an effort to re-enter the local job market. I’ve been a developer, programmer, analyst for over twenty years. I love building new software. I know you have a number of books that would be helpful. I’m also reading some of the “Head First” books. Is “Applied Software Project Management” the best place to start to build these skills?

Thank you in advance for your time,

Eric D.
Clemmons, NC USA

Now, this is an especially good question because it lets us plug our first book, Applied Software Project Management. More importantly, it’s a topic that’s near and dear to my heart, since I spent a few years managing a really incredible team of business analysts a while back. I learned an enormous amount from them, and I feel lucky that I can share a little of that with you, too.

Business Analyst

It was near the tail end of the Silicon Alley dot-com days, although I was working at a decidedly non-dot-com company. At the time, I’d already been managing a team of software engineers — developers, architects and the like — for a few years at a New York-based financial software company. I felt a lot like Miles Silverburg on Murphy Brown: a relatively fresh-faced manager with a team of seriously seasoned and talented people who, to be honest, knew a lot more about the job than I did. Luckily, I’m a quick study, and I had some really great people to learn from.

First and foremost, I learned a lot more about what makes a good business analyst. Very few people start out as a business analyst — they usually move into the field from another area. Some of my team members started off as software engineers, others started off on the business side. What they all had in common was a deep understanding of users and how to make sure their needs were met. Throw in a healthy dose of project management knowledge, add a pinch of quality engineering, and top it off with a solid background in software requirements engineering tools and techniques, and you end up with a well-rounded, highly effective business analyst.

So that’s a tall order — and I should know, since I had to hire a whole team of people who fit that bill. I’ve gotten a lot of skepticism over the years from people who don’t believe that you really need someone who has such a broad background. And I’m sure that there are plenty of people with the title “business analyst” who can barely do their jobs… because there are people with every title in every industry who can barely do their jobs. But why does it take so much to be a good business analyst?

Consider what the real job of a business analyst is in a software project. She’s got to talk to users and figure out what their needs are. That’s a tough job, because users have a tricky habit of asking for things that don’t necessarily fit their needs. Time and time again I saw the people on my team tease the real needs out of users who, to be honest, didn’t really understand what they wanted. And that’s a really tough job. It requires some very solid elicitation skills, and a good familiarity with software requirements engineering tools and practices (like this one, this one and this one). Because the other part of the business analyst’s job is taking those needs and turning them into a functional solution that can be implemented in software.

That’s one thing that Jenny and I spend a lot of time talking about in Applied Software Project Management. We go over exactly what it means to construct a functional specification, and how that’s different from designing software. Just as importantly — and this is where a good understanding of quality engineering comes in — you need to make sure the users actually understand that solution, which means holding lots of reviews.

Finally, a good business analyst needs to be able to work with the rest of the engineering team to make sure that those needs and requirements actually get built into software. And that’s where a good understanding of project management comes in. She’ll have to work with the team to make sure they understand everything that needs to be built, and she’ll usually play a big role in the estimation — which means she needs a good understanding of estimation practices [PDF].

So to answer Eric’s original question, where should someone start building skills to get a job as a business analyst? If you looked at any of those links, then it probably won’t surprise you that I’d recommend Applied Software Project Management to anyone who wants to get a head start as a business analyst. I also really like Karl Weigers’ book, Software Requirements (2nd Edition). That book was a huge help to me when I was first learning about requirements engineering. I also learned a lot from Software Requirements Engineering (2nd Edition), a compilation of classic IEEE papers edited by Richard Thayer and Merlin Dorfman — including the classic Jim Rumbaugh paper on use cases, which I consider one of the most important papers ever written about requirements engineering. The best book on use cases that I’ve found is Use Cases: Requirements in Context (2nd Edition) by Daryl Kulak and Eamonn Guiney. When I was hiring business analysts, I would definitely have been pleased with a candidate who was familiar with the concepts in these books.

The Kitchen of the Future

A clear need for a better kitchen

What is it with futuristic kitchens? I swear I’ve seen the same TV segment about the “kitchen of the future” repeated on different channels with different people at least twice a year for the last decade or so.

This wired article seems to have a good description of the generic kitchen of the future:

Kitchen of the future
General Electric

What if your appliances were so smart they took the drudgery out of meal preparation? “Your kitchen can basically be your sous chef,” says Marc Hottenroth, an industrial designer who helped create GE’s concept kitchen. Call home from work and your pantry and fridge – outfitted with RFID readers – will tell you what’s stocked, suggest meal options, and list the ingredients you’ll need to pick up at the grocer. (They’ll also remind you to buy milk when you’re almost out.) Craving a quiche? GE’s kitchen will guide you through assembling one and heat the oven to the optimal temperature. If, say, elderly Aunt Rosa is visiting from Italy and wants to whip up some gnocchi instead, the appliances can display text in larger type … and in Italian. What’s more, GE’s setup redistributes energy (such as using excess oven heat to warm dishwater) to lower power bills. Rather not cook tonight? The kitchen can find a number for pizza delivery.

There you go! It’s got everything. It gives you recipes, tells you what’s in your fridge, and lets you look up phone numbers. All that, and it will remind you to buy milk.

Sounds great! So why does the kitchen of the future rub me the wrong way? And, more importantly, what lessons about building better software can we learn from the kitchen of the future?

Let’s put aside for a moment the fact that it’s pretty unlikely that your elderly Italian aunt Rosa doesn’t already how to make gnocchi. There’s one thing that’s true about every engineered product, whether it’s a stove, software or a slide rule: it’s built to meet someone’s needs. But there’s another thing that’s almost always true: some needs aren’t obvious. And it may just turn out that you’re building a kitchen that doesn’t actually meet real needs that people have.

Here’s an example. A hat seems like a pretty simple product that meets a straightforward need, right? It keeps the sun off your head. But wait a minute… plenty of people wear baseball caps inside, where there’s no sun to protect you from. And they’re not playing baseball. So hats fill another need — they help the wearer feel fashionable. And there are other needs, too. A baseball cap has a visor that’s placed in a way that shields your eyes from the sun, but it also advertises a sports team, and, when adorned with the proper Greek letters and bent in exactly the right way, makes frat boys look cool to other frat boys. Those are all important needs.

What about a toy program that you just threw together in your spare time because you were bored? Does that fill a need? Sure! You needed to kill some time, and it served that need perfectly.

So what does all this have to do with the kitchen of the future?

The perfect kitchen GUI?

Take a minute and have a look at this excerpt from a CNN transcript of a segment about one particular kitchen of the future:

TIM WOODS, VICE PRESIDENT, INTERNET HOME ALLIANCE: This is kind of a nerve center for the entire kitchen. In fact, it’s the nerve center for the home. This is the HP TouchSmart PC. And it’s kind of social computing, right, at its best.

But the idea here is, you put everything in one place at a touch point. There’s a middleware program on this from a company called Exceptional Innovation. And what that did is, it brought all of these elements like lighting and shade control and music, and put them all into one interface. Now, mom does about 80 percent of the input on any family calendar, but she wants the ability for dad to go in there, the kids to go in there, leave notes – do all of these things that really become tools for the family.

Now, I don’t want to knock HP and Exceptional Innovation. I’m sure they worked hard on their software, and I certainly know what it’s like having a product to sell. And they’re following the siren call of the Kitchen of the Future that plenty of people have followed before, and I can’ blame them for that.

But really? Controlling the lights and keeping a family calendar — is a computer really the best way to do that? Most families have a dry-erase board or calendar stuck to the fridge. It meets their planning needs really well. It’s much more Agile. (And, interestingly, it never crashes.) Think about it from a software development perspective: do you want to go through a whole bunch of screens in a touch-screen GUI to get to your calendar? Or do you just want to go scrawl a note with a marker? Which of those seems “heavyweight”? Which seems more agile?

The same goes for controlling the lights and the entertainment center. Most kitchens have a small handful of lights. I’ve yet to find a software interface that works better than a light switch or a dimmer on the wall. Plus, you can find a light switch in the dark when you’re half-asleep and looking for a midnight snack. I’d be surprised if that’s a need that most lighting control software developers realistically considered.

Which brings me to buying milk. Just about every Kitchen of the Future I’ve seen in the past ten years makes a point of being able to tell you that you’re out of milk. (On the video, the computer in the CNN segment showed an image of a Post-It note displaying a hand-written note that read, “Buy milk!” I have the feeling that showing a picture of a Post-It note seems, from a UI perspective, to be an admission of defeat.) Is it a real need? Yes, with the exception of or vegan friends, we do all need to buy milk.

But is it really so hard to figure out when you’re low on milk?And if it is, can we realistically expect the kitchen to know when we’re low on milk? Will we always need to put the milk on a special Lose Weight Exercise sensor? Will I get a false alert when little Kaitlynne or Brandyn puts the milk back on the wrong spot in the fridge? Does it know when my milk’s gone bad, or only if it’s low? It all seems far more complex and error-prone than just having a stack of Post-Its and a marker next to the fridge. The simplest and most convenient solution to the problem is still scrawling “buy milk” on a Post-It and sticking it somewhere obvious.

And that’s my point. When you get down to it, the Kitchen of the Future is available to us today at a reasonable price. Why don’t we all have one? Because it doesn’t meet a need. It’s an Lose Weight Exercise in gold-plating. It’s a solution in search of a problem. And I get it. I’m a programmer at heart, and I love new applications of cool technology significantly more than the next guy. But we won’t find buyers for our products if they don’t fill a need.

And that’s the software lesson to learn here. Make sure your software always meets someone’s needs before you start building it. Because the last thing you want is to put your Kitchen of the Future out there, only to discover that the world’s just not ready for it yet.