I became involved with style guidelines, UX, and content management discussions at Optum in 2012 through my role as director of a training and communications team, and through my team’s increased involvement with other groups who had their own rules for style. My team of 15 included people who supported legacy applications and others who were publishing content entirely online, and I worked with training teams who were in similar situation. My role was to manage this group while my task regarding UX was to develop a style and design guide that implemented the pattern libraries and stylesheets provided by the newly formed UX Design team, then design a content management solution that would work for all of the content teams.
It was not typical for documentation and training teams to be involved until development was nearly done, and discussions of user experience or stylesheets weren’t a required part of the documentation or training design process. Rather than working together, UX designers posted stylesheets and design patterns to the Cloud to define the style of Cloud applications, while writers and trainers were without a consistent method to publish and manage content.
This was acceptable for legacy days of user manuals and classroom training, but it was not going to work going forward with users expecting fully functional help and training to be available within an online application.
The biggest challenge was to get all of the groups to see the benefit of change their own habits. Rather than being involved with application development, online help authors were producing, posting, and managing content outside of the applications, then tying their content in to the applications after release through tools like RoboHelp. Trainers were working similarly. Development and UX teams were working from the same stylesheets and visual guidelines, but documentation and training teams were on their own to come up with standards.
One of my first deliverables was the Optum Brand, Design, and Style Guidelines for Documentation, Design, and HTML Publishing. This document was intended to provide internal users with a definitive place to start when developing user documentation in Microsoft Word, HTML content, and online training.
Along with the Style Guidelines, I also put together some examples of pattern libraries and recommendations for how to style elements within Word documents, PowerPoint presentations, and online content so that the work occurring independent of the UX team would be styled similarly to the pattern libraries and CSS that they would be distributing and using with web-based applications.
With the design and style guidelines complete and in use across the organization, the final task was to provide a content management recommendation. Scope and requirements became more and more complex with so many channels and audiences involved. It sounds strange saying this in 2022 when online/Cloud content is the norm and working on mobile devices is common, but this was not typical in 2012-2013, and it was difficult to explain the concept of managed content, different UX, defined by user ID, and responsive layouts.
I presented multiple times to senior leadership before handing off the concept and proposed architecture. We concluded discussions with the following list of requirements:
Writers, trainers, instructional designers, and content partners post assets including CSS to a content management system such as Adobe CQ5/Adobe Experience Manager (AEM)
Content and assets are managed within/by this CMS to be published and updated at Cloud-based destinations and apps
Content and asset development is tool-agnostic, but posting the content follows specific processes defined by Cloud architecture team within the service management framework
Application development occurs between content management service and client layers; online help and other content or assets integrated within application are posted directly from the CMS to Cloud/online application online help through source code management tool such as TortoiseSVN
Users access all content at Cloud client layer; SSO provides access to assets and content that is tied to the user ID; content and applications are available on dashboard UI; writers, trainers, and other content partners work with Cloud team to manage roles and dashboard content
My recommendation was to begin efforts to implement Adobe Experience Manager. Knowing that there were very few Cloud-based applications in development at this time, I recommended that my leaders begin discussions and socialize the concept with other leaders and other development managers across the organization in order to gain momentum for a CMS and for Experience Manager.
I left Optum in the summer of 2014 to take on another project, but from what I understand they moved forward to implement something very similar to my recommendations and are now using Adobe Experience Manager at the enterprise level.