Brief Synopsis:
A need to increase quality, efficiency, and consistency across a suite of 40-products enterprise products was made clear. Atlas being implemented and leveraged by all kinds of associates and engaged with/adopted significantly contributes to NielsenIQ's ongoing mission of reaching a higher-tech maturity level amongst design, development, and product teams.
Before proposing any new solutions, it was necessary to understand how Nielsen was producing, and communicating work from both a design and development perspective. Through this process, and onboarding to it myself, key areas were identified that could be enhanced to improve efficiency amongst technology teams.
The design production process was not standardized.
Axure is robust, and for high-fi prototyping, it's excellent, but not necessarily friendly or consumable to the average designer starting or working within Nielsen. While there was a previous design system, it was not maintained, and the integrations into other enterprise tools were slim to none.
Conducting an audit into the repository (CUIC), the former documentation site (Axure share file), and the Axure Library itself, it became clear that there was little congruency between the different informing sources on an organizational level. This was a huge light-bulb moment.
Taxonomy and terminology differing from sources of truth.
Upkeep and connection of these sources was a retroactive and painstaking process.
Hard asset uploads (manual .jpg) and documentation authorship difficult created.
It became clear; there was a need to increase quality, efficiency, and scale. Having an improved design system, leveraged by designers and developers, would transform Nielsen.
Miro as workshopping and iteration tool
Sketch as a primary design tool
Invision for publishing designs, along with DSM for housing the components and documentation
Storybook being configured to our DSM environment to marry CUIC to Atlas
Axure as interactive hi-fi prototyping tool (if required)
Unity: The production process will be consistent across the organization. Centralized libraries ensure consistency.
Speed: Pre-built components for design and development, living in harmony. Updates to existing resources are made dynamically.
Fewer fixes = More time: Instead of time being used to ensure something is on-brand, on-spec, etc...Time can be used for improvements, testing, and enhancements, for the best experiences holistically. Taxonomy and terminology differing from sources of truth.
For Atlas to be socialized and adopted meaningfully, associates needed to consume the system from a place of want, not need.
To do this, we made it clear through workshops, demos, and consistent communications, the amount of time and effort/oversight could be saved by using the Atlas ecosystem.
Designers can learn, interact, and publish with ease, not having unique workflows (where possible). It also allows for as much creative freedom as possible, with as little opportunity to make something off-spec (overrides control from a central library in Sketch)
Developers recognizing the merit in being able to have inspectable specifications, exportable assets, and front end documentation, all in one place.
Project owners can provide feedback, learn proper usage guidelines, and feel ownership of the work being done, unifying the initiative across business units.
It was known Nielsen media and Nielsen Data would split into two entirely different entities. Nielsen Data became NielsenIQ, and with this change came an opportunity (and requirement) for all associated products to update to new standards.
Flexibility was needed as Marketing was finalizing what the new brand would be called and look like.
Empathy to varying levels of maturity amongst Tech Teams was (is) imperative.
Different technologies were maintained over years, with varying levels of proficiency existing across thousands of developers.
Establishing an MVP standard to get teams in congruency aesthetically... what's the easiest way to do this? By leveraging the CUIC repo (tied directly to Atlas)
In the case of teams not having the capacity or ability to leverage the most up-to-date standard of the CUIC, there are tools and methods (Live components, Spec Sheets, etc...) that enable them to glean more information than was ever available before.
