What is the Document Development Life Cycle?

This guest blog post was written by Tracy Mack, the Senior Content Designer at IRIS Software Group.

A documentation development life cycle is a systematic way of developing technical documentation and continuing to do so in a cyclic order. It consists of five or six key areas:

• Requirements and analysis
• Design
• Develop the content
• Review the content
• Publish
• Maintain

That's a great concept for some, or even most businesses but for others, sometimes a more fluid approach needs to be taken. A document development life cycle also depends on how your content fits into the development cycle of your products, and how well your authoring/content team is integrated into the wider business. The lifecycle can only work if it fits in with everything else.

Here’s how our content authoring process fits into our product cycle.

Content Design is relatively new as a formalized discipline in our business. We don’t just write help content, we’re also involved in the production of onboarding emails and in-app engagements, UI copy, and occasionally some marketing copy. As you can see, we’re involved from the early stages, which helps us influence the user experience and determine what user requirements are needed and where.

Why Have a Document Development Lifecycle?

IRIS Software Group business has over 100 different products, split across four key business sectors. Some of these products were acquired so we've inherited content written by many people with a variety of tools and published to multiple places (Zendesk, FreshDesk, Wordpress, PDF, and support websites to name a few). Trying to implement a documentation development lifecycle wasn’t going to be easy. So why did we need one?

With so many products across multiple business sectors, we started by quickly auditing and consolidating existing content and identifying how we could make it accessible to end-users. Some content was presented in multiple PDF documents so wasn’t searchable and could be out of date before it was read.

After the audit, our first goal was to move all content online, in a consistent format as quickly as possible. We needed an up-to-date, easily accessible single source of truth our customers could trust. IRIS recently moved to a Salesforce CRM system so we also needed to publish on this platform.

For each product, we assessed what was required based on the product design and its intended usage. A style guide was also produced to ensure there was consistency in brand, style, and tone of voice.

Following this exercise, we began the process of migration.

As with many transformation projects, there were of course barriers and frustrations to overcome. Dependencies on external platforms such as Salesforce and Adobe led to many discussions and it was during this stage we were introduced to MadCap AMS.

MadCap AMS is an authoring and management system which supports the entire content development process. Following a review and consultation, we switched to the platform.

Working with MadCap Software was a relatively smooth process and enabled us to set up and apply a consistent design across our product range. We also set up project templates to help our growing team of Content Designers be successful.

Finally, we have been able to publish to Salesforce. It took a while to iron out some data issues but with help from the MadCap Flare support team, have been able to automate the entire publishing process. The days of inefficient manual copying and pasting are truly gone.

A key learning point for any professional looking for a content lifecycle system is to make sure you assess what you need in terms of output before you start the technical documentation process. This includes assessing the tools and resources for the job. Single sourcing using an authoring tool saves an incredible amount of time, ensures consistency and accuracy, and means you can implement a multi-channel system whenever you need to. You can also react quickly to feedback so your documentation is always up-to-date.

Producing Content Based on User Needs

The starting point for any document lifecycle is to consider your users and their needs. With so many different products, personas, and varying user journeys, it's almost impossible to serve all of our users with perfect and consistent content right from the start. While it might be painful releasing user documentation that isn’t up to our ridiculously high standards, it’s sometimes better than providing no content at all – after all, no content puts more pressure on support teams. It's one of the many reasons documentation cycles have to be fluid and iterative.

In terms of planning, when producing a help centre, we typically start with a site map based on the functionality available in the software product. Here's an example:

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