Content Design

A year of content design at Sage

After a year of change with content design at Sage, I wanted to review how things have gone.

The team keeps growing

At the start of the year we were a team pulling together into a new organisational structure. Each of us had been at Sage, largely as technical writers, for many years. In January, we were forged together into a new content design unit responsible for many products.

As we reach the end of the year, our team has expanded. We’ve gone from a team of 7 to a team of 13. I’ve been at Sage for 23 years and never seen so much commitment to content.

We began this recruitment in August and it feels different to when I last recruited two years ago. Then, I had 2 content marketers and 2 technical writers apply for 1 content design position. It felt challenging to get across what we were trying to accomplish with content design at Sage. In hindsight, if we’d have advertised for UX writing candidates, we’d have done a lot better.

Now, we’re getting candidates with the right skills, and although experience is limited, the quality of work produced for interview tasks was superb. Candidates were also younger and their confidence and enthusiasm for content design as a discipline in its own right was evident.

And Sarah Richards was mentioned a lot.

Existing processes are questioned

With a team of 7 who were used to working together, we could get away with muddling through the work. At the start of the year, we were a little unsure of how we should be working with the larger Experience Design organisation at Sage. The larger organisation knew we existed, and would do their best to make sure we were included, but processes were not written down and we were still (sometimes) justifying our position.

As our team grew, so did the Experience Design team. New solution designers and UX designers joined our division at Sage and the process for how we would work together was formalised. Content was where it needed to be, right alongside the solution and UX designers at the start of any new workstream.

Since then, we’ve done our best to keep to this process but it feels that the ratio of content designers to other disciplines may not be quite where it needs to be. For some workstreams, we’re right at the beginning, for others we might get involved when there are designs to review.

This isn’t anyone’s fault. It’s just a question of demonstrating the value of content consistently so it becomes more noticeable when we’re not involved at the start. As the team is growing and we’re able to allocate more people to workstreams, I’m hopeful that we can improve this picture.

Standards are considered part of the global design system

Sage has an updated design system and content is set to play a key part. We’ve had our own internal style guides before of course, and in the first version of the Sage Design System we had a reasonable amount of content to support content designers. But what we’re aiming to do with Sage Design System version 2 is provide true value to content designers globally across Sage.

It’s a big task. We operate in 24 countries and serve millions of customers. But we still want to bring some unity to the experiences we provide. Just this week, we set off with four new workstreams to flesh out the content parts of the Sage Design System.

Content design is in even more demand

There is no shortage of work for content designers at Sage. Our remit includes: UX writing, help topics, help videos, and lots of other things that I’m going to group together as content strategy.

Historically, our remit consisted solely of writing help topics but if we were to through that way now, there would still be too much work for us to do. It seems news is spreading that we have good content designers who can contribute to other products and aspects like our website.

This demand for our team is pushing us to revisit our requests for work process. We’re well past the stage where email is an acceptable way to request our time so we’re trying out a few different things.

We’re making more use of Microsoft Teams with the Support team. Support have a preference to use the same feedback mechanism that we offer to customers on help topics because it’s simple. It’s also messy and requires us to process the feedback so we can easily see what’s come from colleagues and what’s come from customers. Teams allows us to implement the Lists app which gives us a simple change request form. It’s handy for Support as well as they get to see what else has been logged.

Deciding where to focus is difficult

The team has a somewhat fuzzy boundary. There is a list of products that we need to provide content support for, but how much content support each gets is largely down to our discretion. For development teams I imagine it’s a lot easier when deciding what work to do. They have a backlog and the product owner determines the priority. When you’re spinning plates across multiple unrelated projects, having a single product owner to determine priority becomes nonsensical.

We’re working through this but it might be as simple as being very honest and open with each project’s stakeholders as to how much time we’re spending with their projects, and what actual work is being done for them. As projects move on, we will get feedback as to how well we’re doing.

No time to sit still

As we prepare to enter a new calendar year, it’s reassuring to me that content design hasn’t lost any of its impact at Sage. We might not be quite where I’d like us to be as a discipline but tangible progress is being made to bring the rest of the business along with us. It’s still a good time to be in content design.

This article was originally published in ISTC Communicator, Winter 2020.

Content Design Customer Service

Running a customer journey workshop

It seems everyone in our company is talking about customer journeys. As a company with a clearly stated customer focus this is to be expected, but how can content design use this enthusiasm to benefit an aging help system?

Running a customer journey workshop title card

Customer journeys are primarily used by my Experience Design colleagues to understand the processes a customer goes through in their work, in an effort to map those experiences onto our software designs. The end result should be a software experience that fits seamlessly into a typical customer’s work lives.

Whilst that makes for a better software experience, we wanted to explore whether we could use some of these techniques to improve help content for existing software, in essence, using the customer journey to facilitate a content audit and review with the aim of targeting our limited capacity to get the best results for our company and our customers.

What is a content audit?

Keeping content fresh and relevant to its audience is crucial. If it’s not relevant or kept up to date, the audience won’t find any value in it. This has repercussions. Customers who are already struggling with the software, and are now struggling to find the help they need in the help system, will find a way to contact Support and they won’t be happy.

Support costs are huge and there’s a constant pressure on our departments to encourage customer self-serving behaviour. For this to be a success, the help content itself must be up to scratch.

A content audit can help us ‘sniff the milk’ on our content, i.e. to understand what we have, what we’re missing, and what is out of date.

Why is this important?

We’ve recently picked up responsibility for the help system for one of our key products. Previously, the help system content was owned by Support who had a different view on how to create and maintain a help system.

A significant issue for us has been on previous adoptions of the Knowledge Centred Support methodology where support technicians were encouraged to end calls by writing content in the help system that answered their customer’s query. Without tight governance, this has caused significant bloat in the help system that caused a number of issues.

  • Multiple topics answer the same question.
  • Topics covering the same area are sometimes contradictory.
  • A large number of small topics with relevant keywords can clutter up search results making it more difficult for customers to find the relevant topic.

It’s not just KCS we’re dealing with. The help system is over ten years old,  covers multiple regions, and has been written by multiple authors. Good topic curation has sometimes fallen by the wayside as the pressure of delivering new content for new features has taken precedent.

Who to get involved?

Instead of just reviewing all existing help content, we wanted to target a particular area. In deciding what area to target, we dug into the customer feedback we’d been gathering steadily for years. This together with Google Analytics helped us answer the following:

  • What terms are customers searching for?
  • How many topics cover the same topics?
  • What satisfaction score does the most popular topics in this area have?
  • What negative verbatim feedback have we received for this area?
  • What verbatim feedback has been left to Support colleagues?

Our biggest resource in understanding customers in this area (beside customers themselves) was clearly our support team.

We identified a major area of concern in the help system was Bank Feeds and confirmed this with Support who had this down as one of their biggest call causers. (A bank feed is just a way of bringing your bank transactions into our bookkeeping software for businesses.)

Unquestionably, there were issues in the software in this area, and once we’d passed back the main concerns to the development team, we were able to focus on how the help system could also be improved to support this area whilst we waited for software changes to come.

Workshop it

Invitations were sent to the support team and we received overwhelming enthusiasm from colleagues keen to work with us on improving the content. We decided on a workshop format to bring ideas together and form a plan of action.

Working remotely because of Coronavirus, we settled on Miro and Teams as our facilitation tools. Miro is incredibly flexible and great for collaboration, allowing multiple collaborators to work in the same virtual space simultaneously. It also comes with dozens of useful templates, including a customer journey template.

We set up a MIRO board with a typical customer journey through the process of setting up a bank feed in our software. Whilst we could have done this in the workshop itself, we decided against it as the process was fairly well understood and easily replicated. 

The customer journey board prior to the workshop starting, was then a timeline of screens that formed the bank feed connection process. At each stage, we wanted to draw out any potential customer pain points.

We also prepared the board by adding direct customer quotes from feedback left via the help system about this area. In Miro, virtual post-it notes are the simplest way to realise this. We kept a section to the side of the main timeline with customer quotes that we’d be able to refer to in the workshop to back up observations or stimulate discussion.

Running the workshop

We kept the workshop to a somewhat pacy two hours, knowing that typically workshop fatigue sets in around this point and there is little to be gained from prolonging the experience. This was also why we wanted to focus on one targeted aspect of the help rather than the whole shebang.

With three Support colleagues and three content designers we walked through the customer journey that we’d already mapped encouraging the following:

  • Corrections to the flow
  • Anecdotes from Support at each point as to typical calls received
  • Issues we’ve identified in the help system at each point

Participants were encouraged to refer to the customer feedback, add their own feedback, and share their customer experiences.

What happened next?

The workshop had several outcomes.

  • We understood, as a content design team, the problems customers were having on a day to day basis with bank feeds.
  • We made notes of the terminology Support used so we could incorporate that into content metadata.
  • We came up with a list of topics that were deemed to be key in reducing call volume and planned for those topics to be created or reshaped from existing content.
  • We identified problem areas in the existing help content that we would need to look at.

Running a workshop like this was new for us and proved a lightweight way of tackling known problem areas. By involving Support, we were able to build relationships and demonstrate that we were able to collaborate efficiently for the benefit of our customers.

We now have more workshops lined up with the aim of working through the major areas of the help system.

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.

Content Design terminology

Designing with the right terminology

Using the right words is a crucial part of any customer journey. Whilst this shouldn’t be the total responsibility of content designers, we’re well placed to help nudge the rest of the design team toward the best choices. At Sage, I work within a close knit team of designers who are quite happy for me to explore word choice in the design process.

Licence versus subscription

A large part of our business is now in software as a service and this means a shift away from one-off purchases for software towards a pay-monthly option. As part of redesigns in this area, I was asked to review some screens from a content design perspective.

The screen I was asked to review contained the words ‘licence’ and ‘subscription’ in the same sentence which struck me as odd. I’d seen these words used interchangeably in our designs before and I wanted to ensure we weren’t being lazy with word choice.

The UX designer had included both words at the behest of the solution designer, who had included them because they existed in a previous iteration of the software.

Digged deeper, I asked both the UX designer and the solution designer to explain the difference between a licence and a subscription in the context of the screen I was reviewing. Neither had a compelling answer. One admitted to using both terms interchangeably depending on whom she was speaking with.

There was a can of worms here and I’ll admit to thinking twice before opening it.

Confirming the problem

My initial reaction was that if we weren’t sure of the difference between the words, then we were at risk of confusing customers. Many of these customers were transitioning from our desktop software, where licences were indeed bought for perpetual use, and moving to a subscription service. I wanted us to get this right to avoid any confusion as to what they were paying for. My gut instinct was we should be using the word subscription and could probably drop licence from our vernacular altogether.

But, maybe we were in too much of a bubble in Experience Design. Perhaps outside our department there really wasn’t an issue at all.

I spoke to a long time colleague in the Sales team.

‘I only ever use the word licence,’ she told me.

‘Never subscription?’ I pushed.

“Nope. Only licence. It’s what we’re used to.’


Researching options

I turned to online definitions:

Subscription – An arrangement by which access is granted to an online service.

Licence – A permit from an authority to own or use something, do a particular thing.

This led me to the example sentence:

When a client subscribes to product X, they have a licence to use that software.

So, we could still use both words but I didn’t think we needed to. In the context of many popular software as a service providers, they go out of their way to avoid even the word subscription.

  • Netflix talks about signing up for an account and cancelling that account rather than subscribing and cancelling the subscription.
  • Spotify mentions subscriptions in their help files, but not at the front end.
  • On the Microsoft Office 365 product page, the word subscription is only included as a footnote.

Do our customers care about this?

What do our customers think of our licence / subscription terminology? Was there any evidence that customers struggled with the terms?

I’ll admit to not following up this aspect of research at this stage. My advice to you would be to contact your Support and Sales teams and ask them this question directly.

Also look to any feedback mechanisms you have within the product to see whether customers have demonstrated any confusion.

My approach was to handle this in the testing phase once I’d firmed up my thinking and we had something to show customers.

Terminology expands

It wasn’t just a choice between the words licence and subscription. Within our product, we have a feature where one customer can purchase product units for their clients. Where a customer has bought multiple product units (aka subscriptions) for their clients, what should we call the ‘thing’ where these units are stored prior to being assigned to a client?

I dumped a lot of initial thoughts on a Miro board along with examples of how each word might be used in the type of sentences we were likely to need in help topics and the user interface. This gave my thoughts some shape and helped me understand what might be feasible.

Narrowing down the options

Language and emotion play a huge part in the customer journey. I needed to decide on a word to use for this collection of subscriptions. When a customer buys a unit for one of their clients but doesn’t assign it to them straight away, it gets ‘stored’ for them, ready to be assigned.

But, what to call it? Pot? Store? Pool? Bench? Archive?

I quickly dismissed Pot. It seemed too homely for the business scenario. Store was next to go because of its obvious commerce connotations. I seriously considered ‘bucket’, but I associate buckets with soil, and ‘building’, and dirt. Yeah, I didn’t like the dirt association. ‘Bench’ could have worked. I was thinking of the American phrase around benching players, but thought the phrase wouldn’t be obvious to most. That left me with ‘pool’. It’s not perfect, but subscription pool had a certain ring to it.

(I also invited others to suggest words, but no one came up with anything that wasn’t already on my list.)

Bringing stakeholders on board

As I was about to propose dropping one commonly used word from our development team’s vocabulary, it was necessary to start building up support. I work in a fairly small team of content designers in a much larger department of developers, solution designers, and product managers. Whilst I feel my work is respected, it can sometimes feel like shouting in the wind. I needed to amplify my message by finding supporters.

I’ve found visuals and examples the best way to bring people over so I created some before and after screenshots of designs impacted by the change. I use PowerPoint to create these fairly crude designs. I deliberately haven’t asked for access to more designery tools as I don’t want it to ever look like I’m trying to do the UX designers job for them. Instead, I want people to be able to focus on the word differences I’d introduced.

I met with the key stakeholders and outlined what I saw as the problem with my proposed solutions. It was rewarding to hear that stakeholders had recognised there was a problem but hadn’t been able to make moves to addressing it. I was given the blessing to carry on down my preferred route of simplifying by dropping licence from our designs.

With stakeholders on board, it was simple to work with the UX designers and arrange for my changes to make it into the latest round of designs. The UX designers were happy that the stakeholders weren’t going to be surprised at the next design review.

What do customers think?

We’re lucky that we have two dedicated user researchers who will put designs and questions in front of real customers. I’ve arranged for the latest designs to be shown along with some guidance that the researchers should ascertain whether the customers are clear on the subscription terminology.

This has been scheduled into the next round of testing (due after this article’s submission date).

We get good feedback through the user research programme and I’m optimistic that my recommendations will stand.

What I’ve learnt from this process

  • As a word ‘expert’ it’s always worth scratching those itches to see if word choice can be improved.
  • It’s difficult for people to object to evidence so user research is important.
  • A good relationship with stakeholders, especially UX designers, oils the wheels, making the content designer’s job easier.
  • Acting as early as possible in the design process will reduce friction.
  • Opinions matter but if you can provide evidence and demonstrate the value your recommendation will make, you’ll find supporters.

Why is this good content design?

I didn’t set out for this change because it irritated me. I did it because I was focusing on the user journey and how this particular word choice shaped many aspects of it. The most important of these relating to how much the customer would have to pay each month.

Working with other experience design professionals, particularly UX designers and researchers demonstrates how content design is a collaborative process and can’t work in isolation. As word ‘experts’ our teams are looking to us to solve these word problems for them, and expect us to help improve the customer journey.

Never be afraid to open the can of worms

Content Design Content First Content Strategy

Does content first matter?

Content First is the practice of designing a product or service with content being a primary concern ahead of things like the functionality a website offers.

Typically, designers may mock up designs and include placeholders for product text. They may even take a stab at writing their own content to fill these spaces.

An example of this might be when designing a travel website. If consideration hasn’t been given to the content we want to display on the first page, we might end up with an unsuitable layout. If boxes are saved for content using lorem ipsem text, the wrong amount of space might be allocated for the actual content that will end up there, resulting in awkward spaces.

Interest is increasing

I first heard the phrase two years ago when our new Experience Design director joined the company. Content First was how we were going to design going forward. Only, no indication was given as to how this was going to change things.

I’ve most recently heard UX Design colleagues returning from general UX conferences explaining that Content First is what attendees are talking about. It has become a buzzword in design circles.

My initial reaction to hearing about Content First, despite not fully understanding what it meant, was that us content folk were going to get listened to. No longer were we going to be thrown the designs just before hitting the development team. Instead, we were going to become an intrinsic part of the process; our involvement perhaps even more valuable than the UI Designers.

What are the common problems in designing without content first?

These are some common issues where content isn’t considered in the initial stages of design:

  • If we accept that content is a fundamental part of the customer experience, then throwing dummy content into a design and presenting that to a customer is going to result in questionable feedback. How can they give us feedback on a design where a fundamental part is missing?
  • Content can unify different parts of the experience. Where large design teams are creating a single experience the tone and messaging can become inconsistent leading to customer confusion.
  • Bringing a content team in late, can unnecessarily constrain their ability to shape the experience resulting in content being used to fudge through the experience rather than be the thread that pulls customers along.

How can Content First improve the situation?

Beyond obviating the problems outlined above, there are some other ways Content First can improve the design process.

  • By thinking more like content strategists, UX Designers can design without surprises. If they know in advance how many pieces of information their navigation designs will need to handle, they will design accordingly. If the titles of each page are going to be a certain length, they should be prepared and provide enough room.
  • Content teams can feed terminology preferences into the designs. As part of our work, we’re researching with customers and taking a wider view across products to make sure we’re presenting the appropriate words to customers.
  • By thinking of the wider customer journey, including key marketing and business goals, content designers can ensure products are designed with the appropriate messaging built in from the start.
  • By paying as much attention to the words on the screen as to the buttons to press, designers are becoming more aware of the emotional impact their designs are having on customers. If we can teach them why we’re using humour or not in a given scenario, we are helping to bring the customer back to the centre of the design process.

What are we doing at Sage?

Two months ago, a meeting was called to discuss how to implement a content first approach to our design process. It was the first time since our Experience Design director had mentioned Content First that the rest of the Experience Design team were ready to make changes.

I spent a lot of time researching Content First. There are different opinions on the importance of the approach and I needed to see where my views lay. As ever, it’s complicated.

I quickly realised that in none of the examples in Content First articles I could find, was anyone talking about complex web applications like we were building at Sage, where tables, charts, and dialogs were important.

I suggested that actually, what we needed wasn’t a Content First approach. It was a collaborative approach where content was included from the get go and where content concerns were raised as soon as possible. The UX Designers had enough constraints from the solution designers and as long as we were understanding workflow and seeing designs as soon as possible, we could shape content appropriately.

It didn’t stop us owning the terminology part of the design, or working with user research to ensure we were truly understanding the customer.

Finding balance

Whatever you want to call it in your organisation, it’s more important than ever that content is considered as early as possible. That might mean you need to find a way to work more closely with the design team.

At Sage, we’ve discovered that a close collaboration between UX Design and Content Design is the sweet spot for us. It needn’t be a tug of war between content and design. Better results can be had by remembering we’re on the same side.

Content Design

Playing nicely with the wider team

As a content designer, I wasn’t prepared to continue being forgotten like I was as a technical author. The director of our Experience Design department told us all that content designers were part of the core team bringing designs together and our work was to be valued.

Our work had value. We just had to demonstrate it.

Team structure

I work for Sage UK, a FTSE 100 organisation with over 15,000 employees worldwide, and we develop software to help small businesses thrive. The team I work on is focussed on creating software for accountants to help them run their businesses and work with their clients. This includes accounting and payroll software (for businesses) , and compliance and practice management software for accountants.

When a piece of functionality is to be developed, a core team forms.

Solution Designers, UX Designers, Compliance Analysts, User Researchers, and Content Designers come together to create the designs.

What’s the process?

Our process can be summarised in these stages:

1 & 2 – Roadmap and committing 

Content designers should be familiar with what’s on the roadmap. Content designers can help Product Managers tell the story of these features to sell them to stakeholders.

At this point, we likely haven’t allocated a Content Designer to the work but it’s important to be visible.

3 – Exploring the problem

The core team should have formed by this stage.

This is a great time to work with the User Researcher to understand the feature from the customer’s point of view. We will go on customer site visits and ask questions alongside the researcher, some of which will be related to content. The objective should be to empathise with the customer as well as nail down any specific terminology in use.

As soon as colleagues work on a new project, they’ll be creating their own terminology and often this isn’t a pretty sight. Casual terms used as placeholders, when used often enough, stick and find their way into the end designs. As Content Designers, we steer the terminology towards what we know our customers will understand and then share the agreed terminology with the wider team and stakeholders, all the way to the marketing folk.

We should already have established good relationships with Support, but here’s another chance to reach out and show we care. By listening to Support’s concerns as customer proxies, we can pre-empt those concerns in the designs and get a picture of where the pain points are likely to be.

4 – Creating detailed designs

UX writing becomes the main focus for us at this stage, and this is where it pays to take time to build a relationship with the UX Designer. Before Content Designers, UX Designers created the user interface and added words to the screen. During reviews, changes would likely be suggested and the UX Designer, may or may not implement those changes.

This way of working is changing.

It’s probably unrealistic to expect the UX designer to create designs without any content before passing them over to the Content Designer. The way I work is my UX Designer designs the screens, adding in first draft text then passes it to me to revise. The finished content can look very different to the original. It’s difficult to get this right.

One method might be to get the UX Designer to write the intent of the content in its place and that serves as a requirement for me to deal with. For example, they might write in an error dialog:

“We need to tell the user that the HMRC server isn’t responding and they’re going to have to try again. The devs don’t think it’s very likely and there’s not much Support can do if the customer calls them.”

I might then write:

“We’re not able to contact HMRC right now. Try again in a few minutes.”

This approach can help in a couple of ways:

  • It helps the UX Designer get it clear in their own head what the point of the dialog is.
  • It takes away the pressure from the UX Designer to get content right leaving them to focus on the flow of dialogs and interaction.

It takes trust to get this right, and the UX Designer needs to see that there is value in building this relationship. After all, previously, they’ve been able to work in relative isolation, presenting something as a fait accompli. We’re now expecting them to collaborate with the ‘word people’. And to some, that might seem insulting, after all, everyone can write can’t they?

5 – Implementing designs with development teams

With the designs complete, the devs should be able to implement the designs. Development work is never that neat though.

What I see on a regular basis, will be devs finding situations we haven’t considered and thus needing solutions and wording we haven’t prepared for. As work is in flight and devs are likely waiting for us, we typically have to drop what we’re doing to help.

Often, this is providing wording for error messages, but because we’ve worked closely with the UX and Solution Designers we’re able to do more. We understand the problem and the customer journey and can work as a peer in solving customer journey problems.

In our case, at this stage we’re also writing help articles and supporting other stakeholders who are producing content. That may mean reaching out to digital marketing teams and offering our assets to see if they can be reused, or working with Support in anticipating the types of calls they may get.

6 – Release and post release support

After the release of a feature, hopefully, there’ll be a breathing space to reflect and refine our process. If there are wider project post-mortems, it’s worth getting included to let people know how content design can work better as a function.

Overcoming hurdles with the process

No projects are the same and no company organises their people in quite the same way. There are problems with our process. Likely there are problems with yours.

Make a note of these as they come up, and have a retrospective to review the process.

No project is frictionless but with an agreed process and buy in from the right people before work begins, Content Designers can help make a better product that benefits the stakeholders and the customers.

What are these roles?

Solution Designers – Take the high level requirements from our product manager and break these down into detailed requirements. This forms a solution design that is passed to the UX Designer.

UX Designers – Take the solution design and explore different UX design avenues by creating wireframes and prototypes.They are skilled UI professionals.

User Researchers – Take the different visual designs from the UX Designer and explore these with users to understand which avenues need to be continued.

Content Designers – Work closely with UX Designers and User Researchers to get the best language choices in the designs. We’ll be aiming for putting the right words in front of customers at the right time.

Compliance Analysts – Akin to Solution Designers but focused on the legislative requirements for the product. For example, when HMRC introduce new legislation like Making Tax Digital, our software has to support it.

3 things this week Content Design

3 things this week

Stop press. I’ve got the central heating on.

  1. We’ve been given a couple of hours a week on a Thursday afternoon for professional development. This is just what I need right now. If you’re anything like me, you’ve signed up to more UX newsletters than you have time to read and they’re building up in your inbox. There’s generally plenty of good advice in the articles they link to, and you need time to go and explore.
    This time has given me the chance to catch up on a few emails, and read about five articles. I’ve taken notes on a few things I want to follow up on including the action to look at the possibility of adding more humour to our help content.
  2. Terminology is a hot topic across our Experience Design organisation and I’ve just been given a goal to try to solve this.
    The problem is we’re working so fast on new development of a new platform with many services interconnecting, and we need to agree on some common terms.
    What should be happening is the Content Designers should be taking a lead on this by being included in early kickoff meetings and collating terms into some central repository. This will ensure that everyone in Experience Design is consistent in their language and that will feed through to customers in the final designs.
    What’s actually happening is that the Content Designers haven’t been present at many of the design kick-offs so language is being developed with us to observe or steer. This is already leading to a ‘he who shouts loudest gets heard’ mentality.
    I’m working on this problem with the team’s user researchers to introduce a sensible customer focused approach that will be difficult for anyone to object to.
  3. I attended our company’s Accessibility Guild for the first time yesterday. The driver for this existing is HMRC need us to be AA WCAG compliant for any products that interact with HMRC services. As an Accounting software provider we have a few strategically important solutions that link to HMRC.
    It’s been great to see all the work we’ve been doing to make sure we’re compliant. An accessible website is accessible for anyone.
Content Design

Take control of your video brand

As technical writers, we do tend to love a good style guide. It’s important to bring consistency to the presentation of help content. We don’t want customers to feel they’re reading content from different writers; we want them to feel like a friend is talking to them. For this to work well, we need style guides and we need teams to adopt them and use them appropriately.

In large organisations, videos appear chaotic

What I’ve seen happen in my organisation is whilst generally written content is written with some respect for company style (at the bare minimum an understanding of our corporate tone of voice), less rigour applies when creating video content.

Video content is produced from marketing and sales teams, as well as Support, and our in-product technical authors.

If we want our video content to feel like it’s originated from the same organisation, it would help if video style guide existed that could be readily adopted by these different groups.

Note: for the purposes of this article, I’m primarily referring to screen recording videos, but some of these principles apply to other video content as well.

What do you put in a video style guide?


It’s tempting to just jump into a video recording and ‘wing it’. If we’re aiming for a high production level and a consistent feel, that won’t cut it. I’ve seen that in areas like marketing and support, there’s a tendency for creators to record themselves ad hoc: basically, making it up as they go along. And this is tempting, especially for support teams who are threatened with failing to meet KPIs to just get some new content out there to solve the problem.

Don’t wing it. Ever.

In your pre-recording section, outline the following:

  1. Planning – Understanding what the objectives of this particular video is and who the audience is.
  2. Script – Outline why scripts are important and if there are any preferred script templates to use. You might also want to set up a shared location which the rest of your organisation can search through. Scripts can save you time as you can get them reviewed before wasting time recording video, and will help when producing captions or translations.
  3. Prepare example data – If you’re using customer data, it’s got to be anonymized, and any backups you have of the original must only be kept under GDPR guidance. Keeping a backup of example data will help you if you need to rerecord any sections.
  4. Test runs – Running through the script before recording can help you check you’ve not missed anything and will highlight any pain points you’ll need to address later (like if new windows open in unexpected places or processes take uncomfortably long to complete).
  5. Computer settings – Decide what your resolutions should be. If your computer desktop is ever going to be seen, decide whether this needs to be the bare bones corporate look or something else. Do you want your customers to be distracted with your desktop icons or installed programs appearing on your taskbar?


The audio experience is also part of your brand. What might sound good enough to you over your PC speakers, might sound terrible when listening back over high quality headphones.

In our style guide, I outline:

  • The recording equipment I use (a Yeti blue and a pop stand)
  • The settings I use in Audacity (we record audio and video separately and join them together later)
  • The techniques I use to clean up the audio. This is the main reason I record audio separately in Audacity as the tools available to do this are great. If you use mess with the compressor settings and bass and treble, identify what settings you use. Tip: cleaning up the breath noises between utterances is great, but avoid using the ‘silent’ tool. Listening to a track on headphones where the silent tool has been used is more jarring than it should be.

There are plenty of tips for how to improve audio but you don’t want to get too technical for fear of putting people off using your guide.

Recording software

If you’re using a specific recording tool, it will help to outline the various settings you use. If possible, consider creating a project template that other creators can use.

Things to consider when discussing your recording tool:

  • The screen resolution used for recording and for editing and producing. You should be aiming to be consistent across these three to avoid your tool having to scale. It’s worth considering how your audience is going to consume your video, so whilst a massive resolution might look good on a full sized computer monitor, it might make it impossible to make out the necessary detail on a mobile phone. It’s worth testing different resolutions and target devices and include your recommendations here.
  • Editing – With tools like Camtasia, it can be very tempting to include ALL THE THINGS. There are so many pretty transitions and callouts. Not to mention the pan and zoom! Including more than a handful in a video is going to look messy. It would be better to choose a handful of simple transitions and callouts and use those. You’ll need to mention the settings for these in your style guide lest everyone ends up using different colours, speeds etc.

How to get buy in

Depending on your authority as a content creator and the size of your organisation this is going to vary considerably. My take on this has been to incrementally share the video style guide with wider and wider groups. You need to demonstrate the value in having a guide and there’s no better way to do this than to share examples of the finished product. You’ll want multiple videos, using the very same style guide behind it to demonstrate consistency.

Once others see how good you can make your videos, they’ll start coming to you for advice on how to do it.

Content Design

Keeping track of content

It’s not been an easy couple of weeks on our team. There have been lots of reviews and that’s inevitably led to requests for changes to wireframes and prototypes and inevitably the content tied up in those designs. So I’m grateful that I stumbled across an idea that’s helped keep the content on track.

Changing designs when content is part of the work

My content team have transitioned from technical authors responsible solely for writing help topics to content designers with new responsibilities. UX writing, as in the words that are part of the user interface, has only been part of my team’s remit for the last year.

We’re getting better at establishing our style, tone of voice, ensuring we meet our content principles, as well as agreeing on processes.

And our processes are inevitably entwined with the rest of the Experience Design team’s. A problem that’s been lurking ominously, has been how we keep track of changing content when the UI changes.

The UI has been changing continuously. It’s never anything truly drastic but with multiple reviews and an ever-growing posse of stakeholders, it has at times felt like death by a thousand cuts. Our designer has done all he can to keep on top of changes, but it’s meant that content changes sometimes get lost in the mix.

Whose job is it to make sure designs are up to date?

Our designers are using Sketch on Macs. The content team are using PCs.

Every change that I need the UX Designer to make has to go through him and he makes the changes. For a while, we were using MIRO (previously RealTimeBoard). With that, I was able to put my copy into comments which he would then place into the right wireframes. It worked. Kinda. But it also felt incredibly flakey and the real problem for me was that I wasn’t able to easily track what changes I’d made.

In addition to adding copy into comments, I was mocking up screens in PowerPoint to get a feel for how content looked when it was in place. To then take just the words and drop them into MIRO seemed disconnected. I was working in one set of files: the UX Designer was working in another.

And occasionally, content went missing. Sometimes, when prototypes were updated, my updated wording wasn’t there. This was usually because I’d shared the content in Teams or Email and not thought about how difficult it would be to track those done later.

Another issue was that I wasn’t able to always justify why content had been written in such a way. Changes to content might get suggested in reviews and the designer would sometimes make those changes. The lack of an audit trail on content was a problem and was wasting time.

There was no question: it was my responsibility to make sure that the designers had the correct content.

Enter copy docs

I stumbled upon this article on the concept of copy docs. The copy doc is essentially a word document owned by the Content Designer to keep a record of UX copy.

Whilst reading this article I knew this would solve many of the problems we were having.

  • I’d be able to track content changes from one iteration to the next.
  • There’d be a single point of truth to see what the most recent content was.
  • I had a way to get people to review content even if the wireframes weren’t current.
  • There’d be a record of alternative content that I’d previously considered. So useful when faced with stakeholders asking why particular wording was chosen.

I created a test document for a screen I was working on and shared it with colleagues familiar with the challenges. The initial feedback was very positive and that encouraged me to continue working with copy docs for several screens on my current project.

The inevitable ‘not a panacea’ moment

Copy docs have their own problems that you need to be aware of should you go down this route:

  • A copy doc is going to introduce a disconnect between the protoypes and content. Having these assets in separate tools only reinforces that.
  • When copy needs changing, you’ve got multiple things to keep in sync. E.g. prototypes, copy docs, user stories.
  • You’ll inevitably face resistance from some quarters. I faced incredible apathy from some Content Designers who couldn’t understand why I’d want to have an audit trail outside of UX Designers files. Their suggestions were to pass this audit trail problem over to the UX Designer instead.

But there were also benefits I hadn’t considered:

  • Some non-techy stakeholders prefer to review content in a tool they’re familiar with. Word is a comfortable choice for these people.
  • It forces me to really own the content and care what stakeholders think.
  • When writing content for new screens, I have an easy archive of content to flick through for inspiration and consistency.

Copy docs are absolutely not a new thing, and they’re certainly not very high tech. But sometimes low tech can work. If you’re experiencing any of the issues I’ve outlined, it’s easy enough to have a play with them and see whether they’re a good fit for your team.

Content Design

The rise of the content designer

Content Designers weren’t around when I started in the computer industry, and whilst they’re not exactly ubiquitous in software teams yet, there are definitely more of us than ever. How did that happen?

Title card for The Rise of the Content Designer and an image of a person on the top of a ravine

How I became a content designer

I left university with a mediocre degree in computer science and accounting and sought out a job as a computer programmer. To put that in perspective, one of my first projects was working on the conversion of a successful MS-DOS programme onto that new-fangled Windows 95. It still hurts me a little that I’m now working with people younger than that operating system. Let’s not talk about that again.

Fast-forward twenty-two years and gloss over promotions into management, then sideways into Technical Writing, promotions into management again, before arriving at the land of the Content Designer.

I’ve had this job title for eighteen months and am still getting to grips with what it means to be a Content Designer.

Luckily everyone else on the team is still coming to grips with it as well.

But isn’t a content designer just a new name for a technical writer?

If only it were that simple.

I’ve been in the technical writing space for over a decade and worked on dozens of software projects. Toolsets have come and gone, organisation changes have sometimes decimated our workforce, whole departments vanish in the time of a conference call, but the tech authors remained. Our small team (always too small) endured, always floating just low enough under the radar to be left alone come reorganisation, but high enough that we had a certain mystique (ha, who am I kidding, outside R&D, people didn’t care).

At our most recent reorganisation, a new Experience Design department birthed itself with a pretty hefty thud. Rest assured, there was plenty of splashback and bodily fluids. An enigmatic leader proclaimed how we were to adapt to our new roles and put a focus on the customer (because we would never think to do that on our own), and many of us were faced with new titles.

The first Content Designers in our organisation came into being.

Six months later, someone smart thought to write a job description.

You still haven’t said what you do

Good point.

But the job description didn’t answer as many questions as we’d hoped.

“Content Designers provide locally-relevant micro-copy, learning content, and product self-help and documentation on a global scale. Content is right for the user and context, and right for the business.”

We already did all of this apart from writing micro-copy. What even was micro-copy? Was that another word for UX copy? Wasn’t that something the Business Analysts did?

Hmm. I didn’t feel like we’d made much progress but at least it was something to focus on.

We don’t work in isolation

Another change with the business reorganisation, was that we were part of an Experience Design team with other specialists including UX Designers, Researchers, and Solution Designers.

Our historical way of working was very much waterfall based. We were once assigned to individual project teams but as our team shrunk we ended up with multiple projects each. And we had no say in the design of anything. We might be invited to review meetings (equally, we might be forgotten) but our work wouldn’t kick in until the software was written and we had working code to play with. And then the focus was on writing help topics.

As content designers, that’s not what’s expected of us. We’re at the opposite end of the process, in the thick of it with the other designers. Did you hear me just say that? “With the other designers.”

How many content designers are there?

In our organisation of 15,000 people, anyone globally that worked within software development with a Technical Author title became a Content Designer. We do have some technical writers in isolated support teams that avoided the transition but their remit hasn’t expanded to include micro-copy.

We’re close to 30 content designers.

Not that many.

In a recent ISTC survey, with 154 respondents, 110 said they still had the job title of Technical Writer or similar. Content Designer wasn’t listed as an option, the closest being Content Strategist (4 people), and Other (45). The ISTC is perhaps rather self-selecting with many established professionals as members. What it does indicate is that there hasn’t been a mass rebranding of job titles across the industry.

Are we any better for having more content designers?

That’s too big a question to answer in one blog post.

What I can say is that from my experience, it’s a positive rejuvenation of my career. I’m still doing what I love, playing with words, but there is a much greater emphasis in our team on the words we’re putting in front of customers.

Collaboration with our UX designers is also becoming the norm (also a post for another day), and that has helped us get a better understanding of the customer journey far earlier in the process.

Time will tell whether this niche is here to stay, and as I feel like some kind of pioneer, there’s a certain responsibility to prove our worth to the organisation.

It’s going to take a lot of work for those transitioning into these roles to make a difference. There’s a mindset shift as well as some new skills to learn, change is uncomfortable for many, and this is the biggest change I’ve seen in my technical writing career.