Saturday, November 9, 2013

Musings on tech writer interviews

Google recently announced that it's ceasing its practice of asking brain teasers in interviews. Their VP of People Operations said they'd stop asking things like, "How many golf balls fit into an airplane?" and "How many gas stations are in Manhattan?" and “How would you weigh your head?”

I haven't interviewed at Google but I've been asked some pretty goofy questions. I was once asked "If you were an animal what kind of animal would you be?" (to which I said, "I don't have an answer for that"). I once interviewed for a financial analyst job at Wood Gundy and was asked what country clubs my parents belonged to and where our cottage was located. (I had no answer to that, either.) I was once asked no questions... the interviewer just talked and talked nervously and then offered me the job.

Mostly, though, I've had pretty good experiences being both interviewer and interviewee. I think the trick is to make a connection and exchange information frankly. That's why I don't like interviewing unemployed applicants, cruel as that sounds. If someone has to quit a job to take a job, then they will be more interested in ensuring it's a good fit on both sides.

I've always thought that things said in interviews should be considered as semi-contractual. If an employer tells an applicant they're concerned about the applicant's short durations at recent employers and asks if they'll stick around - and the applicant says yes - then the applicant has an obligation to stick around - at least two years, unless there's something really wrong. If the applicant says he wants to move up to manager within a few years and the employer hires him, then there is a presumption that he will have the opportunity to advance, given good performance and favorable conditions at the company.

I think it's folly to ever hire a writer without administering a writing test. Having writing experience, even senior experience, doesn't guarantee that the candidate has any writing chops. The test can be as simple as having the writer edit a poorly constructed paragraph or writing a procedure to perform a simple task. Similarly, it's important to ask questions that validate skills... I once interviewed a woman who said she was expert in SQL but despite ten years documenting databases, she didn't know how to retrieve data from a table.

Fluxible 2013: Recap

Last year I wrote a series of detailed posts about sessions at the Fluxible conference in Kitchener, Ontario. This year I was a volunteer at Fluxible #2 so I was unable to take as good notes. I had to keep dashing out of sessions to put drinks on ice and so on. But I got the gist of things and in some ways, it was an even better way to attend the conference, as I was less lost in the weeds and reflected more on the big picture. So here's my scattershot and/or 10,000 foot view of what was going on at this year's Fluxible.

Warning: I am basing this post off my notes, but I can't guarantee that I'm representing every speaker completely accurately. A particular problem may be omissions since I was not always in the room.

The conference started with a series of five minute talks. Steve Baty started us off by talking about the nature of innovation - from the old meaning of the word (insurrection, rebellion) to its meaning as incremental improvements such as those practiced by Toyota, which constantly pushes ahead with an empowered workforce and small steps in manufacturing and design that enable it to make the best cars. The next speakers talked about disruptive change requiring a new attitude. We were reminded to not focus only on users, but to also research "near users" (people who use a similar product) and non-users.

Trip O'Dell talked about the changing demographics of mobile users and how we need to adjust our thinking. He said previous heuristic expertise is becoming obsolete. He warned that designers are becoming more distanced from their users - up till now, it was "20 year olds designing for 20 year olds": designers tend to be rich, educated, tech savvy, and early adopters of technology - what he calls "high agency users". But now, increasingly, mobile users are in poorer countries, and users are often poor, less educated, and functionally illiterate. He calls these "low agency users". These users aren't just in developing countries: he said that 15% of North American adults are functionally illiterate too. Italy and Mexico have especially high percentages of low agency users.

Low agency users are usually not of low intelligence: we just need to show rather than tell. The main things that need to change are the text-based nature of UIs and icons that are rooted in our culture.

O'Dell pointed out that the current trend in UI design, flat icons, was inspired by transit language in airports: those icons pointing to baggage pickup and so on. Those icons are big, bright, clear, and meaningful across cultures.

He also noted that a new trend among apps for low agency users is playfulness. For example, the Chinese app WeChat, which has 550M users, has a feature where you can shake your phone to connect to other people who are shaking their phone at the same time.

"Low agency countries" tend to have an ownership culture, where people want to own rather than rent. Netflix would not do well there.

Diana Wiffen of Quarry Communications talked about how to design winning digital experience design strategies.

Here are speaker Konrad Sauer's notes on the conference: link.

Cell phones > Smartphones > Superphones > ?

Just fooling around here, but with the rapid evolution of smartphone technology, you have to be wondering where it's going.

Earlier this year we learned of an imager chip that lets mobile phones see through walls, clothes, and other objects.

With Square, we see an evolution to peripheral devices that free consumers from the sales cycle of phone manufacturers. (Square sells a little piece of hardware that turns phones into credit card readers.)

And of course, wearable phones are here, currently as glasses or watches.

But we still seem to be just on the cusp of fundamental change. There is emerging technology that lets finger and hand gestures do many things, that lets brain power direct objects without physical intervention, that replaces phone screens with public viewing areas. In five years the paradigm of typing on tiny keyboards and peering at tiny screens may seem ludicrous. More interestingly, there may be a fundamental change in what we do with our mobile devices.

I don't pretend to have any clear view of the future, but I wonder what the social effects will be. Economist Tyler Cowen worries that technological change will kill the middle class, although he doesn't argue the case very convincingly.

The internet was built on porn. More recently, the economic driver of technological change appears to be advertising and its insatiable need for more and better data on consumers. Game developers even talk about the importance of "digital exhaust" - making gold of information previously thought worthless, like how long certain demographics of player linger on a level in a game.

What will happen if data becomes available to everyone - if, just as free access to the internet became seen as a right of humanity, access to data becomes a right? The killer apps of the future could be ones that mine, analyse, present, and use data. That seems like a future I can get excited about.

* * *
This post is cross-posted on my other blog: Yappa Ding Ding

Sunday, September 8, 2013

The lesson of databases: use only when necessary

The current CIDM newsletter has an article about content management systems: Why do organizations hate their content management system?

The article is scathing about companies that make bad purchasing decisions, and scathing about CMS vendors that make difficult, bloated products.

But the article is missing something important. The fact is that relational databases are notoriously difficult to use. I spent over ten years documenting databases, so I've seen some of the messy innards first hand. You don't just buy an RDBMS and then figure out how to use it. You need Database Administrators with a lot of skills. You need to make an ongoing investment of money and time just to keep the thing working.

When I worked in the IT department of a large financial firm, there was a prohibition on databases. We used Excel in very sophisticated ways. We transferred millions of text files a night. But we avoided RDBMSs at all costs. Apparently the company had been burned badly by a database implementation and was unwilling to try again.

The CMSs used by doc teams present extra challenges. At one DITA shop where I worked, our CMS vendor decided to deprecate documentation use of their CMS and end support for our application of it. That meant that we had to spend an enormous amount of time and expense to choose a new CMS and get it set up. The cost must have been in the hundreds of thousands of dollars, none of which was figured into the initial ROI for moving to DITA (which we had done just a couple of years before).

I would admonish documentation departments to avoid using a CMS unless they really need it. As with DITA, it makes no sense to take on the enormous expense, steep learning curve, extra manpower requirements, and ongoing hassles - unless you really need it. "Really needing it" means that simpler options won't work for you. The complexity of reuse in most doc departments doesn't come close to justifying the enormous expense.

Friday, March 29, 2013

Documenting customer research

All too often, in-house customer research efforts are ineffective because the results are poorly documented. My rules of thumb are:
  • Write up your results as soon as possible after conducting research. No matter how good your notes or recordings, you had "ah-ha" moments that you won't recall later.
  • Write your results in an effective way. Make the important points resonate. Don't bog down your report in useless details. When writing up one-on-one interviews, think of it as writing personas. Think of it as telling a story.
  • If you archive your results in a PowerPoint presentation, make use of the Notes feature to fill in all the information that you impart verbally. Think of the deck as an artifact that will be read on its own.

When I started working at one place, I learned that my manager had done a round-table discussion with customers the year before. I asked if I could read her results and she said that she hadn't written anything because she recorded the session. I listened to the recording, but the way the mike was placed I could only make out what she was saying: the customers were largely inaudible. It was clear that I was the first person (including her) who had bothered to wade through the three hour recording.

This recording-in-place-of-report seems to be a common problem. Recordings are supplemental to reports, not a replacement for them. Whether audio or video, recordings can be very useful when snippets are excerpted and presented. They are also hugely useful for writing reports. But in almost every case that's the end of their usefulness.

I have frequently found that the only report of a research study is a PowerPoint presentation, with lots of cute photos, lots of headings, and virtually no results.

At the other end of the scale are the faux scientists who write hundred page reports filled with large pie charts, with numbers reported to four decimal places (NO decimal places, please!), and a complete lack of understanding of how to report results of research where the sample is not representative of the population.

Even the most dismal interview can be useful if the results are well-presented. This isn't about window-dressing. It's about ferreting out what's important, and as with most things, it requires hard work to be successful.

Thursday, March 21, 2013

Documentation as web sites

Those of us who write online documentation have an opportunity to move beyond the old book style of technical writing. Instead of writing books, we could start to think about whether we can present our documentation as web sites.

Instead of an opening page that has the date and a copyright notice (or whatever your HTML opens to), you could create a web page that is interesting and engaging, containing:
  • A mix of types of information that draws people in and makes them want to read: a section on samples or case studies that are interesting to read through; a section of videos; and so on.
  • Subtle but consistent and informative use of metaphor, such as visual clues that complement navigation.
  • Quality art/photos that create a mood (not icons or clip art).
  • Playfulness, creativity, and a focus on making people want to read the site.
When architecting doc web sites, I'd like to see writers considering good web site design principles. For example:
  • Creating headings that use dynamic action verbs; headings formed as questions; and intriguing section titles such as "Try me".
  • Chunking content based on reader needs (such as new/not-new, inexperienced/experienced, or UI/API), rather than organization by typical content-based chapters.
  • Providing a seamless mix of content from all sources.

I haven't mentioned providing the opportunity for reader participation and feedback only because I think we're geting a good handle on that in the industry, and it's a given.

It's vital to note that none of this should be frivolous or have a marketing bent. None of this should feel like a bells-and-whistles approach. All of the effort should be focused on helping readers absorb and retain information.

The site should first and foremost be informative, and it should contain reference materials, numbered lists, detailed conceptual info... but content should not be included just because it covers everything that could be said. Content should be included only when it's needed by readers.

The whole thing could be written in topics and single-sourced into both the web site and a more standard structure in a PDF. Single-sourcing could also be used to repeat content in more than one place on the site.

There are problems to overcome with tools and with browser support. There are possible pitfalls: we don't want to create something that's busy, causes navigation problems, or is annoying. But I think this could be done.

Speak French?

Cirque du Soleil is advertising for a technical writer. They call the role "Documentalist".