The site maps are used to create the structure of the project, such as the home page and landing pages, and ensures this flow matches how a user moves through the product. It also allows us to review product terminology. From here, we build out the project as we gather more information. The research methods will depend on your business, but typically involve discussions with SMEs, product owners, support staff, trainers, etc. You can also review any supporting user stories, customer journeys, functional specifications, etc.
This process is always iterative - write, test, review, re-write, re-test, review, until you're happy with the content. The content should then be factually reviewed from a technical perspective too. Next, ask your peers to review, proofread and edit (if you have an editor, all the better).
MadCap Flare has made the document review process incredibly easy. Similar to the review features in Microsoft Word, we send a copy of the content to a reviewer who accesses the content via MadCap Central. They add comments or make direct changes which we can then import and accept or reject. This document review process is vital and can be repeated as frequently as needed.
When is Good, Good Enough?
I'm sure every content author revisits their content frequently and finds areas they can improve - that’s the joy of writing. But don’t be afraid to release content even when you think it’s not perfect. This testing phase means you’ll receive both positive and negative feedback - all of which leads to improvements.
This does not mean the rigorous process should be abandoned but you can release content knowing that if you had more time, you could do a better job.
At this stage of our document development life cycle, we don’t stress about consistency, we care more about usability and work on the basis that every page is page one.
We published the content to our new Help Hub, swiftly followed by publishing to Salesforce. We’ve since published a further 20 help centres to the Hub with many, many more to come. These help centres are now helping customers and colleagues to be successful.
You’ve Released the Content – What Next?
Once the content is released, you need to make sure it meets the user requirements. We include a Google Analytics (GA) code in each topic (easily achieved by adding the GA code to the Flare master page) and used MadCap Central’s analytics.
GA provides great analytics about the user journey within the help centre and MadCap Central’s analytics show us what’s being searched on and which search terms don't return results. This allows us to identify what content we haven't provided, or where the content has not been written in a way that our users might want to consume it.
We’re in regular contact with our Support teams who share ticket and case trends and flag any issues following a release. This means we can be reactive and make sure our users have the information they need when they need it. We’re also working on a plan to enable our support colleagues to write the content themselves which will help us achieve excellence faster.
We invite our customers to review the content and help us improve and we have a dedicated email address so anyone can provide feedback. We’re always seeking opportunities to engage with our customers so we can make sure they can access the help they need.
Don’t Be Afraid of the Bin
Collate all the feedback you receive (together with your analytics) and constantly improve. With the right authoring tool, revising and republishing content is a simple process. That’s what’s great about webhelp – you can make corrections or improvements and publish them instantly. Our pages are date-stamped too, so users can see when the content was last updated. This means they can trust that the information they are reading is current and relevant.
Monitoring and revision shouldn’t stop until the product or process is retired or the content is no longer useful. A simple process is to assess each topic - is it helpful? If so, keep it. If it isn't helpful, bin it - there's no point wasting time monitoring or revising content that is no longer used or required. Focus your energy on perfecting the content that is useful.
The Never-ending Story
Document development life cycles are clearly an important principle to work towards, but they shouldn't be constraining. You need to flex and adapt to each situation you’re presented with and balance that with the needs of your users and the business. Make sure you get the right tool for your requirements (we needed to migrate and consolidate then publish the improved content to multiple channels), then you can endlessly monitor and revise until you end up with the perfect content, well, nearly…….. sleep, monitor, revise, repeat! Take a look at our never-ending story - https://help.iris.co.uk/.
ENDS
