Sector:
Healthcare, B2B, B2C
Challenge:
Bring the perspectives of real people (key actors & end users) into all stages of the program from design through implementation to change management and implementation.
My Role:
Product Owner, Lead UX
Engagement Time:
12 months (ongoing)
Overview
In this article, I’ll be sharing my understanding of design systems. The lessons I’ve learned through my past experiences tackling some of the common problems I faced within mid-size to enterprise organizations as a designer or product owner and ultimately how this has led me to evolve my perception of design systems and has helped me in “Reimagining an enterprise design system ” for my organization.
Methodology and Approach
#1 Going back in time
Here's a quick recap of my past experience with design systems.
It was in late 2009 when I first joined EF. EF is a global product helping students to travel abroad and learn a language. I was leading a design team that supported both the Internal applications including booking and operations and Customer facing post-booking experience which included web and mobile applications. Because we were a small team and had a good grasp on the product roadmaps we took the lead in building the company’s first unofficial cross-platform design system, cause we believed it and it would improve the quality of our digital experiences. We extracted the content from our brand book also known as GUD which was a PDF and Created our design kit documentation in the sketch. We spent weeks tweaking the color swatch to ensure the digital color met the WCAG color accessibility standards and we used Dropbox to publish the UI kit within our team and to maintain a single source of truth. These were the early days of design systems, they were not widely accepted in the organization and I found myself deep in the trenches getting buy-in from leadership and other product teams. Good old days... So With a small team, we were able to set up a Basic design system that would help our design and product development teams to produce quality outputs consistently. I loved being part of it.
It was in late 2009 when I first joined EF. EF is a global product helping students to travel abroad and learn a language. I was leading a design team that supported both the Internal applications including booking and operations and Customer facing post-booking experience which included web and mobile applications. Because we were a small team and had a good grasp on the product roadmaps we took the lead in building the company’s first unofficial cross-platform design system, cause we believed it and it would improve the quality of our digital experiences. We extracted the content from our brand book also known as GUD which was a PDF and Created our design kit documentation in the sketch. We spent weeks tweaking the color swatch to ensure the digital color met the WCAG color accessibility standards and we used Dropbox to publish the UI kit within our team and to maintain a single source of truth. These were the early days of design systems, they were not widely accepted in the organization and I found myself deep in the trenches getting buy-in from leadership and other product teams. Good old days... So With a small team, we were able to set up a Basic design system that would help our design and product development teams to produce quality outputs consistently. I loved being part of it.
#2 Coming back to present times
When I left to join Novartis, I found myself in a similar position as EF, but on a different scale. Soon, I realized how hard it was to create change in a larger organization. To give you perspective, within our Central UX practice team, we were about 20 designers internally + 40 external designers. We were supporting around 5 domains, and across the team, there were an average of 40-50 projects/demands in a calendar year.
Operating at this scale without a unified design system led to a lack of consistency in the end-user experience. In terms of methodologies and expertise, everybody was doing or redoing what pleased them, almost reinventing the wheel.
Operating at this scale without a unified design system led to a lack of consistency in the end-user experience. In terms of methodologies and expertise, everybody was doing or redoing what pleased them, almost reinventing the wheel.
#3 Creating change is hard
When we set out on this journey to build our design system, our ambition was to unify both the end-user experience and the way we build digital services. At first, we did not have a dedicated budget to build and scale our design system and another challenge was the amount of influence we had on the product development was limited.
I realized...the biggest challenge for our team was that - we could not invest our full time in building the design system.
I realized...the biggest challenge for our team was that - we could not invest our full time in building the design system.
Since we all had other priorities to tackle. It all seemed like a rapid path to burnout. But we were persuaded in building the design system. Slowly we started to see our effort pay off, Our design system started to become a basic necessity for any custom web implementation within the portfolio in which we operate. Our team's channels started to become more active and after 17 months in early 2022, leadership mentioned OneDS in one of our town halls and we were able to secure our own Budget to ramp up the team to build our comprehensive design system and our products started to look more consistent across our portfolio.
I realized... that Design systems are a culture change disguised as a UI kit or reusable code.
**A metaphoric example I often use to describe is how we- designers shifted from pixel-based to vector based on cloud designs and Figma... Nowadays it's a no-brainer for any design team to be on the vector-based cloud design tools. Similarly, we live in a world where technology change/evolves each day, and in my opinion design systems will be playing a crucial role this will become the new normal in the future of product design and development.
#4 Our first attempt
In 2020
Understanding our organization landscape We first started analyzing our team's structure, our diverse demand portfolio, and how much influence we had on the solution delivery. We also had design teams using more than one design tool and the dev teams using the framework of their choice (40% Angular, 20% React, 10% Vue, 30% others). Because of this, there was a disconnect between the design and development teams. Our goal was to break the silos, figure out a way to bring both these communities closer, and discretely influence the overall delivery of output digital solutions produced within our portfolio.
In 2021
We rolled out our first version of the design system called WADS (web app design system) on Sketch & distributed it through Abstract for the design user community. WADS library was designed around how you could construct furniture. You would use the material, and structure and then assemble the parts…. Web components built on Stencil.js (technology agnostic framework) for dev community distributed through private NPM repo. with code documentation on Storybook. WADS was built on a hybrid meaning centralized with the federated model. It kicked off really well, For the first time in our organization designers had detailed UI kit guidelines and a library that they were able to link to their projects (The sketch and Abstract combination and Invision DSM) and import the design assets directly into their projects. Development teams had a mirror version in the stencil.js framework with documentation that they could use and calibrate using storybook, teams could copy the code and build on top of their code base. Slide 14: It all seemed good on paper and going on track during our pilot. We had a problem... Although the system was received well within the design community we realized the system was a bit too rigid, our guidelines were almost like a mandate that was bestowed upon our designers and our designers felt imprisoned within the boundaries of the design system. From a development perspective, using WADS for a new project was fairly straightforward, however, to customize the component the team had to rely on our WADS developers, and migrating an existing custom web solution to WADS took much longer than expected.
In general, we realized... A rigid system, unfamiliar dev. framework = recipe for failure
In 2021
We rolled out our first version of the design system called WADS (web app design system) on Sketch & distributed it through Abstract for the design user community. WADS library was designed around how you could construct furniture. You would use the material, and structure and then assemble the parts…. Web components built on Stencil.js (technology agnostic framework) for dev community distributed through private NPM repo. with code documentation on Storybook. WADS was built on a hybrid meaning centralized with the federated model. It kicked off really well, For the first time in our organization designers had detailed UI kit guidelines and a library that they were able to link to their projects (The sketch and Abstract combination and Invision DSM) and import the design assets directly into their projects. Development teams had a mirror version in the stencil.js framework with documentation that they could use and calibrate using storybook, teams could copy the code and build on top of their code base. Slide 14: It all seemed good on paper and going on track during our pilot. We had a problem... Although the system was received well within the design community we realized the system was a bit too rigid, our guidelines were almost like a mandate that was bestowed upon our designers and our designers felt imprisoned within the boundaries of the design system. From a development perspective, using WADS for a new project was fairly straightforward, however, to customize the component the team had to rely on our WADS developers, and migrating an existing custom web solution to WADS took much longer than expected.
In general, we realized... A rigid system, unfamiliar dev. framework = recipe for failure
#5 A blessing in disguise
We went back to our drawing boards and as we were evaluating the pros and cons, we listened to the feedback from user communities one highlighting sentiment that came out of this exercise was the fact that we had to simplify. Slide 15: During the same time Within our team we were going through a design tool migration from sketch, Abstract, and invsion to Figma. It was a mammoth migration.. was also a blessing in disguise.
We use this opportunity to upgrade our design system and based on our learnings from our predecessor we decided to build our new design System. - We called it OneDS (one design system) built on the backbone of Google material and included the design process (principles & UI Kit), Development process (component library and Code documentation), and Governance and scaling rules.
Both from design and development, this new strategy had multiple advantages. From an architecture perspective, we were able to rebuild our system to scale to, multi-brand and multi-tech platforms. By breaking the system into separate interconnected files. Within the Core, we had themes ( color and type tokens and iconography) and then we have white label components (all atomic components with grid system). The foundation was based on Google material design, Change we made was to introduce our own 2 layer tokens system and separate the theme from the components. With this approach, designers could switch brand themes without disturbing the design file and from our development perspective migrate to. OneDS was like switching to a new theme within a framework. The only catch was them was they had to be using Google material and had to upgrade to the latest version of MUI. 5 This was also tested on large-scale products and we were finally able to get teams to switch to OneDS in a matter of weeks' time.
Both from design and development, this new strategy had multiple advantages. From an architecture perspective, we were able to rebuild our system to scale to, multi-brand and multi-tech platforms. By breaking the system into separate interconnected files. Within the Core, we had themes ( color and type tokens and iconography) and then we have white label components (all atomic components with grid system). The foundation was based on Google material design, Change we made was to introduce our own 2 layer tokens system and separate the theme from the components. With this approach, designers could switch brand themes without disturbing the design file and from our development perspective migrate to. OneDS was like switching to a new theme within a framework. The only catch was them was they had to be using Google material and had to upgrade to the latest version of MUI. 5 This was also tested on large-scale products and we were finally able to get teams to switch to OneDS in a matter of weeks' time.
#6 Lessons Learnt...
Build trust + open source mindset = Greater adoption.
Let's take a deep dive to see how we were able to expand our Influence.
Firstly, Designers:
Our first users, and we have the highest level of influence here. I would highly recommend that you focus your attention on empowering this team here.
Let's take a deep dive to see how we were able to expand our Influence.
Firstly, Designers:
Our first users, and we have the highest level of influence here. I would highly recommend that you focus your attention on empowering this team here.
We started by establishing trust.
The way we planned to do this effectively was during an employee's first week of work, and we called this team onboarding. We set up a checklist that introduced new designers to our ways of working and OneDS fundamentals, do's and don'ts, access to Figma, and orientation around the core design kit.
We started with a manual process, and now we are on the verge of making it self-serve. The important thing was that this practice of onboarding came with a perception shift from being one of many resources at Novartis to a trusted team of dedicated designers here to help you. It was important to build trust from day 1 and cultivate relationships with the designers we serve.
We also connected with people who use the system and asked them how we could better improve the system and how we could help them be better designers and improve their design craft.
Establishing trust by asking, "How can we help you be a better designer?"
Designers were our primary stakeholders, so feedback was critical for success. We created an easy channel on Teams for a feedback loop. This was helpful both ways - for designers to communicate with us and for us to communicate new releases and bug fixes.
I realized that the system is only successful if the designers want to use it.
Next, Product Teams and Development Community:
The goal of our design system was to reduce the effort during the digital product development lifecycle and allow teams to go from design to usable product interfaces in the most efficient way. So, the system would not be complete without a development framework that is widely accepted by the development community. This was a real must for us.
The goal of our design system was to reduce the effort during the digital product development lifecycle and allow teams to go from design to usable product interfaces in the most efficient way. So, the system would not be complete without a development framework that is widely accepted by the development community. This was a real must for us.
Leveraging a well-established open-source framework has a massive advantage, especially since we were a large enterprise organization working with a lot of external teams and agencies on a project-to-project basis, and we had very little influence on the choice of technology or framework for product development.
Our system needed to be easy to understand and built on a universal framework that most development teams are used to. From my experience, this was key for greater adoption and frictionless migration or use of our design system.
An icing on the cake would be good code documentation with automated scripts for package installation. We used private NPM package installers and CLI commands that the dev team could run to auto-install basic foundational packages and boilerplates, making it less hassle for dev teams to install necessary elements and start using our system.
Lastly, Business leaders:
We showed them the value of cost savings and consistent experience across the portfolio and standardization of tech. Also, what was helpful here were success stories and CX quality, consistency with the framework.
We showed them the value of cost savings and consistent experience across the portfolio and standardization of tech. Also, what was helpful here were success stories and CX quality, consistency with the framework.
Along with this, in order to scale, we set up a good governance and operating model. Some of the questions we asked ourselves while setting up the governance were:
#7 Scaling the design system
We set up a good governance and operating model. Some of the questions we asked ourselves while setting up the governance were:
How do we keep your library up to date?
How can others contribute?
How can others request support?
Another thing I learned is that making your system visible is key. We created and hosted our own custom web portal designed with the components from the design system, which also served as a demo site.
Key takeaways and conclusion
1. Simplification is the ultimate sophistication:
I realized that by keeping it simple and by shipping well-structured, well-documented foundational elements with robust guidelines and examples of how the system can be used, we were able to provide our product development teams with the right tools to empower them to elevate their craft and allow room for creative interpretation, striking the right balance between flexibility and rigorousness.
2. The power of teaching by sharing:
With an open-source mindset, allowing your design system users to use the system as a tool to start with a foundation and learn from your creative output and build on top of it to make it their own, helps you build trust, and with trust comes adoption.
With an open-source mindset, allowing your design system users to use the system as a tool to start with a foundation and learn from your creative output and build on top of it to make it their own, helps you build trust, and with trust comes adoption.