Layoffs

The news this week was that IBM laid off 5000 workers in the US. Some take-aways for me:

• No matter how strong you are, you can't be stronger than your customers. IBM looked at the numbers and said we need to be leaner in the coming year. Anyone watching the news could have seen that coming.
• When you work for a good company, good people get laid off. Why? Because there aren't any bad people to lay off. Those of us who kept our jobs need to reflect on that with a bit of humility.
  
• In a bad economy, avoid specialist roles like "special adviser" or "ombudsman." If you're out there all alone on an org chart, well, it's as good as wearing a target. Avoid being an infrastructure person; try to be writing words someone is ultimately paying for (i.e., user-facing doc).

I got some insight from our director about how this sort of thing works. I'd seen it from the inside before, but his clarity gave me fresh insight.

It starts at high-level management as a dollar amount. "Our income and our burn rate are misaligned by this much, therefore we need to cut x dollars." Payroll is the deepest pocket, so that's where you have to go if x is a big number. Then middle managers do some calculations and x dollars is translated into y headcount. From then on, y becomes "the number." Lower level managers divvy up y among even lower level managers until some sub-component of y is communicated to a line manager who must convert that number into names, that is, actual people who have to figure out how to make mortgages and buy food.

It's a cold calculus and a heartbreaking one that gets more so as the process trickles lower and lower. It probably works because the ones at the top who have to start the ball rolling are insulated from the humanity where the ball lands.

So if you lose your job, take some solace in the coldness; it was never about you and it wasn't because of anything you did. If you keep your job, it doesn't mean you are better than those who didn't, just luckier, perhaps.

May we all be lucky.

Because I said so

A colleague sent me a link to a blog by someone leaving Google. The person joined Google seven years after it had been founded as its "first visual designer." He refers to himself as a "classically trained designer" and contrasts that to the other designers at Google, who had backgrounds in CS and HCI.

It reminded me why I have trouble working with visual designers. I deconstruct his blog to be saying, "It got frustrating not getting my way on the merits of my stated, expert opinion, but having to actually justify and convince non-classically trained people--often being asked to justify my decisions with USER DATA (how pedestrian!)."

I think technical communicators are grounded more in the social sciences and rely less on the kind of connoisseurship I find with visual designers. For example, I'm involved in fewer and fewer discussion where someone says "It just doesn't sound right to my ear." In most discussions I have with technical communicators, they have reasons and research to back up why this combination of words is more suitable than another combination.

Not that I don't work with visual designers who do the same. It's just that with visual designers I'm more likely to encounter the "because I have taste and you don't" rebuttal. (I have yet to get a good explanation for why Comic Sans is a bad font.)

Imagine going into engineering meetings and justifying my suggested changes to the UI labels by saying, "Because I am a classically trained technical communicator." Like THAT'S going to work.

My point is that I'm glad it doesn't work. I don't mind basing my decisions on principles and research that can be empirically validated. It's part of what makes me a professional.

Progressive User Adoption

I have a new column out in UXmatters.com on progressive user adoption. It is based on an article I wrote for the Cutter IT Journal. It shows how technical communicators can expand the value they add to their companies by increasing user adoption within their current user base.

I think it is a good example of how we can restate our value proposition in terms of our sponsors' business models, a theme I harp on a lot in this down economy.

Value

I'm working on a number of fronts around the issue of Value, as in the value of my profession to my company, the value of my department to my division, my value to my department, the value of STC to my profession, etc. A couple of aha! moments for me:

• Good organizations are not cutting stupid programs or laying off poor performers in the face of this economy! Good organizations have already cut their stupid programs and gotten rid of their poor performers. All that's left to cut are good programs and good people, so the rebuttal "We can't cut this program or this position because [however 'they're good' translates]" doesn't mean anything.
• We need to quit talking about mission and vision and talk only about deliverables and value here for awhile. What do I produce and how does it add value; what do we produce and how does it add value?
• We need to articulate how we assess the value [it] adds.
• We then make that assessment the litmus test for every initiative.
  

UAX

I was recently contacted at work to be a member of the "Next Generation User Assistance Experience Council." The person setting up the group was somewhat apologetic over its long title, but I loved it. I thought it told a compelling story. In setting up a folder to start collecting files and such, I named it "Next Gen UAX."

UAX, I like that! UAX carves out a special niche for us in the UX world. I also think it sets up some interesting discussions about what would constitute UAX as a discipline or practice that would be different from just talking about user assistance.

First, I think there are two dimensions along which to view UAX, each with its own set of implications and requirements.

• UAX encompasses how the content of the user assistance supports the user experience with the product the UA supports. Along this dimension we would discuss the usefulness of the UA.
• UAX also encompasses the user experience manipulating the UA delivery channels with things such as navigation, linking, interactions, affordances, pliancy, etc. Along this dimension we discuss the usability of the UA.

So the mantra of a UAX approach is to provide information that is useful in a way that is usable. Ingrained in this approach is a user-centric task analysis that identifies task- or goal-oriented information requirements and the design of a delivery mechanism that optimizes access to that information on an as-needed basis. It also requires an evaluation methodology that looks at how useful the information was to the user and how easily was the user able to access it.

I know this is not a big departure for most of us, but I do think that linking user, assistance, and experience into one semantic unit does shift the perspective in a significant way. It moves us further from being merely writers and more to being developers of information delivery applications. It moves us from looking at Help as a codified body of knowledge about the product as a whole and more as a collection of interventions targeted at specific moments of opportunities and points of pain. We will worry less about "Is this presentation consistent with one the user might have seen elsewhere in the Help" and more about "Does it meet the likely need of someone in this task on this screen?" We will worry less about "Is this complete" and more about "Is this sufficient?"

So, as of right now, I start relearning my craft under the new classification of User Assistance Experience (UAX) with the driving question of "What's next?"