Reworking A Workflow — A UX Case Study
The story of rebuilding a project tracking intranet-site to include and automate paper processes and cumbersome workflows.
The Global Marketing Communications department at a previous employer worked with a frankensteined project workflow that was time-consuming, introduced errors, and required departmental shutdowns to audit previously completed work.
The workflow was made up of:
The Action Tracker 1.0 — the old project tracking system
Document Control Review (DRC) — a process with a corresponding form
Print-on-Demand site — a site populated with approved marketing materials, a corresponding process with a paper form, and google docs as a content handoff.
Action Tracker 1.0 was built to produce project tracking numbers which was a necessity for FDA and trademark compliance. Additional key functions of Action Tracker included assigning team members to projects and tracking deadlines. Since Action Tracker was first put into place, two important process changes had been added to the workflow.
The first process change was the Document Review Control (DRC) process. The DRC process is a document review committee reviewing for trademarks, FDA compliances, and branding. After DRC approval, an appointed admin had to clear documents for public consumption which was done manually. A lawyer, regulatory member, content owner, designer, and the Marcom Manager all had to hand-sign the same approval documentation which was then reviewed by the DRC admin and approved for dissemination.
The second process change was the addition of our print-on-demand vendor. Printing-on-demand provided access to international affiliates to customize documents for their regions, change document languages, adhere to country trademark restrictions, obtain new DRC approval, and print their pieces locally.
Watching my department suffer was something I could not ignore. I decided to do some research to find out what possible fixes were available to us. Talking with the developers in IT I asked if there was a way to grant limited Action Tracker 1.0 access to our vendors within the company’s intranet and possibly rebuild it to include all of the information necessary to remove the extra step of google docs. Our IT contact said that it could be done but that the whole Action Tracker would need to be rebuilt. I took the information back to my manager, print-on-demand internal coordinator (Suzanne), and department head.
Our department head asked Suzanne and I to pursue the Action Tracker 2.0 solution. I was excited and nervous about the new project. The department’s digital lead provided invaluable advice, “lookup Information Architecture courses online.” I took classes, read articles, and found forums to learn as much as I could.
While I educated myself, the core project team (Suzanne, James our IT contact and myself) began the content migration from the old intranet site and platform to the new platform. This started with a content audit.
The finalized content audit was compared with the print-on-demand needs and our department process needs. The results revealed unnecessary content. A Review with the team gave Suzanne and I the go-ahead to archive this content from the new site.
Knowing the process from the designer viewpoint was helpful but I didn’t want to overlook the rest of our team’s experiences. I conducted user research by interviewing the managers, coordinators, other designers, and the admin to learn about their experiences with Action Tracker. Taking the data back to the core team, I asked if we could incorporate permissions-based approvals. These approvals would eliminate the carrying around of approved paper forms that triggered the DRC-approved content to be sent to the printers. James said it was not only possible but suggested adding a push-notification into the designer view of Action Tracker. This push-notification became the to-do area, which appeared in the main action tracker view for each team member, placing their to-dos above their team's projects. The to-do area was populated by a project’s status change. Previously in Action Tracker 1.0, changes within a project were often overlooked and a verbal “hey something changed in that project” had to be said among the team. The to-do area eliminated the walk-over notification within project teams, cutting down on distractions and removing extra work.
James opened up Action Tracker 2.0 possibilities by explaining capabilities of the new intranet site. His explanations provided the knowledge needed to inspire production based cascading dates, new project adpro number auto-population, parent-child adpro numbers (1234-A, 1234-B, ect.), and a populating print-on-demand information section with new content push notifications to the vendor’s email inbox.
“Action Tracker 2.0 improved the efficiency and effectiveness of the team.”
— Manager
The information needed for the print-on-demand site was provided by content owners outside of our department. When the print-on-demand site was first launched there was not a consistent approach to collecting keywords, navigation, and user groups. All of this information was hand-keyed from emails into google docs to handoff to the print-on-demand vendors. This process was inefficient. In an attempt for a consistent experience, I built a PDF form to ensure the same questions were being asked of the content owners. James made the PDF into a web form. The web forms were programmed through the individual action tracker projects to send an email to the project content owner with a standardized message. Once the form was filled out and saved by the content owner, the information was populated into the vendor area of the action tracker project. The filled out web form was tied to the project with the username of the content owner and time stamped for record keeping. This integration removed the duplicate work from the designers’ and managers’ process and eliminated hand-keyed errors from being introduced.
Navigation for the print-on-demand site had been communicated through google docs. The process introduced incorrect nomenclature, duplicated navigation due to misspellings and a once a month clean-up audit. Action Tracker 2.0 alleviated these issues with approved navigation built into responsive drop-downs. A new approval process to request navigation changes was introduced.
“Gianna displayed focus and passion, knowing that the value would be realized fully upon experiencing the solution. She saw the bigger picture and kept that in mind for everyone.”
–Manager
The Information Architecture was designed to follow standard project flows. Each tab was either a step in the process, a calendar overview or the information handoff to the vendor.
Once the working prototype was built I presented our progress and asked for testing volunteers. With the volunteers ready, I tested the project management system with a third of our team. Suzanne, the print-on-demand coordinator, brought up the issue of the missing vendor code (an adapted number built off of our adpro number, the DRC approved date, and the print pieces region). Taking the finding back to James, we asked for its incorporation. The vendor code was added to the action tracker as a self-building field, pulling from other information within the project. This was yet another example of how Action Tracker 2.0 was removing the cognitive load of time-consuming work from the designers and managers of the department. Following full buy-in, we implemented the content migration. During the IT migration, I designed and built the user interface design.
“Thank you Gianna! Excellent work in continuing to simplify and add accuracy through automation.”
– Department head
The general feedback on Action Tracker 2.0 was that it made the team’s workflow smoother, took up less time, and was easier to use.
