Technical Communication UK 2015
The Technical Communication UK (https://istc.org.uk/tcuk) 2015 conference was in Glasgow, 29 September to 1 October. Mike Unwalla gives this summary.
Breaking the boundaries of technical communication
Neil Perlin said that two technical writers in the 1980s did not accept jobs from DEC, because "technical writers don’t use computers."
All jobs have boundaries, but sometimes we choose our boundaries. For example, some technical writers say, "I will never take a job in which I must use Word."
Andrea Ames (www.linkedin.com/in/andreaames) said, "The current safe boundaries were once unknown frontiers." To break boundaries, Andrea gives these methods:
- Learn about technical communication. If you know the theory well, you can more easily break the boundaries.
- Do not say, "It’s not my job."
- Be a consultant. Do not become emotionally attached to your agenda. Tell your story with data and give advice.
- Communicate clearly.
- Know the result of not changing. If no change occurs, what will be the result?
- Be prepared to be uncomfortable. (Change is not easy.)
- Be the change that you want to see. Change your behaviour to cause people to trust you. Collect followers on the path to change.
- Know that change is a process, not an event. Think about systems, not about events.
What can technical communicators learn from content strategists? Neil Perlin thinks that technical communicators are content strategists. Andrea Ames says that content strategists manage the technical communication parts of a project.
To be successful, do not argue about whether Word is better than FrameMaker or whether content is more important than the technology that we use to create the content. To be successful, technical communicators must think about business, not about writing.
To break our boundaries, we must ask questions and we must learn new subjects. Employers want technical communicators who have 2 primary skills:
- Writing skills
- Project management skills.
Technical communicators must also know the subject and the tools that are necessary to develop the content.
Technical communicators must know what is possible. But, to find work, our network is as important as our training.
Developing the documentation
Chris Atherton (https://finiteattentionspan.wordpress.com/) said that the function of a good user interface is to make the user not think about it.
Technical communicators must do the difficult work, so that users do not need to work (https://gds.blog.gov.uk/2014/07/28/doing-the-hard-work-to-make-things-simple/).
There are no stupid users, only bad user interfaces and bad content. Technical communicators know too much. We cannot know how a new user feels. "Yes, but what is the user need?" is an irritating question. It is also very powerful.
People think that looking at a screen is work, but thinking about a problem is not work. But, until you think about a problem, you cannot have a solution.
Attention is like a lens. If we focus on one thing, we cannot focus on other things. The largest computer screen is a relatively small area. We cannot see all the parts of a problem in sufficient detail.
Chris recommends that for large problems, we initially do not use a computer. As an alternative, use a large surface such as whiteboard.
Card sorting is a good method to help people to select the most important item. If you give people in a team a list of items, and tell them to select the most important item, you will get many different opinions. If you give them a set of cards and tell them to agree on the most important item and put it on the top of the cards, people in the team will argue, but they cannot give you different answers. Only one card can be on the top of the set.
For good advice about principles of design for digital services, refer to www.gov.uk/guidance/government-design-principles.
Technical documentation in industry
SAP
Users expect software that is intuitive and easy to use.
The documentation team at SAP (www.sap.com) is changing the way that it supplies help to users. As an alternative to PDF files, help is supplied as embedded help. The style of language is changing from formal to friendly. Text is clear, simple, and accessible.
Technical writers must change the way that they work. They must learn new tools. They have an important function in the development of SAP products.
Some technical writers want to change, and are excited by the new opportunities, but some are afraid, and do not want to change.
To help technical writers, SAP developed training courses for technical writers. Training only is not sufficient. The work culture must also change. But, time is necessary for change to occur.
What SAP learned:
- Writing skills and language skills are important.
- New tasks mean that technical writers must take more responsibility and must be flexible in their attitude to work.
- Experts are necessary. Most people cannot do all the different tasks well.
- With agile methods, the technical writers must be in the development teams.
- To develop the skills of technical writers, SAP must work with universities.
SCHEMA
SCHEMA (https://quanos.com/) has more than 100 customers that are manufacturers. These customers have complex documents.
A complex document has these properties:
- A complex document is translated into many languages.
- A complex document has many output formats.
- A complex document contains content for a subset of all the product versions.
For example, if a product has 3 versions and the content for the documentation in 3 languages and each language has 3 output formats, then 27 different documents are necessary.
The SCHEMA ST4 is a component content management system for complex documents. A good feature is the authoring memory for sentence completion and for terminology.
SDL
SDL (www.rws.com/about/news/2020/acquisition-of-sdl-by-rws-enhances-capabilities-in-language-services-and-technology/) had problems with some documentation. The documentation was not shared between employees, was not compatible with different devices, and was inconsistent.
To solve these problems, SDL started to use structured writing in XML. Technical communicators can reuse content and share it. Content is customized to the readers.
To help technical communicators, SDL has authoring memory for 'guided authoring’.
Structured writing let the 130 technical communicators at SDL reuse between 25% and 70% of the content. The cost of translation decreased by 50%, and SDL decreased costs by 25 million US dollars during a period of 5 years. The cost to supply documentation to international markets decreased by 300%.
For documentation for 'the car of the future’, SDL put the documentation into the car’s computer system so that people can read it from the computer screen. The documentation was integrated with the car’s diagnostic system.
RSS feed