Managing Product Development

I was shopping today, taking advantage of the summer sales. One of my favorite retailers offers petite sizes online, but almost nothing in the store. I go to the store to try the clothes on and then decide what to order online.

I had a number of blice (blouses to those of you who are not aware of alternative plurals to order, and the nice salesperson who was trying to type my information into the form got frustrated, “I keep putting the wrong data in the wrong boxes.”

“It’s not your fault,” I explained. “The developers should have sat with someone in a store to see what it’s like to input the data when you’re interrupted and holding onto clothes, and all the things that happen when you’re on the floor and not in a back room.” She then explained that the form was the same whether you were online or in the store. But the problem is the data available online is different from the data available in the store.

I don’t know if the developers were lazy, or pressured, or if it just didn’t occur to them to test the system with a real user. But a salesperson should never have to apologize to me about the lack of user interface keeping me at the store longer than it should have. It wasn’t her fault.

User experience design and implementation is difficult. But why make it more difficult by not getting feedback from the users? I’ll never understand.

I’ve been traveling a lot this summer, and I saw bad requirements exposed while waiting for my turn at the kiosk. If you buy an e-ticket, you can walk up to a computer, called a kiosk, insert a major credit card, and check in. No one calls you. You have to know the computer is called a kiosk (which is not the same as a mall kiosk). You have to know that you’re limited to 2 bags, that you need an id (ok, I’m not sure how people missed this), and a whole bunch of other stuff. Lots of people travel in the summer who fly once every few months or every few years. They don’t know what they’re supposed to do.

While I was in line, the first people were happily waiting to be called to the people behind the counter. The people behind the counter were talking, waiting for people to come to the kiosks. I was too far away to be helpful — even I don’t think it’s helpful to yell across 20-30 feet, “Go use a machine!” Even if I’d yelled it, the people would not have known what to do. Finally, someone had pity on all of us in line, and explained that the people in line had to walk up to a machine.

Even when these folks moved to a machine, they didn’t look at the machine to see the terse instructions — instructions you can understand if you’ve use a kiosk before, but not if you haven’t. (Kiosks started about 6-9 months ago? and when the airlines started using them, they had helpful people standing around explaining how to use them.) These folks still thought they were going to be waited on — like the last time they flew.

I think the kiosks are too hard to use for a new traveler — they automate what a counter person does, not what a traveler does — but once you’ve used one, the rest are similar. But, here’s a perfect example of not thinking about the consequences of changing how travelers check in. Sure, the airlines had plenty of helpful people when they introduced the kiosks, but they don’t now. E-tickets don’t say how to use the machines. You already have to know how these things work to use them successfully. I’m allowing more time at the airport these days, to accomodate the people who just don’t know. (And to accomodate the people who refuse to take off their shoes in the security line.)

What have you changed in your product? If you have non-frequent users, do they know what to do? Do your users know how to use your product — especially now that it’s changed? Make it a conscious decision to change things, and then decide how you’ll educate your users.

I’ve been thinking more about requirements. In the most recent two assessments I’ve done, both organizations have been stuck on thinking they could define their requirements before design and implementation.

IWBNI (It Would Be Nice If) users could know their requirements early. For small projects (a couple of people, maybe a couple of months) it might even be possible to fully know and define the requirements at the beginning of the project. But I contend it’s not possible for users to fully know their requirements early for any substantive effort.

The nature of software — ephemeral and malleable and not well understood by users until the users see the artifacts — guarantees that as soon as a user sees the system, the user will see the next step in the evolution of the requirements. (If any of you want to help me rewrite that sentence, please do.)

Here’s an example. Fifteen years ago, I bought a light timer for the lights outside the front door. We want the lights to come on when the sun goes down and go off when we’re all in for the evening. It was an electro-mechanical clock timer switch and worked for about ten years. About five years ago it started losing time and the ring around the outside was harder and harder to use, to set the time properly. Finally, I took Mark to Home Depot a couple of weekends ago and said, “Honey, it’s time for a new switch.” I used the don’t-argue-with-the-wife voice, and Mark decided to give in. He picked up a timer with an LCD display and put it in the cart. I picked it up and said, “Oh, no, this has software in it. We don’t need something this complicated.” We discussed it, and he used the don’t-argue-with-the-husband-who’s-going-to-install-it-for-you voice, and I acceded. Well, when he’s right, he’s right. I love the timer. It knows when sunset is, so the lights always come on at sunset. We don’t have to reprogram it every week, or risk the kids coming home to a dark entryway.

I didn’t think I needed the extra features. In fact I was sure I didn’t need them. It wasn’t until I saw how well the timer worked that I realized the extra features were exactly what I wanted. I don’t want to have to reprogram the timer every week during the winter. I don’t want to mess with it at all. But I was sure no product could do what this timer did. But the “extra” features are now part of what I require in a light timer.

I could have taken my own advice about requirements, and asked myself “What attributes of the timer are important to me, as a user?” I would have answered: ease of programming, fewer times of programming, programming override for those gray days. The first two in my list are system attributes, not functionality. Users are notoriously ambiguous about system attributes — not because they want to be, but because they literally don’t know how they want the system to work. The override is partly functionality, and partly an attribute of the system.

System attributes are the most important part of the requirements (some people call these non-functional requirements), and they are the hardest to determine in advance. One of the reasons agile methods work so well is that the user/customer sits with the team and discusses the system attributes constantly. If you’re not using agile methods, plan on iterating on requirements anyway. Especially plan on iterating through the system attributes, and the product cost for those attributes. You won’t know your requirements early, but you’ll learn them as you develop the system. And you’ll develop a product people want to buy.

The only good thing about this current spate of worms and viruses is that the spammers seem to sending less spam. Naively, a few months ago, I bemoaned the state of automated spam filters. Now I wish my mail program (Eudora) and spam filter (SpamSieve) could detect these ridiculous pif files and delete all mail with a pif attachment.

I’ve come to the conclusion that we buy our tools for emotional reasons, not logical reasons. Why else would so many companies and individuals buy an operating system with easily-exploited security holes? It can’t be for logic. Logic dictates that the second or third (or fourth or fifth or…) time the OS was exploited people would move to a new OS. But they haven’t. (Yes, there are options.)

I’m not out to convert everyone to buying my kind of computer (Mac) or OS. We live in a heterogeneous-OS world, and that’s to everyone’s benefit. If I could, I’d make everyone buy anti-virus software when they buy a computer. If I could, I’d make anti-virus software a part of Windows, so it wasn’t an option. It affects me (and huge number of other people) when other people don’t take care of their environments.

When we choose to own computers and connect those computers to the network, we need to take responsibility for our environments. In my town, we’re not allowed to burn leaves in the fall, because of pollution. When we connect computers to the Internet and don’t install the latest security patches and anti-virus software, we’re polluting the Internet. I don’t know what the right consequences are, but allowing people to be naive is no longer acceptable. Allowing companies to ship security-holed software is not acceptable. Allowing the worm-generators or virus-generators to get off with a slap on the wrist is no longer acceptable.

I don’t care what tools you choose to use. Multiple environments create richer environments for each of us. I care when your choices make my tools difficult to use or prevent me from performing my work. Choosing tools is a personal choice. And my obligation when I choose my tools is to act in an environmental-friendly manner. You too.