Creating user guides that users love to use can be a challenging task. Not only do you need to master technical writing, but you also need to be familiar with designing, visualising, usability principles, legal stuff, and good old-fashioned psychology. The IEC/IEEE 82079-1-2019 Standard on Preparation of Information for Use provides guidelines that help you create better instructions. If you want to create happier users and make sure that you fulfill market, legal, and regulatory obligations, applying this standard is an absolute must.
In this podcast, I am interviewing Sven Ring, who has been part of the committee that developed the 82079 standard. Sven talks about how an international and interesting group of people has developed a standard that helps anyone who wants to create user instructions. Sven Ring is a technical documentation and information expert. He currently works for a Chinese wind turbine manufacturer. Sven has 34 years of experience in technical communication.
Listen to the interview below and make sure to subscribe to the INSTRKTIV’S INSANE INSTRUCTIONS SHOW on your favourite podcasting platform. You can find the free transcript of this episode on my website as well.
If you have a topic or question you’d like me to cover, send me an email here.
SOME TOPICS WE COVERED:
- How the standardisation process is set up.
- Why we need a standard for information for use.
- Major breakthroughs of the new 82079 standard.
- Implementation of the principles of Minimalism.
- How to deal with safety instructions.
- How usability requirements are integrated in the standard.
- How to use the new standard.
- Structuring information.
- What the benefits are for the end-user.
- Determining the audience of your user instructions and how to write for your user.
- Artificial intelligence and will robots replace technical writers?
LINKS MENTIONED IN THIS EPISODE:
Read the Full Podcast Transcript Below:
Ferry: Hi there and welcome to this podcast. In this podcast, we’re going to talk about the new standard for user instructions, or actually I have to say the standard for information for use. The new revised standard provides principles and general requirements for information for use of products. Clear information for use is necessary for using a product safely, efficiently and effectively. Our guest for today is Sven Ring. He was part of the committee that developed the standards.
Sven is a technical documentation and information expert. He currently works for a Chinese wind turbine manufacturer. He has over 30 years of experience in technical communication and developed several other standards. Sven welcome!
Sven: Hi Ferry! It’s great to be here and it is strange to hear one's life summed up so shortly as you just did.
Ferry: So Sven tell me, you were part of the committee that developed the 82079 standard for information for use?
Sven: That’s correct, yes.
Ferry: Since when have you been involved?
Sven: It’s about eight years ago. I was at that time working for another wind turbine manufacturer, the largest one in the world. Well, they say they are. Vestas. I was asked if I wanted to basically join the Danish standards organization because I was very vocal in the lack of use of standards at that time with regards to documentation, and when I got in with the Danish Standards Institute they asked me if I wanted to join this particular working group. That’s eight years ago and I’ve been involved with it ever since. I’ve been through two revisions. The last one, I will say, is by far the better.
I have had comments from a lot of people about the previous version and they said that it was not clear enough. I think a lot of people expect that the standard kind of grabs you by the nose and drags you through the entire process. That’s not this type of standard, it’s one that really you have to use your head but gives you guidelines.
Ferry: When was the standard ready?
Sven: The latest version was released in May of this year and we have been very successful finally in getting it into the, that would be referenced from the machinery directive which means that it has risen in clout and usability. It has really become the standard for documentation. There are others out there but we have been very careful to either ask these people to address the issue they have because there is particularly one in Germany that uses a lot of content from the 82079, but I think we manage to solve this 82079 will be the standard to use in the future.
Ferry: Right, and you’re saying you manage to solve this. So..
Sven: Sorry, when I say “we managed”, it was a convener the way standards are set up is that you have a group of experts and a convene is the context to the standardization organization for whom you are updating, creating or whatever standard and it was the convener who through a lot of communication with various people and various standards organizations managed to get this going the way it should do. I really have to put it down to Claudia Klumpp to honor her for that because she was the convener and she’s the one that managed to this.
Ferry: Right, okay. Give a short description of the other people that were part of the committee. Was it like an international group of people?
Sven: It was very international. It consisted of a couple of Japanese gentlemen mostly from the standard organization from universities. Then there were several German participants. This was very much business people with an interest in getting a standard of running. And there were a couple of Brits, they were very much trying to ply the British standards point of view in this standard.
Then there’s me, representing little old Denmark and there was an American involved as well. So, we had the link into American standards because she was heavily involved in American standards around documentation and god knows what else. She lived from working out standards and traveled all over the world. We had online meetings where one minute she will be in the US, then suddenly she would be in China then suddenly she will be somewhere else. A well-traveled lady that was very well connected and therefore we had some really good experts that all knew what they’re dealing with. I tried to very much along with Germans to bring in the actual user’s perspective on it so that is it something the user can use or we just get academic here. So, I think we ended up with a very good standard.
Ferry: So you said that you have a lot of online meetings? Did you meet in person as well?
Sven: We had at the end because finances began to become short and let's be honest like the meeting we’re in right now, the technology has developed over time. So we started with meetings and we started with meetings in Tokyo and I've been to Washington, we’ve been to Stockholm. We've been to various other places where participants have been. The secretary for the technical committee under which this work group that worked on the standard belonged, was Swedish that's why we ended up in Sweden at one stage. We also have a Finnish member who has a very dry humour and also working in the standard organization.
Ferry: Did you experience any cultural differences between for example the Americans, Japanese people, European people that they have their own kind sort of inputs when developing the standard?
Sven: To begin with our Japanese colleagues, their input was very much on the formality side. Are we allowed to say this? Are we allowed to do these in the standard? They unsurpassed in knowledge and skills whereas others were most are in the user perspective and end-user view of it. But we didn't really have cultural clashes as such. We had clashes of wishes I shan’t deny that our German colleagues at one point tried to sneak in a little bit of German standardization that they wanted to reference in this standard and they very quickly pulled it up again so I’ll honour to them for that, but there have been clashes of interest rather than clashes of culture.
Everybody knew what we're there for. Everybody knuckled down and everybody provided one with the other that was, a suggesting came up and some said, “Oh, no, I can't do that’,” because all others are saying, “Yeah we do that like this,” and being the word nerd that I am being with technical documentation for so many years, I was the one that tended to come up with a suggestions to wording rather than perhaps too much of contents because a lot of it we argued out before it actually was written down. The conveners were the ones that would take notes and bless them, both the current one and the one prior to it, were very good at getting all the words that we said down on to papers so it ended up being a standard. So I can only praise them for that.
Ferry: Right. And you're saying you have quite some suggestion regarding wording? Do you mean the wording as in the terminology being used in this standard? Or wording in terms of how to write clear text or clear instructions for example?
Sven: Both actually, you know all of us except the American or one British member. English is our second language so we couldn't really ask them because they know how to say it but they don’t know why. Whereas the rest of us could argue all the grammar and all this that very much. But my input was very clear and concise language, yes. Because that is one of the things I have over time developed a great passion for and still have a great passion for and I hope to continue to have a great passion for.
Ferry: Where does this passion come from?
Sven: Basically the fact that I realized that when you write clear, concise and simple without using insulting language, you catch the reader. You get them to do what you want them to do and you avoid that they do something wrong because they don’t understand you. That is so vital when you convey information to others that it is not based on, “Oh, they know what I mean. Oh, they can guess that. Oh, should they know that”. You can’t base your instructions on that. You’ve got to be very sure that when they read and follow your instructions, everything is done correctly and it’s safe.
Ferry: So, do you think when you apply this new standard, is applying this standard a way to create clearer instructions to catch the reader as you’re calling it?
Sven: Very much so, but of course the industry is such a vast and multifaceted beast that you can’t really give really them simple rules as you do this, this.. this.. We should think about what people are looking for. You have to give them, “This is what you must consider this is what you should do”. Explaining to people what clear, precise language is will always be very difficult because yes, it’s perfect in English perhaps it may not be perfect let’s say in German or French or Japanese. One of the first things you must do when you write technical documentation is to know who are you writing for, who’s the recipient of your fantastic information. I mean, are we talking a consumer which must we assumed not to know anything about the product, or are we talking about that super trained technician who really should know everything and who possibly could be able to correct your documentation in the first place.
So, it’s vital that one, you know who you’re writing for and two, write in a simple preferably well- illustrated if possible way. So that you avoid mistakes or as I said, people are expected to read between the lines, or people are expected to know what the writer means because it’s obvious to him or her but certainly isn’t obvious to the reader.
Ferry: Are you saying that when you read the standard, when you read the requirements of the standard that there’s still a lot of own interpretation needed in order to create?
Sven: Yes, you have to apply it to your particular subject. You know there are so many different things that you have to write technical documentation about. I mean, I write currently about wind turbines. I’ve written about sports cars; I’ve written about ground equipment for aircraft, soft sea oil equipment. The basic idea, the way of writing and producing information is exactly the same and that’s what the standard is for. But the actual subject matter you’re writing about will always differ so, therefore, the standard requires you to make up your mind on your own but it gives you the guidelines and the layout. and I don’t want to say rules, but lays out the pathway you should follow.
One of the things that is very important in my view and I will put that down as being my view, is that technical writing should not be a mechanical rattle things out the same way all the time. You need to have the ability to allow the writer to have a little bit of poetic license. You could almost recognize who wrote this piece of information even though it’s precise, correct, simple to read followed illustrations and perfect in any aspect of the conveyance of information.
Ferry: For me what you’re saying this, because last week I was in Antwerp, Belgium. Do you notice a shop or organization called School of Life?
Sven: I’ve heard of it, yes.
Ferry: They have a set of playing cards for explaining different kinds of professions. I grab that pack of cards, I opened it and the first card that I saw was about technical writers. What a coincidence. And it said, there are several aspects being discussed by giving numbers. One of them was the chance that the technical writer will be replaced by a machine or will be replaced by robot machinery in the future. The chances are quite high according to that card, a chance of 45% within the next few years. Are you saying when writing instructions doesn’t need to be too mechanical, do you mean that with that as well, it’s almost impossible to replace a technical writer by a robot or a machine?
Sven: No, it’s not impossible to replace a technical writer for a robot if the robot is writing for another robot. What we mustn’t forget is that, yes, artificial intelligence is storming forward and yes, it’s going to be able to put a lot of things together but still is who is the recipient of the information? If it’s just a machine then yes, we will be replaced that’s no doubt about that. But when it comes down to if it’s humans, we all know that humans will first of all try, and then when things didn’t go the way they expect they will look. And no machine can anticipate where or what they will look for.
Humans can anticipate that because we know ourselves what kind of weird creatures we are and therefore anticipates that people have gone into and done something and there we can say that. Not tell them that you have done this you fool, but saying coming with the information in the sequence that we know the people will come to receive them.
And that is different from product to product, from service to service and although that is without a lot of fairly medial tasks the technical writing that could be done by machines you will always have to have a human eye on it and that means that technical writers I don’t think will be replaced. That rule may change that they still have a lot of input. I think it’s being a little bit naïve to think that we can just be replaced like that. I’m not saying we can’t be in various areas, but I still think we have a long time ahead of us where we will be most definitely needed.
Ferry: Yeah, so, we still need a standard for writing clear instructions.
Sven: Yes, if nothing else that’s standard should then be used by the robots to write the clear instructions. So if someone is clever enough to put something together that can read the entire standard, understand what meant with it and then apply it but at the same apply it with a sense of is it necessary here to apply that rule yes, no. If it’s able to that then by over time by that we can be replaced but I think it’s gonna be a long time.
I mean, to give you an example, everybody is hailing machinery translation at the moment. Oh, it’s a bees knees, everything is fine is so good. But then, when you go into it and you say write okay give me a machinery translation. The first thing it asks for is to give me a list of standard words. Hang on, you’re a machinery translator, you should be able to do this automatically. You can see already there the machinery translator falls flat on his face. It will come, it will get better without a doubt over time particularly when we feed them with more and more standardized words. It’s a long way off, I’m pretty certain of it even though the development of artificial intelligence is raising ahead like nobody’s business. But who knows maybe the clever people will stop in time and say hang on let’s not forget ourselves.
Ferry: One thing that I noticed is that the new standard is called the 82079-12019 preparation of information for use where the old standard, the 2012 version was talking about instructions for use. Do you know where this difference comes from?
Sven: The intention was to get the standard to cover more than just instructions. Technical description, that is not an instruction but it’s also covered by the standard. There are various areas that were missed out because we use the word instructions because everybody expected then step-by-step instructions, and there are others that are not step-by-step. And as I said technical descriptions and functional descriptions, and all this sort of things, that have nothing to do with doings of things but has a lot to do with what you’re actually working with. So that’s why it was changed from instructions to information.
Trust me, we argued wall’s up, doors down about this for two or three meetings. One minute we switched towards instructions, then we switched over to information and back and forth but eventually we settled down on information for use and it was also then accepted by our steering committees higher up on the systems so that’s why it’s now called that. Being that it’s a -1, there were thoughts that perhaps we could fit in other more specific types of information for use underneath that. The suggestion was we have consumer products, but actually having argued over that one as well, we found that really the standard as it covers all conveyance of information to someone to use something. That’s why it’s there.
Ferry: So, standardization work is everything but boring?
Sven: You know when you first open up the collection of let’s say comments for the current version, you can sometimes go, “Oh, my God, what have I let myself in for”? When the people that you’re with are all dedicated this right the yeah, there at times, your mind will go wandering when someone goes into a particularly academic way of explaining things instead of you do. I wouldn’t say it doze off, but no it’s never boring you get to meet some amazing characters.
I’ve always said that I’ve never met more strange, interesting people than I have within the technical writing fraternity if you can call it that. It’s not a fraternity because there is plenty of very good female writers. I used to have a colleague many years ago whose in-tray was one side of his desk and just down from that side of the desk was his waste paper basket which was rather large. He didn’t have a tray, he just piled the stuff on top there and you know when the paper gets piled up to a certain height it would just slide off. So, it would just slide off and into his paper basket that he forgot about it. That was his way of sorting out the tasks, very interesting. And I believe I’ve formed some really good friendships with some of them over time.
Ferry: I can agree on that, I have the same experience with my standardization work. Going back to the beginning where you said that one of the major parts where you contributed to this standard has to deal with the usability of user instruction or information for use. Can you tell a bit more about how usability is being integrated into the new 8079 standards?
Sven: It really is, can you apply the suggestions or the guidelines we present because quite often the standards for? How do I apply this to the situation? I sit in so there’s a lot of thoughts from my side and from several people about what we say here can we put this is in? Can we use it? Can we make use of it? Can we apply it? There were areas where people insisted on having methods put in that I do not personally agree with because I find them incredibly difficult to apply. But there’s a great love of this particular area in certain parts of the world and therefore one of these battles if you want to call them that, that I had to give in on that one and accept that’s included in the standard. I don’t agree with it but that’s just me.
Ferry: One of the things that is integrated is the principles, or at least being mentioned in the standard, are the methods of minimalism. Minimalism is a user-centered way of creating writing clear instructions. So, would you say that this is one of the major improvements of the new standard or at least one of the things that is..
Sven: It is a natural progression of the standard that it includes and very much suggests you use minimalism because minimalism is a fine tool for creating precise instructions that are easy to understand. The whole thing is a question of passing on the information that people need. Don’t flood them with unnecessary information. Let’s give them what they need in a precise, easily understood manner.
Ferry: What are the benefits for the end-user when you apply the principles of minimalism?
Sven: They get the information they need and they get in a fashion that they can use straight away and is readily understood and the information is achieved as it is set up to achieve which is to convey an important piece of information at that point and no more no less.
Ferry: I’ve read the new standard a couple of times myself. I wasn’t part of the committee, I didn’t speak to anyone but when I read the standard I thought to read through the lines that there have been quite some discussion between people supporting minimalism and people supporting safety instructions. I do agree that minimalism and writing safety instructions do not go hand in hand all the time quite well, however, I think for example what my minimalism teacher once taught me you can write safety user instructions in two kinds of ways. You can place a warning at the beginning of a section saying “Always turn off the machinery before you conduct any maintenance works”. So then it’s a warning, but when you apply the principles of minimalism you can start the first instruction in your maintenance chapter with, “Make sure that you turn off the machinery before you conduct or perform, do any maintenance task”. Meaning, that warning, which is I think is proven that almost nobody reads the warnings, is transformed into an instruction that people do read.
Sven: Previous jobs I worked in have been several attempts to do various ways. One way was to put all the warnings at the beginning of the document. Very quickly we discovered nobody absolutely read those sections because you know there are 10 pages of warnings, doesn’t ring a bell any of it because it wasn’t at the location where the actual danger was. Then moved it to the section where the danger is. That reduced it from 10 pages to perhaps half a page, but still people skipped it because they weren’t interested in doing the job.
Warnings, dangers or whatever should really be about that this here is dangerous. What you should do in my mind should be in the instructions. If you give them precise, correct instructions, then they won’t put themselves in danger, but at the same time we must make people the fact that this could hurt you or this could destroy the machinery. And that’s how you now get me into my pet subject in this one here which is the ANSI standard about warning, precautions, and notes which I’m not a friend of.. Let’s put it that way.
Ferry: I do know that I think in Europe we never had a standard saying where to place safety warnings in your documentation or user manuals?
Sven: Ah yes, the machinery directive actually hints at this. There should be a place where the danger is present.
Ferry: So, I wasn’t aware that there is a European requirement on where to place the safety instructions that’s the reason that I was a big fan of applying the ANSI Standard and ANSI Z535.6 which says there are several kinds of safety warnings. General safety warnings, sectional safety warnings and embedded safety warnings, and one more, the directional safety warning I think, and by dividing it into these four groups you’re already saying “ Hey you should place your safety warning there where the danger is”.
Is that something this American standard that you took into account when developing the 82079 standard?
Sven: Yes, that was taken into account. That’s not the part that I’m at loggerheads with. It is the part where you have different types of warnings whether you die now, die tomorrow or maybe die next year. It’s that one I have difficulty with because I find that impossible for anyone including, despite the most learned and most valued colleague of mine in the workgroup said that it was up to the safety responsible person to define which type of warning it should it be. I would defy anyone that they are able to do that. This is why I personally always apply the principle that you can get hurt, it’s a danger, if you can do damage to the machine it’s something else. I’m not to say there’s a caution because in 82079, we state that we shouldn’t use caution that has anything to do with the damage to machinery.
If you could hurt yourself and include you get a bruise or you lose your life, it is always a danger. That is just me because it is easy for the tech writer to understand and remember, and it is also something that therefore the tech writer understands it, the reader will understand it as well. The end result should really be the people don’t get hurt.
Ferry: Right, let’s go back to how the new standard can help anyone, a company, marketing manager, technical writer to create clearer instructions. So for example, I think clear instructions or let’s say accessible information also has to do with the medium in which the instructions are being distributed.
Sven: Definitely, but again, sorry, I may be old school here. I mean, yes, a lot of people are very interested and I agree with it and they’re interested in videos particularly animations because it’s easy for people to understand all this and trust me if all service technicians had an iPad or a tablet or some means of displaying this. I mean, if we take it to the ultimate solution you have VR where you actually look at the machinery and you can see through the machinery because what you’re looking at is the line drawing of what you’re looking at and by there, they’ll be able to see exactly what to do. We’re not there yet by any means, what I tend to say that Guttenberg is about 300 years old the PC is about 20 years old we still have a little bit of time for the human brain to embrace the media of electronics and animations.
So much as I agree with animations that are perfect for training, perfect for teaching. When it comes down to standing out there and you got a situation where you need to know what to do. You need to able to flick quickly through some information and you need to find it and you need to have it lying open so that you can see what you suppose to do. We’re not there yet with the electronic media, we are racing towards it. There’s a lot of good efforts going on. The single-sourcing and DITA the standard of working very much towards that.
Ferry: What does that mean for the end-user, data single-sourcing etc? Why does that mean when applying those principles again, and let’s say I’m a layperson I don’t know what DITA is, I don’t know what single sourcing is.
Sven: First of all single-sourcing basically means write once, use many times. That is the idea behind that which means that, if you have an instruction that applies to a particular part of your machinery and that part is re-used many places. If you have a system where you have written the instructions about the parts, the system should be able to. When it looks that all those parts are used over in this machinery as well then I can just apply the same basic information.
Ferry: Meaning that you can create a draw up of instructions more efficiently?
Sven: Yeah, you can assemble them if you want. DITA is a standard on how you structured the content of the bit of information..
Ferry: But again, these are benefits for the technical writer..
Sven: They’re benefits for the user, the end-user because the end-user will therefore always get...if 82079 standard is applied to the bits of information that is attached to part, the bits of information have been structured according to say DITA. It doesn’t really matter which ones. Then the information will be available for that part and that can be provided electronically, which could be updated daily, which can be delivered dynamically to the end-user and thereby the end-user will get the information he or she needs. At the point of use they don’t even have to take anything with them. So, that’s delivery media but we’re not there yet, we’re working really hard on it but we’re now there yet.
Ferry: Can you.. for example, can you apply as a technical writer those data principles of structuring principles and you start chunking up all the information you have. For example, you have all your information for use, you can create several information types out of that, for example, a user guide, maintenance guide, installation guide etc. within that user guide you can create topics. Each topic consists of instructions and each instruction consist of single steps for example.
But then for example when you have like one step out of an instruction, for example, “Put the switch in the on/off position”. When you single source that single step, then for example in instruction 1 and instruction 4, the same step is being used. So when you use exactly the same phrasing for that step, then it’s clearer for the end-user I would say that exactly the same thing is mentioned instead of saying one time, “I put the switch in the off position”, and saying in the other topic “Put the on/off button in that position”.
Sven: Exactly, you start having consistency in terminology, etc. But it requires a lot of thought, a lot of planning and now we are slightly getting away from 82079 which is really about the information you provide. It’s the complete assembled output we’re talking about in 82079. When you get down into the smaller parts, again, you’ve got to look at it as if it’s a parts list. You know to make a piece of machinery, you have a part’s list, which consist of many or few parts but each parts have some instructions attached to it and this instruction is maybe either installation, transport, service, replacement, you name it. Whatever you can think of that who you want to be done to this part. All this information is attached to the part so that when the part is brought into another assembly, another parts list then the information will follow along, but it requires the system knows that it belongs to the given part. It requires that a system that knows where the part is used.
Normally, production systems will know that, but the content of the topics as you call them will be determined by if it’s written with minimalism to the last degree and contains all the correct warnings and there’s a point where you have to say, “Let’s not split it down any further. Let’s accept we have duplication for information because it doesn’t make sense to split it off completely”. Put the honus on the system that you know where to find it.
I know several companies started out with the best of intentions and they did all manners of tagging and information marking and you name it. And then they did a complete product, fantastic, and then went to the next product and they look at it and said “Yeah, that’s fine we can use all this”. And then someone said, “But I need to update,” whatever part it was. Fine and they realized “Oh. My God!” They couldn’t work out where things belonged. It is a slow process, it’s a process that needs to be well –thought through and it’s a process that takes a long time. And there you meet the jumping up and down marketing manager who wants the information yesterday.
Ferry: Yeah, okay. And again you’re saying that you can use 82079 standard as a tool, as something to rely on when creating your user instructions. So, it doesn’t give really clear instructions, no, it’s your theoretical background maybe or standard. Meaning, it sounds like not everyone can directly apply the standards so is it limited to technical writers or people that want to become a technical writer, who can use? Who’s the target group for the standard?
Sven: As far as I’m concerned, the target group is anyone who wants to convey a piece of information about technical information. I will limit to that because it’s not about politics or anything like that. This is about conveying technical information to people in a safe, efficient manner. That means, obviously marketing, it means sales, it means service, it means installation, it means transport.
Anyone is a user of it to a certain degree, of course, some are less users than others but they are recipients of the information. And the creators of that information, be its as I said marketing or sales, or be its technical writers, or being service organization or whatever can make good use of this and it will help them in structuring the information they have to provide not unimportantly, but also it will help them achieve what they said out to do. Because I don’t believe there’s any technical writer that writes because he thinks he should write something. He wants to convey the information that he’s dealing with to that the end-user so that they can do the job that they’re supposed to do. That is the point of that standard. It is to make sure that people get everything they want. People write in a simplified and straightforward manner, people make sure that all the safety that is needed is in there.
Ferry: Okay, let’s go to the next topic.
The standard discusses several aspects. For example, it gives requirements on the content of information for use and gives requirements for the information process. It also discusses how to format and present your information etc. That is a lot of things that have been discussed and have been taken into account.
Can you say that you agree with everything that has been decided? Are you satisfied with the end result?
Sven: Yes, I am satisfied with the end result. I will back up on it fully. As I just said earlier, there are areas around the warnings and cautions, and notes that I don’t agree with 100% but I back up on it and I will say that you said, apply it because it actually is a very good document for how you should work when you create your technical information. And I would definitely use it as a basis for what they’re doing. Whether they are hundred percent compliant or not depends very much on the industry and also on the company that they are writing for, but it certainly lays down to overall rules instructions on how you create good technical documentation for the use of pretty much any product.
Ferry: Let’s say when I want to apply the 82079 standard to write better instructions, where do I begin?
Sven: Good idea is certainly read the foreword, read the table of contents to make you sure you know what it is you are wanting you to have information on. Then, I will start setting on the structure according to the guidelines that are in there so you have an overall outline of what it is you’re doing. But again I think what we mustn’t forget is that the standard covers normally a multitude of documents. If we still talk about documents.
I mean, you would normally start writing a technical description of what you’re dealing with. Then you look up what they say you should do there. There’s a lot about terminology, there’s a lot about making sure you call the things the same throughout your documentation and a good way of asking is by starting by the technical description. Because they can lay down the rules for what you call something because trust me, that is a huge problem throughout any industry that they call the same thing, different names depending upon who’s dealing with it. And it causes confusion with the end-reader when he suddenly gets...
I can give you an example, I was working for a document for a previous employer and this particular piece of kit had two, in the beginning, it was named as “arms” which help a call on some rotating piece this arms halfway through the documents suddenly change the name to” legs”. It took me two days to find out that it was the same thing that the previous writer has changed the name of it halfway through and me as a user of the document, I got totally confused and was unable to do what I was supposed to do because the terminology was not right.
That is one of the first things that you start on, then you start structuring according to which product you’ve got, what is done to it and what the end-user is supposed to do with it. Quite often, of course, it’s mainly using it, that is the important thing but you may have stuff like how to transport, how to install, how to commission etc.
Ferry: And the 82709 standard guides you through this?
Sven:: It does indeed yes, it helps you understand what it is you’re supposed to come up with. But it doesn’t give you exact this is the wording you should use because that varies from industry to industry, from product to product.
Ferry: Right, so by applying the standard, going through it or start creating your instructions from scratch or maybe from already your database where you single-source your content you’ll be able to create safer instructions, you’ll be able to create them more effectively maybe? efficiently?
Sven: Efficient and effective and of course that you end up telling people to do things in a safe manner.
Ferry: Okay, thanks a lot Sven! I think we’ve discussed quite a bit about the new 82079 standard. Then, I want to wrap up this episode. Thanks a lot Sven for taking part of it.
I don’t know how to end now.
Founder of INSTRKTIV and keen to help users become experts in the use of a product, and thus to contribute to a positive user experience. Eager to help organisations to reduce their product liability. Just loves cooking, travel, and music--especially electronic. You can also find him on:
Profile Page, Linkedin, Instagram and Twitter!
You may also be interested in
26 April 2022
How These Companies Never Had To Create a Manual Again
Jean-Pierre is a technical writer at INSTRKTIV and enjoys working for companies that outsource their manual creation. He spends fixed days each week providing capacity to companies that need help with their documentation. We asked him all about how he helps product owners and engineers balance their workload, create impressive manuals and other documentation for innovative products and boosting team efficiency....
26 April 2022
Create Awesome User Instructions For Leading Companies
JP is a technical writer with a background in international law and marketing. We asked him all about the projects he works on and what makes working with product leaders so interesting....