MDS V3 has been re-engineered from the ground up to support the way product teams work today
July 8, 2020—By the summer of 2019, the Morningstar Design System (MDS) team had reached an impasse. The design system we had launched more than two years earlier had become an established standard used by more than 30 product and capability teams. MDS made it easy to build products that looked and felt like Morningstar, and product teams had been quick to adopt the system. Guided by the mantra to “build what is shared, omit what is not,” MDS gained a reputation for quality, and provided a shared foundation for teams to build well-crafted user experiences.
While our core mission had not changed, we needed to rebuild, with a new architecture that would support the way that product teams work today.
While MDS provided a shared standard, each team maintained its own separate instance of that standard, translated for their product or framework. And the longer these instances were in use, the more they diverged.
What we needed was not just a shared look and feel for Morningstar products, but a shared approach to building them. But how could we achieve this while continuing to support products that were already in production with MDS?
It was a formidable challenge, but the team grew increasingly excited as our vision for a new system began to take shape.
We started the same way we had always done, by listening to our users. Through conversations with product teams, leaders, and stakeholders, we aligned on a set of objectives that would guide our design of the new system:
What we needed was not just a shared look and feel for Morningstar products, but a shared approach to building them.
Based on the questions we were hearing, the framework preferred by Morningstar product teams increasingly seemed to be Vue. Sensing a trend, we surveyed our users and confirmed that as of September 2019, a strong consensus for Vue had emerged. Yet at an organizational level, we were not reaping the benefits of this convergence since teams continued to maintain their own integrations.
If teams were building with Vue, why not meet them in the framework they were already using?
Aligning on Vue will allow teams to build more quickly, since they will no longer need to wrap our components. It will improve cohesion by reducing the risk of accidental deviations. And since we will all be using a shared framework, it will make it easier for designers, engineers, and product managers to collaborate and move between teams.
Aligning on Vue was a critical step, but we still needed to make sure the new system was adaptable enough to meet the needs of product teams.
Previous versions of MDS were released in a single library. This mandated an “all or nothing” approach to upgrading that was impractical for many teams. It also meant that a change to a single component could ripple across the entire library, often with unintended consequences.
With MDS V3, each component is released in a separate package, while still maintaining its connections to foundational visual language and related components. Product teams can integrate and upgrade only the components they need, one package at a time. When changes are needed, they can be limited to the specific components that are directly impacted.
Since each component has its own space, we have room to thoughtfully iterate on component improvements, push out updates, and allow teams to contribute and adopt changes to meet both their product team’s and the organization’s needs.
To eliminate the risk of style conflicts when multiple MDS versions are used, styles are encapsulated within each component using CSS Modules. This ensures that regardless of which version of MDS your product is using today — or even if you are not using MDS at all — you can gradually add V3 components to existing pages while continuing to use older versions of MDS.
While this modular architecture ensures the system will be flexible enough to evolve, we still needed to make sure that changes could be introduced at the speed that product teams require.
One crucial piece of feedback we heard from product teams was that with previous versions of MDS, it took too long to make changes to the system. Even a simple bug fix typically required 2–4 weeks until the next MDS release was available. For many product teams, that wasn’t fast enough, so they would make changes locally in their product instead.
To remedy this, MDS V3 components can be updated and released immediately when changes are needed, and updates are available to product teams within minutes. If your team needs a change, instead of making it locally in your product, consider contributing it back to the system so that all teams can benefit from work done across the organization.
This also applies to MDS V3 documentation, which is automatically updated each time a new component version is released. Comprehensive documentation is automatically generated for each new component version, and the complete history is preserved so that users can access documentation for older versions of any component.
Fulfilling all of the objectives we had set for the new system, MDS V3 has been re-engineered from the ground up to support the way product teams work today, increasing velocity, quality, and cohesion. But this is only the beginning.
As customers expand their use of Morningstar products, they expect unified experiences across the portfolio. This extends beyond simple components like buttons, to deliver unified capabilities to solve more complex problems, such as connecting to a new data service, or adding a new investment vehicle to your portfolio.
While the design system is often thought of as just a library of code, it is also a means to build community around more collaborative ways of working. By empowering teams to help expand and improve the system in tandem will the products it serves, MDS will expedite a new way of building products at Morningstar.