Preface: The work I completed at Putnam is confidential and under an NDA. As a result, what I write here will mainly be about the process and high-level details about the system. I've obfuscated any confidential information or otherwise proprietary data to protect Putnam. If you want to learn about my involvement in this project or have any questions, please feel free to get in touch with me.
At Putnam Investments, I led the coordination of designers and developers to build Putnam's Atlas Design System. The name Atlas derives from the eponymous Greek Titan Atlas, who was responsible for holding up the sky and heavens after Zeus defeated the Titans. Our design system serves a similar purpose, responsible for laying the foundation and fundamentals that support Putnam's designers and developers when building digital products. In addition, the term Atlas also denotes a collection of maps or charts, an analogy for providing direction and guiding Putnam product teams forward.
At its core, Atlas is a set of shared processes and components that allow us to manage design and development at scale. In addition to making sure we have design consistency and cohesion across the board, Atlas eliminates knowledge gaps between the different product teams at Putnam.
I joined Putnam Investments at the end of 2017, fresh out of college. As a large organization, Putnam struggles with a lot of similar difficulties that other enterprise organizations face - scaling in size, maintaining consistency across developer-designer handoff, and sharing knowledge across different teams. I noticed this firsthand in my role as a UX engineer, facilitating and bridging the gap between developers and designers.
For the design team, designers were working on their own Sketch files in their own silos, using and creating their own symbols without sharing them with the rest of the team. When it came time to hand off their designs to developers, design spec documents were inconsistent; some designers exported their designs to Invision while other designers created detailed redline documents that were emailed to developers as PDFs.
On the development side, I realized that individual teams were creating their own components and using npm packages without consulting other teams about recommendations or best practices. Additionally, when presented with handoff documents from designers, the final product sometimes didn't match the specifications defined by the designers.
As all of this was happening, Putnam was migrating from an API-based architecture over to a microservices one. The decision to standardize the UI while allowing teams to write their separate services was a strategic decision that would allow teams to work independently while maintaining the ability to collaborate. Throughout this process, I took note of all of these pain points and started formulating ideas for how we could improve our current processes and cut down on any existing friction and inefficiency.
As a financial services company, Putnam's focus is on stability - the ability to keep systems running constantly with little to no interruption. As is the case with many other companies in the financial sector, every second of downtime can result in millions of dollars lost. For us, we were fortunate to be able to start over from scratch and redesign a completely new platform, while still providing support to our legacy applications. This allowed us to define the direction we want to go towards and learn from our previous mistakes to ensure the new platform was more robust and would not suffer from the same pitfalls from previous systems.
The first step in our process was to take an inventory of anything we were currently using from both a design and development standpoint. This ranged anywhere from Sketch symbols to npm packages to custom-created components.
Our goal was to identify any technical needs and constraints that were crucial to starting the process of creating a shared documentation hub. In addition, we wanted to see how much of these previous elements we could bring over to our new system. For some of these elements, such as the shared Sketch symbols and any style elements (color, typography, etc...), they were easily transferrable over to our new platform. However, other elements such as legacy packages that wouldn't be supported by the new codebase were noted but would not be pulled into the new system.
The second step of our process was to start researching core external packages we could leverage so we wouldn't have to completely reinvent the wheel when first starting out. For teams that wanted to build quickly, this would allow developers to bootstrap and not have to rely on other teams to provide custom-developed components. Not only would this eliminate the bottleneck in the process, but it would help us ensure that whatever packages we would pull in were well-maintained and robust enough to share with other development teams.
For example, from a UI standpoint, we decided to go with a popular front-end framework used by many large corporations. We initially chose this front-end framework because it was created and managed by a large powerhouse in the technology industry. This gave us solace because we knew it would be well-maintained and would not easily be deprecated or become abandoned. To make it more reusable and custom to Putnam, we developed a custom theme based off of our branding and also extended the functionality of several of its components.
Once steps one and two were completed, we had to start thinking about what we wanted to include in the design system from a functional and concrete standpoint. We knew at the very beginning that this would not just be a place for documentation, but also a place for centralizing how designers and developers interact with one another. We have to ensure that all existing and any new developers would be on the same page when it came to the technologies, best practices, and shared toolset we were going to use.
In addition to defining the sidebar menu structure, we also had to determine the workflow for designers. We ended up deciding to use our online shared storage system for version control and file storage. This would allow us to access previous versions of our library if we ever wanted to revert a change to a specific component or element.
To work around the problem of not allowing multiple designers to work on the same Sketch file at the same time, designers had their own local files, on which they would work on specific components or features. Once those components were completed and signed off on, only then could someone push their work to the master library document.
After a month of development and design, we were at a point where we had 80% of the initial documentation completed. New designers and developers could access the internal design system link and quickly gain access to the latest version of our shared Sketch library or get started with a starter package for building out new applications. However, we quickly realized that although components were being documented, we weren't in a position to scale well.
The work of a few can not provide for the needs for many.
I started thinking about how we would be able to grow Atlas and allow more teams and individual employees to help contribute to it. After a lot of reading and research on others who had implemented design systems for their companies, I stumbled across the idea that making the design system open-source would be the best approach to help it grow organically. As leaders at Putnam push for a more collaborative work environment, this was a way to test cross-functional collaboration on a smaller-scale before implementing it on a larger scale.
We first started with a group of interns, who had developed several components that weren't part of our common library before starting at Putnam. These were generic components that you'd expect in business applications (export to PDF, export to PDF, file uploader, etc...). Because we were still at the beginning of the process of creating and researching which components we would use and build platform-wide, we had to make sure whatever we chose for specific components would satisfy requirements a year, five years, or even ten years from now.
As a result, we decided on three main criteria for evaluating whether these components were robust enough for usage. These were: the extensibility of customizing or augmenting each component, the simplicity of usage (from a user standpoint), and the difficulty of actually implementing and creating the component. We wanted to provide a distributed model to allow individuals the autonomy to make decisions and pick up where others left off. This approach would allow us to scale a lot better and contribute to the growing community of self-driven developers and designers at Putnam.
As we finalized our MVP, we had to start thinking about who we would test the first iteration of our design system on. Putnam works within the Agile methodology, so we wanted to come up with something functional and usable without holding off for so long that we would miss out on any valuable feedback.
Before testing it on the first group of users, we set up Google Analytics to track utilization and the most frequented pages. We wanted to also get an idea of who used which pages so we could determine where we could focus our efforts.
We chose to pilot the design system on a group of recent college graduates who recently joined Putnam. For this group, the design system served two purposes - to act as a guide for developing applications at Putnam and also to onboard them as new employees at a new company. In order for the design system to be successful, we conducted frequent check-ins, surveys, and in-person interviews to identify any pain points they encountered. Over the course of the two months we checked in with them, we aggregated the priorities, wants, and needs of these users to determine the most important items to add to the backlog.
In addition, the design system was also a main topic of discussion at a weekly meeting in which designers, key product owners, and architects checked in. We would use the time to determine which components still needed to be developed and whether any modifications needed to be made to existing ones. Atlas acted as the single point of truth, ensuring that whichever component was being discussed was the latest version.
At Putnam, one of the main challenges was working on a small design team. As one of three designers in my department, I knew that creating and scaling a design system would be difficult without the resources of a larger team.
Although the number of designers and developers I could recruit to help with my work was initially limited, I was able to leverage the help of a few of the summer interns to help me build out a lot of the initial documentation and features. They contributed to the overall vision of the design system and were able to effectively implement what use cases were created from our refining meetings. However, in order to get more initial sign-on, I worked closely with the architecture team to get them to document any common components or packages they were pulling into our common codebase.
One of the main challenges was getting others as invested as I was in the same vision for the design system. Although senior stakeholders and developers were able the see the value in creating a design system, there was a lack of incentive to get people motivated enough to contribute to the system.
To encourage collaboration, we made two changes to our existing processes.
1) Firstly, we learned that developers didn't want to work on the design system because each developer was tasked to a specific project and didn't want to take time out of their day to work on something that wasn't directly related to their deliverables. To target this pain point, we implemented a new incentive system that would give credit to whoever worked or created a specific component. Although the components are centralized, the work didn't have to be. This way, developers could show their directs that they were working on something common to Putnam to justify the lowered bandwidth in their individual teams.
2) Secondly, to get developers more quickly acquainted with the codebase and design library, we included an introduction to the design system as a part of the developer onboarding process.
Like so many other enterprise organizations, Putnam struggled with developing applications for its internal users that go beyond just the functional. The culture for creating internal applications is different than shipping for external users because many don't see the value of making an application more than functional if it satisfies the requirements of what business users need. Although product usability and aesthetics are coexistent but not identical, the two were closely related at Putnam. The usability of the applications built was heavily impacted by the design of the UI, an area that was heavily lacking at Putnam several years ago. Unattractive and unintuitive software can cripple a user's experience, whereas companies that have well-designed software can cause a company to run smoother.
"Products designed for more relaxed, pleasant occasions can enhance their usability through pleasant, aesthetic design. Aesthetics matter: attractive things work better." -Don Norman
The underlying problem is trying to change the culture of enterprise organizations. Engrained and deeply rooted in the requirement to quickly ship to market, developers were used to pulling in external packages and libraries to meet deadlines. As a result, inconsistencies ran rampant across different applications and even within the same applications.
To tackle this issue, we had to implement and enforce some stricter rules around what developers should and shouldn't do. Additionally, we had to convince others the value of design and how it would alleviate a lot of the maintenance issues and bugs that arose as a result. Instead of hacking something together, we ran joint design sessions to get developers to empathize with users so that they wouldn't develop or design something that they themselves wouldn't use.
In order for a design system to be successful, it has to be continuously maintained. This was a point I made clear to anyone who worked on our design system.
A design system is not a static style guide. It's a living application that evolves to the needs of its users and must be maintained and improved over the long run in order to be successful.
Right now, as we continue to roll out new components and documentation for anything new that's added, our next steps are to set internal standards for any repeated processes moving forward. This will help ensure that documentation is consistent and written in the same format each time, components are well-built and won't break any releases, and manual processes can be eliminated so developers and designers can focus purely on the work in front of them.
Since the release of Atlas, evolution and adoption has been amazing. I was initially unsure of how adoption would be, but because this is the first time Putnam has ever implemented any type of initiative like this, developers were extremely happy to use and reference this. In addition to serving as a guide to developing applications, it's been a great resource for onboarding anyone from new hires, to interns, to offshore developers.
With the design system, we now have consistency, brand unity across all applications, faster product launches, and a lot of saved time from making one-off changes. Atlas is the single of truth, which provides us a lot of benefits that we didn't have before.
I want to conclude by expressing my gratitude to so many thought leaders in the space that have given me their advice and feedback on the work we're doing at Putnam. Without their articles, books, lectures, and Powerpoints, I would not be able to go ahead and create this for Putnam and centralize and drive our design language forward. I want to specifically thank Alla Kholmatova, whose book Design Systems helped me with implementing and driving the vision behind Atlas, as well as Mikhail Gündoğdu, who provided advice on measuring utilization in design systems in his Medium article.
Lastly, thank you to the team that helped contribute to Atlas, specifically Cyril Dasari, Jason Xu, Morgan Hites, Ryan Luu, Thomas Corcoran, Jocelyn Shiue, Christopher Myers, Vijay Kolluri, and Sarah McCarthy. Without their help, none of this would have been possible.