Who/how/when is content handles in a (less than ideal) UX workflow?

Question

In the several corporate UX settings I've been a part of, once consistent pain-point is content. A bit reason for that is that rarely do I see dedicated technical and copy writers on staff who are subject matter experts in content writing.

So what usually happens is it falls into the hands of a mix of business stakeholders and UXers.

Let's assume that this isn't changing any time soon (ie, we're not going to hire a staff of copywriters, unfortunately)...what is your process in terms of handling content and maintenance.

Some specific challenges we've encountered:

• content is written into wireframes and/or prototype
• content is updated post-launch. when it comes time to update wireframes, prototypes, content is now out of sync.
• review/feedback happens in isolation of the broad big-picture. Example: one team changes a term on a microsite, doesn't inform the team handling a different microsite to be in parity.

The question: In lieu of having a proper, dedicated content writing team, what process have you found works for handling content within UX?

At the very least, I'm thinking a separate document should exist outside of the wireframes and prototypes for 'final' content review and authoring, but at the same time, I'm adverse to having yet-another-document floating around.

Answer 1

In an environment where you end up wearing many hats, someone has to buck up and tackle the work of copywriting. This sometimes falls into the realm of the UX designer (I've done this many times) when it comes to keeping language understandable for the target audience. If there are marketing people around who can write, that's good too.

I often try to include accurate copy within mockups, and have that reviewed by product owners or other stakeholders to make sure it's the message we want to be sending. I always operate with the understanding that the copy will likely change down the line, and that the mockups are there to serve as a guide for styling, layout and placement more than they are an exact representation of everything that is going into the final product.

Once a product is live, I consider copy changes and the like to be more of an iterative process. That mockup document that you made was an artifact of the initial design process, and I don't find much value in going back to try to make the mockups match what's in production. It's a game of catch-up, and mostly a waste of time that could be spent doing something more productive. If for some reason you NEED to keep things in sync, then screenshots of the product itself would serve this purpose since they reflect all the content in its present form.

To your last point, communication helps. There should be someone responsible for approving changes and keeping the microsites in your example in sync. If not a product manager, than someone who just volunteers to be a bridge between teams to let the right hand know what the left is doing.

Answer 2

Although I may not answer your question in full. I can give a few recommendations.

Central Content Repository

This is very much what your last paragraph mentions. I have seen two versions of this concept:

Content Matrix

I'm not sure when and how exactly you go about content requirements but in my case it will currently be introduced once template scopes are aligned within task models.

We then create a Google Docs spreadsheet, with each template being a sheet, and throw the content attributes there (id, type, status, scale, text). Depending on the number of elements and the scale of the content, we may use a Google document instead of a spreadsheet (typical few elements but long content).

This google doc is shared between various people who all may have some input.

You can set change notifications. And you can always trace all changes from a specific date by looking at the revision history.

Internalisation Files

Depending on the underlying technology, these may be XML files or simple text files used to support the translation of text in the system.

These are deployment files.

Version Control

I've been using Git for a few years now and the benefits that come with it are beyond description. While to properly understand it to an administrator level would take time, there are some simple workflows that can be explored.

The GitHub GUI client (Mac/PC) is a no brainer app to use (basically most of the time people will just have to commit and push). And although there are smarter ways of achieving sync between everyone, the most simple straightforward way is for everyone to fork a repository and then ask to owner for pull requests.

If you git your internalisation files, and only allow a particular team to deploy the system - you should have a far more solid control over changes.

To be perfectly honest, there's a lot more to be said with relation to the written above, but I'm not even sure whether I'm on track. I'll be happy to share more information if you find this answer useful.

Answer 3

There are three parts to the questions, so they can be answered separately.

1. Who - As you know, the bottleneck is getting the content created or approved, so either one or both of the people involved should take responsibility for this. Depending on the team structure and chain of command, it makes sense for the higher ranked person because they have the authority to get things done (as long as they are not tied down with too many other responsibilities).

2. How - You'll probably have more success managing the content as another asset in the project because like you said, there's not much point creating another document or standard for text. It is just another thing that people will have to manage and learn, so make it consistent to how everything else is managed, at least that way it will be easier to handover/transfer to another person.

3. When - This is based on the expectations of the people involved. If they expect the design and content to be up-to-date then you will cause problems if the expectation is not met, and time wasted discussing issues that are not relevant because it is not what they are expecting to see. The expectation should be set out as part of the design and development process (which can be changed as you go along if required - after all that's the point of being Agile).