Photo by NEW DATA SERVICES on Unsplash
We all have a process. Each of us, as professionals in the digital space, utilize procedures and techniques that have made us successful. To get the job done as a User Experience Architect, there are stages in a design process, based on industry standards, that have given us the ability to determine if an application or feature is Discoverable, Findable, Understandable, or Usable. These are the key principles of User Experience, and how projects can define, deliver, and measure success.
But what happens when you come across a new process that changes the way you approach design problems and speeds up your productivity as well? Utilizing Design Systems allow product development teams to do just that. While style guides for digital experiences have been around for decades, they quickly become dated because they can't evolve. There is no baked-in feedback loop to a document you can print or file away in an obscure network drive. A Design System is a combination of a tool and methodology, that allows for cohesive digital experiences. It is a product that serves other digital products.
FSA Design System hosted on Github
At the USDA, part of my role as a UX Architect is to help build, test, and evangelize the FSA Design System, whose purpose is to bring cohesion and consistency to over 250 applications designed and developed by federal employees.
$1 Million for Buttons
We presented to various groups within the USDA, and I started each presentation explaining a very common situation for organizations that have a large number of development teams. By first identifying a problem, and sharing it with executive-level stakeholders, we were able to gain buy-in from the top. Organizations spend millions of dollars often reinventing the wheel, or button in this case, and a Design System helps to eliminate this failed practice.
Below are slides from the presentation that illustrated the impact of many development teams all producing buttons which creates a library of inconsistent buttons, and costs the organization millions of dollars.
Evolving Your Design Process
As part of the discovery and evangelism stages of the FSA Design System, I facilitated and lead the proceedings of a Digital Usability Team, consisting of around 25 individuals. We met weekly, shared ideas, and help discussion that helped inform the building and testing of numerous prototypes in an effort to build a Minimum Viable Product (MVP) of a Design System. The group included various members of development teams, products owners, and end Users as well. The process was exploratory in nature, and generally ran like a focus group that tested features, components, and process flow.
When I started, I first utilized Axure with a combination of static Wireframes and interactive Wireframes. As many UX Architects know and understand, Wireframing is a process that helps flesh out ideas prior to developers spending hundreds of hours coding a working application. The main flaw of a Wireframe is that very few individuals outside of the UX industry know how to use them and interpret them, especially product owners and clients. I always like to compare Wireframes to football plays or pages of music. Unless you are a coach or a musician, it is very hard to understand what is going on.
Photo by Marius Masalar on Unsplash
But what if you could watch the football plan being run at a practice, or listen to the piano play the music? You would have much better understanding about what to expect in the stadium or at the opera house. This is were a high fidelity experience is warranted, and interactive prototypes come into play. We are visual learners as humans, and to see what something looks like and experience the interactions, we quickly find a path to understanding.
As I was working with the Digital Usability Team, I noticed a resistance happening each week from a number of individuals. While my Axure prototypes were mostly understandable to the developers and QA testers, the business representatives and end Users generally had a hard time following along. The Design System was far enough along that I decided to start using it as a means to quickly prototype out various concepts. What happened immediately was a better understanding of the concepts and process flow for the end User, because the audience could "hear the music" or "watch the play unfold".
The FSA Design System, even in its infancy, was being used in the way development teams would strategically utilizing it within their own projects. I very quickly was able to create high fidelity prototypes, that retained the same look and feel across all features at a speed traditionally unattainable with normal UX tools. Wireframes were indecipherable, and design comps lacked movement and process flow. The new process became an exercise of Whiteboard sessions mockups of new features, followed by prototypes utilizing the Design System itself.
So, what is a Design System?
When you combine an ever evolving codebase with documentation that provides guidelines on how it is utilized, you have a Design System. That sounds a little abstract and since we as humans are visual learners, I believe it is best explained by using an analogy and showing imagery that most can relate to. The goal of any architectural project is to build something, and to help us out with better understanding how a design system works, let's start by building the below Lego truck.
Our goal is to build this Lego Truck
As kids, we began with a large pile of hundreds of mismatched Legos. It was very difficult to find more than one or two pieces that had the same shape, size, color, or function. It was always a mess. As architects, we need to be smarter about how we play with our toys, and so we decide to first build a Design System before we start building anything else.
We organize our legos based on a specific color palette
Once we have started to organize the Legos, and have identified a color palette, we can see how a theme is developing. One of the main issues within large organizations is having many digital experiences and keeping them all on brand.
We organize the individual parts and arrange by size, shape, and function
By creating an organizational system that logically places the parts and pieces in an arrangement based on size, shape, and function, anyone can now utilize this Design System to quickly build our Lego truck.
Now we can quickly build our Lego truck
Because of the speed and efficiency that is gained thru utilizing a Design System, different Lego vehicles can be build that are cohesive, consistent, and operate in very similar ways. We have achieved a methodology that optimizes a build process and alleviates the need to make design decisions that could potentially cause a poor User Experience.
We can build different types of vehicles that remain true to design and functional standards
Products Giving Back
One of the major benefits of a Design System is the feedback and development loop that is created by all product development teams utilizing the same codebase. If a new feature is developed in one product, the feature's code can be fed back into the original Design System, allowing for distribution to all other products.
For example, lets assume our new product requires a contact us form, and the Design System has a number of different form fields that can already be used. We build out our application but discover the requirements ask for a field to have a toggle, which doesn't currently exist. A developer can build a new toggle component utilizing the same patterns of markup and style of other documented components, and launch the new project with a new feature. If it is deeded to be a component that would benefit from being shared across other applications, the code can be integrated in the Design System codebase and them pushed out to all products with a new release. The feedback and development look is completed when other projects update their codebase with the latest Design System release and can now utilize the toggle component.
Final Thoughts
Building a Design System to create cohesive and consistent User Experiences will require a bit of ramp up time, but once a MVP is available, product teams can begin to see the benefits of working with a Design System. As the codebase continues to be build out, the accompanying documentation informs development teams of best practices, usage, and accessibility concerns.
Working with Design Systems has changed my way of thinking and the way I approach a design challenge. Not all organizations have the ability to build their own Design Systems, but there are a number of Open Source ones available for adaptation and integration, including the FSA Design System we have been reviewing. I highly recommend looking into ways to incorporate the same methodology and process if you are looking to speed up product development and create consistent and cohesive digital experiences.