Miliarium Design System: ClickSoftware’s case study
Design System is one of the most effective tools to minimize the gap between design deliveries and the actual outcome in large organizations. It serves as an effective communication tool for designers and developers in the same organization and as a single source of truth for multi-interfaces products.
In this post, I will share the experience of the establishment of a design system at ClickSoftware. The purpose of the article is to encourage the establishment and implementation of such a system in other companies, thus improving one of the most significant factors in the development process, the communication.
Background
ClickSoftware was a global product company engaged in field service management and has been around for 30 years. Prior to its acquisition by Salesforce, the company had about 700 employees, 130 of whom were developers and 10 of whom were product managers. In addition, the company employed three outsource development centers (India, Russia and another center within the country) of about 40 developers.
Back in 2015, it was decided to migrate the company’s flagship product to the cloud, which later called Field Service Edge (aka FSE). Therefore, most parts of the product were essentially redesigned by an external design agency. In addition, ClickSoftware has been making her shift into an Agile development process, which meant a rapid development rate with frequent releases.
Over the following years, in the absence of a single maintainable style guide, many modules and features were added without been crafted according to a single source of truth. The implications were noticeable: prominent inconsistency across the system; mixed and incompatible color palette; different patterns for the same need; multiple font systems and so on.
The research
We had to come up with a solution that will support the needs of a company of such a magnitude and the Agile environment it was shifting to. The solutions examined were diverse and included the use of Invision Studio that supports code exposing and design management solutions; the use of Zeppelin for exposing the code from Photoshop or Sketch files; the use of Figma; and many more. All of these solutions were abandoned due to the fact they did not support real code production infrastructure, limited the flexibility of self-development and created a dependency on third-party providers. We decided to explore the use of a self-built design system.
We gained most of our knowledge about design systems mainly from web research by reading material developed by leaders in the design system field. The greatest inspiration came from Brad Forest, author of “Atomic Design”. In his book and articles, Forrest compares the user interface into a modular entity made up of atoms (colors, fonts, buttons), molecules (input box with label, page header), organism (forms, primary navigation, search form), templates (page parts) and pages (full pages).
In addition, we learned about existing frameworks such as Twitter’s Bootstrap, Salesforce Lightning Design System, Marvell Design System, GE Design System Predix and many more.
Our pain point
The design system's purpose was to facilitate and optimize Click’s development process. By doing so, succeed in coping with the following challenges:
- Size and distribution: The number of developers (~120) and their distribution (Israel, India, Russia) made the communication a real challenge. Basic UX guidance and UI interactions such as buttons, checkboxes and more had to be carefully discussed upfront the development process and carefully test after. Multiple meetings were held to guide basic UI behaviors that occupied many team members each time.
- Inconsistency: Due to the lack of clear and orderly Style Guide, the product has reached a state of multiple variants of the same UI elements such as buttons of different sizes and shades, many versions of dialog windows, fonts of various size and weights, and a general feeling that the product consists of dozens of products incorporated into one. Needless to say, this inconsistency is very damaging to the product experience and mentioned as one of the Nielsen Norman 10 Usability Heuristics for User Interface Design.
- Continuous delivery: As from the transition to the cloud and the use of an Agile methodology that enables the release of versions and bug fixes at a higher rate than ever, substantial pressure has been acted on the design and development teams.
- Accessibility: Due to the need for accessibility support according to the WCAG accessibility standards and the substantial time invested in making our products accessible, now this was a good opportunity to integrate accessibility into our product in both the design and the behavioral levels (Contrast, Keyboard Navigation, Screen readers, etc).
Architecture and strategy
Technically, we had to write a central CSS library that would be supported by many browsers and contain the code that defines the visibility of each element in the interface in addition to its behavior during different user interactions. In addition, the library had to be available for downloading and embedding in the development environment.
Strategically, due to the fact that the design system had to serve an existing product rather than an alternative visual language, we decided to follow the existing product design language in order to avoid more inconsistencies. We marked all the existing components and patterns we found useful and to which we believed we should stick.
The design and development process
The development turned out to be much more complex than we expected, with elements such as dropdown menu and date picker requiring careful consideration of both the functional level (JavaScript integration) and accessibility aspects (keyboard navigation, tooltips, etc.). Due to the complexity of developing such UI elements in parallel to the urgency of developing additional features, it was decided to focus on elements that did not require a significant amount of work. The first elements were the buttons, the checkbox, the radio buttons, the toggle buttons, the loaders and a number of dialog window types.
We also created a robust sketch file that contained the UI elements on all states for designers and product managers for rapid wireframing. Those elements could be of much help when trying to deliver requirements and stay aligned to one experience. We used Zeplin to communicate the exact specifications for each UI element.
Color palate
Our product’s color pallet was a combination of two libraries (Flat Color and Material design). A uniform color palette was selected to avoid abnormal changes in the existing system. Out of this logic, we determined our primary brand colors (blue and yellow), a palette of grayscale for backgrounds and text and a varied palette for data visualization.
Font system
Prior to the font selection, FSE used two fonts family determined by the OS it was running in (Ariel for Windows and Helvetica for MacOS). This separation caused a great deal of inconsistency and usability issues such as different font-weight that led to readability problems, text swiping and so on. We chose Roboto to be our primary font family and Ariel and Helvetica as the fallbacks. Roboto is a well-known web font family that supports multiple languages (which was a mandatory requirement) and can be used in any OS.
Icons
FSE icons are a combination of the widely used Font Awesome library and icons made by Click’s UX team. Each font system implementation and update method is different, so we chose to preview the two separately in order to support the developer's way of use. Each icon includes the class name as been used in the production environment.
UI elements
The UI elements were selected in the same way as the color palette. The elements were designed so they would not look much different from the overall look and feel of the system (so as not to create another inconsistency). In order to improve the current look and feel we provide a bit of a design twist, for example, the buttons received a border-radius of 2px in their new design compared to a sharp corner in the previous version, dropdown menus were designed in a slightly different shape and radio buttons were also updated.
Templates and pages
As mentioned above, we followed the “Atomic design” methodology and issued what we considered to be the template section. We decided upon the structure of the main dialog window and issued a consistent set of templates for representative and diverse needs. We chose to focus on the most common and basic patterns in the system in order to provide the most essential ready-to-use templates.
Code
Without dive into many technical details, the system's purpose was to ensure consistency, therefore the code should support it as well. The color palette mentioned above was designed according to the UI needs, which means that each color was carefully included in the SCSS custom property list. by following this method we increased the chances for consistency as long as developers embrace the use of variables instead of hard-coded Hex values.
Micro Copy
Language and tone of voice are critical parts of building a positive user experience. Every element that includes textual content has been reviewed by a technical writer who ensures that the written language is according to the company’s voice guidelines. Examples of this can be seen in the validation content in the various forums, in the use of capital letters in the dialog window titles and even in the explanations for each UI element across the system.
How to get resources for such a project
A project of this magnitude can not be done alone, especially, in conjunction with ongoing work on new features, maintenance of old features, endless distractions and “more urgent” things that require immediate attention and support. In order to carry out the project, a number of colleagues that were familiar with the urgency for establishing such a system joined forces for research work in parallel to the ongoing work. The goal was to expose the problem clearly to the management, to explain the chosen solution and the reasons for its election and to integrate the development as a defined time during the sprints ahead.
As a prelude to convening with all the decision makers, personal meetings were held with each one, so that the kickoff meeting would be practical and achieve its goal (development hours) rather than presenting the idea in multiple participants meeting and creating confusion among some. The kickoff meeting included an organized presentation of the problem, the reason for its creation, presentation of the suggested solution, evaluation of the hours and resources required for the development of the system and a PRD (Product Requirement Document) according to our company’s accepted format.
Miliarium?
Miliarium, which means a milestone in Latin (miːllɪˈaːrɪʊm ˈawrɛʊm), known to be a monument in the Roman Empire that all distances were measured relative to it. It was erected by Emperor Caesar Augustus near the Temple of Saturn in the central Forum of Ancient Rome.
We take the establishment of Miliarium, ClickSoftware’s first design system as a substantial milestone in the ongoing effort to establish ClickSoftware as a customer experience leader for FMS (Field Management Software).
Advocation
As an opportunity to share with the local tech community what we learned from the process, we hosted a design meetup, called “UX at Scale”. Among other lectures, I told our story of achieving our goals.
Conclusions
There is much to consider when building a design system, from the level of the technical architecture to its design challenges and limitations. On projects such as this, I strongly recommend designating one person to act as a product manager and be responsible for the implementation of the system and ensure that awareness is raised for it among the decision-makers in the organization. It’s very important to allocate stakeholders within the company who will contribute to the realization of the project from all parts of the process (designers, developers, and product managers).
Special thanks to all of those who contributed to the realization of the Miliarium.
