Blog Archives
What I get from speaking at conferences
I’m in the throes of composition. My presentation for STC Summit 2014 is in good shape, and I’m working on the proceedings paper right now. I got to thinking about why I put myself up for speaking at conferences. It’s a lot of work! Is it worth it? I also saw a post from Neal Kaplan, who doesn’t get conferences. So I decided to blog my thoughts.
If you’d told me five years ago that you’d seen me speaking at a conference, my reaction would have been
Ha ha, nope, that must have been some other Sarah.
Public speaking scared me to death. (Actually, it still does.) I never thought I’d be able to do it. Simply standing in front of a handful of peers turned me into a blob of jelly on a roller coaster.
Then Joe Welinske asked me to speak at WritersUA in Seattle in 2009. Of course, I said “Eek, no.” But Joe’s sweet persistence persuaded me to think about it. After all, he said, I knew a lot about what was then an emerging technology for technical writing: wikis. A few days later, Joe asked me again. To my utter horror, I said yes. My thinking went along these lines: I know no-one in the US. I’ve never even been to the US. If I make a total fool of myself, it doesn’t matter. No-one I know will ever know. 😀
I survived WritersUA 2009. And now, five years later, I’ve spoken at twelve conferences.
Oft-discussed benefits of attending conferences include:
- Peers: Meeting other tech writers has been hugely rewarding. It’s especially great to meet in person the people I’ve bumped into on blogs, Twitter, and other online meeting spots.
- Learning: Conferences seed ideas. I see what other people are up to, get a glimpse of new technologies, peer at different products. A while later, an idea pops up about something I can use in my own environment.
What’s the benefit of speaking yourself?
Getting funding to attend the conference is a big one. For me, living in Australia, the travel costs are too big to cover personally.
But for me, the biggie is this: Putting together a presentation makes me think about how others see what I’m doing. It makes me look at my own work, and that of my team, in a new light. It gives me a wider perspective. It firms up my own opinions on what are good procedures to follow, and what could do with tweaking.
So, a call to all conference speakers: why do you do it? 🙂
Technical writers and public speaking
Technical writers and public speaking – a match made in heaven? We have the knowledge about and passion for our field. We can safely put one word after another without causing mayhem. But can we stand up and speak in front of a crowd? More importantly, what would we do when confronted by a chandelier?
To find out whether you can do it or not, try Scott Berkun‘s book, Confessions of a public speaker. I’ve just finished reading the book, with great enjoyment and plentiful note taking.
Technical communicators who do it already
Anne Gentle, Janet Swisher, Tony Self, Rhonda Bracey, Char James-Tanny, Tom Johnson, Sue Heim, Joe Welinske, Ellis Pratt, and many more. All excellent speakers and presenters. Perhaps most people reading this post have a public-speaking story to tell, either of horror or of triumph. 🙂
Until two years ago, you could have blown me down with a feather duster if you’d told told me that I would speak at a conference. Then I met Joe Welinske and started blabbing about my love of documentation wikis. There was probably a lot of arm waving and even a bit of in-place leaping about. Joe quickly suggested that I speak at the next WritersUA conference. I remember silence. I probably went pale. But I must have said yes, because within a few months I found myself on stage. To my absolute astonishment, my presentation went reasonably well. Since then I’ve presented sessions at a few conferences, and I enjoy the experience more each time.
At work, our team has decided to investigate public speaking as a way of sharing our experiences with others and of learning from others too. I tweeted about this during a #tcchat on Twitter, and Andrew Frayling recommended the book, Confessions of a public speaker, by Scott Berkun. Andrew is right. It’s good.
The terrors of public speaking
One of the very first things I learned from Scott’s book is that fear of public speaking is a good thing. It’s your body’s way of preparing for a challenge. Without it, how would you cope when “a legion of escaped half-lion, half-ninja warriors fall through the ceiling and surround you, with the sole mission of converting your fine flesh into thin sandwich-ready slices”? (Page 16.)
Now, that may sound a bit of a stretch. But think again. Towards the end of the book is a set of stories of the situations some hapless speakers have faced. Dan Roam was on stage in Moscow when “six balaclava-hooded and heavily armed OMON troops (Moscow equivalent of a SWAT team)” burst in, grabbed an audience member and marched out again. (Page 184.) That story makes the average tech comm conference seem a little quiet.
It is strangely comforting to read a list of things that have gone wrong for other speakers!
Another of the stories, called “Watch your slides”, is told by Gerv Markham. His laptop with slides, and all his other luggage, was stolen in a subway station when he was on his way to give a presentation. Since then, Gerv always takes a cab.
Gerv’s experience reminded me of what happened just before my very first presentation ever. It was also my very first trip to the United States. I took a cab from the hotel, and unwisely let the cab driver put my laptop bag in the trunk with the rest of my luggage. When we arrived at our destination, the driver jumped out, grabbed my bags before I could get to them, perched the laptop bag on top of the suitcase, and then turned round to me for his fare. The laptop fell off the suitcase with a loud thump.
When I opened the bag, I found that the laptop casing was squewed, the DVD drive was permanently jammed open, and there was an ominous rattle coming from deep inside the computer. But, wonder of wonders, it booted up and worked. So I left it like that. I didn’t even try to fix the DVD drive or straighten anything at all, until the presentation was over and I was safely back in Sydney.
So, Gerv, cabs are not safe modes of transport for presentations either. 🙂
Good solid advice
Scott’s book is full of stories, and it’s full of tips too. The advice on page 19 rings true with me, about the importance of practising your presentation thoroughly. Page 21 has some great tips about how to prepare immediately before your speech.
I loved the description of the importance of a title. It “divides the universe into what you will talk about and what you won’t”. (Page 61.) And there’s an inspiring description of the only moment when you’ll have the full attention of everyone in the room: the silence just before you start speaking! (Page 80.)
Scott reveals a mild obsession with and definite antipathy towards chandeliers. (Page 40-4.) But hey, we’re all entitled to our oddities. 😉
The book emphasizes the importance of simplicity. This is something close to a technical writer’s heart too. On page 162, Scott explains that it is our duty as speakers to simplify and clarify our points. The audience should not be doing the hard work. We should.
Thank you Scott
Thank you for a good read! I’d like to be in a room and hear Scott speak, putting all these techniques into practice. Especially if there’s a chandelier in the vicinity. 😉
WritersUA 2011 wrapup – a great technical communication conference
This week I attended the WritersUA 2011 Conference for Software User Assistance in Long Beach, California. For the past few days, I’ve been blogging about the sessions I attended. This post is a wrapup and a big “thank you” to Joe Welinske and all the conference organisers.
This is the second time I’ve attended this conference, and I enjoyed it even more than first time. Walking around and talking to everyone else, I saw nothing but happy contented people. Thank you Joe and all the people who put so much work into organising this excellent conference.
The sessions
Over a period of three days, we could choose from five sessions per time slot. All were high quality presentations covering a wide range of topics of interest to technical communicators.
Here are links to my blog posts about most of the sessions that I attended. Some sessions were essentially hands on or interactive, and I didn’t blog about those.
- WritersUA 2011 – Out of box experiences to delight your customers
- WritersUA 2011 – Best practices for embedded UA
- WritersUA 2011 – Using social media to get readers involved (this was my own presentation)
- WritersUA 2011 Tuesday – HTML5
- WritersUA 2011 Monday – Design and tools for eLearning
- WritersUA 2011 Monday – Adobe RoboHelp’s commenting feature
- WritersUA 2011 Monday – Hotrodding your online help
- WritersUA 2011 Monday – Quick survey of technical communicators
- WritersUA 2011 Sunday – Social media for the technical communicator
There were many more sessions that I missed, because we had five per time slot. Luckily, other people are blogging about them too. Here are some links. Let me know if you know of any more!
- Chuck Martin has written a number of posts on the 2011 WritersUA Conference Blog.
- Rhonda Bracey has posted great summaries of day one, day two and day three.
The people
This year there were 360 attendees. Eight of them were from Australia!
The place
We were at the Hyatt Regency hotel in Long Beach, California. The Travelling Worm was at the conference too and has posted more pictures and words on his blog.
Networking
Quite apart from the conference sessions, I really enjoyed meeting up with people from all over the world. It was especially good to catch up with people I met at the last WritersUA conference.
At lunch time, each table had a designated topic. We could choose which table to sit at. On Monday, I chose the “agile” table. That’s not a table from the Faraway Tree that hops around while you eat. Nor is it a table of meals for the super fit. 😉 Instead, it was for people working with, or soon to be confronted with, development teams using one of the agile development methodologies. It was great to chat to technical communicators who are working with agile development teams, and who are at various stages of integrating the technical documentation tasks into the agile process. These are some of the points that came up for discussion at the table:
- In an agile team, the idea is that there are no specialists. Each developer, in principle, should be able to pick up any of the stories or tasks. How does that work when there’s just one technical writer (or, as is so often the case, half a technical writer) on the team?
- The tools that a technical writer uses are different from the tools that the other developers are using. Indeed, technical writing tools can be a barrier to allowing other team members to contribute to the documentation. I raised the point that a wiki helps here.
- What happens when the technical writer is away for a sizable portion of a sprint?
- Some development teams react negatively when told that the documentation tasks are now part of the definition of done.
- How can you finish the documentation for a story in the same timeframe as the development of the UI and the other software components for that story?
- It all comes down to the skill with which you define the stories that make up a sprint.
Peer showcase
The WritersUA peer showcase, on the last day of the conference, offers another opportunity for swapping ideas and information. If you are hosting a session at the peer showcase, you sit at a table for two hours and people drop by in groups or individually to see your project.
There’s also an award for the most innovative peer showcase project. I was completely overjoyed when my project won the award this year! (It was all about using social media to get your readers involved in your documentation.)
Fun stuff
The entire conference was fun! (Well, once you’ve got over the inevitable attack of nerves if you’re presenting a session yourself.) There are some special events to add extra lustre.
Dave Gash hosted the infamous Geek Trivia Quiz. (Click the pictures to expand them.)
The other outing not to be missed is the Australian Cultural Event, not to be confused with Australia, culture, nor even really an event. It’s more like an explosion of Ozzies and would-be Ozzies. Kiwis are tolerated too. 😉 The intrepid Tony Self is in charge. More or less. This year, remembering the penchant of his charges to become confused and lost towards the end of the evening, or even at its start, Tony came equipped.
Perhaps we’ll leave it at that point of the evening, when things are still relatively clear in everyone’s head. 😉
WritersUA 2011 – Out of box experiences to delight your customers
This week I attended the WritersUA 2011 Conference for Software User Assistance in Long Beach, California. On Wednesday Cathy Moya gave an awesome presentation on “Designing out of box and first time user experiences to delight your customers”. This blog post is derived from the notes I made during the session. If you find any inaccuracies, they’ll be mine.
Cathy works at Microsoft Hardware User Assistance. Her talk was all about OOBE (“ooby”) and FTUE (futooey”). She pronounced those two acronyms as words rather than individual letters, and with a big grin. They stand for “out of box experience” and “first time user experience”.
Introducing Cathy’s talk
Cathy started out by saying, “Remember that feeling you had, as a child, when you got a present?” She brought out a big box of child’s toys. Then she said, “And the disappointment… when you had to go find scissors to snip the plastic, or to unfasten the doll’s hair?”
“Sometimes, these barriers are necessary. Sometimes the out of box experience has to be a bit tedious. But sometimes, it is beautiful, magical. That’s what we want to talk about today.”
In her presentation, Cathy gave us examples of great OOBE and FTUE. She said that when she got into the Microsoft hardware user assistance area, it was the first time that she really looked at the OOBE. She is now responsible for designing the OOBE for Microsoft customers.
OOBE in the product lifecycle
Cathy sketched out the full product lifecycle and showed us where OOBE fits into it.
- First, there’s a need. The customer needs something, and they know what it is.
- They may research the product, to find the one they need.
- Then they acquire it, or someone else acquires it. That’s an important distinction. You may have several audiences that you’re trying to please.
- If it’s a physical product, someone has to unpack it. Even if it’s not a physical product, they have to get it somehow, via download or delivery.
- People need to set up and configure or even customise the product.
- A person uses the product for the first time
- A person or people continue using the product for a period of time.
- Eventually they discard the product.
OOBE includes these parts of the lifecycle:
- Unpacking the product.
- Setting up the product.
- Using the product for the first time.
Who cares about packaging or unboxing?
Cathy said there’s a large group of people out there who care. Do a Google for “unboxing”. 11.7 million results, and climbing!
Why should we care?
Cathy suggests that a good OOBE will:
- Make your brand stand out.
- Reinforce the perceptions people have about your brand. Create an overall experience for customers that makes them feel good about the product.
- Reduce support calls.
Identifying your stakeholders
It’s important to find out who your stakeholders are and to work with them. Cathy works with a large number of stakeholders, including:
- Designers of the structural packaging
- Marketing teams
- User assistance teams
- Industrial designers, and environmental and recycling engineers
- Retailers
- Safety and compliance engineers
- Software developers, QA, product management, and so on
Defining your goals
Cathy called these the “experience goals”. That’s what Disneyland calls it, and that’s the level that can differentiate you from your competitors.
When defining your goals, consider your audience (all the types of people involved), your brand, the location and method people will use to buy the product (Amazon, off a retail shelf, and so on – different retailers may request specific packaging types), and where the customers will set up the product.
Most importantly, consider your priorities for your OOBE (for example, batteries in the pack) and the pitfalls that people must avoid (such as throwing away the batteries with the packaging).
People should be able to just start at the beginning and work through to a successful conclusion.
Cathy said with a grin that she aims for a “yellow brick road rather than a scavenger hunt”.
The OOBE
Now Cathy dived into each part of the OOBE in detail:
- Unpacking the product.
- Setting up the product.
- Using the product for the first time.
Unpacking the product
Cathy took us through a number of examples of good and bad products.
For example, good OOBE offers with easy-to-open packaging, such as clear marking to show where to start pulling the tab. She mentioned “wrap rage”, and the fact that some wrapping actually hurts people. The best thing is when you need no tools to remove the packaging
She showed us the infamous Windows Vista box. Evidently there’s even an online guide on how to open the packaging. (I found it here.) But the guide actually leads people astray and makes it harder to open the package. And this is after all the user testing that was done. (It was quite refreshing that a person from Microsoft came a highlighted such problems with their own product. Cathy was great, with wry smiles and candid humour.)
In contrast, the Wii packaging makes it very clear how to open the package, and it’s easy to do.
The Kindle is also great, in that it offers an integrated experience. The guidelines for using the Kindle are on the Kindle itself, clearly visible on first use.
It’s also good to minimise the waste of packaging material. If you can use the packaging for something else too, that’s great.
Setting up and configuring the product
(Woohoo, Cathy mentioned my Peer Showcase presentation here: Using the Dragon Slayer documentation to turn a negative experience into a cool, fun experience. she said, “This is some of the magic that we have the opportunity to do in setup.” Thanks Cathy!)
Cathy listed the important things to do in the setup guide:
- Tell people about the dependencies. How will they know about the steps they need to do before other steps?
- Make it easy to find the setup. In Windows 7, you just plug in the computer. This is great.
- Don’t make people swap between different media. For example, when they move from paper to screen, they should stay on the screen from that point onwards.
- Be careful about what belongs in each phase: Setup, configuration and first use. Generally, if it’s something that people absolutely must do, put it into setup. But if it’s user-specific, put it into the first use, such as setting up your personal colours.
- Manage the time and make sure that the proceduredoes not take an unacceptable amount of time. Group together the sections that require user input.
- Make sure your users feel that they are in control. Give them a progress bar that shows a realistic indication of progress.
- Let them know when the setup is finished. If possible, launch the product. If it’s a suite of products, tell them they’ve finished and suggest the next step for their first use experience.
- Use “forcing functions” to prevent common errors or mistakes. For example, different types of cable have different plugs so that it’s impossible to put them into the wrong sockets.
- Respect people’s privacy. By default, select the most secure and private options. Give people minimal but enough information to make an informed choice, if they do have to make a decision.
Examples:
- Facebook offers 3 steps, every one optional. If you do them, you will have a much better experience because it will find your friends for you.
- Kinect requires some setup. This is the Xbox game where you are the controller, meaning that you don’t need to touch a physical game controller. You do have to go through the 3 setup steps, but it’s clear exactly what they are and it walks you through the steps.
First use
It’s show time, said Cathy. This is the stage, the moment for your product to shine. Unfortunately we often use this opportunity to make people do unnecessary housekeeping, such as product registration.
Instead, we should go back and examine our priorities, and get people right into the product.
Games are a great example. They tell you where you can go for more information if you want it, but you can choose just to jump right in. You start gaining points immediately, and the game rewards you at each stage.
Provide just enough structure. Tell people what steps they can do now, and a suggested order they can do them in.
Facebook does this well. It also offers a tour.
When things go wrong
What if things don’t work as expected? Part of your OOBE design must consider what happens if something fails.
Cathy told us how she had gone to the Quicken helpdesk late at night when she had a problem. She was waiting for someone to pick up her call, and the helpline started telling her about common problems and their solutions. One of those problems was hers, so she had the answer without even needing to speak to someone.
How do you know if you’ve got it right?
Cathy listed a number of techniques we can use to judge whether we have succeeded. I didn’t have time to note them all. Here are those that I did jot down:
- Get your competitors’ products, install and use them to see what they’re doing.
- Look at your website and your community.
- Do surveys.
Microsoft Touchmouse
This section of Cathy’s talk was a really cool walkthrough of the OOBE for Microsoft’s new Touchmouse. I haven’t seen it before, and it was great to see a live demonstration.
It’s a mouse, with left click and right click. But you can also use gestures, instead of pushing buttons.
It’s exclusively for Windows 7. This information is right on the box, because people really need to know it.
The packaging is a transparent box, so that you can see the mouse. Microsoft had learned that people wanted to actually see the product. Feedback was that this made the product feel like an expensive piece of jewellery.
The inside flap also gives some information on how you interact with the mouse.
There are “break the seal” labels, one on each side. Then the whole top pops up. This builds on that “jewellery” experience.
Cathy showed us how to remove the mouse and the batteries. She walked us through the design and usability testing they had done, to design the procedure people need to follow to install the batteries into the mouse. Then there’s a nano dongle that fits into a compartment in the mouse. They don’t ship the dongle inside the mouse, because then people won’t know about it. Instead they instruct people to put the dongle into the slot.
The UA is also in the box, in the form of a booklet. Cathy walked us through the design of the booklet, with diagrams up front and then textual instructions. (At the moment, they’re still full of “lorem ipsum”.) 🙂 Throughout the book, there are a lot of diagrams showing the user’s hand in relation to the device.
When people finish setup on the computer (accept licensing agreement, etc) you see the “Mouse Properties” window, displaying videos that show you how to interact with the mouse. It looks pretty cool. I’d love to try one. You just gesture with your fingers to flip through pictures, and so on.
Cathy says that user testing shows that they need even more than they have right now, to help people integrate the new mouse into their lives.
Summing it up
Cathy ran through the main points of her presentation. Her very last point was:
“Build it so that users can’t mess up.”
She pointed us at a YouTube video of “the best unboxing ever”. 😉 Samsung Omnia i900.
As a finishing touch, Cathy drew some prizes for members of the audience. She had given us each a raffle ticket at the start of the presentation. The prizes were the various toys that she had used to demonstrate packaging. A nice touch!
My conclusions
Thank you Cathy for an awesome, funny, riveting presentation. Wrap rage or wrap rapture, I’ll look at packaging design with new eyes from now on.