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

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).

Leisa Reichelt during her UX camp CPH keynote

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:

Business model of AirBnB, sketched.

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.

Rlf Mölich talks about heuristic methods

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.
Eric Reiss during his closing keynote.

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!

Advertisements

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.

Link to PDF slides: Pattern recognition for tech comm

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.

Logo of the Technical Communication UK conference

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.