I fell in love with soap in 2015. No, not that material you use for washing. The technical communication conference in Kraków, Poland, called soap! with the lower-case “s” and the exclamation mark.
I returned for the 2017 soap! experience, which is what I want to share here. I am providing a summary of the conference design, some useful links for additional reading, and all my personal, rather raw notes from the talks. Those are shared “as is”. If you wonder what I meant by something, leave a comment!
I hope some of the information here will inspire you to consider joining the “soapy” community next year in Kraków.
Note: This is a very long post because it covers two days of info from a conference. I wrote it as a reference article for storing my notes.
Where can you find more information about the soap! conference?
The soap! team has a great video summary of the soap! 2017 conference. Watch it if you think this post is too long and too much to read, or watch it for inspiration for your first or next attempt at summarising an event with a nice video.
Other links are:
- The soap! conference site
- The soap! Twitter account: @soapconf
- The soap! Facebook account
- The soap! YouTube channel with playlists of all the speakers and talk teasers that were posted prior to the conference
- My own soap! photos on Flickr
What is the structure of the soap! conference?
This conference is run by a dedicated group of volunteers and supported by some great sponsors and a registration fee. The conference ran for three days with the main conference on Thursday, 8 June, and Friday, 9 June. On Wednesday, 7 June, there was an all-day Edu Summit filled with workshops ranging from one hour to seven hours. The Edu Summit was only open to the main conference attendees. Topics ranged from DITA to UX to structured authoring.
On Thursday and Friday, the conference ran from 9.00 to 18.00. The doors opened half-an-hour before so attendees could grab a coffee and a bite to eat and say hi to the other attendees.
The location was perfect for this time of year. We used the conference room at the beautiful Manggha museum on the banks of the Vistula River, just across from the Wavel Royal Castle.
The skies were blue and the weather was just right for all three days, with the clouds staying away until we all dispersed after the conference. Sitting on the terrace outside the Manggha café with that lovely view seemed to keep the conversations going non-stop.
This volunteer-run conference also included great evening events: bowling after the Edu Summit, a concert on the banks of the river at the end of Day 1, and a brew pub (T.E.A. Time) after the conference.
The conference always has a theme. This year’s theme was “problem solving”.
They solicited our thoughts for the theme for 2018. Four proposed themes were written up on a whiteboard, and we could vote for a theme with soap! stickers. “Artificial intelligence and content” won the popular vote. Now the committee will evaluate how to make that work as a theme for the 2018 edition of soap!.
What is so great about the soap! conference?
I have to quote one of the speakers, Oded Ilan, on this. He summed up my sentiments in the video summary of the conference.
I see so many young people engaged and interested in [this technical communication field]… That’s the most powerful thing I saw at this event. – Oded Ilan
Why is it called the soap! conference
I learned about the soap! name at the 2015 conference. Gosia Radymiak, head of the soap! team and conference, said it was a fun idea that came up in conversation. They called it “soap” to stand for strategy, opportunity, advancement, and professionalism. Think of it as a fresh, clean start, said Gosia. “It’s something we can relate to, something we ‘just gotta have’.” I think a lot of writers know many manuals that could use a good scrub to get a fresh, clean start! It’s a great analogy.
What was the biggest takeaway from the soap! conference?
It’s all about people and communicating with people. Talk to people. Learn from people. Those people can be those using your products or services and they can be those you work with every day. They can be those you work for or those who work for you.
The talks – my notes and the videos
The remainder of this blog post is a list of all the talks in the order that they were presented along with a link to the video of their presentation and whatever (raw) notes I took.
- User documentation vs loser documentation: Great content, no readers?—Dirk Göhmann & Cate Mackenzie
- What the tag? From Wiki to DITA CMS in less than 80 days—Barbara Szwarc & Justyna Adamczyk & Mateusz Wiktor
- The yin-yang of technical writing. Solve your problems to the user’s advantage—Jarek Orłowski
- “Done! Oh, wait… we need translation.” Facilitating content translation process—Dagmara Szostak
- Finding your way back from Documentation Mordor—Natalia Katryńska
- More than just a technical writer—Maryland Sara
- Problems you can solve and create with DITA—Patrick Bosek
- Documenting microservicesŁukasz Górnicki
- No documentation strategy? Build one from scratch! —Tomek Prus
- Need more problems? Start localizing videos! —Anton Bollen
- What 1000 participants taught me about productivity—Piotr Nabielec
- Overcoming the Forgetting Curve: New Content Creation Paradigms—Oded Ilan
- Quality technical training – Making things happen—Szymon Serwatka & Gosia Pytel
- Always open – Open source documentation with open tools—Meike Chabowski
- Reducing waste in a project with conflicting needs. The story of the 33 miners—Adam Sanyo
- Our content sucks, right..!?!? —Alan Miller
- The Convergence of Marketing and Technical Communication—Stefan Gentz
- Customer success and UX – The ultimate tag team—Paddy McShane
- Remote Collaboration for Introverted Geeks and Misanthropes—Brad Schmidt
- How to turn local success into global failure—Marta Bartnicka
- Rethinking your content. Happifying through improved usability—Joanna Malicka & Tomasz Poznanski
- Keynote: Inspiring action through content leadership—Kristina Mausser
User documentation vs loser documentation: Great content, no readers?
With Dirk Göhmann and Cate Mackenzie from Appway, Switzerland
See the recording of Dirk and Cate’s talk on the soap! YouTube channel.
Great title! You can have great content, but no readers! So true.
What direction do you want to go in? Do we just want to produce great content? Written and published a manual and that’s it?? That can actually be loser docs. No one is interested in it and it never really gets to the reader. How to get USER docs.
Four areas they looked at – the journey they are on:
- Findability
- Analytics
- Testing with users
- Engagement
1. Findability
Used “Find Waldo” to illustrate situation. The user needs get lost in the chaos. Can you avoid this with “site search”?
What factors are there for your site search?
- Scope
- Weighting (how to decide what is really relevant)
- Presentation
- refinement
- Maintenance – need we say more?
- Performance – slow response is enough to scare away users
Showed a nice example of their organisation of information. Started with top level of 9 items. Looks cool.
Finally talked about inline links. Careful with using them (I agree), but make a dedicated area for pushing people to other areas (like “see also”, “users also liked”, etc.)
Main takeaways for findability:
- Search is a MUST
- Organise your content (maybe visual)
- Anticipate and link
2. Analytics
How do you know your findability works? The answer lies in analytics. Finding patterns in your data. Measurements are numbers. Metrics puts measurements in context.
Using metrics to answer business specific questions with limited time and resources. What do users love that I should do more of.
Need to clearly define the goal!! Tracking the wrong metrics can be meaningless.
AVOID VANITY STATS! Those that make you feel good.
Measure what matters: What, why, and what. What do I want to learn? Why is this good to know and how can I find that out and how do I implement it and how do I know if it is working? what am I going to do about it.
Ask for help if you don’t know what to do.
Get the measures in there so you have the data ready at some point.
True, measurements can be open to interpretation.
Analytics takeaways
- Have a clear goal in mind
- Measure what matters
- Context
3. User Testing
Numbers can be deceptive. Asked audience if we were enjoying this and nearly everyone said yes. But then Dirk said why – was it because we liked his shirt? So he asked users in audience – give real feedback and that was far more valuable.
Can use a feedback button.
Can use surveys.
Can use face-to-face meetings with real users.
User testing takeaways:
- Make feedback easy
- Bigger picture (surveys)
- Watch users in action
4. Engagement
Would be nice with the roar of the crowds when we publish. When you get negative feedback, it is actually fantastic. I agree. Eye candy. Colours. Font size. Minimal. Different browsers and different devices.
If you do something great – TELL PEOPLE ABOUT IT!
How about a doc-a-thon?! Get people focused even if just for one day on your content.
Do say thank you always.
Engagement takeaways
- Delivery
- Communication
- Travel (go see your users)
During the Q&A, someone suggestion a “Doc Day” somewhat like a doc-a-thon. I have also heard of doing “Raids”, which testers often do to plow through the documentation to check for accuracy, validity, etc. Someone asked for a few examples of metrics. Number of page hits (open to debate – maybe refactor the one with 500 hits, not 5 hits), how many support tickets are related to what areas of your content (no support ticket and no one reading it – hmmm).
What the tag? From Wiki to DITA CMS in less than 80 days
With Barbara Szwarc, Justyna Adamczyk, Mateusz Wikto from SAP Hybris, SAP Hybris, Braintribe – Germany, Poland, Austria
See the recording of Barbara, Justyna, and Mateusz’ talk on the soap! YouTube channel.
Why they moved:
Mateusz told a cute love story how they got into a relationship with a system. But then they changed. Number of releases a year changed. Needs for versioning were even more crucial. Reuse became poor. Didn’t have the enterprise solution they needed. Top issues were search, broken links, separation of content and form, and manual, permission-based release process. Started to notice a collaboration tool is not a documentation tool. At least not for their product. Growth in the company wasn’t accompanied by necessary changes in their documentation processes.
The way we moved:
Justyna told how they moved 10,000 docs automatically thanks to scripts from their Uncle Bill. DITA belongs only to the technical writers. Had to convince the developers that the only good docs were produced by technical writers.
Life after the move
Log in via remote desktop.
Add their content to the structured map. Topics, topics, everywhere. Conversion didn’t specify topics so all were topic topics! Topics were rather long. No TOCs. Random tags! Too many tags not rendered properly.
Unclear structure, inconsistent content, problems with scrolling.
Had initial investigate and cleanup. Divided team into committees to tackle the work.
Introduced regular publishing interval so they could improve their docs EVERY week.
This led to changes in mindset. Created better docs from the start.
“Gaze upon my documentation. It is astonishing.” Barbara.
Had to think ahead and plan the work in advance.
Worked more at keeping developers informed. More conversations. “Draw some diagrams together – it will be fun.” 🙂
20 people and 1 DITA expert to do this conversion.
Remember that all this takes time. Need to change mindset of developers, too.
Move was for selfish reasons, first, but they also solved issues for users. Thought it was merely a change of tool. Turned out to be a change of mindsets. Writing is better and more structured. Feedback was extremely positive.
Q: Why 24 hr turnaround for deliverables. Due to a procedure to not overload server perhaps. J said it is because they don’t have dedicated servers for their output. B. said they are planning to have their own servers. Also so many builds put in the queue so it takes a while.
An audience member said he could do it with one writer manually in 2.5 months.
They still use Confluence as their internal tool.
The yin-yang of technical writing. Solve your problems to the user’s advantage
With Jarek Orłowski, Lead Information Developer, Dynatrace, Poland
See the recording of Jarek’s talk on the soap! YouTube channel.
Writes application performance management (APM) docs. His company was previously named CompuWare.
His users are analysts who check metrics and draw conclusions, dev/admins who just install machines, but don’t care about the performance, business (CTOs) who want software to work as expected and sometimes verify this by looking at the docs, support, sales/partners who perform PoCs (one customer is MoD in UK who only allow you to enter premises with a piece of paper – i.e. docs become important).
Started out with DocBook. CompuWare bought up lots of other companies, which meant getting a new ecosystem of tech writing each time!
Ha ha! His company moved from DITA to Confluence.
He published 10,000 topics to Confluence daily and it killed the server.
His stories for his presentation covers
- being the new kid on the block
- being the curator
- working with devs – docs as code
- being customer support assistant
Being new, do you ask how should I write something, why I should write something, when I should write something, and how much I should write? You also have to deal with technology: tools, subject, (domain) knowledge, and processes.
Being the curator means you also deal with content from others.
I like his Death Star picture with an actual quote from a content provider who wasn’t a tech writer: “It is imperative that a full description is provided with as much detail and reasoning as possible”.
Those who make graffiti call themselves writers.
I like his photo of graffiti writers and their work followed by a curation of their work in an art gallery.
Collaborative authoring:
- The hardest step is to step back
- Appreciate input
- Be kind!
- Show the difference (Nodded with neighbour Joanna at this!)
Docs as code – Pointed out word “project” was missing
Immerse yourself in the dev! Be a pig, don’t be a chicken.
Points about code as docs:
- Don’t be a chicken
- Fail early
- Commit
- git not email
- use the same tools
- Code is information
Customer support
You ARE the support – solve problems before your user knows.
Build relationships.
Get feedback.
Continuous improvements (on doc sets and processes)
Communicate early.
Listen carefully: (takeaways)
- Know what you write
- Be a wordsmith
- Your skills are precious
- Users don’t bite
A Polish site for technical communicators: fb.com/uContentowani
Quote on a photo of Kurt Vonnegut sitting on a box marked “SOAP”: “Pick a subject you care so deeply about that you’d speak on a soapbox about it.”
Said everyone is saying that you cannot commit fully to the scrum teams.
He’s not part of Definition of Done – only for UI text.
“Done! Oh, wait… we need translation.” Facilitating content translation process
With Dagmara Szostak, Project Management Specialist, GET IT Language Solutions, Poland
See the recording of Dagmara’s talk on the soap! YouTube channel.
I don’t work directly with translational – I just “write for translation” – but I’d share this talk video for those who have to make decisions about translation and localisation.
Areas where problems may arise:
- Terminology: So important to keep consistent terminology, which is also compliant with the customer’s needs.
- Platforms
- Quality of the source file
- The process
Gave a bunch of tips.
One example told of pain of no versioning.
Don’t embed text in images. Don’t embed images in text.
Advocated style guides (yay!), but had specific recommendations on a slide.
Re: the process and the quality of the source file. Think of the flow of the documents and keep track of the versions and the quality of the files.
Write source content so that it is easier to translate. Simplify, gender neutral, no abbreviations.
Treat your LSP as a partner IN the process & in return you will gain a cooperative partnership & a successful outcome.
Finding your way back from Documentation Mordor
With Natalia Katryńska, Senior Technical Writer, Poland
See the recording of Natalia’s talk on the soap! YouTube channel.
Sharing some documentation demonstrations.
She says you need to prepare your environment, your workplace. Build a doc infrastructure.
[This makes me think of people not following a dictated information model. How to get them back on track. They need to understand that this infrastructure isn’t there to thwart them. It is there to maintain the professional and high quality of the documentation.]
Her takeaways
- Talk with your teammates and get inspired
- Start counting to 3 and automate your work
- Test your solutions
- Enjoy it!
A colleague once told me, “If it can be automated, automate it”. Echoes Natalia Katryńska’s message: Automate your work.
Always open – Open source documentation with open tools
With Meike Chabowski, Documentation Strategist, SUSE Linux, Germany
See the recording of Meike’s talk on the soap! YouTube channel.
They receive info. Then they move to Trello to evaluate, accept, and organise. (Had to get permission from their workers’ council to use it – wonder why? Possibly religiously open source?)
The classic programmer paintings are hysterical!
SUSE has their own style guide.
They use git. All can contribute.
Their DAPS builds the doc and does validation. Would be nice to have.
Oh! They have a style checker. Stylechecker built in-house. Checks re abbreviations, figure titles, sections, terminology, sentence length, nerdy phrases, etc.
LibreOffice OpenOffice has a style checker.
Problems you can solve and create with DITA
With Patrick Bosek, Co-founder & Director of Customer Success, easyDITA, US
Completely missed this talk due to chatting with someone long after the break prior to this session.
See the recording of Patrick’s talk on the soap! YouTube channel.
Documenting microservices
With Łukasz Górnicki, Product Owner, SAP Hybris, Poland
See the recording of Łukasz’ talk on the soap! YouTube channel.
Been at SAP Hybris for 10 years.
He was fascinated by the architecture of documentation more so than writing it.
Compared microservices with a school of fish. Looks like one unit from outside, but has many replaceable units “inside”.
Architecture: Have to build everything from scratch, otherwise you’re doing it wrong (when moving from monolith to microservices).
Designed for the cloud.
Most use REST API over HTTP.
Services are independent, but documented in one portal. So developers’ challenges become yours.
You can write microservices quickly. More are forthcoming and teams are extending. Need to scale accordingly.
Involves continuous development and deployment which adds more demands to the documentation.
Main principle for microservices is “You build it, you run it”, that is, eat your own dog food.
Reasons to become a writer for microservices:
- Ready playground and production environment
- You really become a “technical” writer and you quickly learn things
- Continuous release = continuous feedback = continuous improvement
Talks about “destroying” current doc department/org.
So TWs are real dev team members with the same manager as other team members.
Community of Practice that works together on standards and best practices.
(Quoted Rahel for saying that scrum teams are actually micro silos. True! Gasp.) But he says his CoP helps to bridge that problem.
New scrum team with cool name that consists of documentation architecture, trainers, language reviews,
New scrum team that consists of documentation architecture, developers, and works on doc solution.
Developers start to treat writers as a team member.
Their writers are talking “developish”. So developers begin to really like their writers.
“We can’t release it without documentation. We need to document and talk to Q team to get a language review”
“I don’t like how it is formatted in the UI. We need to talk to the doc team to improve it.”
(mentioned Spotify using scaled agile)
Technical change in theory:
All content stored in git repos with the code.
Documentation and release notes kept together.
Central registry of each doc topic.
Portal template based on static site generator.
Continuous integration plans.
He uses docpad.org – it’s what they use as a static site generator. Has details of API documentation template for DocPad at https://github.com/yaas/docpad-skeleton-apidocs.
No documentation strategy? Build one from scratch!
With Tomek Prus, Documentation Manager, Unit4, Poland
See the recording of Tomek’s talk on the soap! YouTube channel.
He started by just observing.
Implementing a strategy is a long-term job. Made reference to strategy games, which he used to play before he stopped having time to do it!
Starting point for doing this is conducting an audit. Checked for
- Types of content
- Internal stakeholders
- Requirements
- processes
- content quality
- effectiveness of your info model
Checked results of audit. Resulted in among other things creating a style guide and setting up templates for consistency. Also established quality criteria.
Nice to hear he is also part of the Definition of Done. They use Flare, too.
They have 12 different types of docs in their old info model!
Made new model.
Cut out some things from translation which saves time and money.
Pointed out four main areas of documentation to focus on in this model:
- UI Strings / embedded user assistance
- Online help (guide tours, examples)
- Release notes (what’s new)
- Reference manuals (installation, troubleshooting, configuration, system description)
They have 2 test types: by writers and by testers. Writers mainly test that the help is available.
Wow! They do a lot of translation and localisation!
Built strategy pillars.
Important that tech writer is part of team and that translation is a key enabler.
Content must be
- Easy to translate
- Consistent
- Easy to read
- Engaging
- Easy to find
In “Design > Measure > Analyse > Improve > Control” implementation cycle, he emphasises communication!
One of tips & tricks is “Documentation is a part of a product. Always.” Amen.
Need more problems? Start localizing videos!
With Anton Bollen, Technology Evangelist, TechSmith, Germany
See the recording of Anton’s talk on the soap! YouTube channel.
Anton loves video.
YouTube is second most popular search engine – after Google!!!
Bigger use on social media.
tekom survey: 38% using video.
Video elements are visual and text and audio and cultural.
What do you really NEED to localise to achieve your goal with the video?
Factors:
- Type of video
- Audience and expectation
- Content and content design
- Resources
Onboarding videos were so crucial that they decided to localise everything. Too important to ignore.
Cool tip: Made audio recordings for each step in script that were possibly only a few seconds long. That made it super easy for a non-Korean speaker to synch video with audio. Cool! Very pragmatic. Fine for getting started when you have only a few languages or a few videos. It is time consuming and hard to scale. What to do? Design with localisation in mind. (More detail outside scope of this talk, but he had a couple of pointers.
Important: de-emphasize audio narration. Reduces localisation and synch needs.
Captions: Support many languages with a single video file. Captions can actually = more audiences with relatively little work.
To scale up, they went for a translation partner.
A translation partner needs info, context, and guidance.
So they made a video style guide. They also made an enhanced script. Added more and earlier review cycles, made audio pronunciation key. This worked. All this saved about 2 days of back and forth and probably added only 1 hour extra work.
Question: apropos numbers and what they say. what is the 38%. Is it just using videos or is there also written material?
Videos should be short. Only meant to enhance or provide variety and not to replace text. Nice answer!
What 1000 participants taught me about productivity
With Piotr Nabielec, Chief Productivity Officer, Produktywni.pl, Poland
See the recording of Piotr’s talk on the soap! YouTube channel.
We didn’t have smart phones 10 years ago.
8% are systematically planning implementation of priority goals.
4 years ago he thought doing lots of stuff meant being productive and had 13 concurrent projects. Wrong.
2 years ago reduced to 3 projects.
(He does still believe productivity is about having fun, too.)
Plans one week every Sunday. Defines tasks for the week. Brains love it because you have fewer things to think about.
2 recommendations: Asana and Todoist.
His slide of apps doesn’t include Trello because Trello is only good on big screens.
Cut out distractions. StayFocused app!
How do you track progress.
Bad if you cannot answer “what are the 3 most important things that I want to achieve next week”.
What are the 3 most important things that you want to achieve here at soapconf?
Think about spending your time wisely. Can’t spend time like you can spend money.
OKR Object and Key Result
How do we organise “near future” projects – projects are “currently running”, “near future”, “maybe someday”.
Idea: some details.
In Analysis: what is the goal, how do I know when I am done, how do I track progress (I skip this part, which isn’t good).
In progress: Ready to be split into tasks and feed weekly/daily system.
Showed Trello example. He moves 60% of the stuff that moves to analysis BACK into Idea because it’s not the right time to do it. Food for thought!!
Gather materials for “maybe someday”.
Tools cannot ask you why are you doing this? Or tell you that you have too much to do this week.
Q: what to do when outside influences changes your plans.
A: Remember that your influence is limited. Ensure that your stuff is prioritised. Then you can handle the ad hoc stuff by comparing the value of each and help you to prioritise a bit. You might not be able to handle the prioritisation because you don’t have the power, but at least you know where you stand with the things that you do have power over. (Someone from the audience also suggested the pomodoro technique.)
Also do Retrospective every week!!!!!!!
I really enjoyed listening to Piort at soap! 2015. This second talk was also great.
Overcoming the Forgetting Curve: New Content Creation Paradigms
With Oded Ilan, Chief Marketing Officer, Iridize, Israel
See the recording of Oded’s talk on the soap! YouTube channel.
We forget 50% of what we learn within 1 hour of learning it! – Herman Ebbinghouse 1885.
After one week – 70% unless we put it into practice.
Today our world has a lot more data (i.e. a lot to remember or forget).
The way we use the internet is changing our brains.
Do you remember your FRIENDS’ phone numbers??!
Using our brain differently. We find info – finding is a skill. Sifting through that info is also a skill. Recognising what you need now is also a skill!
Stop thinking about people remembering your info.
Start thinking about how people USE info on a daily level.
25-30% of today’s job types didn’t exist 25 years ago.
What’s more important: performance vs retaining.
(My reaction is performance.)
People want to get answers to THEIR questions RIGHT NOW.
Provide only what is needed to hit the ground running. (Classic progressive disclosure.)
Get what you need when you need it and not afterwards.
Info needs to be digestible – entertaining, small bites, relevant.
Supportive rather than instructive training. This means something that is ongoing.
Training should be self-paced and always available.
Metrics (He feels this is SO IMPORTANT) – measure for results and improvement. Just do this! (Diff between training and teaching – doing rather than learning.)
Because tech has changed us, training should support the new human thought process.
He feels contextual content is also highly important. Info available when the users need it.
Micro sessions: small snippets of info specific to what people need and not more. Too much info? – They might stop along the way and not reach something critical at the end.
Personalised content can be good. (Like logging in to FB in the morning and it says good morning and this is the temp.)
Measurement and big-data generated training is another area that he has already mentioned.
I asked a question about metrics – how to find good questions. Ask around in the company. Use intuition to start with. Do A/B testing.
Someone asked about size for tool tips and other UI things. Think of using Twitter philosophy of just a few words.
Useful talk – worth re-visiting in the video.
Our content sucks, right..!?!?
With Alan Miller, Managing Director, Simply Consulting, UK
See the recording of Alan’s talk on the soap! YouTube channel.
Our content doesn’t really suck. Recognition is important to our success. Our confidence, pride, ability, and acknowledgement of our value are key. We must take back the narrative.
Here’s the problem:
Everyone has an opinion (like everyone has assholes).
All the focus on what’s missing or poor. No one looks at what is successful!
But what if it is us allowing this narrative??
We discuss how fresh our docs are. Talk about completeness and accuracy. We discuss our technical acumen. Agree! Can’t use terms like DITA, structure, CMS, etc. outside our own little world.
We’re just framing the discussion the wrong way.
A challenge when you meet criticism – if it was as easy as they say, it would already be done.
Zip up your grown-up suits!!
Lots of talk about customers here at soap! this year. GOOD! Also measuring things about customers.
They value credibility and knowledge about the product.
Have the confidence to truly know what the customer needs – be prepared to hear it firsthand. Like feedback. He would call customers for whom he had fixed a content problem and said thanks and it’s fixed and was there anything else he could help them with.
Define the customer needs simply and share it widely (with your teams/department/etc.)
Summary: start with customer.
You need to know what is stopping customer from purchasing goods. Then stop seeking permission to go and fix the problem. Charge out and set the example by acting on the need.
Leadership needs leaders.
WHO is saying that our content is crappy and difficult to change? Doesn’t help if WE say it. Get people to focus on the why – what the customer is asking about – and let them focus on the what and how. Don’t assign tasks – empower team members.
Momentum is a virtuous circle. If you make small changes, get customer delight, get happier writers, and on it goes. Have success and share it with the people.
Inspire team to understand what the customer needs and empower them to go achieve the outcome.
“Shoo away the magpies” – be wary of bigwigs saying “that is dull, let’s do this – shiny, shiny”. Show them the money.
You want to understand what is working – metrics for you – just enough science to survive.
Whose responsibility was the success? Doesn’t matter. A win is a win! Have confidence in what is happening. Worst you can do is produce great content that isn’t adding value.
You’re on the verge of greatness, does it sound like it? People can see what you do has an impact. Focus on progress even though it is all about outcome.
Why are you explaining this to people? We’re explaining details and not focusing on outcome.
Do the people you speak to deserve your time explaining things – do they deserve to be educated? Don’t get drawn into explain why things are good.
When content providers feel pride, it is a motivator to take on the next challenge.
Also be proud when you hear “content is improving” around you, but don’t say “I told you so”.
Third who will understand things are great, third who don’t understand but know because you told them, third who never care.
This lets you have freedom to operate, recognition, and (possibly) money.
Content is becoming a commercial specialism and a strategic asset.
More than just a technical writer
With Maryland Sara, Information Developer, SAP Hybris, Germany
See the recording of Maryland’s talk on the soap! YouTube channel.
How a tech writer can become a scrum master.
- Expands your skillset
- Adds value
- Leverages existing skills
- Gets more insight
How?
Study the scrum guide (and lessons “out there”)
Connect with other SMs
Learn by doing
Consult other scrum teams (teaches you their best practices)
5 out of 20 techwriters are TW/scrum masters!!!
Their thoughts?
Gain better understanding of a bigger picture
Solving problems and organising things
get an overview of what team is doing
Build strong human relationship
More involved in the project
I like to help my team
What if you are both? Benefits?
Encourages more visibility
Helps you to know your team
Improves your communication skills
Increases the quality of your product and docs
Reducing waste in a project with conflicting needs. The story of the 33 miners
With Adam Sanyo, Senior Information Developer, ARM, Hungary
See the recording of Adam’s talk on the soap! YouTube channel.
Phase 1 create a public beta website and add some of the existing content to the site
Phase 2 (he thinks is most interesting) improve and deliver: improve the wesbtei’s features and deliver live documents
Phase 3 migration: migrate all existing public tech docs of ARM
Waste reduction was also important to point out.
- Created a process for delivery jobs with clear reqs.
- Several related errors were corrected at once.
- Established direct link with developers and taxonomy team.
Quality technical training – Making things happen
With Szymon Serwatka & Gosia Pytel, Learning Manager, Dassault Systemes, Poland
See the recording of Szymon and Gosia’s talk on the soap! YouTube channel.
He uses ReadyTech as the training service in the cloud.
They were 3 people (another one in California) who got 20 people coordinated to make improvements and even add certification to their training program in just 1 year.
Had printed & shipped PDFs. Switched to SCORM packages all online-only.
Went from training server in a desktop to training server in the cloud.
Went from 100% classroom to blended classroom/self-paced online learning.
Developed great working relationships with experts.
Q: Do they get complaints about no classroom?
A: This offering is just one offering. They also have mentors and regular Q&A sessions. They didn’t eliminate humans from the equations. (Q&A webinars sound like a great idea!)
Q: What did they produce?
A: PowerPoint plus SCORM packages. No talking heads. Business reasons: cost. Just went for Minimum Viable Product.
The Convergence of Marketing and Technical Communication
With Stefan Gentz, Worldwide TechComm Evangelist, Adobe Systems GmbH, Germany
See the recording of Stefan’s talk on the soap! YouTube channel.
Still silos about marketing and techcomms. Unconnected. Seems like it’s in the future. Talking about the future is talking about expectations.
Techcomm is changing. People are changing as well.
Transient attention span 12 seconds in 2000. MS study.
In 10 years, went down to 8 seconds.
There were attention impact factors.
Media consumption, social media usage, tech adoption rate, multi-screening behaviour.
60% of visitors to Adobe techcomm page only consume from mobile!!
We need to present info on all channels. Let customer decide where they consume it.
He showed a great example with GoPro Hero5 material. Sexy marketing stuff and awkward tech docs.
They call it blended communication – marketing together with techcomm.
Technical communication is marketing communication. (Yes, think about it.)
As Jarek pointed out in his question, it’s a matter of content strategy to get marketing on board with this.
Customer success and UX – The ultimate tag team
With Paddy McShane, Customer Success Manager, Optimal Workshop, Ireland
See the recording of Paddy’s talk on the soap! YouTube channel.
UX and customer success are the ultimate tag team.
He is a Customer Success Manager. That title really exists! Especially SaaS companies.
They didn’t want just users, they wanted successful users. They looked at other orgs to see what they were doing to achieve success. Looked at those with good user experience. E.g. he uses Slack and feels it works best for him so he is a successful Slack user.
Also looked at those who weren’t successful.
He appreciated the creation of personas from the UX team. Learned the people they were talking to weren’t customers, but researchers.
Learned about language. Knew they were researchers so they knew how to talk to them.
Just say it like you mean it.
Learned his users were researchers, learned how to talk to them. Learned to be careful in the language he used, otherwise he would be found out very quickly.
UX team helped with all this.
“Desired outcome? That’s what you want to do? Use these features to do that…” Have to know Desired outcome so you can manage their expectations. As effectively as possibly, not necessarily as quickly as possible.
At this point, they had info to take back to the UX team. This is what makes our researchers successful so let’s design around this. UX team could go in and cut out the fat. Kept only successful researchers.
He likes the word/concept of friction.
Per Axbom talks about Friction.
Hurdles need to be removed. But Per says this friction is an opportunity to stop and think.
Told of a company that was too fast so not trusted and believed to be inaccurate.
Told of story of wanting to inquire about a B&B in Krakow and ended up booking it before he knew it! Too fast. No friction.
Not everyone needs you and you don’t need everyone. How many actually use your product? No friction might get someone onboard, but then not a user and then not a successful user.
Support – great place to get more input (user research pool) for the UX team to work with.
Reveals what the user will experience.
Support can have potential customers – those who are asking questions because they are close to being successful but not quite there and asking a question to get there.
Demos reveal a lot, too. He’s a super user of their tool. He demos. If he encounters any problems, he is a rich source of info that UX team can also use for improvements.
Use customer success principles together with UX.
Must also know what an unsuccessful customer is. Learned this from their support team.
He had good relationship with marketing. More trouble with sales team, actually. He has got that to change now. It’s about managing expectations and making sure all are singing from the same hymn sheet.
Remote Collaboration for Introverted Geeks and Misanthropes
With Brad Schmidt, Documentation Specialist, MSD, Czech Republic
See the recording of Brad’s talk on the soap! YouTube channel.
When on a call or podcast, be engaged: stand up, smile, & gesture when talking on conf calls!
Cultural awareness goes a long way. Oh yeah!
Virtual Teambuilding is a thing. “Scavenger Hunt” is thing for getting new teams to get to know each other. “Picture This” is about collaborative resolution.
Structure helps! Makes it easier for reserved people to share ideas, opinions.
Identify yourself on calls to help people match your name with your voice. Use people’s names when asking questions.
“Treat others as they want to be treated” – platinum rule!
Being a better collaborator will change how people relate and connect with you.
At some point, someone shared this link which is a Google search for “extroverts understand the value of introverts in the workplace”.
How to turn local success into global failure
With Marta Bartnicka, Manager for CEE, IBM Translation Services Center, Poland
See the recording of Marta’s talk on the soap! YouTube channel.
Covers globalisation, localisation, and internationalisation.
Why worry about translations – because of money (lost revenue, costly adaption later on).
She showed some examples of failures and then an IKEA image as a way to avoid language altogether.
The more global you go, the more factors you need to consider.
She recommends a free reference: IBM Globalization Design Guidelines.
Didn’t know that the owl was a symbol of stupidity in India.
Great link to fun facts about names, that is, what trips up programmers about names!
Some phrases that can trip people up: West Coast, the first day of the week, Christmas time.
Wow! Respect to Polish postal service who managed to deliver a package sent to #%D; (which should have been the city named Łódź)!
Wow. Real story. Phone being tested for Arabic-speaking countries. Could not offer a Hebrew version because it was regarded as offensive.
Rethinking your content. Happifying through improved usability
With Joanna Malicka & Tomasz Poznanski, Learning Services Project Manager, Content Designer – Motorola Solutions, Poland
See the recording of Joanna and Tomasz’s talk on the soap! YouTube channel.
They are from the Learning Department (training). Critical communication for product safety.
Transitioned from PDF to web help.
Followed steps in design thinking.
Talked to the users in regular conversation.
Users didn’t like the jumps from their links or having to use several manuals to fit their imagined scenario.
First issue was about navigation. Based on info model that was a bit old. Cross-reference links were OK at beginning when less complexity. Not now when they have over a million links.
Had test phase where they performed A/B tests. Wanted to avoid putting old content into new wrapper.
Gained immense value from building a prototype and testing it. They loved their prototype and thought others would like it, too, but others didn’t!
Define > Ideate > Prototype > Test. Take notes from Test and repeat.
Cautiously optimistic to cheerful – the range of feedback they got.
“Webhelp is great, but where do I get the PDF?”
Q&A: They did this on their own to get the experience rather than hire external consultants.
Keynote: Inspiring action through content leadership
With Kristina Mausser, President and Senior Content Strategy Consultant, Kina’ole, Canada
See the recording of Kristina’s talk on the soap! YouTube channel.
Definition of Kina’ole is great – a Hawai’ian word for “flawlessness”. “Doing the right thing, in the right way, at the right time, in the right place, to the right person, for the right reason, with the right feeling… the first time.”
What happens when there is no uptake on your great idea?
Parks Canada looks after all the great nature areas in Canada.
Had to rethink its content culture when they went on the web. Parks in person were great experience, but how about the web.
Small team in Ottowa managed site for entire country. But different parts had different info needs.
Team chose to focus on content, not people. Content problems are business problems. Made policies around who can publish what. “The more policies, the less buy-in you’ll have for your ideas.” > Orgs can’t be mandated to change their corporate culture so they might end up going rogue.
Studies show that the less control people have, the more stress they feel.
So you stress people with these policies and you can end up having shelfware.
(Make sure the style guide is not shelfware.)
So focus on content wasn’t helping. Had to focus on people.
Because content problems are people problems!! Focus on discovering internal motivations for content decisions.
More to change than change management. Empathy is a noun, but you need a verb for action.
She prefers empower. To make someone stronger and more confident. She likes it more because it’s a verb.
“Content leaders who provide vision, direction & inspiration are critical to a content team’s success.”
“We often forget importance of internal communications. It’s a fundamental component of change management.”
A whole lot has to happen for the ta-da moments to happen. She showed slide of the pyramid of this stuff with buy-in and support at the top. Bottom row is internal communication infrastructure. Next layer is employee engagement, then change communications. All helps to build up to the ta-da moment.
If you don’t know what your role and place are, you can’t get behind the ta-da moment.
Content problems are Leadership problems. Means you have no comms and you are relying on ta-da moments. (77% of employees don’t undertand their responsibilities.)
What can we do as content leaders? Focus on learning instead of lecturing. Show, don’t just tell.
Content team members are motivated by opportunities to grow and develop. (Colleen’s survey).
Take five ideas you get from soap! and share with your team. Gives a starting point/foundation.
She uses customer journey maps.
Focus on problem solving, not problem selling.
Companies focus on product fixing, not solving. Solving goes deeper.
Focus on ownership vs accountability.
She likes to delegate tasks with high a-ha moments. Often to content owners because a-ha has bigger impact with them.
Focus on Collaboration rather than teamwork.
Create content in spite of silos, not around silos.
Docathon is a collaboration idea.
Develop playbook that encourages autonomy, rather than policies.
Finally, focus on inspiration and not ideation.
She says leadership and content are more important today than ever before.
Content needs leadership. Great leaders set out to make a difference.
Content is King coined in 1996 by Bill Gates.
Had connotation of importance over power.
But this idea has degraded over the years because we talk about content being power – power over importance.
After this conference, it’s important that we all become content leaders.