STC13: David Pogue’s keynote spech

David Pogue, technology columnist for the New York Times, kicked off the STC Summit 2013 with his keynote. He looked back to his previous keynote at the 2009 summit and forward to what future developments in technology and materials science might bring. (This is part of my coverage of the STC Summit 2013 in Atlanta.)

Alan Houser, President of the STC, introduced him as the “most publicly visible technical communicator on the planet”. David started with a recap of his earlier address. He explained (again) how up to 2009, the acceleration in technological developments had led to a challenge and a paradox. The challenge concerns hardware where machines have become smaller and smaller, while our means to operate them, namely our fingers, have remained essentially the same size. The paradox occurs in software where companies often justify the most recent upgrade by piling on yet more new features – without necessarily having a good place to put them.

David Pogue delivering the keynote speech at the STC Summit 2013. Photo by Nitza Hauser.

Out of this challenge and this paradox comes the unexpected situation where a company such as Apple can achieve a competitive advantage by successfully eliminating features in a device such as the iPod. This cult of simplicity sells, and the product or service with fewer buttons win, whether it’s an iPad or the Google start search screen.

The reason why this works is psychological, says David: Achievements give us joy and make us feel that, yes, I can do this, and for this, I’m a good person. Conversely, not understanding how stuff or works or why stuff is so weird terrifies us.

Which brought David to Windows 8 and his task to write book for his “Missing Manual” series about the operating system. David made it clear that he appreciates much about Windows 8 – however, there are certain features that drive him crazy because they task him with documenting something that makes no sense – a feeling many tech comm’ers know well.

Specifically, Windows 8 presents two versions of many applications, two browsers, two e-mail clients, etc. – one in the GUI with tiles and one in the regular desktop. In the tiles GUI, there are no folders or files – and the control panel with system settings is only available via search.

Okay, so David decided to document the two GUIs in two separate parts of his book. Which raised the question how you call each GUI. The desktop is the desktop. But what is the GUI with tiles called? It started out as “Metro” until a German retail chain of the same name threaten to sue Microsoft. The “Modern UI” moniker was internal Microsoft lingo only. So David asked Microsoft directly. The GUI with tiles it turns out is called – “Windows 8”! As is the operating system in which the GUI with tiles and the desktop both live…

This didn’t make sense to David, so he invented the name “TileWorld” – and the name stuck! (… it does sound like a DIY store for bathrooms to me…)

David thought the main issue was the decision to combine the two GUIs. The common desktop is a more cumbersome but runs all applications and is known to most Windows users today. “TileWorld” has its advantages in a mobile tablet world, but is unsuitable for many uses such as drawing, spreadsheets, word processing, etc. – all these don’t work well with gestures on a large touchscreen on the desk in front of you.

The takeaway lesson David shared was: Terminology should be for clarity and to serve the reader.”

David ended his keynote to rousing applause as he regaled us to his very own version of the show tune “I Feel Pretty”, “Im On Twitter”.

Join me for “Mental models for tech comm” at STC 13

I’m proud and happy to be presenting at the STC Summit in Atlanta in a couple of weeks on meaning and mental models and how understanding them can help us in technical communication. If you’re attending the Summit, I invite you to join for me:

Addicted to meaning:
Mental models for technical communicators

Tue, May 7, 4:00 pm in room Hanover AB

My presentation will explore how “meaning” works in technical communications, why it fails and how you can create meaningful documentation. I will draw on the cognitive psychology of mental models and advances in user experience design to show why minimalism works, but FAQ’s don’t, and how to write for users without irritating them.

Being meaningful in technical communications is harder to measure than being correct, concise or consistent. However, it is just as essential: Understanding how and why communication is meaningful to users helps to create more effective documentation. Participants will get a deeper understanding and a fresh perspective on what makes communications meaningful.

Maning proceeds from information to knowledge.

You will learn:

  • What distinguishes data, information, and knowledge
  • How (technical) communication transmits meaning
  • What mental models are and how they shape the meaning that users create from documentation
  • How we are addicted to meaning
  • How to ensure your documentation is meaningful

It’s a G-rated session, so you don’t need any previous experience or knowledge of psychology – just a curiosity what makes us tick when we read and write documentation.

So treat yourself to a fun romp of aha moments in the last session slot of the day – hope to see you in Atlanta!

Techcomm lessons from UXcampCPH barcamp

Two big lessons I take away from attending last week’s UXcampCPH, Copenhagen’s “un-conference” on user experience, are:

  • Tech comm’ers and UX’ers can and should join forces because we have essentially the same goals.
  • Barcamps can be a fantastic alternative to conventional conferences.

While the 270 attendees were a mixed bunch, to be sure, I met only about a handful of technical communicators like myself. So what was it like to be a tech comm’er among hundreds of UX professionals, graphic designers, information architects, web designers, etc.?

Barcampers hanging out between sessions at Copenhagen's IT University; photo by @andersmn

Barcampers hanging out between sessions at Copenhagen’s IT University; photo by @andersmn

So close, and yet so far apart

I frequently heard the question: What does a technical communicator actually do? The answer “Write documentation” proved confusing because that meant to some the documentation of a UX project. “Writing user manuals and online help” was satisfactory, but apparently not an obvious answer…

That’s a pity because at heart UX and tech comm share a gommon goals: We both make products mean something to customers. We just do it in different ways: UX’ers design the actual experience. Tech comm’ers help the user along with additional instructional, background, and technical information, when necessary.

If tech comm’s user assistance is embedded in UX’s user interface we actually blur the boundary: User assistance can start with UX field labels and progressively disclose more documentation via tool tips to a full-blown help system.

We even have an external reason to join forces as we both occasionally suffer from similar misperceptions when it comes to the value we add. The varieties of our achievements often goes unnoticed outside our respective fields, as the cliché goes: “Everyone can draw / write…” 🙂

What makes a barcamp special?

A barcamp tries to avoid many of the hierarchical pitfalls of conventional conferences. It emphasizes participation and networking over listening and consumption. The general motto is “You are the barcamp” – and the program is built at the beginning of event when potential speakers pitch their ideas for sessions. Depending on the number of votes from attendees, speakers get a spot on the program.

At UXcampCPH, everybody got to speak: Of approximately 270 participants, there were only 16 pitchers for the 24 session slots. The event was a bit special in that they invited 3 keynote speakers – which often isn’t done at barcamps to stress the egalitarian, participatory vibe. But in Copenhagen, the keynotes worked well by bringing everyone onto the same page (see my previous post of session summaries).

UXcampCPH participants pitching their sessions; photo by @JohannaBlomgren

UXcampCPH participants pitching their sessions; photo by @JohannaBlomgren

Here’s how I would compare features:

Conferences vs. Barcamps

  • Primary tool: Laptop vs. iPhone
  • Communication artefact: Business cards vs. twitter handle
  • Networking over drinks opportunity: Drinks reception vs. pitchers of beer
  • Food: Banquet buffet vs. organic soup kitchen
  • Location: Conference hotel/convention center vs. university lecture halls
  • Sponsors’ presence: Trade exhibition vs. brand exposure via room names & swag

If you know more reasons why tech comm and UX should join forces – or what distinguishes barcamps from conferences – feel free to leave a comment!

Half-price sale ebooks on UX and tech comm

O’Reilly sells ebooks from the publishing group Elsevier at half price until 23 April.

I blog about it because I think this is a good deal. Also, I like O’Reilly ebooks because they are DRM-free. I am not affiliated with O’Reilly or Elsevier. I get no payment in money or in kind for writing this.

Here are some titles of interest for tech comm and UX people. So if you’ve heard about one of these titles or keep it on a list of books to check out, here’s a good opportunity.

  • The info below is straight from the O’Reilly web site.
  • Prices are before the discount.
  • Use discount code WKESEVE to get 50% off until 23 April.

For tech comm

Designing the Search Experience
By Tony Russell-Rose, Tyler Tate
December 2012
Ebook: $39.95

Letting Go of the Words, 2nd Edition
By Janice Redish
September 2012
Ebook: $49.95

Information Visualization, 3rd Edition
By Colin Ware
May 2012
Ebook: $64.95

Content Strategy at Work
By Margot Bloomstein
January 2012
Ebook: $29.95

For UX

Designing the Search Experience
By Tony Russell-Rose, Tyler Tate
December 2012
Ebook: $39.95

Agile User Experience Design
By Diana Brown
October 2012
Ebook: $39.95

Observing the User Experience, 2nd Edition
By Mike Kuniavsky, Andrea Moed, Elizabeth Goodman
September 2012
Ebook: $59.95

Information Visualization, 3rd Edition
By Colin Ware
May 2012
Ebook: $64.95

Quantifying the User Experience
By Jeff Sauro, James R Lewis
March 2012
Ebook: $49.95

Sketching User Experiences: The Workbook
By Saul Greenberg, Sheelagh Carpendale, Nicolai Marquardt, Bill Buxton
November 2011
Ebook: $19.95

Global UX
By Whitney Quesenbery, Daniel Szuc
October 2011
Ebook: $49.95

User Experience Management
By Arnie Lund
May 2011
Ebook: $39.95

Brave NUI World
By Daniel Wigdor, Dennis Wixon
April 2011
Ebook: $39.95

Thoughts on Interaction Design, 2nd Edition
By Jon Kolko
January 2011
Ebook: $29.95

Usability Testing Essentials
By Carol M. Barnum
October 2010
Ebook: $49.95

Smart Things: Ubiquitous Computing User Experience Design
By Mike Kuniavsky
September 2010
Ebook: $41.95

Sketching User Experiences: Getting the Design Right and the Right Design
By Bill Buxton
July 2010
Ebook: $49.95

Measuring the User Experience
By Thomas Tullis, William Albert
July 2010
Ebook: $53.95

Visual Thinking
By Colin Ware
July 2010
Ebook: $45.95

User-Centered Design Stories
By Carol Righi, Janice James
July 2010
Ebook: $69.95

The Essential Persona Lifecycle: Your Guide to Building and Using Personas
By Tamara Adlin, John Pruitt
March 2010
Ebook: $31.95

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!

Trying something new: UXcampCPH

UXcampPH logoThis week, I’ll be trying something new: I’ll attend UXcampCPH, my first “unconference”, in a neighboring discipline, namely user experience.

How it’s new for me

Unconferences are new to me. Apparently, unconferences forego much administrative clutter, such as advance session programming and sponsored presentations, for a more grassroots approach of: “The conference is us!”

That means unconferences emphasize participation and networking. Attendees bring presentations they want to present and pitch them at the beginning of the unconference.

I’m expecting a good deal of “fly-by-the-seat-of-your-pants” attitude and possibly a glitch or two. Considering the occasional bust session I’ve caught at conventional conferences, I don’t think unconferences need to be worse on principle, though.

User experience (UX) is one of those neighboring disciplines that I bump up against in tech comm ever so often. According to the ISO definition, it means “a person’s perceptions and responses that result from the use or anticipated use of a product, system or service”. Tech comm brings practitioners, theory and research to UX, as Ginny Redish shows in the first part of the article “Overlap, Influence, Intertwining: The Interplay of UX and Technical Communication“.

Seeing how closely UX is connected to what we do in tech comm makes me regret knowing so little about it and wonder if I shouldn’t take it into account more. (Other disciplines which evoke similar reactions include usability, accessibility, content strategy, etc.)

Why I recommend trying new stuff

I have no idea how much I will actually get out of UXcampCPH. But I’m excited about the opportunity to participate for several reasons:

  • Find out how UX people tick. Hanging out with them for a weekend will give me a good idea what’s important to them, how they approach their work and what they think of tech comm’ers.
  • Include UX in my work. I’m hoping to get beyond my theoretical, distant understanding of UX towards a more practical grasp that can help me incorporate it better when conceiving and creating documentation.
  • Spread tech comm goodness. In the second part of the article mentioned above, Ginny Barnum asks “Why should technical communicators claim a seat at the UX table” and endeavours to “stimulate technical communicators to join with UX specialists”. I guess some UX’ers might feel about tech comm the way I feel in reverse: They might know about it from more or less distance, but maybe not understand exactly what we do or how we add value. I’d be glad to point out where and how we can work together, each with our individual skills and talents.

Shameless self-promotion

Kai's portraitI’ll be one of the tech comm guys. If you attend UXcampCPH and are wondering what tech comm does or why documentation can be so weird, feel free to talk to me.

I’ll be the pattern recognition guy. If you attend UXcampCPH, vote for me: I’ll pitch my presentation how we can apply cognitive processes to improve UX (and tech comm). Thank you!

Address information overload in tech comm

Addressing information overload helps your user assistance succeed when knowing your audience and offering correct and concise content is not enough. You can have great topics well-written and well-structured, if they’re part of an information deluge, they won’t help your users get their stuff done.

I take my cue from a post by Nathaniel Davis over at UX matters called “IA Strategy: Addressing the Signatures of Information Overload“. Nathaniel describes six such signatures. I think at least three of them have something to say why and how too much information fails in documentation, too.

1. Feedback

Feedback is the essential reality check to determine whether users suffer from information overload. Customers may report that they’re not sure they’ve found the right information or they cannot apply it efficiently. Even if the content is fine topic by topic, the bulk of information is unmanageable. In this case, consider improving search and browsability for more efficient use of the documentation.

2. The utility gap

The utility gap means that customers only use a small fraction of all the information they have at their disposal. As Nathaniel says, it’s what I have vs. what I use.

If certain user types experience utility gaps, consider addressing them with special documents. For example, you could assist novice users with a quick start document. Or address a special use case which only requires one of the many processes, plus some reference information. With topic-based authoring, it’s usually easy to create such additional documents by re-using the relevant topics. (Maybe add one or two specific “glue topics” to make sure the new document still flows nicely…)

If all users experience utility gaps, consider progressive disclosure by layering your content. The benefit of offering all content within three mouse-clicks wears off if it’s too much. Progressive disclosure structures content by providing the most essential, most frequently used topics first and more obscure information later. Make sure, however, that all topics remain searchable and findable!

3. Filter failure

Filter failure means that users lack ways to judge which information to trust and use. It’s what I can use vs. what I should use. Filter failure can be solved with tools and with content.

Customers who are confident to use their own judgment require tools to filter information. In documentation, faceted search allows users to reduce search results by categories to weed out inapplicable information.

Customers who prefer to rely on expert judgement will benefit from recommendations in the content itself. Consider adding such recommendations for certain user roles or use cases to guide customers to the most suitable information.

– Have you had symptoms of information overload in documentation? Would these strategies help users to cope? What other solutions are there? Feel free to leave a comment.

Ray Gallon’s Hairball of Content at TCUK12

Ray Gallon‘s session The Hairball of Content was a high-level tour de force where he argued that we technical communicators do much more than just technical writing. However, we rarely get credit for all the other work we do in tasks such as content strategy, user interface design, information architecture, etc.

Assisting the user

Our overarching task is to assist users by translating the functional thinking of engineers into something that users can act upon and experience. That means our content is not just in the documentation, but it’s also in the user interface, in the error messages, etc. So technical communications accompanies the complete design process – and we tech comm’ers need to be involved from day one.

If we take our role as the users’ advocate seriously, we need to tweak some of our dogmas a little to ensure that users get the maximum benefit.

Embedding fosters knowledge

Concepts as documentation content are not an end in itself, but they need to offer decision support to users. A concept should tell readers whether they are looking at the right tool or function at the right time. That means such conceptual information needs to be available right where it matters. Even if it means to give context with conceptual information inside a procedure topic, either in the introduction or even as a short sentence in the individual step.

Yes, such mixing of topic information goes against the rules of topic-based authoring, but it will actually help users: Offering such mixed information in context transforms the sheer information of how to do a task  (which is hard to remember) to knowledge of why and how to do a task (which is easier to remember.)

Context is everything

Ray said: “Context is everything” – which applies across the board:

  • User assistance needs to be available in the context of the user’s workflow. Embedding contextual information in layers, from GUI labels via tooltips to full-blown help topics, will support users accomplish their tasks faster and more easily without taking more of their attention than necessary.
  • Each piece of user assistance also needs to offer sufficient context to be meaningful and “learnable” for users: Only offering steps 1 through 5 in a procedure usually doesn’t offer enough context for users to actually learn how to use a product or a function, if we omit the “when” and the “why”.
  • User assistance also needs to offer enough context to allow users to navigate easily and with confidence through the product and the documentation. Specifically, we need to offer users an easy way back to where they’ve come from and a way back to the product and their task.

Offering successful user assistance isn’t a question of offering more at all costs, because more information isn’t necessarily better for the users. Instead, we need to stimulate cognitive demand, the will to know and learn, in the user by offering the right information at the right time.

TCUK12, day 1: Workshops & company

The first day of the ISTC conference TCUK12 offered workshops and great opportunities to meet tech comm’ers from all walks of life and many corners of the earth.

When I arrived late on Monday evening, I promptly headed for the bar and joined the advance party for a last round – which lasted so late that I’m not even sure in which timezone it was 2 am before I turned in…

Robert Hempsall: Information Design 101

Robert Hempsall offered a great and engaging hands-on Information Design 101 workshop about information design. The workshop focused on the five key areas of content and structure, language, layout, typography, and lines and spatial organization. Using a formal application to vote in English elections by mail, Robert led us through the process of designing the form to maximize clarity and usability.

Thanks to our versatile and engaged group of delegates, our work on the form was not only lively, but showed how different disciplines contribute to the solution of better information design, from tech comm (with its principles of minimalism and parallelism) via user interface design (with its emphasis on making completion of the form as easy and painless as possible) to graphic design.

In this sense, the workshop presented a good example of “design by committee” (which is usually a terrible idea): We discussed the most intuitive and user-friendly sequence of the form’s elements and how best to phrase the section headings, as questions or as imperatives. A seemingly innocuous “all of the above”  check box also caused a debate: Should it precede the individual options, to make completing the form quick, easy and painless? Should it come last, so users hopefully first read and reflect on the options? Or should it be omitted altogether, so users have to think about each option and select all that apply.

Form design is maybe not among the core tasks for many tech writers. Yet I’ve found several challenges in it that are strikingly similar to getting a topic structure just right, whether it’s a consistent, indicative heading, good, clear instructions or logical structure.

Rowan Shaw: Quality Across Borders

Rowan Shaw‘s workshop Quality Across Borders: Practical Measures to Ensure Best-Value Documentation in Global Technology Businesses focused on creating documentation both with authors and for users who have English as a second language (ESL).

As in introduction, Rowan presented us with 10 sentences each of which had some element that can create a problem for ESL readers, ranging from “10/03/12”, which could mean 3 October or March 10, to metaphors and slang.

If you need to hire ESL authors, it can be helpful to ask applicants to sit for an exam which tests skills such as procedure writing, fluency of expression, structuring, detail, consistency – but also their motivation for applying, to spot those candidates who want a foot in the door, but might not be interested in tech comm in the long term. We discussed a sample test, whether it was applicable and appropriate in all cultures.

Rowan suggested that, given the practicalities of global ESL authors, you might have to settle for less than perfect profiles in candidates. Then it is important to know which skills are easier to teach someone on the job, for example, grammar, structuring, capitalization, punctuation and how to use a style guide. Other skills are harder to teach, such as an eye for detail, audience orientation, logical thinking, but also more intricate language skills, such as prepositions and correct modifiers.

Again, this workshop benefitted tremendously from the diverse talents in the room and the experiences delegates brought to the topic.

The right company

I keep harping on how much I enjoy and benefit from meeting other tech comm’ers. Just on the first day:

  • I found that several other doc managers are also wary to hire subject matter experts, who are less committed to tech comm, because they might just want a foot in the door (see above).
  • I had an immensely helpful conversation with someone who’s a visiting professor and who could give me tips and ideas that I can try as I consider teaching as a future path.

So day 1 was very fruitful already, and I’m looking forward to more sessions and conversations to come.

But do we create documentation with meaning?

Being meaningful is an essential, but elusive feature of good technical communications. Yet being meaningful in technical communications is just as essential as being correct and clear, concise or consistent: Understanding how and why communication is meaningful can help you to make your documentation more effective and to make your product more useful.

What is meaning?

Information theory suggests a hierarchy of information which proceeds from data at the bottom via information and knowledge to wisdom at the top. For example:

  • Data is the sheer fact that the Microsoft Office 2007 software has an “Office button” icon in the upper left corner.
  • The information is that this icon gives you access to functions such as opening, saving and printing a file helps you with generic functions.
  • The knowledge is that this functionality has replaced the File menu you’ve been used to. This adds meaning and supports your active experience.
  • The wisdom might be in the affirmation that nothing lasts. Or that Microsoft has flipped-flopped when they abolished something as sensible as the File menu – only to bring it back in Office 2010…

So meaning occurs at the knowledge stage in this hierarchy when you make sense of data and information, when you “connect the dots” into something that you can apply purposefully. Meaning gives answers to questions such as “So what?”, “What does this mean for me, in my situation?” and “Why should I care?”.

Why should technical communicators care?

Technical communicators should care about meaning, because we are in the business of creating meaning and transmitting it to users. We can provide all the data and information we want, if it’s not meaningful to customers, it’s wasted and dead. Any time documentation fails, it’s either because meaning has not been created or not been transmitted successfully. Documentation that merely informs the user “To print a file, click the Print button” does not support any active experience. It does not create any meaning, if it omits the context, such as the task the user may be engaged in, the prerequisites and the expected results of the user’s action.

– How can we ensure that our documentation is meaningful? Should we be thinking about meaning explicitly? Or is it enough to know our audience, use personas and create task-oriented documentation? Feel free to leave a comment.