A new way to build Morningstar products

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.

Despite these successes, the approach we had taken—packaging HTML and CSS that product teams would paste into their application code—was proving costly to maintain. Upgrades were cumbersome, product teams struggled with the different JavaScript frameworks that were in use, and the challenges were only going to increase as the system grew.

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.

Early adoption of MDS

The Morningstar Design System was first released in June 2017. The first release only packaged HTML and CSS, which made it easy for teams to get started by copying and pasting MDS HTML markup into their application code. Since MDS did not include JavaScript–the third key pillar of Web application development along with HTML and CSS–developers had flexibility to choose whatever JavaScript frameworks and technologies they preferred.

This approach helped to accelerate adoption, but it also put the burden on product teams to keep their code up to date as MDS continued to evolve. And the omission of JavaScript left product teams responsible for scripting any behaviors and interactions, leading to duplicative and divergent experiences. The latter detail was key. While HTML and CSS define the look and feel of an application, it is JavaScript that brings web-based applications to life.

To address these challenges, product teams took matters into their own hands, wrapping MDS HTML components in their preferred JavaScript framework, building their own libraries and adding their own functionality.

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.

A new vision

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:

• It needed to be adaptable, allowing individual components to evolve without triggering breaking changes across the system.
• It needed to coexist with older versions of MDS, allowing teams to upgrade gradually, and on their own timeline.
• It needed to support continuous delivery, so that fixes and updates could immediately be made available to product teams.
• It needed to be accessible, including keyboard control, screen reader support, and proper use of ARIA tags. This was integral to our mission as a modern product organization.

What we needed was not just a shared look and feel for Morningstar products, but a shared approach to building them.

Most urgently, we needed a strategy to manage JavaScript framework support. Since Morningstar product teams had always had flexibility in their choice of framework, this was outside our team’s direct control.

Aligning on Vue

Morningstar product teams have long been aligned on the value of JavaScript, but until recently, there was no consensus on which framework to use. Angular, Vue, Ember, and React had all been used to varying degrees.

When MDS first added JavaScript, we chose an approach that would support all frameworks, and released pure JavaScript Web Components in May 2019. But practical and technical challenges slowed adoption of web components. While none of the issues were insurmountable, the result was that many teams continued to wrap MDS HTML components in their preferred JavaScript framework, which meant they were not benefitting from the added value that Web Components could provide.

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?

After long conversations with product teams and with leadership, we came to a decision to build our new system in Vue, which was also designated as the preferred framework for Morningstar. We will write more about our reasons for this decision in a future blog post, but the short explanation is that we needed our MDS JavaScript components to provide the simplest and best option for product teams, over the long term but also today.

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.

Built to evolve

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.

Beginning 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.

The need for speed

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, our new architecture allows MDS components to be updated and released immediately when changes are needed, so that 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 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.

A new way of building

Fulfilling all of the objectives we had set for the new system, MDS 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.