Problem:
USAC’s (Universal Service Administrative Company) online tools and applications were not a part of a cohesive experience. As a result, users were burdened learning difficult systems and teams were not functioning efficiently.
Goals:
We set out to build and sustain a design system called Indigo. Encoded in HTML and CSS, this design system needed to create a visual language and foundational component library to support USAC program web applications and tools complete with documentation available to internal and external partners.
Process:
Reference Designs
We started with compiling page design concepts spanning products and platforms to normalize the visual language and component design decisions. The goal of reference designs is not intended to be explorations of project-specific details, but a reference for designing a visual language and identifying core components across products.
Prioritize System Parts
We conducted a workshop with the USAC teams including developers, program project leads, and design and UX to identify what parts the team would prioritize for this system.
As a result, we set the goal for V1.0 of the design system to build the foundation by creating a compressive, scalable visual language and build atomic components most often reused and combined to make user experiences. Our emphasis in this process was to emphasize data collection and displays through normalization of form controls and standardize UX patterns and best practices.
Components vs. Patterns
Critical to the success of the system was alignment with all teams on the difference in the parts we would be designing and building. Components are distinctive UI elements that are built to be used over and over throughout a product. They are most often actionable elements like buttons, input fields, selections, or tool tips.
Patterns refer to recurring elements or practices throughout a product, such as navigation, tables, notification, alerts, or modals. They are versatile and often contain multiple components.
Design, Develop, Document, Publish
The process to make and maintain Indigo required cross-functional collaboration. Using an agile approach, we set up sprints to include design critiques and regular reviews to keep tasks a manageable size and identify and address problems quickly.
Design
Design the parts to be included using Sketch and InVision.
Develop
Build and test HTML / CSS / JS for all variations of the part.
Document
Record the basic guidelines and uses of the part in a shared document and in code to ensure proper inclusion and adoption.
Publish
Create a page on the Design System documentation site for users to access the information.
How good are the parts?
Indigo’s QA process ensured that each item was:
High visual quality
Flexible to variety of content
Accessible
Cross-browser
Functional
Mobile-friendly (adaptive, but not yet fully responsive)
Result:
Within the organization, utilization of the system increased design and development collaboration. It also served to improve efficiency in developing new tools, leading to a more cohesive, higher-quality user experience.
Externally, Indigo presented a unified, single USAC to stakeholders and succeeded in simplifying the most high-profile systems with potential to touch millions of users. It created a foundation for building accessible and usable products.
Next Steps
We have big plans for Indigo's continued growth. The library is built in a way that with new releases they can be easily adopted into products and we're working to generate a backlog of new patterns and components to build. Legacy products are adopting elements of Indigo as part of updates, and new products are being built using the library. As tools and applications adopt Indigo they are receiving consistent praise with partners and users for their clean designs and ease of use, which further motivates future adoption.