Overview
This is a content workflow and communication process I created while I was the content designer working on the development of a clinical program for a major healthcare company. This process increased efficiency, saved time, and improved communication within the highly cross-functional product team.
Role: Content designer
This process helped improve communication and increase efficiency for: Product designers, product owners, developers, QA, CMS team, and the clinical product development team.
Time: It took around 1 month to create this process and get everyone’s approval to implement it.
Tools: InVision, Miro, Jira, Confluence, Microsoft Office, FigJam
Impact
- Saved 10-12+ hours a week for every team involved with content
- Reduced content oversight by and rework by almost 100%
- Reduced QA content defects by over 75%
- Improved communication
- Created a long-term safe and productive work environment
- This process is now being implemented as the program is scaled
I created a FigJam template of this content process that other teams can use. If you want to take a closer look, here's the link to the entire process on FigJam:
Approach
When I first rolled onto this project, the team was creating a pilot version of this clinical program. The content was all over the place and very disorganized. I was working between 2 different types of content - the product content and the content that the clinical team was curating for customers, which was the bulk of the clinical program.
We had 5 different sources of truth for the copy and everyone was confused about what the actual source of truth was, so I had to make sure the copy was correct on all of the platforms at all times. The program was very content-heavy, so there was a lot to keep track of as the program was developed.
The 5 different sources of truth were:
Invision: Designs and product copy
Confluence: Functional requirements, designs, and product copy
Miro: Designs, product copy, and copy for the clinical activities
Excel: Requirements, logic, and copy for the clinical activities
Jira: Functional requirements and copy
At the beginning, I wasn’t able to access Invision to update the mocks, which created a lot of extra work for the designers. Whenever there were any copy changes, I added sticky notes on the Miro board, updated Confluence and the spreadsheets with the copy changes, and I had to let the designer know to update the designs with the updated copy in both InVision and Miro.
I had to hope the right copy was being transferred over to Jira for the developers, which often didn't happen because we didn't have a clear line of communication set up at the time.
My biggest roadblocks were:
- Meetings, meetings, and more meetings.
- Unproductive meetings with the wrong people in the meetings.
- Unproductive follow-up meetings, still with the wrong people in the meetings.
- No system to track content additions or updates, which meant a lot of them were missed. This caused hours of rework and headaches for everyone.
- Oversight of new and updated content, which meant we had to schedule more meetings.
- No one took ownership of the work that needed to get done.
- Mass emails were sent out to groups of over 20 people and ended up getting ignored or buried most of the time.
- Toxic work environment. People were angry because there were so many issues. There was yelling on many of the calls and I did not feel comfortable raising issues or speaking up because I was afraid of getting yelled at.
As we were developing the content and making changes and updates based on user feedback and testing, there wasn't a defined process for tracking content. The CMS team, developers, and QA were not aware of the updates I was making to the content, which caused a ton of issues for QA.
At one point, there were so many issues coming in because of the oversight that I had to go back and spend at least 20 hours going through all of the content and start creating a content tracking system, marking what had been changed, when it had been changed, and why it had been changed.
It was really frustrating because I was under the impression that the changes had been communicated to the rest of the team, but clearly they had not been.
That's when I started developing and implementing this workflow process.
I started by thinking through the process and writing it out step by step, clearly defining roles and responsibilities. Here's the bulk of the process written out (All names except mine are blurred out):
Then, I mapped out the process in more detail and ran it by the rest of the team to get their approval.
Once I had everyone's approval to move forward, I immediately implemented the process.
How the Process Works
The first part of the process is basically a notification system, letting the rest of the product team know about any content additions or changes. I work with the designers and product owners to make sure all of the changes are captured and that the designs and all sources of truth are updated with the correct content.
Here are the pieces of information I list out in the notification:
- The title of the section the copy is located in
- Where the copy is located (this gives the CMS team and developers easy access to the content so they're not spending time digging through everything to find it)
- Production date (This helps the CMS team and developers plan and prioritize their workload in order to get the work done on time)
- Whether the designs/sources of truth are updated (This is important for QA. Since the source of truth for copy is not the designs themselves, it's helpful for QA to know whether they can trust the copy in the designs or not)
- Summary of what changed
- If there is new copy, I list out all of the new copy. If it is updated copy, I list out the previous copy and updated copy so there is a record of exactly what changed.
- Screenshot of the copy addition or change. This screenshot also has the tracking information such as date added/changed, what changed, and why it changed.
Here's an example of one notification I put together (names and other identifiers are blurred out):
Once the notification is sent out, the CMS team updates the content keys, the developers implement the changes, and then it goes through QA testing. If everything is okay with the content, the product owners and I are notified and we give business acceptance testing (BAT) approval and then it goes into production.
If anything is still not right with the content, QA reaches out to me. We work together to get to the root of the issue, figure out who to contact to resolve the issue, figure out a solution, and then implement it.
That is the basic process I go through every time there is a content change or addition. I made sure everyone involved in this process on the product team had input and gave approval before implementing it.
As we scale, I would like this process to be automated so I don't have to manually collect all of the information and send it out every time there's a content addition or change, but for now, it's working really well and things are running a lot more smoothly.
