Nobody wants to talk about copy decks.
I spend a lot of time thinking about content strategy, storytelling, content design - I read all the articles and follow the podcasts and do the things that professionals engaged in this craft do, and I've learned a lot through the years about how to think strategically, how to evangelize the importance of the story to our experiences, and more.
One thing I've never heard one word on, though, is how to capture all that good storytelling, intelligently structured content, and content-first design in a document. Most content strategists spend their days making decks, but none of the leaders in our industry are talking about what the things we make look like - what they should look like - or how to make them better.
I'd love never, ever to have to make another copy deck - but working in the financial sector, with all its heavy regulation, I'm not sure it's possible. I have learned through the years that I've been in banking, though, that there are ways to capture our content that are smarter than how I worked when I was new to the field.
These documents aren't sexy. They're clunky. They're a little archaic and schoolmarmy. But I haven't figured out how to stop making them.
My team has tried a few things through the years, like writing in HTML (time-consuming...we aren't super good at it...we still end up creating wasted code that developers don't use, so why not work in the systems that are familiar to us? etc) creating content in comps or prototypes directly (which makes it difficult to capture global changes, are tedious for design and IA partners, and requires dev partners to re-type copy - introducing an opportunity for inadvertent errors, dropped punctuation, etc. There's no reason to make folks who aren't on the hook for quality control on content be responsible for it).
I'll begin at the beginning. When I started my own career as a professional writer, I wasn't familiar with the term "copy deck." It's a phrase we've borrowed from our roots in advertising agencies, and it might not be as familiar to people starting careers in content from different backgrounds.
What's a copy deck?
Standardization and Componentization
One thing that's helpful when you're creating content for an enterprise is to standardize and componentize as much as possible - and teach everyone to rely on those global patterns to save all of us time. I mean more than having standards like your organization's official policy on the Oxford comma. I mean creating a batch of content that will allow no one on your team ever to have to type up the address fields for a form ever again. They're the same every time (unless you don't make a standard - then watch each line of business within your organization create new ways to write ZIP code / zip code / Zip Code / Zipcode / ZIP / Zip. These things multiply like STDs.)
Free yourself and your team from having to think about error messages by capturing the most common error scenarios in a batch - potentially a flexible batch that your development parters can cleverly customize with the field labels that coordinate with your errors.These standards are the rules we create so that we don’t have to make decisions. It’s like Barack Obama’s famously generic wardrobe...his collection of sensible grey suits that looked great on him, that he wore all the time to conserve energy he might expend on deciding what to wear for the more important decisions.
There will still be content to write - so much content - but you can focus your team's efforts on the good stuff, and never have to discuss with your stakeholders if the confirmation message should say "We received your request" or "You submitted a request" or "Your request is being processed by our system boop boop beep." The standard is the standard, and once it's approved one time, you don't have to talk about it anymore.
Reuse
It's not lazy to reuse material that's working. If you have pre-approved content that's working in its context, don't recreate it in your copy deck. There's no need to re-present it to your stakeholders for review, opening the wormy can of feedback for no good reason, and there's no need to introduce the potential for error and confusion in the asset that you share with stakeholders or developers. If it's fine - it's fine. Indicate that there's a block of text you're leaving alone, and move on.
Capture global elements once per deck.
If you're documenting the copy that's present in a series of complex flows, get the elements that will appear over and over again in the flows one time. Otherwise, you run the risk of having button copy for one flow read "Submit" while the next say "Make This Payment." Decide on a CTA strategy, and document it one time to keep yourself from creating inconsistencies.
Use the table of contents.
Creating as much structure for yourself early on will help you as your decks get bigger, later. I'm a big fan of the tables of contents that Word will generate for you. Some of the decks I've created have been upwards of 100 pages long, and it's easy to get lost in those novels. Being able to look at a table of contents and jump to the relevant section saves me a lot of heartache - especially at that point in the project when I've kind of dumped all the information from my brain and moved on to the next thing - which is usually when folks further down the project pipeline have questions for me.
Create templates.
I use the same cover sheet every time to present a brief strategy summary, provide the context the user is in when they encounter the experience, and generalize any decisions I've made at a high level. I also use the cover sheet to track my changes throughout the project lifecycle. I make note of any accessibility content that my development partners should look for, since the won't see a lot of it in the visual design comps or prototypes.
I also have a template I use for every email I write to help me remember to capture certain pieces - such as the pre-header text or to indicate which footer our development team should attach.
Save everything, and annotate why you made changes.
I meticulously document the date and rationale for a change - whether it was my change or something that was a requirement from a stakeholder. I also save every version of the document I create. I usually begin this process after my work has been blessed by the relevant stakeholders, and then begin carefully tracking my changes.
I also like to have every version I've worked on that's meaningfully different from the last. I find that the magic version is usually 2 or 3 - you've done your thing, a few stakeholders have weighed in, but you haven't thoroughly wrung the thing out through feedback loops. When you get to version 756 and realize that it isn't really written in intelligible language anymore - go back and see what you did in version 3.
What am I missing?
I'd love to have a conversation with other people doing this work on what makes sense for their teams, and I'd love even more to find new ways to capture content that make sense.
One thing I've never heard one word on, though, is how to capture all that good storytelling, intelligently structured content, and content-first design in a document. Most content strategists spend their days making decks, but none of the leaders in our industry are talking about what the things we make look like - what they should look like - or how to make them better.
I'd love never, ever to have to make another copy deck - but working in the financial sector, with all its heavy regulation, I'm not sure it's possible. I have learned through the years that I've been in banking, though, that there are ways to capture our content that are smarter than how I worked when I was new to the field.
These documents aren't sexy. They're clunky. They're a little archaic and schoolmarmy. But I haven't figured out how to stop making them.
My team has tried a few things through the years, like writing in HTML (time-consuming...we aren't super good at it...we still end up creating wasted code that developers don't use, so why not work in the systems that are familiar to us? etc) creating content in comps or prototypes directly (which makes it difficult to capture global changes, are tedious for design and IA partners, and requires dev partners to re-type copy - introducing an opportunity for inadvertent errors, dropped punctuation, etc. There's no reason to make folks who aren't on the hook for quality control on content be responsible for it).
I'll begin at the beginning. When I started my own career as a professional writer, I wasn't familiar with the term "copy deck." It's a phrase we've borrowed from our roots in advertising agencies, and it might not be as familiar to people starting careers in content from different backgrounds.
What's a copy deck?
A copy deck is a single
document that contains all the language that
will appear in a particular user experience. A good copy deck will:
- Convey the semantic, hierarchical structure of the content
- Make it easy for stakeholders to read and give feedback
- Make it easy for developers to implement the copy
- Provide whatever the consumers of your copy deck need to make their jobs easier
I like to put a cover sheet on my copy decks that gives me a little room to explain the context, describe what will be covered, and outline any strategic decisions I've made along the way. I also use the cover sheet to document changes after I've delivered the initial deck. I'll indicate any systems I'm using in the copy deck to call out special types of language or non-interface language, like, "Italicized purple text is informational only, and it shouldn't appear in the interface. I also use this style to call out accessibility content that's for screenreaders only." For projects that require more than 10ish pages to capture, I'll include a table of contents to make it easy to find exactly what you want.
Next, I'll cover things I've learned along the way to make copy decks more useful.
Standardization and Componentization
One thing that's helpful when you're creating content for an enterprise is to standardize and componentize as much as possible - and teach everyone to rely on those global patterns to save all of us time. I mean more than having standards like your organization's official policy on the Oxford comma. I mean creating a batch of content that will allow no one on your team ever to have to type up the address fields for a form ever again. They're the same every time (unless you don't make a standard - then watch each line of business within your organization create new ways to write ZIP code / zip code / Zip Code / Zipcode / ZIP / Zip. These things multiply like STDs.)
Free yourself and your team from having to think about error messages by capturing the most common error scenarios in a batch - potentially a flexible batch that your development parters can cleverly customize with the field labels that coordinate with your errors.These standards are the rules we create so that we don’t have to make decisions. It’s like Barack Obama’s famously generic wardrobe...his collection of sensible grey suits that looked great on him, that he wore all the time to conserve energy he might expend on deciding what to wear for the more important decisions.
There will still be content to write - so much content - but you can focus your team's efforts on the good stuff, and never have to discuss with your stakeholders if the confirmation message should say "We received your request" or "You submitted a request" or "Your request is being processed by our system boop boop beep." The standard is the standard, and once it's approved one time, you don't have to talk about it anymore.
Reuse
It's not lazy to reuse material that's working. If you have pre-approved content that's working in its context, don't recreate it in your copy deck. There's no need to re-present it to your stakeholders for review, opening the wormy can of feedback for no good reason, and there's no need to introduce the potential for error and confusion in the asset that you share with stakeholders or developers. If it's fine - it's fine. Indicate that there's a block of text you're leaving alone, and move on.
Capture global elements once per deck.
If you're documenting the copy that's present in a series of complex flows, get the elements that will appear over and over again in the flows one time. Otherwise, you run the risk of having button copy for one flow read "Submit" while the next say "Make This Payment." Decide on a CTA strategy, and document it one time to keep yourself from creating inconsistencies.
Use the table of contents.
Creating as much structure for yourself early on will help you as your decks get bigger, later. I'm a big fan of the tables of contents that Word will generate for you. Some of the decks I've created have been upwards of 100 pages long, and it's easy to get lost in those novels. Being able to look at a table of contents and jump to the relevant section saves me a lot of heartache - especially at that point in the project when I've kind of dumped all the information from my brain and moved on to the next thing - which is usually when folks further down the project pipeline have questions for me.
Create templates.
I use the same cover sheet every time to present a brief strategy summary, provide the context the user is in when they encounter the experience, and generalize any decisions I've made at a high level. I also use the cover sheet to track my changes throughout the project lifecycle. I make note of any accessibility content that my development partners should look for, since the won't see a lot of it in the visual design comps or prototypes.
I also have a template I use for every email I write to help me remember to capture certain pieces - such as the pre-header text or to indicate which footer our development team should attach.
Save everything, and annotate why you made changes.
I meticulously document the date and rationale for a change - whether it was my change or something that was a requirement from a stakeholder. I also save every version of the document I create. I usually begin this process after my work has been blessed by the relevant stakeholders, and then begin carefully tracking my changes.
I also like to have every version I've worked on that's meaningfully different from the last. I find that the magic version is usually 2 or 3 - you've done your thing, a few stakeholders have weighed in, but you haven't thoroughly wrung the thing out through feedback loops. When you get to version 756 and realize that it isn't really written in intelligible language anymore - go back and see what you did in version 3.
What am I missing?
I'd love to have a conversation with other people doing this work on what makes sense for their teams, and I'd love even more to find new ways to capture content that make sense.
Comments
Post a Comment