Fierce at 50, Or, User-Centered Development

What job? What career? I am not an expert. But I have had some great jobs, some truly horrific ones, and am now in a position to sit on my sofa and think. To ask myself, what could I have done differently in my 20’s and 30’s so that at 50 my career would be better than it is? Better for me that is. Me as I am.

It’s an enormous question.

The only way I can address enormous questions is to break them into pieces and go after each piece separately. Take the blue velvet bag of marbles labeled “Career”, throw all the marbles on the floor, and step back. Look at the patterns. The marbles are separate, the glass ones, the metal ones, the cat’s eyes, the blue ones, the rainbows. Then you lay the marbles out again. According to the patterns. Disaggregate. Refactor. Break down. Rebuild. Take that amorphous concept called “Career” and break it into the smallest possible meaningful ideas.

Don’t worry, I have a somewhat less abstract way to explain what I mean. Comes from software design. “Quelle surprise,” as my mother would say. There’s a practice known as User-Centered Development. The theory is that if you want to design good business software, although it’s important to outline the General Manager’s goals, i.e. how much revenue she wants to bring in and what sort of costs she wants to reduce, most importantly you have to tell the story of the User and what task she is automating with the software. You have to break the User’s tasks down into her actual movements, thoughts, and needs. Throw those marbles right down on the floor.

For software, here’s a pretend example of a User Story to build call center software (real ones are much more detailed), “The User sits at her desk in a large room with 25 other customer service agents. She is drinking coffee and talking to her friend at the next desk. A call is forwarded to her from the central exchange. When she answers the phone the customers ask her questions such as, “How much is my bill…when did I pay last…can you apply my credit card to this bill…do you have my credit card number on file?” This story is very different than design begun by saying, “We need a drop down menu on the right hand side and then when you mouse over a button it turns yellow and the headers are all blue.” And of course even in User-Centered Development you need to define the General Manager’s goals very precisely, ROI, new customers accrued, market share, clicks, eyeballs, upticks, down dogs. Well no, but you get my drift. After all, it’s the GM who pays the bills.

The problem in designing good software is that frequently the goals of the User and the General Manager conflict. The User would like to be sitting on a sofa, with a laptop, drinking coffee and talking to her friends. She wants to spend time with each customer because she actually thinks her job is customer service. As in providing service to the customer. The General Manager would like the User to be isolated in a virtual cubicle, or at least with headset on, taking call after call after call. Because the GM thinks the job is reducing cost of product support. But you won’t know if these goals conflict, if the tasks are not aligned, until you tell the stories. People like to live a large portion of their lives, particularly while working, in denial. They like to say what they want to be true, rather than what is true.

In terms of your career, you are both the User, and the General Manager. Your goals, too, will most likely conflict. You too will try to find a job by specifying that it be blue and has a drop down window in the corner and turns yellow when you mouse over it. And your User may rebel. They do, you know, generally in a quiet but devastating manner. Or your General Manager may want to fire everyone. Except you are everyone. You can train yourself. You can manage yourself. But it’s pretty hard to fire yourself.

And no, I’m not finished yet.