XDS - Experience Design System
What is XDS?
XDS, or Experience Design System for short, is Allstate’s very first design system. It had its start from a couple of UI component patterns in a Sketch file passed between designers, but the need quickly grew for something much more robust to encompass our ever-growing needs and vast product library. What is a design system? According to Will Fanguy from InVision, "A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.” - (https://www.invisionapp.com/inside-design/guide-to-design-systems/)
The Challenge
Designers across the enterprise were previously just passing Sketch files back and forth between each other, without any documentation, or syncing & versioning behind each file. Those last two are very important, since you never know who has the most up-to-date file. Since there was no documentation, that means that there were no usage rules for the components, content guidelines, branding guidelines, or developer guidelines. In short, there were no consistency in any of our designs.
Our Main Objectives
Research and define user needs
Creating a Sketch symbols library all designers to use
Creating a central documentation repository for brand, content, developer guidelines, as well as component usage rules
Secondary objective: Minimizing effort on design & maximizing time spent on actual problem solving for each product line
Our primary users were -
UX designers, product designers, visual designers, content writers, and some user researchers in our greater enterprise organization.
My Role -
UX / UI Designer & project lead / product owner
The broader team -
Me as the lead UX / UI Designer (Team Lead / Product Owner)
UX Designer
UX Content Writer
Visual Design Manager
Frontend Engineer
Scope & Constraints -
One of the constraints that we had facing this project was the tight timeline that we had imposed by our senior leadership. They gave us 3 months to have an initial MVP version of the design system to deliver, and with a small lean team, we had to work fast. Another constraint was that not everybody was dedicated to the design system full-time, so a lot the resources on our team were only on the project part-time. I was the only person on the the product full-time for our initial 3 month project scope, and even afterwards.
Understanding
Our very first step in creating our design system was understanding where our current state of design standards were, and what our user needs were. In this case, our primary users were UX designers, product designers, visual designers, content writers, and some user researchers in our greater enterprise organization. What were our designers looking for in this design system? Were they looking for content guidelines or strategy, a repository of patterns, a code repository, or how to best utilize the brand assets? Also, how can they find what they’re looking for? Is it a Sketch file? Is it a website? Do we have anyplace for developers to reference code?
Planning
One of our first steps in such a massive undertaking of creating a design system is gathering the correct resources and that includes involving different stakeholders as well as forming a team. Within the team, we needed to figure out our workload and process and how we can best divide work among us. With that, we utilized the agile framework to help keep us responsible on a schedule of release and accountability to our business leaders.
Problem Statement
In our understanding & planning phase, we have already identified a main problem statement: How can we introduce a platform for designers at all experience levels to use that will help with the goal of uniting our extensive products in consistent branding and is something that they will understand that will be effective & efficient for them to use?
Research
Looking externally
In trying to understand our users, we also needed to look externally and see what other companies were doing and how they set up their design systems. So we did a competitor analysis. This was a really big step in helping us know where to start. Instead of trying to reinvent the wheel, it gave us a point of reference. We started with identifying common components that all of these design systems had.
Aside from the components themselves, we looked at the component usage rules and the documentation behind them, as well as best practices. What we found across the board was, typically, all of the usage rules were the same for common components. The biggest difference is the naming convention for these components between different companies design systems.
We utilized this strategy in helping us create our architecture as well as our naming convention. Seeing what was common across multiple company’s design systems helped us make note of what we should include and what were some outliers that we might be able to get rid of or make our own.
Looking internally
Along with gathering data from the competitor analysis, we also surveyed a wide spectrum of different designers working on multiple different products. We asked what was most important to them in a design system? We asked about different components and their naming convention, and how they expect common components to interact, as well as what they would be looking for specifically in a system that might be useful to them?
We utilized the Affinity Clustering methodology to organizing some of the information and see where there were categories coming out of the needs of the designers that we were surveying.
(Especially since there was a wide varied number of designers who called one component different things.)
Analyze
After our research step of our process, we took some time to analyze and look at a lot of the data that we had collected. This helped us come to a solution based on our original problem statement and feedback from other designs, to synthesize a minimal viable product.
We recognized a few important points in our research findings:
A wide varied number of designers called the same component different things.
Naming convention is important but we don’t need to reinvent the wheel. Go with commonly used industry standards.
The findability of components in a Sketch library is learnable.
It’s important to document the usages of components, as well as how not to use them.
This is normally the stage where we would create a user persona or a journey map, however, since we had the combination of a fixed launch date and aggressive scope with many coordination and time challenges, we decided to bypass this stage. We felt comfortable with this because we knew who our primary users were and they were our own designers from within Allstate.
Design
Starting on small scale, we utilized one of our existing products (Allstate Online Sales) as the core basis and starting point for our branding, since this particular product was the standard of our ever changing branding at the time. From our earlier analyzing process stage, we had established a set of required components that we knew we needed to create a basic minimal viable product (MVP), so we set out to brand those specific components, as well as write usage rules and documentation for each one.
Aside, from our own starter components, we took our compiled list of common components from our competitor analysis research and designed more components based on our product needs, or anticipated needs.
We also looked at designing our design system model similar to what Brad Frost, author of Atomic Design, had described - to start with the tiniest atom (or lego block) for a component that you would need and scale up from there. We recognized the wisdom in this, especially since a lot of design systems we had analyzed were following the same model, including Google’s own Material Design.
In designing our design system, we were met with some technical challenges. One of them, mainly, being, how do we deliver the UI toolkit library across the enterprise to our designers who needed it? We were faced with this unique challenge due to our internal enterprise security firewalls and how it wouldn’t allow for any sort of cloud storage to be utilized, meaning those sites (or products) were usually blocked by our network. We had to find a work around.
Our solution was to utilize what we already did have access to. Our organization already had access to Github so we knew that people could access it. However, with one problem came another. This problem was mainly a user problem on two fronts: you, as the individual user, had to sign up to use Github, and then add the repository you wanted to pull the latest UI toolkit library from. Secondly, Github is confusing for a lot of average people who don’t use it on a regular basis. Developers might be used to using it as a tool, however, with designers, there’s a steep learning curve, and we as a team just didn’t want to place the cognitive load on our end users, especially when we’re trying to increase efficiency and ease of use.
We did still use GitHub, however, our solution to both problems was eased we figured out we might be able to write a script program that can pull from Github. With this, all the user would have to do is download the packaged script program that we made available on the design system documentation site, and with just one click, the script program automatically pulls the latest UI toolkit library from Github to downloads it onto their local computer. The users didn’t need to worry about signing up or logging into Github. This placed the responsibility solely on me for getting onboarded to Github myself, logging into it and pushing updates to the UI toolkit repository. There was still the added responsibility of onboarding our designers on how to download and use the script program, but that was pretty simple since we also documented those steps on the site where they had initially downloaded it.
It was at this point in process that we felt we needed to gather some feedback from an internal testing with some users before we went to launch, and so we had set up testing with a small group of designers. We observed users using the UI toolkit and the website for the very first time. We asked them usability questions on whether they were able to find what they needed to find, and how they would rate the system overall, and feedback on any improvements. With the feedback that we gathered from our beta testers, there really wasn’t a whole lot for us to change. There were some minor bug fixes that we were able to update to the UI toolkit rather quickly. The feedback did solidified our original thesis of our design system, which was that discoverability wasn’t going to be an issue, especially since designers are learning about design systems for the first time, and will continue to get to learn where different components are and how they are classified.
Launch
After we had designed our first iteration of the design system as a product, we decided it was ready for launch. So it was with the blessing of our leaders and stakeholders, we launched the first version of the design system to the rest of the enterprise. Designers were really blown away by how detailed and easy it was to use this new design system.
That wasn’t the only task, however. We also needed to set up a system of communication, to be able to send messages out to our organization on how they can access what they need, as well as know how to reach us. We set up a specific email inbox to intake any questions or bug requests; we set up a specific Microsoft Teams channel where designers can reach any member of our team more immediately; we also set up a fireside chat, a dedicated time where we go over education and any new components we’re introducing to the design library as well as taking any questions that people might have for us or want to discuss.
We also needed to work with different product teams that might have questions on how they can incorporate these components into their current products and how might they codify these components.
Analyze again
No good product doesn’t get to where it is without feedback and iteration and so that’s exactly what we had set out to do immediately after launch of the first iteration of our design system. We gathered further feedback from designers all across the enterprise: what works, what doesn’t, are there any bugs you’ve noticed, is there anything you would like to see improve or that you would like to add? All of this helped us in prioritizing our next steps in the iteration process, which was all about product optimization and improvement. Our most important priorities also happened to be the most achievable, squashing out any bugs that we could find.
We also asked ourselves on the team:
Where did our process go right, and why?
What were some pain points and how can we help to alleviate them in the future?
How are our users responding to the design system?
Can we make things easier for them in any way? Can we improve the product?
What I learned from this project -
Challenge designers on using only the available components in the library as opposed to spinning out a variation. If something is truly unique, they can submit it for approval to be added to the library.
Having a governance process down for when new component patterns get adopted into the library. How do we agree & sign off on it?
Working with a group with differing opinions is challenging and great at the same time. It’s so amazing to have so many different perspectives and to see things that any one individual might not caught. It’s with this thought in mind that we have to remember who we are designing for, and that’s the question we keep coming back to.