Content Design Content First Content Strategy remote working Technical Authoring terminology

Content design at Sage

Content design is a relatively new role at Sage, the market leader for integrated accounting, payroll, and payment systems. I’ve been here for over 20 years and seen a lot of change. Not least the work I do on a daily basis.

8:50 – Watercooler

It’s time for a coffee and a chat with the team.

Sage has offices in Newcastle, Manchester, Reading, and London. We’re working from home at the moment (can you guess why?), but I normally work out of the Manchester office. Most of the team is UK-based, though we also have a few remote designers.

Working from home hasn’t stopped us from staying social. Before the pandemic, it was difficult to socialise as a team, but now we have a daily coffee chat scheduled where we talk non-shop for ten minutes.

This was so important in the early weeks of working from home where we were all adjusting, but we enjoy it so much, we keep having them. It’s our daily water-cooler moment and when we find our way to the offices, I’m sure we’re going to continue these.

9:00 – Catch up

Our working hours are typical office hours. I work 7 hours a day, 35 hours a week. Before lockdown, I would start at 8:00 and finish at 4:00. But now that I’m at home and don’t have to worry about school runs or commuting, I stick to 9:00 to 5:00. A slightly later start works better for me as I can get an early morning run in and still have time for a shower and breakfast before starting for the day.

Firstly, a catch up with my manager to share what’s been happening with the team whilst she’s been on holiday. We use a Trello board to share what we’re working on (because it’s nice and visual) but behind that we use JIRA where our tickets are collected with the other designers.

9:30 – Responsibilities

I start my focussed hours. I like to block a couple of hours each day to reduce the chance of people inviting me to meetings. We’re getting much better at avoiding unnecessary meetings now. Microsoft Teams and Slack are where most of the communication happens, and whilst you need to manage your notifications, you can avoid meetings and collaborate quite effectively using just these two tools.

I need to check a Madcap Flare project to make sure that changes I’ve made to some content for our new deployment targets haven’t broken any of the existing targets.

Content designers at Sage have a number of responsibilities including (but not limited to):

  • Topic writing for help systems
  • UX writing for user interfaces
  • Globalising content
  • User engagement through research and monitoring feedback.

I’m likely to hit three of these areas today.

11:30 – UX writing

I’ve a query from a solution designer who’d like me to check some wording on a user interface design that’s going into a developer sprint next week. She’s sent some screenshots in an email. I’ve seen these designs before in the Figma project and the queries are just clarifications that things are making sense.

On the team we use a mixture of ways to record content for UI designs. Sometimes it just takes a quick comment on a figma project, but for this project, I’d already created a copy doc in a powerpoint file. I tweak a couple of sentences for one dialogue and send it over.

Collaboration is crucial for Sage in designing great customer experiences. Content designers are expected to work closely with the solution designers and the UI designers. For this new project, the work has been split into multiple workstreams. I’ve been invited to kick-off meetings and have already designed a lot of the content that we need. We are seen as the authority in word choices and whilst this does result in many queries, it does mean that we’re seen as a key part of the design team.

Content design dashboards help gather thoughts on a project

12:00 – Support during crazy times

Lunch. Quick sandwich with my kids. School’s just broken up but they’ve been at home for the last four months because of the lockdown.

Sage has blown me away by their colleague support through this period. Within a day of lockdown, all 13,000 staff were safely working at home. We were told time and time again that this is not a normal situation and it’s okay to feel not okay.

I was delighted when Sage provided us all with a subscription to Headspace, the meditation app. I’ve been an off-and-on meditator for years so it’s been great to have this cost taken care of.

A particular worry for me was how I was supposed to help homeschool my kids and work. Managers put my mind at rest.

We are in the same storm, but not in the same boat.

I did what most of us with children did, and muddled through. It wasn’t always pretty, and my kids sometimes got away with murder, but I didn’t have to stress that my every working moment was being scrutinised. It was normal to see other people’s children in video calls.

My son trying really hard

And now that we’re talking about returning to offices (late September at the earliest), colleagues are being kept in the loop through weekly updates with the reassurance that no colleague is going to be asked to go back into an office until everyone is happy.

1:00 – Video tutorial

I’ve recently been asked to look at Adobe Captivate to re-record some videos I made a few years back. I’ve already dug out the video scripts and checked against the current version of the program (only a few minor tweaks needed, thankfully). But, the old videos were recorded in Camtasia and I want to see if I can get to grips with Captivate to upskill myself and bring our toolset in line across the team.

Sage have provided several learning tools to help us keep our skills up to date including LinkedIn Learning, and Pluralsight. I find a beginners course on Captivate and save it to watch later.

I’m surprised by how much Captivate’s come on since I last worked with it. And to be honest, my heart is probably with Camtasia (I just love their timeline editor) but I think I can grow to like Captivate enough to produce some quality videos.

1:45 – Daily standup

Every day at 1:45, the content team have a 15 minute standup where we share what we’re working on. It’s the first time I get to speak to our North American colleague (due to time difference) and it’s great to hear how things are going over there.

During the standup, we identify some work is going to be needed on one of the projects due to the changes in VAT rates. We make a note of who is best placed to do that work and assign a JIRA ticket to them.

2:00 – Giving something back

I get an email. I was expecting it. It makes me a bit sad.

Sage Foundation is our charitable arm.

Embedded across all 23 Sage markets, Sage Foundation unifies colleagues, Partners and customers in a programme of social change philanthropy. We help tens of thousands of people in our local communities through more than 1,000 charities.

Every colleague gets 5 days a year to use at Sage Foundation projects. I’ve already spent 3 of my days at Care UK in Northwich where they have a donation sorting centre. The email advises that due to Covid-19, we’re not able to attend.

Volunteering at Care UK

This has affected a lot of our organised events but the Sage Foundation haven’t let us down. Instead, they’ve worked hard to provide us with remote charitable activities and have encouraged us to work with our families. Our most recent Foundation at home day ended with a virtual party!

3:00 – Design huddle

My new colleague is a little aloof for my liking

Our design huddles are an optional weekly opportunity for experience designers at Sage to ask for feedback on work in progress.

When I first started attending these, I doubted whether I would have anything to contribute beyond pointing out any typos, but my confidence has grown.

As a content designer you need to be a customer proxy sometimes. That means you need to understand what the customer journey is. Not just what steps a customer is physically taking through the software, but what they’re feeling during that time. What pain points are they likely to be feeling? How can the designs be tweaked to take away those pain points? Can content be tweaked to remove ambiguity?

4:00 – The last stretch

I’ve a few points I want to finish on before the working day ends.

  • I’ve recommended that a piece of design goes to our user researcher to put in front of customers and that reminds me to book in with her so I can listen in on the call.
  • I’ve had a reminder to complete a piece of security training. I login to the training website and double-check that I’ve actually done it.
  • We’ve a help release pencilled in for tomorrow. I add my help project to the JIRA ticket to make sure it will get included.
  • I book my birthday as holiday. It’s not until October, but seriously, who wants to work on their birthday?


If this working day sounds like the kind of thing you’d be interested in (apart from the homeschooling, no one wants to do that), please check our content design vacancies.

Technical Authoring


brunch (4)
We all need focus in our lives.
Too many distractions, too many pulls in conflicting directions, too many ideas to chase.
All of it ends with us being tired, exasperated, unable to achieve our dreams.
This blog is about my journey as a technical writer in a FTSE 100 corporation, and the reason it’s been bereft of new content is that it pulled my focus away from where I most needed it.
I’m still on the early part of that path to becoming a successful fiction author, but now that I’m a little farther ahead, I can afford to take stock and bring back some of those areas I deliberately cut out so I could focus on my author career.
I’m looking forward to sharing some more of my experiences working as a tech author professional in an ever changing world.

Technical Authoring

Beyond the Comfort Zone

This article first appeared in the Spring 2013 edition of the ISTC Communicator Journal.

brunch (6)
Falling into Technical Writing is something a lot of us can probably relate to. Technical writing certainly wasn’t a career choice I had in mind when I left university. Mind you, is it any wonder with a degree in accountancy and computer science that I ended up working for a company making software for accountants?
I’ve worked for Sage ever since I left university. Firstly as a developer, then as a project manager, and now as a technical writer. But none of this was part of a career plan. At times it felt like I wasn’t making any decisions about my career and was merely getting dragged along for the ride. But after finally edging into a technical writing job, I found I was good at it, and have been doing this for six years. I’ve spent that time writing Getting Started Guides, and Installation Guides, and F1 help, and Release Notes and all the rest of it.
But, times are changing and recently I’ve come to realise that this job is changing. All fired up on this epiphany, I decided to take matters into my own hands and make sure I stayed relevant.
But, before I could do that, Project Dave happened.

Project Dave

We’ve developed a new software module for customers that’s going to have a big impact on our customers and support teams.
But, why so difficult?

  • This was going to affect a lot of existing customers.
  • The software worked very differently to what our customers were used to.
  • It introduced new concepts that were difficult to understand. The primary one being the iXBRL reporting standard adopted by HMRC.
  • Strong competitors would be looking for any weakness in our offering.

In short, the product had to work, it had to be supportable, and it had to be easy to learn.
A project kicked-off with the aims of rolling out this module; minimising impact on our support team; and ensuring the best experience for our customers.
Initially, I was flattered that a manager recommended me for this project, only later asking myself whether that meant I was considered less fundamental to the development effort. Whatever it meant, this was a lucky thing for the Project Dave team, because I discovered I did actually have some useful skills.

How have I stepped outside my comfort zone?

Comfort zones are great aren’t they? I’ve spent the last six years cocooned in a world of help files and style guides and PDFs. But, maybe comfort zones can become little jail cells as well. I’d got very comfortable in my technical writing role and rarely lifted my head above the parapets to see what else was happening in the company.
I was nervous stepping into that first Project Dave meeting. There were about a dozen people from across the business. I knew some of them, but I hadn’t worked with them before, and I didn’t know what was expected of me. Also, being honest, I was nervous about being landed with a load of work.
I still had my day job after all: writing the help file for this new module.
So, with a team made up from all across the business, we agreed to meet weekly to start this roll-out project.

The right words

What did I have to offer this team? I didn’t know much about any part of the business outside R&D (Research and Development). But, in our very first meeting, someone announced that the aim of the project was to migrate our existing customers to a new product. The word migrate struck me as having negative connotations in the software business. Customers generally don’t like being migrated from one product to another, so I proposed we use the word ‘adoption’ instead. And thinking more on it, the word ‘migration’ wasn’t that accurate as we weren’t proposing our customers stop using their existing software.
Maybe some in that meeting thought I was being pernickety, but if they did, they didn’t voice it. What happened was from then on we used the word ‘adoption’ in all our communications with customers. Precision in language is one of our skills as technical writers, and we should encourage others to see its importance. A small victory then, but it gave me masses of confidence.

Coming up with a plan

On the face of it, we had loads of time to get our customers using the new module. But, after the initial comfort of believing we had twenty-one months until the HMRC deadline, the reality was, that with a tight development schedule, we only had about nine months to get our customers ready.
A comprehensive plan was a crucial part of the project. Over the years, I’ve learnt to become a great planner. If I didn’t plan and tie in with the different projects I work on, I’d be overloaded. stuffed. I doubt I’m the only technical author who feels that constant pull in the directions of different projects and demands on their time. Technical authors are great planners. If we weren’t, we’d be stuck as soon as the next project came along. So, contributing to a business-wide plan wasn’t that difficult.
Hand-in-hand with planning is our ability to estimate effectively. Developers certainly have it tough when they have to estimate off the back of fuzzy requirements. But we’ve got to anticipate how much help their unfinished software is going to need, and try to guess how hard it’s going to be for us to get our heads around the solution so we can write about it.
Planning and estimating are so vital to technical authors because we’re often fitting in our work close to release deadlines, when the software is stable enough for us to play with.

Getting ready for the new module

Customers needed to understand a lot about the new module so they could start using it in their businesses. For example, although we were trying to make it simple by plugging a new module into their existing software, there was a good chance that when they got the installation disk, they’d just assume it was a regular update, and pay it no attention.
By the second week of Project Dave, I was seconded into a sub-team called the ‘Need to know’ team.
It was our challenge to shape these initial messages. We needed to get customers engaged with us and with our plans. As a team we agreed that I’d produce a guide for this new module.
This document needed to do several things:

  • It needed to explain that this update was different.
  • It needed to explain about XBRL.
  • It needed to encourage them to start educating their staff about the release.

It wasn’t anything like the typical guides I’d write: it was more a hybrid marketing and technical piece.
This guide saw the start of some decent collaboration with product managers, marketing, support, training, R&D, all contributing to this guide. Once everyone had contributed, I used my language skills to shape this into something simple enough for the customer to understand.

The Learning Centre

One of my biggest contributions to the project was the Learning Centre.
Our help is delivered in CHM files that are installed on each workstation locally. This of course means that if we want to update our help, we have to wait for the next release of the software. I wanted us to get more into the online space to free us from release cycles and react faster to customer needs.
But creating a new help centre was not feasible for this project, so with no development time available, I suggested a simpler website where we could at least host videos and PDFs. I didn’t even know how to get that off the ground but after working with our marketing team, the idea developed and we soon ended up with the Learning Centre website. It didn’t cost us much, and was designed in such a way that I could produce material and with the marketing team’s help, get new content to customers.
Besides its primary use for customers, it was a great resource to point our staff at to get them briefed on the new module.

Roadshow planning

We knew it was going to be difficult to get all our customers using the new software in the timescales we’d like. Roadshow events had worked well in getting customers engaged previously, so we thought they could help with this project. But what did I know about roadshow planning? Unsurprisingly little. But, all I needed to do was use my problem solving skills and I was able to contribute.
One problem we needed to tackle was an environmental one. We didn’t want to waste printed material at these events, so I suggested we put recycle bins at the exits like cinemas do for 3D glasses. Might not be a great idea, but at least I was able to contribute. All I needed was to use my common sense and draw parallels to other problems that already had solutions. The lesson I learnt here was that it is so important to get past that fear of making suggestions in areas that don’t relate to your specific role.

Usability testing

As technical writers, we’re so close to our products that we should be great user proxies. I know when I’m writing a topic if I’m struggling because I’m having an off day or the process is clunky. But one thing was limiting my ability to speak with authority for our users; I hadn’t spoken to a single customer in six years.
An opportunity came about to get involved with usability testing on the new project and I took it. The first session was done remotely, and the second in the user’s place of work. On both occasions, I got to watch a user perform real tasks with the software I was trying to document. This was pretty eye-opening. Some things I’d assumed would be simple for a customer ended up being frustrating. This taught me that I need to get more involved in the development process from an earlier stage.
One of these usability sessions highlighted another skill we take for granted. The customer had noticed a spelling mistake in one of the software’s reports. This totally dented his confidence in the program and he told us he was now wondering what else was wrong with the software. Technical Authors are great at spotting spelling mistakes, and this largely taken for granted skill, on this occasion, had a demonstrable impact on the customer.

Shaping external communications

I worked closely with the team on external communications to customers, and I learnt loads from doing this. Working closely with our marketing team on a communication was enjoyable. They have a great grasp of language, take time to make sure it’s right, and they’re receptive to feedback. I thought we were very alike.
I was also involved with the script our managing director would use in a webcast to our customer base. I reviewed it and made suggestions. It was crucial to get the tone of this right and make it seem as natural as possible. When I’d finished taking out unnecessary jargon, we had a script that was a great example of plain English.


Of course, it wasn’t just me that would be writing user assistance for the new module. People from support, professional services, and the learning and development team would all be writing material.
I’ve seen work from these areas before, but sometimes when I review their work, I find stuff that other people miss. In short, technical authors are great at reviewing.
For one particular course, I reviewed the training manual that would go to print for our roadshows. Overall, it was a solid piece of work and did a good job in exploring the main areas of the new module to customers. But, there were issues with it. I was the fourth person to review, and changes had already been made based on the initial reviewers’ feedback. But, when I came to review, I found missing words, typos, text alignment issues etc. Reviewers should be catching these things, but they didn’t.
Is this because of a lack of reviewing technique? Are reviewers too polite? Do they not give these things enough time? Possibly. I know the reviewers cared, but I don’t think that reviewing was their strongest skill. However, technical authors are great at this, and we can help teach others how important reviewing is.

Has this experience changed me?

I wouldn’t have been able to contribute to any of these pieces of work without stepping out of my comfort zone. I used to think I was of most use to the business in settling down and doing what was asked of me – writing help files – doing them well, and on time. But, I took a risk and agreed to join a project away from R&D.
And I’ve learnt and achieved a lot.

What am I going to do next?

So, with all this going on what am I going to focus on next? Well, Project Dave is going to be continuing throughout the year and next, so I’ll be working with that team for the foreseeable future.
As well as that, there are some other things that are happening that will continue to take me away from writing help files.
There are roadshows where I can talk to customers and demonstrate the software I’ve been working on.
I’m getting together with other user assistance writers in the business to start collaborating. We’ve started meeting now, and looking at how we can share best practice. I’ve been sitting with some of our support team, and reviewing articles they’ve written for our knowledge base system. This coaching has been really well received. We’re going to be focusing on video production next, aiming to agree some standards on style.
My line manager, Chris, is a usability specialist in R&D, and a couple of years ago he suggested we teach our R&D staff about the Sage tone of voice and how that applies to our user interface in the software. Chris came up with a great workshop format and we present these together. He asked me to be involved as language is a vital component in the Sage tone of voice. So, we talk about how the messaging in the software is so important to users and how we can make it better. We held four sessions last year and expect to hold more this year. Our aim is to get everyone in our R&D department through the workshop. I’ve done one of these on my own, and it was a lot of fun. The attendees listened, and seemed to get a lot from the session.
Our learning and development team are focused on helping our people develop their skills and knowledge. They’ve recently put together a great website with a growing list of resources for our staff to learn from. But, they’ve been asking for volunteers to help produce some of this content. I’ve said yes as it’s a good use of my skills. And beyond even that, I’m now the learning and development champion for our R&D team in Manchester.

What do you want?

I believe that we owe it to ourselves to shout about our skills. We’re too quick to label ourselves and get trapped in our roles. Just because I’m a technical writer it doesn’t mean that I can only write help files, or release notes. Project Dave was a lucky opportunity for me, coming at a time when I knew I needed to start stretching myself. Without it, I’d possibly still be keeping my head down and doing what was asked of me. But, we can’t afford to hide behind the labels we give ourselves. We have skills, and if we need to learn more, we can do that too. Now is the time to look at yourself and your skills and get your employers to recognise that you can offer them so much more than a technical manual.

agile Technical Authoring

Working on multiple project teams

I’ve been asked by a colleague what my approach to attending meetings when working on multiple project teams and sprints.

This came up again at an end of project review where other team members are working on multiple projects at the same time. So, clearly in this age of scrum, this is a common problem for people.

One of the biggest problems with working across multiple sprint teams is that you spend more time in meetings. The more time you spend in meetings, the less time you obviously have to work in that sprint.

I’ve found this challenging. My default position was to attend all of the sprint related meetings for the two projects I worked on. This cost me 2 days out of 10. Effectively 20% of my working time was then spent in meetings.

As one of the projects neared its end phase, I dropped out of one project completely as I knew I just didn’t have the capacity to do the work for both projects. Attending meetings for a project I wasn’t working on, didn’t make any sense.

Now, as one project has ended, and I’ve moved back to the other, those missed meetings have cost me a lot of understanding as to where the project is at. In essence, it feels very much like I’m back at square one with my work. The project’s requirements have changed, and I’m finding that the work I’ve already done is out of date.

So, let’s forget about that little blip. Let’s assume I’m working on 2 projects again with similar deadlines. How am I going to approach my time?

What meetings do I consider important?

Very important

  • Daily stand ups – Keeping in the loop is vital for sprint work. An efficiently run daily stand-up shouldn’t make anyone would feel it was a waste of time.
  • Sprint reviews – Get to see an overall picture of what the sprint achieved. 
  • Detailed sprint planning – Get your tasks added to the backlog. If enough time is given between the high-level grooming and the detailed sprint planning, I don’t see why tasks couldn’t be emailed to the scrum master for them to include. This would get you out of this meeting as well. This depends on your role of course. If you’re documenting like me, or testing, I don’t see why you necessarily need to be present in the meeting itself – which often consists of developers hammering out the details of their approach.

Less important

  • High level grooming – Again, depending on what role you have. User assistance is likely to be a secondary piece of work off the back of someone else’s work, and is unlikely to be a user story in its own right. This changed for me towards the end of the project where I emailed the scum master to get ‘finalising’ activities added to the backlog, e.g. ‘Finalise Installation Guide’, ‘Finalise Help system’.
  • Retrospectives – Our teams distributed the results of the retrospective after the event, so I could catch up in my own time as to any actions. If I had a problem, I could email the scrum master outside of the retrospective.
I guess, it’s always going to depend on what your role is, but I suggest that if people are feeling like they’re spending too much time in sprint sessions then you should take a close look at the reasons why and try to address.