Friday, November 28, 2014

On Not Reinventing a Square Wheel

A couple of months ago, a mess of my content publishing colleagues were unceremoniously let go from their positions at Microsoft. This was just the latest of a painfully extended series of layoffs in the service of “streamlining” the company. Honestly however, the real mess appears to be what's left of their product teams afterwards. Let alone the mess that customers may be faced with in the next release.

See, it's like this... the overarching notion seems to be that in order to “flatten the org” and save money, layers are removed from the management structure. In reality, it's not that the admittedly multitudinous layers of management are thinned out, it's that the people in the trenches, or at the bottom of the totem pole, if you prefer that metaphor, are let go, thus leaving the managers with no one to manage. Voila, a slimmer org.

Right. Well, when you still have a need for writing and editing, but little if any writing and editing staff, then who provides and QA's the content? (Understand that I'm talking about UI text as well as documentation here.) So, it turns out that a corporate subgoal is to give more “ownership” of the product to the program managers. As if they didn't have enough ownership already. Yes, you're correct, I'm saying that the PMs are now to write the content, to “own” the UI. The few writers that remain on staff (who needs editors, anyway?) are relegated to “strategizing,” and only to assist the PMs in actual writerly pursuits “as time allows.”
why not ensure that writers write the most critical info rather than pinch-hit?
It's an... interesting... plan, which is, to say the least, not wholly thought out yet. For starters, there's a lot of “handwaving” about using automated task recorders to, well, record tasks – that is, record clicks in the UI – and then somehow port that output to a text deliverable which is almost ready for prime time. I say “somehow” because the tool and required templates don't exist yet, nor does a team exist for building it.
templates only provide a structure, not the intellectual process that writing demands
And the problem with “almost” is that in reality it will require a lot – a lot – of manual work to turn this output into user-friendly localizable English. Who does that manual work if not writers? By and large, PMs aren't experts in language. Even if English is their native tongue, which these days is often not the case. And then there's PMs' unfamiliarity with corporate style, localization and accessibility and legal requirements, and so on.
will nonexperts even know to ask the right questions?
The funny thing is that this brave new plan hurls the development/UX paradigm back to the Golden Age – er, Dark Ages – when devs and PMs produced all the UI text; User Assistance, as it used to be called, virtually never got a chance to see it, let alone polish it. At best, if they had trouble documenting functionality, they might be able to faintly ameliorate bad UI text with an explanation in Help or perhaps (once they had been invented) a tooltip. The resulting UI, as we know from experience, was all too frequently techy, unhelpful, unlocalizable, and strewn with typos and bad grammar. This made a bad esthetic impression on users, not to mention harming usability. Costly support calls soared. Reviews were bad. Enterprise customers were unhappy as well, where a stymied employee might cost a company some real money.

So between wanting to boost user goodwill and incidentally increase ROI (we're talking many millions), the Powers That Be – and not just Microsoft, this is industry-wide – finally grokked that if you provide accurate, helpful UI text you can achieve those goals, in part by reducing the need for such hefty documentation.

And now, with a new generation of management who seem to have forgotten or never learned about the lessons of the past (and have been seduced by the"modern design" zeitgeist), the subject matter experts and professional writers and editors, some of whom earned their stripes from decades of dedicated work, are tossed out as cosmetic “wordsmithers,” and their jobs are “in-sourced” to people with no background in the field. (Permanent employees as well as contractors were let go and, reportedly, new vendors won't be brought in to Microsoft, off-shore or not.)

As I say, this is not a new phenomenon, but it's somewhat surprising that failed ideas have to be tried again and again. Reinventing a square wheel. Giving still more responsibility to a single person hardly seems feasible given the already tight schedules. Especially if the person needs ramp-up time and special knowledge to do a decent job.

Behind the outmoded process paradigm is the thoroughly disproved mindset that words don't matter and users don't care.

I direct your attention to the following articles that explore the area of:

    The Goodness of Good UI text

  • oft-layoffs-impact-exchange-technical-writers-where-
    "Eliminating some technical writing jobs is not the point. What’s really upsetting is that subliminal message that Microsoft is no longer interested in providing the very best technical information to its customers. That’s something that all of us should be worried about – unless of course, you really are due to be absorbed by the cloud and can therefore rely on the Kool-Aid. You’ll need it."
    Everyone has done layoffs,” notes Patricia Seybold, CEO of the Patricia Seybold Group in Boston…. But the best companies focus on keeping customers happy. “They’re convinced that keeping the quality of customer experience front and center is the key to survivability, then viability, then profitability…”
    "...language experts should play a more active role in shaping the interface because the interface is text."
    "If a software design team hands you a finished interface and wants you to spray some words on it, you’re too late. Why? Because the writing *is* the user interface, and UI needs to be designed with language in mind from the ground up."
    "The idea that you can credibly address a client’s concerns before you’ve actually started working with them is ludicrous, and, frankly, damaging. It undersells the magnitude and importance of our work, suggesting that hard problems can be tackled in such trivial fashion. … the people who best understand user engagement are often the least empowered to do anything about it, while those who have little true understanding of the medium are put in charge."

     And, because the link he gives to his follow-up is broken:

    "Usability problems usually fall into two categories; either it’s not clear how to do something, or something is too cumbersome to do. The latter is fixed by a better understanding of what the key tasks are, and the former is usually resolved by adding clarity. Often the best way to do this is through the writing of the interface."
    "Accumulated across your entire website or app, consistently good writing will help reduce your users’ confusion, and your customer support burden to boot."