As a large organisation Amann Girrbach was in a need of a centralised system in order to bring in design and user experience consistency across multiple digital products. Additionally, the company needed to make sure that the brand identity is consistent across all digital touch-points like landing pages and marketing assets.
The main challenge of building a design system for AG was making sense of the existing design components which were already implemented in multiple code-cases with no alignment to one defined source of truth.
To tackle the given complexity we framed the design system use-case for only one application AG Live!, the most prominent software out of the company's product range. By focusing on a single usability environment we managed in a relatively short time-period to build a system that could be incrementally adapted by other softwares later on without compromising. Building the design system alongside the app development allowed us to grow gradually and in alignment with relevant user needs.
The new design system architecture (see below) was planned to be use-ready for multiple applications. It was divided into 3 UI libraries: styles, assets and components. In order to keep a cross-application consistency we defined the styles and assets libraries as the backbone for all cross-organisational use cases from marketing to product. However, the components library was designed to be application-specific and included patterns that match a certain use-case environment while using the styles and assets libraries as a source of truth.
To define the DS architecture we performed research and analysis of the business, technological and product needs by interviewing and collaboration with different team members. By doing this we invited all relevant counterparts and potential DS users to collaborate which contributed to a better adaptation and advocation internally.
The main idea behind the structure is to create an environment that is easily iterative and scalable moving forward with adding new application to the ecosystem.
Another fundamental step was to scan all existing designs where the component library was intended to be used. We did this in order to evaluate which are the most fundamental components we need to include in our future design system. It also helped us elevate any hidden issues or duplications that can be fixed and/or simplified.
To ensure that our design system is in alignment with the global guidelines we kept on a collaboration and ran constant update rounds with the company's creative direction. This way we made sure our style and assets libraries are fully compliant with the brand CI.
One pain point here was getting the brand and communication to use the new design system as the source of truth. This was mainly due to legacy and contradicting professional approaches. However, by we managed to generate a discussion and a common goal of centralizing a design source of truth.
The design system and UI Library structure in particular was built based on an atomic design approach which helped designers and developers to access and understand the design more efficiently.
We used Figma as the main source of truth. It included styles, assets libraries and an app-specific UI library that included components and patterns. All atomic components included technical spec annotations that made it easier on developers to deploy styles into each component.
The libraries were set up in Figma and intended to be used by the different design files accessible by product, design, tech and (potentially) marketing teams. The main goal of the structure is to allow smooth scalability as the product grows and provide an easy access to the all possible design system users.
The component library included all atomic elements to enable the design team to build complex patterns to be used in various use cases. The new components were configured to be in constant sync with the GDS style library. This means that any global change in colors or font would render accordingly in the component library and all design files respectively.
In order to keep things safe when testing new changes, we implemented the use of branching in Figma, where designers can first branch the main library file into a temp. version which can be separately tested before approval. Once designs would get approved the branch can be merged into the main file and changes would take effect globally.
All component created in the library were annotated in a table so both designers and developers are able to recognise and understand the components types and their variants.
As a design system is not sufficient without adaptation, it was crucial to make sure that all key stakeholders are fully engaged and supportive. Thats why we included product and development team members in creating and naming design files components and styles.
We also understood that a design-to-code process alignment between designers to developers is crucial to establish trust and curate a collaborative environment that were important for the design system adaptation. Thats way we ran workshops with developers and PM that nudge the topic of design-to-code workflows to come up with an agreed process and guidelines.
To round things up we created an external design system documentation on Confluence to a support future onboarding and internal education.
As part of the product research we mapped the current user journey to spot opportunities - where and how we can improve the UX. It also helped us asking the right questions and reveal hidden issues which otherwise would not be visible. Mapping out the user flow contributed to understanding the architecture behind the product and used as a good starting point for the new flow to become.
As a result of the analysis, combined with the user research, we fabricated an improved user flow map that had a remarkable positive impact on conversion rates.
