Digital First Editor
Project Overview
The Digital First Editor (DFE) is an ongoing project designed to streamline and standardize CDC's public health communication strategies.
The DFE is a web-based content management system that allows CDC health communicators to write, edit, review, and publish content for the CDC.gov website. The previous solution (referred internally as the WCMS) required dedicated web developers to manage all content, which caused inefficient processes and misallocation of resources.
The DFE is designed to remove silos and allow better collaboration across CDC programs, while enabling health communicators to be more self-sufficient in content management by reducing reliance on web developers. This means that the system needs to be understandable and intuitive to the average CDC employee, not just those familiar with web and digital concepts.
Primary Role: UI designer
-----
Contents:
1. First major enhancements
2. Collaborating with Devs and QA (samples of specsheets and mockups)
3. Understanding CDC workflow
4. Executive communication and presentation
2. Collaborating with Devs and QA (samples of specsheets and mockups)
3. Understanding CDC workflow
4. Executive communication and presentation
1. First major enhancements
When I first got assigned to the DFE project in 2022, the team had just released the MVP (minimum viable product) and was in the process of designing the first major iteration. Using my previous experience on a different project I was working on at the time, I suggested several enhancements including building out separate screens and introducing a left navigation bar to start shaping the DFE into a true workspace for content management.
We focused on 6 major screens that users would need to work with:
1. Page editing
2. File management
3. Publishing
4. Site mapping
5. Site management
6. User management
2. File management
3. Publishing
4. Site mapping
5. Site management
6. User management
What started off as a rudimentary content editing interface quickly turned into a full system with several tabs and complicated interwoven elements. The release schedule was ambitious and each sprint involved a lot of moving parts. Communication and documentation were paramount, as decisions and requirements continuously and quickly changed.
2. Collaborating with Devs and QA
Over the course of the project, I learned and adapted to our team's working style and expectations. I noticed that given the rush of each sprint and other limitations, mockups weren't being followed completely which confused QA when they needed to validate production with the stated requirements.
Given our use of Axure and the nature of our widespread team, clear documentation meant writing out detailed specs alongside UI mockups to ensure that all implementation would be done to spec. These writeups include expected behaviors for elements, css styling/spacing, data tables, flowcharts, etc.
By developing this method of documentation, I was able to reduce the amount of failed QA validations, allow transparent communication, and collaborate more closely with devs to learn about what's "under the hood," so that I could better understand how to adjust future designs to fit the current architecture.
3. Understanding CDC workflow
