In recent posts, we’ve been describing the different ways to publish policy and procedure documents online. Often, organisations want to write their content in Microsoft Word, as staff are familiar with the application. However, they also want a very nice, and usable, online version.
Here’s an example of a direct conversion from Word to HTML.
Before – Example Mobile Phone Policy IT-0022-v2
After – Mobile phone policy – written in Word and converted to HTML
In this example, we have not amended the source content before conversion, nor the default template. We just imported the document and pressed the Build button.
The document has been broken down into a series of web pages, with a responsive web layout. This means the pages can be easily read on a mobile phone.
The writers would make any changes to the policy by amending the Word document. You’d then run the conversion again, and upload the revised web pages.
We’ve been asked by a client to put together some proof of concepts for polices and procedures guides.
The XYZ Management Guide contains diagrams with “hotspots”. You can click on parts of the images and jump to further information about a particular process or role.
Below are two proof of concept examples of a policy document. In these examples, the selling old mobile phones topic contains a filter for pre- and post- Brexit information. Users can use the filter option to switch between both versions.
The benefit of doing this is because the reader doesn’t get overwhelmed with information, and the writer can manage the both sets of information in a single topic.
Mobile phone policy – version 1
This example has tabs on the left hand navigation panel.
The funnel icon tab enables you to exclude content. In this example, you can exclude pre- and post- Brexit information on the selling old mobile phones topic.
The A-Z folder icon tab enables departments, budget holders and line managers to see which topics are relevant to them.
Mobile phone policy – version 2
In this example, you can exclude pre- and post- Brexit information on the selling old mobile phones topic by using the drop down menu at the top of the topic.
It also contains a job role tab that enables departments, budget holders and line managers to see which topics are relevant to them.
You can click on the menu icon to display the navigation window.
With the triggering of Article 50, the United Kingdom is likely to be out of the single market in two years time. It will be able to set its own regulations within the United Kingdom, but will almost certainly have to follow EU regulations when trading with EU27 countries.
This means organisations will have to manage two sets of compliance rules, and possibly two sets of policies and procedures, which will be similar in many areas.
One approach is to have two documents, cutting and pasting between the two. This can be time-consuming, and with this approach it is easy for mistakes to creep in.
Another way is to have one document with different sections marked up to identify which territory’s rules they relate to. This is known as conditional text. You create “conditional build tags” to include or exclude content from output, and then assign those tags to topics or parts of topics. For example, when you publish, you set the conditions to “United Kingdom” for the UK-only guide, and it will only contain the United Kingdom rules.
You can also create output that your users can easily filter based on parameters that you define using conditional text. For example, you can create a filter that allows your users to filter the output by UK or EU27 rules.
This approach means your writers can work from a single source – no more cutting and pasting!
We’ve just uploaded a free video guide on Getting Customers to Answer Their Own Support Questions.
The guide is free. You just need to register and log into our elearning platform.
See: Getting Customers to Answer Their Own Support Questions.
This month, Microsoft has added Microsoft Teams to Office 365. It’s a instant messaging collaboration tool, similar to Slack. Teams contains the T-Bot, which provides help and assistance to users.
Users can watch videos:
They can read online Help:
They can read an FAQ:
They can ask the T-Bot a question and receive an answer. The T-Bot initially provides the same answers as the FAQ. If it doesn’t know the answer, it will suggest some articles from the Help:
Do you think this way of helping users is good? Share your thoughts, using the comments form below.
We spotted an interesting statement by the “Father of Behaviour Design”, BJ Fogg:
“For somebody to do something – whether it’s buying a car, checking an email, or doing 20 press-ups – three things must happen at once.
The person must want to do it, they must be able to, and they must be prompted to do it.
A trigger – the prompt for the action – is effective only when the person is highly motivated, or the task is very easy. If the task is hard, people end up frustrated; if they’re not motivated, they get annoyed.”
See Ian Leslie’s article “The scientists who make apps addictive“.
If we want users to read Help text instead of calling the support line, then we maybe we need to meet those three criteria.
We can assume the user is motivated to fix their problem.
We can write instructions that are clear enough to make them able to solve the problem.
Where some applications fall down is they don’t prompt the user to read the online Help. The link to the Help text is often tucked away in the right hand corner of the screen.
Instead, we could put some of the Help text into the User Interface or the dialog screens, and we could prompt the user to follow a link to more information. Doing this could get users to read the online Help rather than call support.
Last week, we used the Hemingway app to highlight any unclear pages on our main website. The app highlighted four pages where we’d used the passive voice or very long sentences.
The first inclination was to think our readers are cleverer, our content is more technical, it’s not possible to rewrite those parts. We found, of course, we could rewrite them. We decided to write them in the same way we’d write user documentation. We found those passages were much clearer, as a result. A lesson learnt.