Company Style Guide
how to establish a style for products and keep iterating
Overview - why do this project
When I first joined Automation Anywhere, I was amazed by how much engineers can do in ten years, but also noticed the problems of lacking a professional design team to control the visual language. The biggest problem is, our products were growing too fast and engineers kept adding new features without carefully planning out the overall structure. It resulting in a very powerful but very unfriendly user interface, since whenever engineers want new features, they just added a button, a link, or a page onto the previous version. I named this type of development as the “Band-Aid Design". We need a consistent design language that can represent our products, saving production time, and guide future designs.
In each phase, we experienced different challenges
In the beginning, I had to explore the directions and establish a style from scratch. Defining the scope, and making constraints was the hardest part.
When we had more components, we need to balance whether we need to create new components for special cases, or we can iterate and then utilize existing ones to solve new problems.
When we have a relative comprehensive component library, maintaining, iterating, and educating a larger group become the biggest challenge.
Opportunity & Goal
defined in different phases
Explorations and defining scope
The major work of the first phase was research on the structure of a Style Guide. It could be very simple for small companies, may only have colors, fonts, buttons, form controls, and a small set of icons. It could also be quite large, like the Material Design from Google, iOS guideline from Apple, the Lightning system from Salesforce, or Fluid design system from Microsoft. These guides from large companies not only focus on the look, but also provide guides on the interactions, and practical recommendations on how to apply to your own design. I read many different design systems and made the short-term goal of having a consistent UI, ultimately aim to have a comprehensive guide on interaction details.
For about a month, I almost explored and read all kinds of style guide I could find online every day, try to get familiar with the set up of a style guide, the good practice to present them, and also learned popular interaction patterns. Below are some examples of the style guide I researched on.
to get ideas and set up goals
From 0 to 1
Knowing what I need to do was more important than do it right away. So I started by thinking the following:
Figure out the general framework: the grid system, and the global elements we need on every page.
Figure out the most reusable controls, for example, we use tables a lot.
Figure out the icons we need, and design them in the order of importance.
We design a style guide not just because most established companies have one, but mostly because we want to have consistent UI across components, function units, and pages, thus we can help users to get intuitive experience.
If visual style is the skin of a system, then the component library is the bone. We need to design component library and visual hand-in-hand because the form must serve the function.
Style & Components
has to be designed hand-in-hand
First version visual style
First version component library
From 1 to N
Two big changes brought us the opportunity to make it from 1 to N.
The branding strategy changed - we had a new branding color scheme, and thus can take this chance to redesign the overall UI.
We hired a graphic designer - now UX designers can focus on the interaction and structures, and let the graphic designer take team decisions to the pixel level. This indeed made the project more realistic considering the amount of work we got to do.
The biggest improvement in this iteration is we established a well-organized workflow that enable us to keep iterating in a systematic way.
Although a product design could do the whole process from end-to-end, with the products keep growing, we have to establish a proper way to collaborate: leverage everyone's specialty, help each other filling the gaps, inspire the whole team through active discussion.
Below process happens again and again while we iterating our design.
makes a team more powerful
Scaling & Application
in order to use the style and library on a larger-scale properly, just a collection of components is not sufficient. When front-end engineerings implement pages, or when we try to bring in new features, we need agreed rules to tell us how to combine these components into a meaningful page. How they stacking to each other, what is the spacing between different controls? Thus, a form layout system is the key to ensure the component library works properly. Below example shows how we use the form layout system and reusable component library, to translate a wireframe into a page.
Changing constraints, conflicts handling, and constant iterations
Wireframe vs. Final UI
demonstrates how we convert a wireframe to the final UI
With a properly designed layout control system, designers don't have to draw every single page to communicate with the development team. A wireframe will be sufficient in most cases.
The layout system
build pages just like playing lego
There are 3-layers of containers, and each level has varying base margin. These base margins combine to create the spacing and rhythm that allows content to appear and feel clearly organized in a way that makes sense for the user. By integrating base margins with containers, we create a systematic way to space page content.
System details and examples
to show various applications of the system
We designed and stored UI assets internally. Below process taking the icon library as an example showing how iterations are made.
We iterated our icon system in 3 steps:
1. Count and organize current icons, produce the requirement document.
2. Design all icons in a systematic way that in one style and in a meaningful organization.
3. Maintain the icon collection, and adding new icons when requirements occur.
In order to help the graphic designer to do the visual work. I first need to gather the requirements. I started with going through all the pages in our product, and created a sheet that has five columns:
Icon types: what is this icon, the default concept.
Subtypes: what are the variations of this icon, for example, whether it is a system created or user created.
States: what are the different states of this icon, active, inactive, offline, etc.
Icon ideas: what it might look like, any imagery reference to help create the icon.
Notes: where this icon might be used, whether is used in the landing page table, navigation, or controls? This might affect the design.
Sample component snapshots
Over the past two years of creating and iterating on our product style guide, I learned many lessons:
Draw the bones before the skin.
There are many beautiful design examples in the industry, learn from them but also bear in mind, "Form serves the function". Instead of thinking about the visual style of a system, first, figure out the system needs. If we can depict the fundamental structure of a system, we can quickly adapt to visual changes, color scheme updates.
Workflow, priorities, and collaboration.
In a real work environment, how we do things is as important as what we do, if not more. In order to build a complex system, we need collaboration, discussion, and figure out a smooth workflow that empowers every member to nail their part of work, but also make it as teamwork which much more amazing than simply adding everyone's work together.
Learn by doing.
Look back to the past, I had no idea how to create a system, even afraid of creating one with my limited experience. Two years later, my teammates and I made big progress and we can proudly share our work with a bigger group in our company, and release much more elegant, and friendly products to our users.
If you're interested in seeing how this style guide is applied to a real product, please check out a related project: Enterprise Control Room