A project to create a unified design system, shared across multiple acquired companies, to provide a single design language for Autodesk's AEC industry suite of products. This shared system builds a more cohesive experience for customers in construction and architecture.
AutodeskDesignSystem
Overview
Background
From acquisition to unification
After the acquisition of PlanGrid, BIM360, BuildingConnected, and Assemble in 2019. We kicked off unification efforts to have a single unified solution for our customers. This spawned the need for a single unified design system in order to build cohesion across the portfolio.
Before unification
Autodesk construction cloud is the new unified solution from the “Autodesk contstruction solution” team at Autodesk. It is a single unified tool that connects all parts of the construction process together. Such as pre construction bidding, pre construction estimation, build execution, change orders, project management and all the way to close out and asset management post handoff.
Problem
- Unify 4+ design systems in to one
- Establish a effective contribution model for the growing team
- Establish a process to build cohesion throughout the product
Vision
Clarifying our audience and role
One of the first things we did as a team was establish who are we going to serve and how are we going to serve them.
Instead of trying to cater to all the orgs at Autodesk, we decided as a construction org to only focus on our newly formed group instead of trying to support other orgs close to us. Serving them would come later.
To give a sense of size, our org was about 1600 people with 1000ish R&D team members
We also decided we need to keep our platforms across devices such as iOS, Android, Windows and web.
Designing for cohesion not consistency
We also evaluated and aligned on was our take on “cohesion” vs “consistency”
Sometimes when speaking about design systems the word “consistency” usually comes up But consistency as a narrative is limiting, especially to our customers. And we don’t want that.…we wanted to be consistent, but only to a point – when we strive more for cohesion and retain flexibility, we can be more efficient to each unique user’s workflow.- Also the factor of our effort to unify our various products in 2 years, being more accepting of cohesion is more achievable and realistic given technical underfoot of getting our products together
Aligning our visual language
We explored various degrees of separation but landed on staying as close as possible in terms of visual language, but forking components to serve our diverse set of needs and velocity we were looking to achieve. With the goal in mind to contribute back when ready.
We also looked to identify how will we work with Autodesk’s existing design system and visual language (HIG), while keeping up with our desired velocity and unique set of needs as a org.
Process
Collaborating on a vision
Once we felt we had a strong foundation in place and assets that the team could play with, we created a “design jam.” This included teams across 3+ main gems, 100+ designers for 2 full days. During this time each designer took the initial set of assets and explored how the current design system components could work for them and where they failed.
This providing us endless insights into what we needed to improve and prioritize.
Establishing a Definition of Done
The first step was establishing a definition of done where as a org, we can all align on expectations for the release.
We broke our definition of done into 4 key buckets, Gold Steel , Aluminum and F (not acceptable).
Things marked as gold are items that we all should just be using component wise. This was things like buttons, typography and colors.
Steel is where it can be using the components but at very least look and act the same. Examples here were like trees and tables. Complex items that may need to align to customer goals more then consistency.
Alluminum is where it looks the same but doesn’t need to really act the same. Examples such as patterns or complex interactions.
F, is just an assessment where things failed.
Execute
Guidelines and specs
After we finished our XD vision exercise, gathered all insights from the various teams and began setting a foundation for outlining how we will execute components for teams to use.
It was now time to get our component libraries fleshed out in great detail so our platform engineers can provide the necessary components to the feature teams.
We focused on our core “atoms” first such as color and typography, and even design tokens. Before moving on to core components such as buttons, text fields and navigation. This following the definition of done categorization
Ontop of building out the various components, we also set out to unify and build a single repository of design guidelines our team can consume.
We felt these were crucial part of our initial release as we saw so many similar questions arise and engineers stuck on understanding component logic without them.
These were both new set of guidelines written as well as unified versions of our company wide guidelines, and guidelines from the 4 unified construction design systems.
This was a great area of collaboration as our various team members drove a majority of their development, especially on the pattern documentation side.
Outcome
Accomplishments
- Launched a single unified platform from 6+ acquisitions in just about 2 years
- Built a platform design team of 3 designers, 4 including myself
- Instilled a self sufficient cohesion process going forward
- Established a shared understanding across the org on what accessibility means to the org via a series of shareouts
- Planned, advocated and Released several accessibility initiatives to better support our various users
- Built and distributed tools for engineers and designers to better create accessible experiences without much involvement needed.