The origin story of many design systems starts with a familiar narrative. Without a shared product design language, managing consistency is challenging, duplicate work is created and pains escalate into problems as a company scales.
At Contentful, the challenge of working without a design system presented the opportunity to start one. What followed has been a grassroots effort of design and developer collaboration driven by a strong sense of spirit, hustle and good old fashioned teamwork.
What followed has been a grassroots effort of design and developer collaboration driven by a strong sense of spirit, hustle and good old fashioned teamwork.
As a product designer at Contentful, I’m regularly using the design system as a shared language with engineers, and contributing to it whenever I can. I sat down with João Ramos, Mike Mitchell, Johannes Bugiel and Kevin, a few of the pioneering contributors and champions of the design system, to learn more about how Forma 36 was built, how it gained traction, and how we’ll continue to grow and support it in the future.
How was the need for the design system at Contentful identified?
Kevin: Early conversations from product design and engineering management drove the formation of the design system. Claus Hollensteiner and Ben Lowdon, two other key champions in this process, identified the need for consistency across the design of the product, and I felt we could improve the consistency and workflows across engineering. With this in mind, we created a new UI Engineer role at Contentful to bridge the gap between our disciplines. The pitch we used in recruiting for this role was the opportunity to create and potentially open source a design system for Contentful. We knew that our first UI Engineer, Mike Mitchell, would be key to getting the project up and running.
What type of work was required to lay the foundation for a design system?
Mike Mitchell : I joined Contentful as a UI engineer within a content experience team, and I split my time between product development work and establishing the design system. Initially, I found there was a lot of scattered documentation on our internal wiki, an inventory of components and some direction and existing CSS styles for patterns. I observed that engineers were rewriting UI often, and I received repeating questions about pattern usage, such as when to use a table over a list, or the best practice for writing error messages.
One of our goals was to make the design system as frictionless as possible for engineers.
I moved the patterns into Storybook, a well-established tool for documentation. I added a component library with CSS variables and light tokens, and worked with Claus to identify patterns in the product that we could move over to the design system. It helped that I was a member of a cross-functional product squad with Claus. The product manager of our team, Spiros, understood the importance of a design system and helped us to build development time into our team process. Over time, we started to shift from reactive documentation to planning the future of the design system. One of our goals was to make the design system as frictionless as possible for engineers.
How did the team grow as the design system became more established?
Mike Mitchell: As Claus and I dedicated more time to the design system within our product development team, we began to see the need for more contributors. João Ramos joined the effort as a product designer, and we hired another UI engineer, Johannes Bugiel. We all dedicated time to the design system in addition to our product development work.
João Ramos: One thing that I looked at from a design standpoint was creating stronger consistency in our prototypes and design handoffs to engineers. At this point we only had three product designers at Contentful, but there wasn’t a lot of consistency in our prototypes. I began to create Sketch symbols, which led to a UI kit. This became a key resource as more product designers joined Contentful.
We began to treat the design system as a product
Johannes Bugiel: When I joined, there was already a backlog of components for me to add to Storybook. We began to treat the design system as a product and had regular grooming sessions where we defined each component and prioritized our work.
Were there any milestone moments as the design system grew?
Johannes Bugiel: We had a few big moments, both internally and externally. Something that helped us gain momentum in establishing the design system as a product was attending the Clarity design systems conference in New York. Before the conference, we created a public documentation website, made the design system open source, and developed a brand. This is the point when the Contentful design system became Forma 36. The conversations within and encouragement from this design-systems community also led us to engage with the design systems community in Berlin.
Mike Mitchell: We also felt a lot of validation of Forma 36 when we presented it to product leadership at Contentful. It was clear that everyone understood the value of a strong design system, and we received a lot of encouragement to continue working on it.
João Ramos: Another big milestone moment was at an internal Contentful hackathon, held shortly after the soft release of the open source design system. Almost every hackathon team used Forma 36 to develop their solutions, resulting in a strong acknowledgement that the design system was useful, valuable, and a welcomed addition to the product development process.
Almost every hackathon team used Forma 36 to develop their solutions, resulting in a strong acknowledgement that the design system was useful, valuable, and a welcomed addition to the product development process.
How is the design system adopted into product development workflows at Contentful?
Johannes Bugiel: One of the biggest ways Forma 36 took off after the hackathon was alongside the growing Extensibility team at Contentful. This team makes it possible for customers to integrate UI extensions and apps into Contentful workflows, and the open-source design system became part of the extension tooling.
Mike Mitchell: Contributing to the design system has extended outside of the core group, as many of the front-end engineers at Contentful have helped by contributing new components to the design system as it grows. We’ve also added more product design contributions, with Dominik Markušić and Sara Kalinoski joining the effort to create guidelines for UX copy, date and time, typography and layout.
What are the goals of the design system moving forward?
Johannes Bugiel: We would like to establish the design system more internally in order to maintain it, shape it, and give it the direction it needs. As Forma 36 grows, we’re mindful of some of the less visible tasks required to keep the design system running, such as onboarding new engineers, communicating updates to the design system internally and externally, and managing the increasing and ongoing maintenance.
João Ramos: We’d like to scale the design system alongside Contentful. We are already treating Forma 36 as a product, and one of our next steps on the product side is to establish a process to track the success and adoption of the design system, both internally and externally.
Mike Mitchell: We are also working on an upcoming release of version 4.0, which will introduce more components, guidelines, and new ways to use the design system.
Last question- how did you decide to name the design system Forma 36?
Mike Mitchell: Many design systems we admire have brands outside of the companies they serve. Before we established the brand of the design system, we invited Contentful employees to submit name suggestions, and then sent a survey around the company to vote on the final name. Forma is the Latin word meaning “form, shape, appearance.” 36 is the area code of Kreuzberg, the neighborhood in Berlin that Contentful calls home.
Interested in joining us to develop Forma 36 and Contentful? Check out our open roles