Month: June 2019

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.