November 19, 2021

Engineering Principles of the GS Design System

Miriam Teitelbaum, Vice President, Developer Experience

Goldman Sachs launched the Goldman Sachs Design System in February 2020 as part of our OneGS initiative. The Design System defines the visual styles, interaction patterns, and user experience guidelines to build modern websites and products for desktop and mobile experiences that unify the client experience across Goldman Sachs.

These experiences are built using the firm's User Interface (UI) Toolkit component library, a collection of templates, patterns, and over 60 "plug and play" JavaScript components. The UI Toolkit offers built-in support for Cross-Browser / Mobile, CSS-in-JS styling, and Accessibility features to empower developers across the firm to rapidly build out web applications. The quality of the UI Toolkit is measured not just by the visual appearance and efficiency of our components, but also by the developer experience that we provide to the teams using our product.

As a small example of attention to detail, the first iteration aligning the UI Toolkit to the Design System ensured that we had a consistent visual "look and feel", but the two products were not yet using consistent principles or vocabulary. Component features in the Design System did not necessarily match the APIs and implementation in the UI Toolkit. These discrepancies were natural as the products had grown organically, but it was not the quality of experience that we wanted to deliver to our designers and developers.

Is Lack of Standards an Issue?

The UI Toolkit is an evolving product that leverages open source and custom-made components to solve the common use cases and patterns in financial web applications. Our early focus on delivery to establish the product and meet developer needs did not afford us the chance to take a holistic look across all of our components, so we exposed different styles of API patterns and conventions. As a result, developers using the early version of the UI Toolkit would need to continually check the documentation to look up which features and APIs were available on each component. This added overhead to the development process when using the UI Toolkit to build an app.

For instance, the color property from the old UI Toolkit APIs was a prime example of how lacking standardization can harm the developer experience. At that time we still leveraged Bootstrap under the hood, so values like primary and danger were acceptable as "colors" on many of our core components, such as Alert and Button. Other UI Toolkit components like Badge also had a color property, but here it accepted standard colors like purple or light-blue. Developers who had used the Badge color API were unpleasantly surprised to discover that passing purple to the Button color API (which only accepted 'primary' or 'secondary') failed silently and rendered a button without any background color.

<Badge color="purple" /> // This works since 'purple' is an acceptable parameter to Badge, as seen above.

<Button color="purple" /> // Fail, no background color was rendered, as seen above.

A Method to the Madness

We had many other examples of component features not quite lining up with each other. Aligning the UI Toolkit components to visually match the new GS Design System gave us an appreciation for the breadth of features that we support across the system. Having the full picture of what we were offering also gave us the perspective into why some components supported certain features, or even certain API values, that others did not.

For example, the color property used across the components was trying to do 3 things:

  1. Indicate a hierarchy of actions with values like primary and secondary
  2. Indicate a workflow status with values like infosuccesswarning, and danger
  3. Indicate a color from the color palette with values like purple or orange

This also explained why our components restricted certain values for the 'color' property:

  • Buttons indicate their action hierarchy so users understand their relative importance.
  • Alerts indicate the status of their message.
  • Badges can indicate status like an Alert, but also support standard colors when used for categorization.

Old APIs: Too many definitions of color.

Defining Intuitive APIs

APIs become intuitive when they do what you expect them to do, and they do it consistently.

The Little Manual of API Design is an excellent resource to get started building APIs with an awesome developer experience. The Manual outlines 5 characteristics to achieve when developing APIs:

  • Easy to learn and memorize
  • Leads to readable code
  • Hard to misuse
  • Easy to extend
  • Complete

In the months following the launch, the UI Toolkit underwent a major transformation where we applied these principles and other software best practices to offer a set of component APIs that were intuitive to both designers and developers.

Uniting Design and Development

Before we could begin thinking about the best way to redefine our technical APIs, our designers and developers collaborated on a standard set of feature terminology that would be easily understood across designers and developers. By performing these exercises together, we improved the quality of new designs and decreased our time to market.

The engineering principles of "easy to learn and memorize""hard to misuse", and "easy to extend" came in extremely handy here. We were able to break up features that were initially mutually exclusive in the GS Design System components by separating them out into individual properties. Breaking out features into shareable concepts also helped us find new opportunities to enhance existing components:

  • A generic "categorization" feature of the Badge was simplified to Color, since its purpose was just changing the color of the component.
  • A new Emphasis concept ('bold', 'subtle', or 'minimal') replaced the random "appearance" features to indicate the visual emphasis of the component on a web page.
  • Size was standardized to 'small', 'medium' and 'large', and implemented for all components to provide consistency.
  • New concepts like Shape ('circle' or 'square') and Placement ('top''bottom', etc.) emerged, with meaningful values that didn't require us to run back to our documentation notes to remember how they should be used.

The result of this collaboration led to the publication of our Design System Concepts. The concepts serve as a backbone for both the GS Design System and UI Toolkit to ensure component consistency across different systems. With this as a guide, refactoring the component APIs became a relatively straightforward exercise.

Evolving the GS UI Toolkit APIs

As a practical example, let's step through how we refactored the overloaded color property from the old APIs. As noted earlier, color was being used to represent 3 things: an action hierarchy, a status, and a standard color. This violates several of the characteristics of good APIs described in the Little Manual of API Design. APIs that are easy to learn and memorize "use the same name for the same concept, and different names for different concepts". Our color API was merging 3 concepts into one property, which made it confusing for developers to use properly. The color property also did not promote the hard to misuse characteristic, because developers would often try to provide standard colors as values and be forced to check the docs to learn that options like 'primary' or 'success' were the accepted values.

When redefining the APIs to solve this issue, we decided to refactor the old color API into three separate properties that can influence the final color of a component. The new APIs focus on the purpose of when each of these features would be needed on a component:

  • Action Type describes the type of action to be taken - 'primary', 'secondary', or 'destructive'.
  • Status provides visual context of the component state - 'information', 'success''warning', or 'error'.
  • Color is redefined to only represent that standard colors present in the GS Design System color ramps - 'red''orange''yellow', etc.

Applying these new APIs to our components helped tighten their feature set to better reflect each components purpose. Button accepts action type and an optional status, but not the generic color property. Alert only needed status, and Badge can accept either status or color depending on its context. The new APIs also makes it easier to talk about the components with our designers and users in a way that mirrors their technical implementation. We can have conversations about the 'error' status Alert, the 'primary' action Button on the page, and the notification on the screen tagged with a 'purple' colored Badge.

The code becomes simpler as well:

<Alert status="error" />
<Button actionType="primary" />
<Badge color="purple" />

Hey, this sounds like English! And I can actually remember these prop names without needing to look at the docs every time!

Even better, when developers using the UI Toolkit decide to add an Avatar component to their app and find that it supports the color property, they know this prop will accept 'pinkor 'purple' just like the Badge. They can also infer that the Input component will accept 'successand 'error' for its status prop, based on how status works in the Alert component. Adding consistency and predictability to the UI Toolkit APIs has enabled developers to infer their behavior with minimal reliance on the technical documentation.

Lessons Learned

Here are a few takeaways from our journey that you can apply to your own teams and products:

1. Understand your business and product

Knowing the market you operate in and the full set of features your product provides to users will enable you to make better technical decisions. Determining what your product does is the first step, but discovering why it does what it does will empower you to transform it.

2. Drive change together with your business

Change is scary. When software changes it often means more work for your users in the short-term, since people need to readjust their work habits and get used to new user interfaces. You may encounter a lot of user or business resistance when you start proposing software changes. Embrace their concerns and involve them in the discussions that will impact their workflows. You'll be surprised by the insights your users bring to the table when you collaborate.

3. Learn and apply software engineering best practices

Writing software that other people want to use takes practice. Leverage the wisdom of other engineers and consult early with peers to get feedback. References like the Little Manual of API Design, Clean Code, and Refactoring are great resources to explore.

Join Us!

We have Front End developer roles open across the globe, come build with us!

New York



See for important risk disclosures, conflicts of interest, and other terms and conditions relating to this blog and your reliance on information contained in it.

This site is for informational purposes only and does not constitute an offer to sell, or the solicitation of an offer to buy, any security. The Goldman Sachs Marquee® platform is for institutional and professional clients only. Some of the services and products described on this site may not be available in certain jurisdictions or to certain types of client. Please contact your Goldman Sachs sales representative with any questions. Nothing on this site constitutes an offer, or an invitation to make an offer from Goldman Sachs to purchase or sell a product. This site is given for purely indicative purposes and does not create any contractual relationship between you and Goldman Sachs. Any market information contained on the site (including but not limited to pricing levels) is based on data available to Goldman Sachs at a given moment and may change from time to time. There is no representation that any transaction can or could have been effected on such terms or at such prices. Please see for additional information. © 2023 Goldman Sachs. All rights reserved.
Transaction Banking services are offered by Goldman Sachs Bank USA (“GS Bank”). GS Bank is a New York State chartered bank, a member of the Federal Reserve System and a Member FDIC. © 2023 Goldman Sachs. All rights reserved.
Not all products and functionality mentioned on this website are currently available through our API platform.
All loans and deposit products are provided by Goldman Sachs Bank USA, Salt Lake City Branch. Member FDIC.
Brokerage and investment advisory services offered by our investment products are provided by Goldman Sachs & Co. LLC (`‘GS&CO.`’), which is an SEC registered broker-dealer and investment adviser, and member FINRA/SIPC. Research our firm at FINRA's BrokerCheck. Custody and clearing services are provided by Apex Clearing Corporation, a registered broker-dealer and member FINRA/SIPC. Please consider your objectives before investing. A diversified portfolio does not ensure a profit or protect against a loss. Past performance does not guarantee future results. Investment outcomes and projections are forward-looking statements and hypothetical in nature. Neither this website nor any of its contents shall constitute an offer, solicitation, or advice to buy or sell securities in any jurisdictions where GS&Co. is not registered. Any information provided prior to opening an investment account is on the basis that it will not constitute investment advice and that GS&Co. is not a fiduciary to any person by reason of providing such information. For more information about our investment offerings, visit our Full Disclosures.
GS DAP™ is owned and operated by Goldman Sachs. This site is for informational purposes only and does not constitute an offer to provide, or the solicitation of an offer to provide access to or use of GS DAP™. Any subsequent commitment by Goldman Sachs to provide access to and / or use of GS DAP™ would be subject to various conditions, including, amongst others, (i) satisfactory determination and legal review of the structure of any potential product or activity, (ii) receipt of all internal and external approvals (including potentially regulatory approvals); (iii) execution of any relevant documentation in a form satisfactory to Goldman Sachs; and (iv) completion of any relevant system / technology / platform build or adaptation required or desired to support the structure of any potential product or activity.
Mosaic is a service mark of Goldman Sachs & Co. LLC. This service is made available in the United States by Goldman Sachs & Co. LLC and outside of the United States by Goldman Sachs International, or its local affiliates in accordance with applicable law and regulations. Goldman Sachs International and Goldman Sachs & Co. LLC are the distributors of the Goldman Sachs Funds. Depending upon the jurisdiction in which you are located, transactions in non-Goldman Sachs money market funds are affected by either Goldman Sachs & Co. LLC, a member of FINRA, SIPC and NYSE, or Goldman Sachs International. For additional information contact your Goldman Sachs representative. Goldman Sachs & Co. LLC, Goldman Sachs International, Goldman Sachs Liquidity Solutions, Goldman Sachs Asset Management, L.P., and the Goldman Sachs funds available through Goldman Sachs Liquidity Solutions and other affiliated entities, are under the common control of the Goldman Sachs Group, Inc.