What’s your content design process?

Process matters — even when it‘s not perfect

When I first started working in the UX and content design field, I had no idea how often I’d be defining my own role within companies. It’s true that organizations are looking at content designers as a necessity, but they often have no idea what to do with us. They don’t know when in the design process to involve us and what the best methods are for engagement in an increasingly remote work environment. After talking to in-product writers at content conferences, UX user groups, and through social media, I’m learning that many of us also have no idea what our process should be, either. For that matter, the design process itself is often neglected.

If you know me professionally, you’d know that I hold strong opinions on how and when to engage a content designer in the design process and I’m here, not to tell you what to do, but tell you what I do and why I do it that way.

Line drawn image of graphs, images, music, and documentation in a tablet type device.

Chaos reigns when you don’t have a content design process

The complaint I hear most from other content designers is that there are no systems in place to efficiently do their job. Well, to be honest, that’s not true. I hear:

“I don’t have enough time to process all the writing requests that come in.”

“I’m always chasing down the context behind the content requests.”

“I get all these copy requests at the end of a sprint but nothing beforehand.”

It amounts to the same thing. Without a content design process in place, a in-product writer is either overwhelmed, or out of the loop. Fortunately, we have a process that should already be in motion as we establish our in-product writing culture within the organizations we join.

Without a content design process in place, a in-product writer is either overwhelmed, or out of the loop.

Icon with two cogs and arrows showing a cyclical clockwise direction.

The design process is the content design process

Imagine this:

The content writer is assigned to a design team or 3 (for the love of God, no more than 3 teams, keep your writer to designer ratio low) and they start discussing the future of the product in design jam sessions or ideation sessions. Where are the points of friction? What needs to be worked on next? What new features are up for development. As the writer (who is also a UX expert) interacts with the designers — ideas are passed around, concepts start to solidify, and the words behind the project start to form.

THIS is the starting point in a project for any in-product writer when they are properly embedded into a product design team. This pre-kickoff point is when the germination of names begins to form. It’s when initial user flows are sketched out on napkins. It’s when the magical “what if” takes hold and we can stew in our creative juices while visions of a better future dance around us. The writer should be involved from the beginning, but also in the middle, and the end of the process. The design process is the content design process.

These are times in a design history that I’ve identified as specifically valuable for writer participation and what writing tasks surface during these points in the process:

1. Ideation or envisioning: The writer begins naming, plotting work load, imagining scope as well as participating in envisioning the future of the product. This is my favorite point in the design process and wouldn’t miss this for the world.
2. Proposal: The writer should have access to the proposal to add any information about the writing spaces that adds to the big picture. I often offer to help edit or write part of the proposal. This gives me a chance to ask the designer questions and to make the document as clear as possible. I am not a secretary, though. This is a collaborative document that is passed back and forth between myself and the designers I work with. The PM signs off on it.
3. Kickoff: The writer can attend the kickoff and contribute any information about tone, voice, opportunity for accessibility functions, or to ask questions.
4. Wire-framing: Start filling in the first draft of words. Don’t allow the loren ipsum to sit there for long unless it’s a placeholder for large amounts of user content.
5. Review and decision cycles: This is a great time to iron out points of friction as the copy becomes more permanent. I prefer a casual review cycle where work is looked over on a weekly basis with one or two formal reviews. Points where testing is needed is easier to identify while everyone is looking over the copy and different interpretations occur. As the writer, I make sure I document every decision that effects the content and make the documentation accessible to the designers and product managers.
6. Iteration: As the design changes, the words must change as well. I make sure that any time words are touched I’m tagged to review the changes. I don’t write every word. I’m usually stretched too thin to do this. I review every word and suggest changes as needed. Remember that editing takes less time than writing from scratch. Mark any points of friction in the copy for user testing during this time. This is also a good time to pitch multiple solutions for interesting word spaces and to check that your terminology and formatting is consistent with the rest of the product.
7. Testing: I sit in on two or more user tests as an observer when the source of the test is a project that I’m working on. If possible, I collaborate beforehand with the researcher to ensure that any outstanding questions about the copy are tested as well as the functionality of the product.
8. Final review for approval and development: I make sure I’m there to answer any questions about the content during the final review and I make sure the development team understand when and how to reach me for questions. When ever post-approval content work is done, I document it and cc a project manager.

I find the people who push back against this plan are often writers, not designers or product managers. This is when I hear that this process takes too much time, isn’t practical, or that the designer doesn’t share information enough for the writer to have this level of engagement.

There’s a reason for this. When you are overworked and you find yourself separated from the designers you’re supposed to work with, this process can seem inconceivable. Communication suffers even more in a remote environment. If the writer isn’t part of the activities surrounding the design team, they struggle to open up those paths of conversation surrounding designs. This cannot be the norm and have a successful content design process.

The first two issues take care of themselves. This process of embedding the writer in the design space actually saves time because the reconnaissance needed for each point of copy is removed from the equation. It becomes a practical process if it’s followed. If you’re following the design process, you should have access to all the information the designer has including all the frames and research. This foster’s collaboration. Collaboration starts with expressing your needs to the team and listening to their needs. Work with the team as a whole to find the best way to collaborate and share documentation. Creating a transparent process and documenting it will benefit everyone.

It serves writers well to posit themselves as communication experts. You have a wider view of the product because you support more than one design team or you interact with marketing or user education. Keep this information flowing through your design team. It saves you all time in the end.

Icon of a folder with images and documents to store in it.

Where do you keep track of all this information?

Not Slack. Please don’t say Slack…

After speaking with dozens of design teams about their documentation process, “We don’t have one” is the most common answer. The second most common answer is Slack or Confluence.

Confluence, at least, has a table of contents and is designed for the storage of documents. Slack is a wonderful communication tool but is not designed for documentation. Jira is another frequent answer but most people are not enthused about Jira and don’t want to access it more than absolutely necessary.

After speaking with dozens of design teams about their documentation process, “We don’t have one” is the most common answer.

I’m biased. I’ve helped develop Abstract’s Notebooks for the past year and love the way the program lends itself to the design process. In fact, it’s designed for the design process. It has the ability to track design history, record decisions, and create asynchronous design reviews, and so much more. This would be my first choice for documentation, but if you can’t convince your team to adopt another tool, set up templates to use in whatever word processing program that you have available to your team.

Create a template that serves as a manifest for the project. It should be a central meeting place to access everything anyone on the design team needs. Be sure to include:

• A link to the proposal
• Any Jira tickets associated with the project
• A contact list for all team members
• A link to all design files
• Space for design review Q&A
• A place to record decisions from every review
• Links to supporting documentation like component libraries or voice and tone documents
• Links to any microcopy crafting conversations or documents
• Links to user maps
• Links to research recordings and results
• Links to any recorded meetings or relevant Slack discussions
• An index to capture anything that doesn’t fit in the categories above. This can include links to old designs or old voice and tone guides — especially important if updating old parts of the UI. It can include recordings of the jam sessions, any initial card sorts…you name it.

Essentially, bring anything into the manifest that may need to be accessed by the designer, researcher, stakeholder, or yourself.

Room for error

It’s important to remember that a process or documentation system is not a perfect catch all for every situation but rather a guideline to navigate a flood of complicated information. Build room for error.

This means that you should make sure that you break occasionally from working in your design process to pick up issues that aren’t captured within in it. You can do this by:

• Hosting content office hours open to anyone needing to troubleshoot a content spot.
• You can encourage people to ping you in a special Slack channel when they need help that doesn’t warrant the use of a designer.
• Open up communication between departments — especially marketing and user education, to ensure that the writing is consistent as users navigate the entire brand.
• Host “Word People” bimonthly meetings to review shared content documentation and troubleshoot any shared writing issues for any department— even internal departments should be consistent.

Transparency, collaboration, and organization are the results of a well documented process.

Consider adopting the design process as your own and if your company doesn’t have a solid design process, get a group together to establish one. It will tame the chaos in your work life and, ultimately, create a content process that’s scaleable as your team grows.

One final note: don’t be critical of the processes that currently exist. Meghan Casey, author of The Content Strategy Toolkit, reminded me of this point when she wrote, “Even the most pointless and cumbersome processes and tools were created to solve the problem at hand. The problem was that they never evolved or they were never re-examined.” When making global changes to process, it serves everyone better by re-examining rather than condemning old processes and systems.

So — go forth and establish process and document it! Reinforce the link between content and design along the way.

Feel free to reach out and tell me about the successes and failures you encounter as you establish your content design process. I also welcome feedback on your best practices or processes. @mcbrideswords can be found on Instagram, LinkedIn or Twitter.