The situation
Mimecast had grown through acquisition and rapid product expansion across multiple technical platforms. The result was four main historic versions of design systems, and within those, products and features that did not consistently adhere to any of them. Many projects that had started as features within products had grown into products in their own right, each with their own inherited UI history and engineering choices.
The core problem was not simply that shared components did not exist. It was that multiple versions of the same components existed across different areas of the product suite, and nobody was certain which version was the right one to adopt. This was compounded by a genuine technical split: some teams built on Angular, others on React, and there was active debate across the organisation about which framework the business should align on. Teams had strong preferences, and those preferences were not easily reconciled.
There had been attempts to address this before. Previous efforts to establish a new standard had been made under each of the four main design systems, and all had ultimately failed. The consistent reason was team fragmentation: isolated engineering teams, under delivery pressure, with no shared ownership model and no mechanism that made using a common standard easier than building something independently.
The director of architecture put it clearly: he did not care which technical framework teams used, as long as products looked visually consistent for users and customers. Visual similarity was the goal. How engineering teams got there was their choice.
The challenge
The platform team was tightly focused on centralised product features and measured on delivery. A proposal to take on ownership of a shared UI system was, from their perspective, additional work outside their remit. Making the case required reframing the proposition in terms that mattered to them: fewer one-off component requests, reduced duplication across feature teams, and a shared standard that engineering could actually maintain rather than inherit and abandon.
This was not a quick conversation. Over many months Graham communicated the value of a common component library, making the case that the platform team could own it in partnership with the design team in a way that would speed up development and provide a common language for collaboration and accessibility standards. A US and UK workshop eventually brought the right people into the same room and secured agreement from the VP of Product for Platform.
From that point the engineering team moved quickly, selecting Storybook as their tool of choice. The design team worked in Figma and used ZeroHeight to document and catalogue the design system. The pairing between Storybook and ZeroHeight was particularly important: keeping both in close alignment meant that what was documented matched what was built, and both designers and engineers had a reliable source of truth.
How it worked
Design leadership and governance
Jackie Simon led the design system work day to day as Design Lead for Mimecast Elements, with the full design team involved in reviewing, agreeing, and supporting changes. The principal burden of creating new UI patterns and components fell on designers, but components could equally be developed by a feature engineering team rather than the platform team, provided the platform team were involved in coordinating quality and consistency of the result.
Cori Ameh held the Product Owner role for the system. It was Cori who prioritised the backlog of component requests, bug fixes, and accessibility updates, not the platform team. The platform engineering team worked those tickets as capacity allowed, typically finding time in gaps between scheduled delivery rather than maintaining a dedicated sprint. Juan Noguera and Zarina Osman contributed across the system's development as product designers.
Engineering partnership
Over time the platform engineering team became genuine partners to feature engineering teams, helping them integrate the design system into their workflow rather than simply providing a library for feature teams to use independently. This was a shift in relationship, not just in process. Cris Evans, as Senior Engineer, acted as an engineering consultant across both sides: advising wider engineering teams on how to use the platform library effectively, and working closely with designers to ensure the patterns being created were both scalable and reusable.
On accessibility, Andrew Doyle worked closely with designers and engineers throughout to ensure reusable components met accessibility standards. He maintained reports on each component and reviewed them continuously, making the design system the primary vehicle for rolling out accessibility improvements across the portfolio.
Component governance in practice
Engineering teams pushed back on requests for new components unless there was clear evidence they were needed: for usability, for accessibility, or because of a bug. This was not obstruction. It was a discipline that kept the system from sprawling and ensured new additions had a genuine rationale behind them. When designers felt an existing component was not appropriate for a particular interaction, there was a defined process for requesting amendments or new variants. Product management support strengthened any such request considerably.
The design system became the path of least resistance for feature teams. Adopting Elements transferred UI maintenance and security update responsibility to the platform team, freeing engineering capacity for product work.
Adoption across the portfolio
Each product team determined its own adoption path, with the platform team working alongside them to support migration. The journey was not uniform, and several products were still working towards full adoption when Graham left.
The first product to adopt Mimecast Elements. Well received by the sales team and Mimecast customers. Customer feedback via Clozd and Pendo showed a significant positive shift in UX perception. Field CTOs reported that customers noticed and valued the improvement.
Built from the ground up with Mimecast Elements. The platform team consulted and coordinated closely on the pattern library as the product developed, making this one of the cleanest adoptions in the portfolio.
Working towards full adoption. A longer-standing product with its own UI history, bringing it into alignment with Elements required careful migration rather than a clean-sheet build.
Initially designed by a designer, then simplified by a product manager using the Mimecast Elements component documentation to create something straightforward enough to translate directly into engineering tickets. A clear example of how well-documented design systems make design accessible across functions.
What changed
Mimecast Elements became the singular design system for the business. Four products were working towards or at full adoption. Customer feedback through Clozd and Pendo demonstrated a significant positive shift in how users experienced the products that had adopted it, most clearly in Email Collaboration Security. Field CTOs speaking with customers reported consistent positive feedback about the improvements in user experience.
The Email End User Portal showed something important about what good documentation makes possible: a product manager was able to use the component catalogue to simplify an existing design and produce something directly translatable into engineering tickets, without the designer having to remain in the loop at every step. The design system had become a communication tool as well as a technical one.
The multiplier effect
The connection between Elements and the accessibility programme was not incidental. Building accessibility into the design system's foundations meant that every product working towards adoption inherited accessible components as a starting point. Services that had not been updated for years found a practical path to accessible UI through Elements, as adoption of the system brought them into alignment with current standards as part of the development work they were already doing.
As engineers began using Cursor to generate code as part of the guild's AI adoption work, the design system's standards shaped the output of that generation. The system was not just a component library. It had become the shared language through which design, engineering, product, and accessibility spoke to each other.
Core team: