UXcampCPH sessions summarized

I attended UXcampCPH, a barcamp-type conference on user experience (UX) design in Copenhagen, last weekend. It was great! There were about 270 people from different countries and different professions, but all of them passionate about UX and willing to share what they knew in sessions and discussions.

Huge thanks to the local organizers who were incredibly dedicated and competent all through the event and pulled it off without a hitch! And thanks to the sponsors who made this all possible.

Below is a summary of some of the sessions I attended. I’ll have more to say about what tech comm can learn from UX and the differences between the two professions and between a barcamp and a conference, so watch this space. (There’s RSS and e-mail subscriptions to the right to remind you when new posts appear…)

Navigation as cross-channel sense-making

Andrea Resmini‘s keynote on Friday was a dense conceptual talk about navigation. Whether on a web site, in an app or in a city, navigation helps use to make sense of our surroundings. We use paths, of edges/walls and of nodes/intersections to choose from available options.

Andrea Resmini starting his keynote, being photographed by Eric Reiss; photo by @kmdk

In our navigation, our perceptions may differ from the physical reality as a city map never matches our personal idea of a city. But maps still are good, sharable representations of quests in which we act our personal narratives.

On the web and in apps this means that we need to learn to “navigate the database”, for example, by perceiving Facebook as our regular bar: It’s probably not a perfect place, but it’s where all our friends hang out. So as we use navigation, we create our own choreography across several channels which makes our experience cohesive and meaningful.

– I thought Andrea’s talk was a bit academic, but certainly thought-provoking. I was glad that a friend of mine had previously tipped me off to one of his earlier talks about “Pervasive IA” which I found a bit more pragmatic and a good introduction to Andrea’s work.

Prototyping user experience

Leisa Reichelt‘s opening keynote was a well-argued, convincing plea for prototyping. Iterative prototyping beats waterfall projects – if you can afford it.

Waterfall-model projects, Leisa said, are often more orderly than the projects and the real world which hosts them: They “require your best ideas while you still know least about the problem.” But if you start out the project with an assigned front-end developer and real content, you can start with a good idea and iterate your solution until it works in terms of quality and volume and until it satisfies the customer (or time/money run out).

Photo by @Berlinertorte

Prototyping, according to Leisa, beats abstraction, will expose stupid ideas quickly and helps to make good decisions based on real content and real solutions. It makes the strategy live in deliverables, not in meetings.

There are two potential issues with prototyping:

• Some companies find it more difficult or more expensive to throw away a prototype development than a solution design. But in either case you will most likely throw away something during a project.

• It’s an artisan model that doesn’t scale well: It’s great in one project, but it’s very difficult to assign the same developer or designer or technical communicator to two projects at the same time.

– I enjoyed Leisa’s talk thanks to her way of presenting: Very lively, emphasizing stories and anecdotes, but her main points are well supported by her slides. It inspired me enough that I will try prototyping in the near future – I have a small in-house tech comm project for which this might work well… 🙂

Pattern recognition

In my own session, I talked about pattern recognition as an essential mental strategy for acquiring and disseminating knowledge, even though most of us are not aware of it. When applied consciously, UX designers can employ pattern recognition processes to develop effective user experiences more efficiently and help users orient themselves.

– I sincerely thank the 100 or so people who attended my session for their kind, attentive reception. I am especially grateful for the engaged discussion we’ve had how pattern recognition can be applied to UX design. You can find my slides over at slideshare.

Simple drawings

Louise Klinker in her presentation showed the many ways how just about everyone can use sketching. First, she walked us through the basics how most people can draw basic shapes like a line, a circle, a rectangle, a triangle, a wavy line and a 5-pointed star. Then she showed how you don’t really need any more shapes than these. Put them together, and you can sketch people (a 5-pointed star with a circle instead of the top arm), place (houses or meadows) and process (using arrows, clouds, symbols).

Second, she showed that sketching can be useful in many areas of business. You can, of course, sketch the obvious, such as GUI and web site designs, but you can also sketch plans and workflows. You can sketch processes and agreements and from them whole business models. Here’s the basic business model of AirBnB:

Photo by @isa_157

– I’m habitually very much a words guy (hey, I’m called a tech writer, not a tech sketcher…). So I really enjoyed that session, because it got me over the fear of sketching and the thought that I cannot draw… I’m nowhere near the 30 days or so it takes to anchor a new habit, but I’m not such an “un-drawing” guy as I thought…

Expert reviews

Rolf Mölich showed how expert reviews of web sites are as reliable as and not more expensive than usability tests with users – IF they are done right. Because data trumps opinion any time.

Photo by @saevarsson

To get expert reviews right, you need actual experts in both usability and the subject domain, these experts need solid methods, and the test needs open discussion to avoid dismissal of the experts’ results as mere opinions.

– I liked Rolf’s interactive mode that had us signal our collective opinions about expert reviews using green, red and yellow (the latter for undecided). And I appreciated his candor when he admitted that he’d had second thoughts about the heuristic method he invented with Jakob Nielsen about 20 years ago.

Beyond responsiveness

Eric Reiss‘ closing keynote summed up many threads and ideas of the day, among them:

• Anticipatory design can improve upon responsiveness. Responsive design often focuses on the device more than on the user. For anticipatory design, extract patterns of use and behavior and make the application situationally aware. The situation includes not just location, but also time of day: Around midnight, show me the bars close by, not the barbers.
• More isn’t better. A portal with 49 links and zero focus is not useful. 20 pages with a good story beat a thousand pages.
• Big data, bigger insights. Spot patterns in user data and decide which are meaningful and relevant to your user experience to derive value.

Photo by @mortenriis

• Create uniqueness. The “A” in IA (information architecture) is not only about structure and usefulness, but also about having a personality and beauty. Don’t worship form: Design patterns are mere templates, not design in itself. Don’t enslave yourself to the process.

– Eric brought the barcamp to a great close with his lively presentation. I didn’t mind much that it was a collection of points rather than a coherent narrative, because I could recognize and connect to several of them as he summarized the last one and a half days.

If you’ve attended one of the sessions, feel free to leave a comment or question!

Advertisement

3 motivators you share with your tech comm readers

What motivates you to work most likely motivates most of your users in their jobs, too! You still need to know your audience, their tasks and background, but the good news is that you have some basic motivators in common. And these can help you understand what makes you happy at work – and what makes your users successful in their work with your documentation.

The three motivators

I take my cue from Walter Chen’s post “The science behind what motivates us to get up for work every day“. I want to focus on three motivators Chen quotes from Daniel Pink:

The 3 real reasons that motivate us to work hard every day

Pink explains … that there are in fact just 3 very simple things that drive nearly each and everyone of us to work hard:

1. Autonomy: Our desire to direct our own lives. In short: “You probably want to do something interesting, let me get out of your way!”
2. Mastery: Our urge to get better at stuff.
3. Purpose: The feeling and intention that we can make a difference in the world.

The motivators for technical communicators

Pink’s model resonated with me, and I think this is exactly what motivates me to do good tech comm work and try to get better at it:

• Autonomy for me means to find something good in the benign neglect that often meets my efforts. Of course, I have specific products, deliverables and deadlines to comply with, but our documentation team is lucky enough to be able to define its own standards and processes as long as they’re feasible.
• Mastery is the challenge to write better documentation. When I revisit obsolete documentation that I’ve written some years ago, it makes me smile: Seeing where I’m coming from and what I wouldn’t do anymore gives me a sense of progress. I’m still using task orientation and topic-based authoring – but I wouldn’t awkwardly mix concept and task in the same topic like this anymore.
• Purpose for me is my reward that my readers can be more successful or simply faster in their work if and because I’ve given them the right information at the right time.

So in a very personal, non-scientific way, I could validate these three motivators.

The motivators for documentation users

I don’t think I’m all that different from my readers in this regard. I believe they get motivated by the same things – they’re just in a different job.

So I try to keep in mind the motivators when I structure and write my documentation:

• Autonomy is tricky, of course. Someone looking up documentation has just given up the autonomy of a self-directed life and needs instruction or information. But I still try to acknowledge this and follow Pink’s advice above: “You (dear user) probably want to do something interesting (or important), let me (give you what you seek and) get out of your way!”
• Mastery is where tech comm can really excel. By presenting essential information concisely and clearly we can make it easy for our users to master their tasks and their use of our product. For this mastery, it doesn’t matter whether users learn from the documentation and internalize a skill or whether they simply know where they can look up again quickly what they don’t need to remember.
• Purpose is frequently neglected, I think. Often documentation focuses on the how, and forgets the why. But there is no sense of purpose without a why. Granted, not every topic can address the big questions of life and the universe. But as long as there is an elegant and possibly noble reason for why our product and its tasks are this particular way, it’s worth sharing it. It will give our customers an extra motivation – and make them more loyal users.

Is this what motivates you? Does it work for your readers or do they have other motivations? Please leave a comment.

Why TCUK is such a cool conference

Technical Communication UK (TCUK) has established itself as a leading tech comm conference in Europe, because it combines expected features with more quirky, informal elements of “unconferences”.

Pivotal programming

Part of the success comes thanks to a well-balanced mix of sessions. This is the “meat and potatoes” that covers the usual suspects of methods, tools, and technologies. It also excels by reaching out into neighboring disciplines. This year a whole stream of sessions was dedicated to “anything but text”. These presentations (and a couple of keynotes) went all visual and covered icon design at Google Maps, IKEA’s textless communication, technical illustrations, colour usage, video in user assistance, and more.

TCUK audience, photo by @FireheadLtd, used with permission

Fascinating fringe

Unconference features, such as lightning talks, a rants session, and a fringe program, make up the rich dessert buffet. They inspire and foster an accessible sense of community among delegates who want to carry ideas and conversations into less formal contexts. Fringe events ranged from meetups of user groups or regional ISTC groups to a film screening, from informal social get togethers to the latest instalment of the legendary annual salsa class.

Committed community

That sense of community is what makes TCUK unique to me: Beyond getting the logistics right of putting on a conference, these worthy folks hit the sweet spot by establishing a framework within which stuff can happen. The amiable atmosphere draws delegates together, whether they’re there as repeat speakers or just for one day. I’ve met someone determined to make the most of his one day, and he was hooking up with people left and right everytime I saw him between sessions.

Three-and-a-half takeways

What did I take away from TCUK 11?

• A feel for where the tech comm industry is at. Technical communication is as dynamic a field as ever and there’s no better place to take a temperature than conferences such as TCUK.
• Learn to think and act outside the box. Thanks to the good programming, I got a lot of insights and inspiration. This goes for tech comm topics, such as personas and minimalism. And it extends into other applicable areas, such as being a riveting speaker and interpreting and visualising statistical data.
• A long-term perspective. Perennially repeated discussions are such as “What do we call ourselves and why?” are legitimate and important. But we also need to think in terms of progress, how we tech comm’ers want to the industry develop and in which direction(s). Fittingly, the final sessions did a good job whether it was Ellis Pratt’s closing keynote or Roger Hart’s compact 3 minute rant that content strategists have little on us, but still might do us in.
• Tech writers will be tech writers. You can’t stop a bunch of tech writers from editing a dinner menu. You just can’t…

Your turn

If you’ve attended TCUK 11, what were your impressions? You probably took something else away… Feel free to leave a comment!

Pattern recognition for tech comm at #TCUK11

Our presentation “Pattern recognition for technical communicators” by Chris Atherton and myself at TCUK11 was well-received and brought “Ah-ha moments a-go-go” according to one tweet. Read how it went or download the slides in PDF by clicking on the title image.

How the session came about

The session (see the abstract) got its start when I met Chris at last year’s TCUK where she spoke about “Everything you always wanted to know about psychology (and how it relates to technical communication) … but were afraid to ask”. She didn’t really talk about pattern recognition, and I didn’t really know what it was, but I had a notion this might be good for another presentation. I contacted Chris, she thought it was a great idea, and so over the year, we came up with this baby.

"Only Chris Atherton can have a picture of a dog's bum in her #TCUK11 presentation and make it relevant." - @robocolumn

And we brought the baby to TCUK11. 24 hours before our talk, Chris and I attended Karen Mardahl‘s and CJ Walker‘s fireside chat-like session “Content strategy year 1: a tale from the trenches“.  Their dialogue format really appealed to us, we decided to replace some of the scripted moments with more informal dialogue – and the baby had two godmothers.

Then we attended Andrew Lightheart‘s “How to be a riveting speaker” (more on that in my previous post) after which we couldn’t very well present something with reams of text-ridden slides. So we threw out most of the text slides – and the baby had a godfather.

By now, it was still the same content, but quite a different presentation. After all the tweaking, we didn’t have a measurement whether it filled the allotted 40 minutes or was longer…

How it went, a view from the lectern

Chris and I met in the auditorium, set up, added some last minute changes. Checking the watch: 2 minutes to go. Looking up: We had filled the place, a good 100 people were keen to recognise a pattern or two…

Karen introduced us, and off we went. I had decided to be extranervous because the session was being filmed and preserved (is my collar right?) – but I completely forgot!

"By creating and following patterns you help your reader understand..." - @dfarb

Through all the changes and tweaks, we had come to know the material so intimately that it seemed to flow quite smoothly. The omitted text slides were actually a relief, because we could focus on the story and the examples, without having to vindicate each and every sentence. We had picked out stories and examples which were easier to tell than some of the concepts we had thrown out.

Karen’s warning of 15 minutes left came around the time I had roughly estimated. We had to leave out the communal brainstorm of more examples and applications, but everything else fit in.

The feedback after the session was very kind and encouraging. I’m glad and proud if we presented something meaningful to our peers.

The slides

The slides are not the actual presentation we showed, but a variation with more text, so they work a little better as a self-contained slide show without the soundtrack.  Click on the image above to display or download. The video by the TCUK crew is forthcoming.

Chris and I sincerely thank the TCUK organisers for inviting us, our peer presenters for valuable inspiration, all attendees for helpful feedback, intentional or not, before and after the session!

Feel free to leave a comment, whether you were there or are merely curious what it’s all about!

Structured content does not kill creativity

Structured content is cooler than you may think. As a model for technical communications, it suffers from several misconceptions which prevent that you and your organization get the most out of it.

I’ll debunk a couple of misconceptions that I’ve encountered. Each one presents a learning opportunity where you can show a writer, a subject-matter expert or a manager how structured content is actually quite beneficial.

Myth #2 is:

Structured content kills creativity, right?

The argument is that the structured content forces you into a corset of rules and reduces you to filling in the blanks. It means to comply with a structural model which can get quite intricate. For a procedural topic, rules could include:

• Start the topic with a heading; start the heading with a verb.
• Start the text with an introductory phrase, sentence or paragraph, depending on how much context the procedure requires.
• Write all procedural steps in a numbered list.
• Etc.

Channeling creativity

I think the argument, taken at face value, misunderstands creativity. Creativity, whether in the arts or in more craft-like professions, is always an expression regulated by rules and confined by boundaries.

Think about poems. Ann Rockley (I think) once gave the example of a sonnet, a fine form of poetry which has been around with few changes for centuries. It is highly regulated in terms of number of lines, rhyme scheme, etc. Or think of a haiku: 3 lines of 5 + 7 + 5 syllables, that’s pretty strict. But I’ve never heard a poet claim that the rules kill his or her creativity.

So structured writing sets up more obvious rules than you may be used to. With them, it channels creativity to ensure that your writing is more reliable, more accountable and to your readers more useful.

Anybody can write?

Filling in the blanks in a structured writing template seems more mundane and banal than to write one paragraph flowing into the next. This can lead to the idea that structured writing might somehow be easy…

Structured writing is mainly different from technical prose, I think – and ultimately just as demanding. In both scenarios, you can ask yourself: Have I put my best sentences into the topic? And in both scenarios you will meet people who think that anybody can write. But the marks of high quality writing are pretty similar in either case: Is the writing clear, consistent, and correct?

Your benefits

For you as a writer, structured writing doesn’t so much limit or kill creativity, but it helps you to channel it: You can focus on putting the most useful, most concise documentation on screen or page in consistent structure. It frees you from having to worry about structure, content and layout at the same time: You can focus on content alone, while the structure is given, and the layout is applied separately.

For readers, structured writing increases their trust and confidence in the documentation. Whether you spell it out explicitly or leave them to discover it by themselves, structured writing ensures a level of consistency that is hard to achieve by other means.

---

If you’ve found this post helpful, if you disagree or if you know additional benefits of structured content, please leave a comment.

Pattern recognition for tech comm

Chris Atherton and I will present a session on pattern recognition for technical communicators at this year’s Technical Communication UK conference near Oxford. The conference takes place from September 20 through 22.

Adding up Chris’s interest in evidence-based information design and her background in researching and teaching human cognition with my experience in designing and modelling technical communications, we’re sure it’ll be an interesting, thought-provoking session. Here’s the abstract:

Pattern recognition is one of the essential mental strategies for acquiring and disseminating knowledge, though most of us are not aware of it. This session presents some ideas and findings about human pattern recognition. It aims to help technical communicators think about how they can employ pattern recognition processes to develop their own documentation and user assistance.

The presentation combines the wit and wisdom of a cognitive psychologist and a technical writer who draw on examples and evidence in their respective fields to show:

• What pattern recognition is and how it works
• Which mental strategies we employ without knowing it
• How technical communicators can employ those strategies
• Making sense of new subject matter
• Starting to build new documentation
• Designing and structuring documentation
• Supporting users efficiently

New conference trend: Collaborative sessions

It’s interesting to see collaborations appear at the conference that create a mushroom-like network of sessions:

• Chris and I talk about pattern recognition.
• Chris leads a session with Mike Smith and Karen Mardahl on statistics (without maths).
• Karen joins forces with CJ Walker to tell about content strategy from the trenches.

Do you think joint sessions are a good idea or not? Have you had bad experiences that we should avoid? Feel free to leave a comment.

Recommended read: Practice technical writing

Becoming a better tech writer requires practice.

Mike Pope, tech editor at Microsoft in Seattle, has a brilliant blog post about 12 ways to practice tech writing. The catch is he means “practice” like a musician, so you learn to do stuff better than yesterday – instead of just doing the same things over and over.

Over the last years, I’ve tried all 12 ways, and they’ve all helped me to become a better writer. And most of them can be fun, too, at least most of the time… 🙂

Here are just six of the ways as a teaser, but I highly recommend you head on over to Mike’s post to find out about all of them with details and examples.

1. Read other technical writing attentively.
2. Read about writing.
5. Writing something outside your usual material.
7. Edit someone else’s work.
10. Learn new tools and new ways to use your existing tools.
11. Talk to other writers.

Top 4 benefits of writing a tech comm blog

Kai’s Tech Writing Blog was one year old last week! It’s been good to me, and the work it takes pays off in several benefits.

If you don’t keep a blog, my benefits below may help you decide whether you want to start one. And if you do have a blog, we can compare notes! 🙂

1. Improve ideas

My blog helps me to come to terms with trends and developments and to test drive new ideas. I usually try to have them thought through well enough, so I can publish something coherent and don’t just think out loud.

2. Connect with the community

My blog’s most important benefit is that I get to meet other tech writers who may have similar concerns, different solutions or interesting insights, whether they appear in posts on other blogs (see my blog roll on the right), in comments beneath my posts or on twitter. I get advice and can learn from smart and experienced people. And I can give back to the community when I can offer my experiences.

3. Picture progress

My blog lets me track my progress as a tech writer, much more so than weekly reports in my company. After several years, I don’t become a better tech writer by completing yet another manual, but rather by mastering a new method or by consolidating experiences into applicable insights. Such advances aren’t always immediately visible in a time sheet. In other words: My blog helps me to report on my development in a more personal, less corporate framework. Oh, and it’s nice to see the tag cloud changing (see Categories to the left)…

4. Write regularly

My blog has been habit-forming. From the start, one year ago, I decided to stick to a regular publication schedule with one or two posts per week. I still find that works best for me.

Writing 400 to 800 words per week, which usually don’t directly relate to my work at the office, has been a very good exercise. It encourages me to keep my eyes open for trends (even though I may take some time to pick them up). And it helps me to express myself clearly in less structured writing than my topics and manuals usually require.

– So that’s what motivates me to write one or two posts a week…

Your turn

If you keep a blog, what do you get out of it? If you’ve wondered about starting one, do you find these benefits reasonable or attractive? Please leave a comment.

Reading outside the tech writing box

Can reading around improve your technical writing? Many writers recommend to read a lot, but discriminately: Margaret Atwood, P.D. James and A.L. Kennedy do,  Annie Proulx, Zadie Smith and Sarah Waters do too, when the The Guardian asked them for “Ten rules for writing fiction”. But does this apply to technical writing, too?

It took me a while to figure it out, but I think reading “outside the tech writing box” helps my tech writing. By “outside the box”, I mean reading beyond an immediate purpose, so I’m excluding writings about tech writing, such as books or blogs, specifications and style guides.

Technology journalism

Most effective for me is well-researched, well-written technology journalism:

• It emphasizes stories and the people behind them and reminds me they are more important in my writing than the latest feature bonanza.
• It helps me to focus on personas and my audience and reminds me where other people in the industry are at – or where they may be headed.
• And with some luck, it’s fun to read and well argued and remind me to try and be engaging in my writing where appropriate.

The kind of writing I mean can be found in print and online in Wired, Slate and Salon, in the New York Times and the New Yorker, the Chronicle of Higher Education and the Columbia Journalism Review, in other blogs and magazines and newspapers.

If you like books, the annual anthology The Best of Technology Writing 2007, 2008, 2009 collects about two dozen articles each year that are frequently worth your while – especially since the first two volumes can be read online for free.

Let me give you a few examples which I think stand out above the majority of magazine articles and blog posts:

• Jeff Howe’s “The Rise of Crowdsourcing” (Wired,  June 2006) first explained to me how off-shoring and outsourcing got a new twist with crowdsourcing of stock photography (such as seen in this blog), serious R&D and Amazon’s Mechanical Turk program.
• John Seabrook’s “Game Master” (New Yorker, 6 Nov 2006) tells the story of Will Wright, the creator of video games such as Sims and Spore.
• Emily Nussbaum’s “Say Everything” (New York Magazine, February 2007) showed me how people who are ten years younger than me have a completely different concept of privacy.
• Dana Goodyear’s “I [Heart] Novels” (New Yorker, 22 Dec 2008) introduced me to cell-phone novels originating in Japan.
• Clive Thompson’s “Brave New World of Digital Intimacy” (New York Times Magazine, 5 Sep 2008) provides an in-depth look at Facebook and portrays its founder Mark Zuckerberg.

What else?

If you’re focusing on a specific industry, you can probably also find outstanding journalism there which is worth hunting down. I’m in financial and banking software. So trying to find good articles with an expiration date beyond the next quarter has been especially interesting… A good starting point for me was an anthology by Michael Lewis and McSweeney’s called Panic: The Story of Modern Financial Insanity with pieces written between 1987 and 2008.

Beyond that, I find my reading cannot inform my tech writing much. Recently, I really liked Alain de Botton’s The Art of Travel for its insights what motivates both travel and art and its concise arguments backed up by well-written examples.

I’m also fond of E.M. Forster’s style and handling of plot and character in A Room with a View. These books, as well as many others, engage me and enrich my life – and remind me that there’s a reading life outside of my job… 😉

What do you think? Can reading help to improve your technical writing? What books, stories or articles have you found inspiring or helpful?

The kick ass curve

How long do your users spend in the “I suck” (or “this product sucks”) zone? Once they’ve crossed the suck threshold, how long does it take before they start to feel like they kick ass?

I don’t know anybody who illustrates the motivational angle of documentation better than Kathy Sierra. Her post “Attenuation and the suck threshold” from October 2005 has one of the most insightful, funniest curve charts I’ve ever seen. It may not apply to everything you’ll ever write, but I recommend it as a fresh perspective.