Categories
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.

Categories
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.