We live in a multi-in, multi-out world.  There are so many information pipelines running into, out and around the organisation these days that it’s overwhelming companies the world over.  The famous information overload is in stark contrast to an endless pressure to deliver excellent content — quickly and cost effectively.

The only scalable answer is to change not (only) the process and skill set (or sheer number) of the people working on content, but actually change the content itself.

We need content that inherently does more for us than it does today. I call content that does this magical ‘more’, content with ‘agility’. But what does that even mean?

I put the question to the Congility 2011 speaking group and got some very interesting replies. One of my favourites was Mark Forry from NetApp:

For many organizations, the expectations of their customers have outpaced with the information managers can provide — and in some cases, can even conceive of. The notion of ‘agile content’ would thus seem to encompass several aspects: development of increasingly sophisticated information in multiple media, storing it in such a way that it is accessible and relevant throughout an organization, and designing the optimal user experience when the information is needed.

In my own experience as a field consultant, the ‘can even conceive of‘ part of this snippet rings very true. Just this month I was doing an onsite Content Strategy Audit for a high tech company. They said to me quiet succinctly and eloquently:

• We can’t keep up with the information requirements of customers as they are today, both internal and external ones, and yet we’re expected to up the pace dramatically in the coming years.
• As a result we spend far too much in hand-holding and live support.
• Content is going out in a mix of old and new templates (Word, in this case) because it takes too long to move things from one to the other and you can’t apply templates globally.
• We can’t assure that either marketing messaging or technical info is consistent and actually representative of the reality of product.
• We want to start localising and translating all this too.
• Competitors are breathing down our neck for our business and provide a far more integrated product and information experience.
• We would love to be able to deliver to both web and print formats.

So — they get it. They could be delivering presentations at an CCMS or structured content conference discussing the business drivers. But they actually couldn’t even envisage a solution. Several dialogues included phrases like, “Maybe a solution is just not feasible”, “Maybe I’m asking for magic”, or “It would amaze me to see something that could actually solve these problems”.

What this tells me is that the world is far too divided into the haves and the have-nots when it comes to content with agility. Even though solutions have been around, and falling in price, for decades, understanding of them has not permeated the market nearly far enough.

In my own opinion, content has agility when it is meaningful, optimised for business and user goals, reusable, portable and accessible. To do these things it needs to be:

• Freed from proprietary formats. If I have to spend time converting, QA’ing or waiting for a software company to release an update with ‘output to format X’, then my content is not agile.
• Freed from its visual style and page paradigm. Have you seen PDF-based ‘eBooks’ on a Smart Phone? With little ‘flippable’ pages you need to zoom in and out of to read, with no social media features? Pathetic. If your content can’t be represented differently and automatically according to the target media, it’s not agile.
• Freed (as much as sensible) from its original context. Context is king, yes. But can you reconstruct context flexibly, or are you locked into only one potential arrangement, forcing you to cut, paste and rearrange every time you want to adapt things? It needs to carry its metadata with it, so you can find it, and know what contexts it can be both used and understood in. If it’s not findable, shareable and reusable, then agile = no.
• Freed from the bias of the creator. Content should be optimised for the audience and support business goals. Commercial content’s business goal is to persuade users. That means delivering the optimum information to best reflect the brand and support the messages to that user, making customers comfortable and motivated to hand over money. Technical (tech communications, support, training and service) content enables. Users should get the content they need and want, no more, no less. In both cases, inaccurate, out of date, hard to consume, or published ‘just because we’ve always published that way’ are major detractors from customer experience.

I’m impassioned enough about these issues to, for the fifth time, be organising an international event gathering globally recognised experts around breaking down these barriers.

Congility 2011, this May 24-26, just outside London, England, is for content professionals looking to advance their organisation’s goals with better content strategy, management and process. It is the only European platform bringing together such a diversity of content experts and learning opportunities under one roof. Learn from ‘The Mother of Content Management’, Ann Rockley, renowned content strategist Rahel Bailie, and case studies from eBay, Nokia, AMD, IBM, AGFA and more.

As part of an arrangement with this blog, you could attend completely free, by taking advantage of this unique discount code. The first person to use the code below will be given access to the conference (but not workshops) at no cost to them besides travel and expenses. Everyone else who uses the code will be entitled to the 20% discount*:

IWBWCA11BLG20SD

* If you can’t go even at 20% discount, you can cancel your registration without commitment or penalty.

B. Noz Urbina is a marketing and presales manager for Mekon Ltd, where he defines and enhances the customer engagement process from beginning to end. With years of experience as a content strategy and content management consultant, he has provided services to Fortune 500 organisations and small-to-medium enterprises. Since 2006, Noz has chaired the Congility events platform (formerly known as X-Pubs). You can connect with Noz through the following links:

Congility is a sponsor of I’d Rather Be Writing.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

I recently spoke with Noz Urbina, consultant from Mekon Ltd, about his upcoming conference, Congility, and about content strategy.

Based in Valencia, Spain, Noz is one of the industry’s thought leaders on XML, DITA, component content management, and content strategy. This year he and Mekon are running a conference called Congility (formerly X-Pubs), held in Gatwick UK, May 25-26.

Noz says that Congility is about making your content “agile,” so that your organization can deliver the content your users want, when they want it, in the format they want it. It’s also about leveraging the content generated or discussed among your users for your organization’s benefit. If you’re interested in attending Congility, you can save 20% until April 29th using the discount code TJRBWCA1120.

In this podcast, we talk about the following:

• What a content strategist tackles that a technical writer does not
• How content strategy differs from marketing
• How one becomes a content strategist
• Bridging enterprise silos in your content strategy, especially without the ability to enforce your strategy
• The role of metadata and taxonomy in content strategy
• Challenges with the diversity of authoring platforms and tools in content strategy

To contact Noz, see his blog, Less Work, More Flow, at or send him an e-mail at noz.urbina@mekon.com.  And don’t forget to check out the Congility conference website. Congility is a sponsor of I’d Rather Be Writing.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

We didn’t have a very good support model for the application. It became clear that our service desk, which included mostly BYU students working part-time and supporting over 100 different applications, couldn’t answer questions that users had. They would only escalate the questions to us. And not many of our customers trusted the support desk anyway. Eventually the project manager started forwarding customer questions to me. I became the go-to person to support the application.

At first I resisted this, because after all, I wasn’t a support desk agent. It was a little demeaning. Customer Support had always been a separate department in other places I worked. But I figured that since I could update the help on the fly, I would just either point users to answers in the help or add to the help until the help was complete and answered every possible question users could have. It would give me good feedback about questions users would have, so that I could write better help.

But as I started talking more and more with the customers, and even observing them in the computer classrooms where I also gave training, a funny thing started to happen. I started to see how users actually used the application. In my training sessions, I would give them a list of tasks to perform, and then I would watch them. It wasn’t so much training as a massive usability lab. I would see users try to click certain buttons because of the interface text, and I would see them go to the wrong screens. I would ask them to explain why they did something. They provided abundant feedback.

Suddenly when we gathered together in project meetings, I was no longer the guy who was just writing the help files. I had tapped into the user experience in a way that the interaction designers hadn’t. I knew how the users thought, how they acted. My close personal interactions with them allowed me to understand users better than anyone else on the entire project team. I even started to offer a few training sessions with the real intent of measuring usability. I would give a 15 minute overview to users on how to use the application, and then give then 10-20 tasks to perform. I just moved about the room watching users try to complete the tasks.

Because of this user knowledge, I became a key player in decisions about design. I was often included with the other core leaders on the team — the quality assurance lead, the project manager, the interaction designer — in key decision-making meetings about the application. When the interaction designer would present an application screen, I would look at it and say, users don’t understand that term. Users are getting lost here. Users keep clicking this button and thinking that it sends the item there, when in fact it sends it here. Users have a different workflow and process for this, and so on.

The project manager had a motto of NIHITO, meaning nothing important happens in the office, and so he often accompanied me in the classroom training where he could interact with the users as well. After a session where he could look over the shoulders of users as they moved through the application, he said the interaction designer (IxD) should definitely be there so he could see for himself how his designs were being followed. The IxD never made it to any of the sessions I led, unfortunately.

The more training and customer support I gave, the more valuable it made me on the project team. I was no longer just documenting what is. I was instead defining what should be. I became an influence in the shaping of the prototypes for future releases. And often when the project manager and the interaction designer were at loggerheads on a design, the project manager would say, let’s let Tom decide. And I would. And you know, I was usually right. It was precisely this user knowledge that gave me a seat at the design table.

I decided to continue filling the support role for the application, mainly because it gave me an incredible insight into the user experience — their pain points and problem areas, their questions, workflows, and business processes. Yes, it helped me create better help. But more than anything else, it helped me transition into a more prominent player on the team, influencing the design and product roadmap. I realized that this knowledge of our users was more important than almost anything else. Others could learn to write. Others could create diagrams. But who knew the mind of the user? I did.

Later, at a conference with Noz Urbina, I interviewed him for a podcast. Noz explained exactly what I had experienced but in the context of social media. Noz said that one consequence of managing the social media channels is that the technical communicator taps into the user feedback in a serious way:

Now the technical communicator is in essence the key holder on a pipeline in of customer data, which is essential to product development, which is essential to the business’s profitability…. So now instead of just giving the manual which goes in the box because they have to, now the tech comm has a conversation going with the client post-sale, to see where their problems are, to see how their customer experience has been with the product over time. And because that conversation is intimate about the details of the customer experience with the technology, then that becomes very valuable data.

Some technical communicators tap so fully into the user experience that they transition from their tech comm roles entirely into a usability role. Theresa Putkey, a Vancouver-based technical writer, made this transition. I spoke with her about how she did it. She said,

I was doing the technical writing. … I had been telling these [project] guys, this UI is really bad. I don’t even know how you could have thought of this. Of course I said it nicer than that. Like, this is a good first attempt, but if you really want to do it well, this is how you can do it. So when they wanted to [start another project] with requirements and usability, they didn’t have anybody to do it, and I said I’ll do it. Because that’s something I’m interested in. Since it was a small team, they said that’s great. And I got along with everybody. So that’s how I started doing the usability stuff. Started designing the UI and writing the specs for it. And then also doing the technical writing at the end.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

I interviewed about 12 people this year. I seem to have a knack for this — tracking people down, asking if I can interview them, getting them talking, etc.

Actually, it has taken me three conferences to get this right. Last year, at Doc Train West 2007, I didn’t have the right setup. I tried using a lavalier mic attached to the mic port of a Mac I borrowed. But I didn’t realize the Mac wasn’t reading the lavalier; it was using a built-in mic.

Then at the STC Summit in Minneapolis, I had the right equipment (a portal Zoom H4 recorder), but by and large I interviewed the wrong people in the wrong places. I did interview some presenters, but I spent too much time interviewing attendees.

This year at Doc Train West 2008, I had the right equipment and I talked to the right people in the right spaces. And it worked extremely well. I give you this advice if you ever try recording live interviews at conferences:

• Buy an H4 Zoom recorder.
• Use the built-in mics rather than an external mic.
• Interview people who are giving presentations.
• Find a quiet room where you can sit down with them.

Really the key is to interview presenters, because they automatically have something to say. They have a message they’ve been cramming and practicing. Conversations flow naturally, and they give you great content. In contrast, attendees have much less to say.

By and large interviewing is weird. I’m not a radio geek, I never did audio as a teenager. I just fell into podcasting and became a podcaster. It takes some tact and boldness to interview people at conferences. I think I learned this skill as a missionary in Venezuela — a two year period where I spent almost every hour of the day talking to people I didn’t know. Strangely, there are a ton of comparisons between being a missionary and seeking people to interview as a podcaster. You have to open your mouth, even when you’re shy. You invite them to sit down and talk with you. You have to initiate contact and be a good listener. Okay, enough of that.

But seriously, it gets even weirder because now that I work for the Church, I had “LDS Church” printed below my name on my conference tag. This only adds to the questions. One person, seeing my name tag, shared her frustrations with the FLDS situation. Another person asked if I write religious tracts. Another said he was converting all of Scientology’s documentation to XML. Several people asked if the Church has software and wondered exactly what I do.

The frequency of the last question (does the LDS Church have software?) is a little perplexing. Let’s say you work for a company with 13 million employees, scattered across the globe, speaking 100+ languages, meeting in thousands of buildings, 120+ special conference centers, with complex financial contribution system, facilities maintenance, an ambassador program with 60,000 nomadic people spread out in geographically diverse locations, with some in delicate states of health. Not to mention numerous external properties, ranches, investments, and other equities. Also include hundreds of committees, with dynamic reporting and information sharing needs. On top of all this, add a twice-yearly general conference held in one location but distributed via satellite, TV, and radio across the globe, translated almost immediately, with a web distribution and extensive resources online. Not to mention handbooks, manuals, pamphlets, and other literary materials, videos, and CDs in multiple languages. Would a company like that need any kind of software to manage all that? Heck yes! Actually, it’s a miracle that there are only 4 technical writers (and a lot of non-technical writers).

But enough of that. More on the conference. One of the incredible things about blogging is that it really does build relationships. This is especially noticeable at conferences, when you meet people whose blogs you’ve been reading and you immediately feel like you’re a close friend, even if it’s a first-time encounter. I feel I know tons of people at these conferences. I got to meet Theresa Putkey and Alan Porter for the first time, who I just recently interviewed. I met other podcast listeners. One listener (“Lisha“) sat next to me in the same session and showed me the latest podcast she’d downloaded to her computer.

Were the sessions good? As good as any. I’m not sure how it happened, but my attention span during sessions has diminished greatly. As soon as a presenter starts droning away at a long bulleted list on a PowerPoint slide, it puts me to sleep. I open up the laptop, check Gmail, Twitter, and before you know it, I’m only half there.

However, when I’m interviewing someone for a podcast, I’m completely engaged. This is because I get to direct the topic and tempo of the conversation. If the interviewee starts to go in an uninteresting direction, I ask a question that brings it back onto the main raceway.

The light bulb moment for me happened during one of these podcast interviews. I was talking with Noz Urbina, who delivered a keynote one early morning. (By the way, when I explained this light bulb moment to my wife, she had little response and later said it was somewhat obvious. Many times the groundwork behind realizations, she said, are laid by numerous experiences, brought together by a simple observation someone states. She’s right.)

Noz explained that as technical communicators integrate Web 2.0 feedback mechanisms to gather information from users — whether through comments on blogs, contributions to wikis, posts on forums, or other ways — the technical communicator transforms into a much more integral player in the user interface design, the task workflow, and the feature roadmap of the application.

Essentially, when you connect with your users in an integrated way, you become the business analyst, interaction designer, and product manager all in one. You suddenly know what the users want, what the users are experiencing. You are not just writing tech docs. Dude, you are leading the direction of the product!

And as you accrue this user experience knowledge, you begin to influence the project team in the direction they should be going. You become a leader rather than a follower. You aren’t simply one who takes directions from an exec who isn’t connected at all to the user base. The execs begins to come to you for information.

As I mentioned earlier, numerous other experiences laid the groundwork for this realization. In my current role on the User Education Team, I write tech docs, online help, quick reference guides, and role-based guides. But I also give training sessions to users, act as a point of contact when users have feature requests or problems, and take occasional support calls when users are confused.

I’ve been taking all the information I receive and channeling it back to the project leads. And I’ve noticed that I am contributing user feedback 100 to 1 (compared to what others send). I’m doing much more than simple technical writing.

As such, the term “technical writer” no longer describes what I do. Not even “technical communicator.” Right now I’d take any wacky term, just to remove the stereotype that a technical writer’s job is to “write documentation.” Information designer, content strategist, user information lead, or whatever.

My light bulb moment was to realize that web 2.0 would forever change the role of the technical writer. The more I enable user feedback and content, the more I will understand users, and the more I understand users, the more central role I’ll play in defining product roadmaps, guiding interface design, and making other key decisions.

The strange thing is, I don’t even have any Web 2.0 formats integrated in my help. I deliver static content — online help, quick reference guides, and user guides. And live training. Once I flip on the Web 2.0 switch, the amount of feedback coming in will triple or quadruple, I’m sure of it.

I also attended several sessions on wikis, including one during the Unconference. The more I listened to Stewart Mader, the more I became convinced that wikis are the way to go. I’ve decided to go in a similar direction with my help deliverables. We have SharePoint 2007 at my organization, and as bad as Microsoft products sometimes are, they got many things right with SharePoint 2007 — namely, blogs, wikis, RSS feeds, and comprehensive search.

I plan to put my documentation into a wiki format, add a product blog, and drive users to this SharePoint site for documentation. Even though Atlassian Confluence offers better wiki functionality and WordPress offers better blogging, I’m using the SharePoint platform for a number of very convincing reasons:

• My organization already has SharePoint technology, and as much as we’re open about tools, getting a non-standard technology approved and implemented has proven to be difficult.
• SharePoint’s search looks at content both in the wiki and the blog (and any other site resources). This is critical, and is the reason I’ve not formalized a blog yet — it couldn’t be integrated with the Madcap Flare webhelp I was using. Having one search that finds all help content is paramount.
• SharePoint’s wiki allows you to introduce columns (metadata) and sort by those columns. This can help keep a wiki organized and prevent it from degenerating into an “unmitigated disaster,” as another conference attendee described her company’s wiki.

Overall, usually applications either excel at blogs or wikis, but not both. You compromise with one or the other. I’m willing to compromise, and I plan to experiment with any SharePoint blog and wiki plugins I can harness to increase the functionality.

SharePoint interfaces can be radically modified, so I’ll be exploring SharePoint Designer to see just how easy that is. However, one thing Stewart said has really stuck with me:

Content is what matters most.

The wiki doesn’t have to look like a professional website to serve its purpose. As long as the content is accurate and relevant, users will benefit — even if the interface is simple.

Did I have any other conference epiphanies? Not really, but I’ll leave you with a small growing idea that I secretly enjoy even without hard evidence — bloggers are cool people. Darren Barefoot, a prominent blogger, delivered a keynote and participated on the Meet the Bloggers panel. Although I only spoke briefly with him, he seemed like a cool person, as did other bloggers I met at the conference (such as Anne Gentle, who organized an Unconference, and Sara O’Keefe, who was doing some impressive live blogging).

Dare I say that bloggers are more engaged, passionate, commonsensical people? Anyone who is engaged enough with a topic to write constantly about it usually ends up being a fun person to listen to. Their passion drives them.

—-

airplane photo from ecstaticist

In this podcast, Noz Urbina talks about how Web 2.0 is changing the role of the technical communicator into one who drives product R&D and interaction design. My discussion with Noz was a light-bulb moment for me at the Doc Train West conference.

Podcast topics include the following:

• How the role of the technical communicator has evolved into a diversity of roles
• How awareness of user needs and requirements allows technical communicators to get involved in product R&D and user interaction design
• How implementing a backwards flow of data from hundreds of internal and external users changes the role of a technical writer to one who aggregates, synthesizes, and ensures quality rather than one who merely writes
• How the technical communicator becomes the keyholder on the pipeline of customer data, which in turn allows the technical communicator to direct and define the product
• How to encourage a culture of participation through surveys and other user interviews

Noz is a business development manager for Mekon. He’s also heavily involved in X-pubs.com, a nonprofit conference and information resource that produces seminars, online events, white papers, and annual conferences.

To contact Noz, send an email to noz.urbina@mekon.com