Designing for Scale with Design Systems
New Benefits in a non-insured benefit provider, which are supplemental benefits to traditional insurance such as telemedicine, counseling, legal and more. New Benefits is looking to become the leader in technology within the insurance industry with the ability to move swiftly, but with a lean development team. To maximize development efficiency, standardize their look and feel and build quickly they needed a governance tool that could manage front end development practices.
Multiple development teams, both on-shore and off-shore, build front-end components and processes inconsistently from each other due to lack of communication, poor requirements documentation and varying skill levels and coding preferences. This causes poor user experiences, inconsistent performance and greatly reduces scalability. A documented system of standardized components that incorporates various stakeholders as a board needs to be in place as the companies source of truth.
High level goals include:
- Create an internal system accessible to all development, design and business stakeholders
- Use project management tools, such as JIRA, to streamline approval process
- Include visible code for peer code reviews
- Ensure we are using industry standard tech stacks, preparing us for the future of technology
The primary audiences/users consisted of:
- Stake holders – The executive, design and development teams are largely responsible for managing the system
- End User – The end user needs to find the components aesthetically pleasing and easy to use
Role & Responsibilities
As the UX Designer on this project, I was responsible for the following:
- UX research and strategy
- Identifying, documenting and prioritizing features and stories
- Creating and presenting components
- Building interactive hi-fi prototypes
- Leading the off-shore and on-shore development team including architects, designers, and developers
- Quality assurance testing
- Ensuring KPI’s were met
Scope & Constraints
While the core team size, one designer and one developer, was a constraint that caused the project to move at a slower pace, the pro was that we were able to reduce confusion, focus on quality and create a completely cohesive system that was consistent from beginning to end.
The Creation Process
Atomic Design as a Source of Truth
To make sure we had a “guiding light” in creating the Design System, we followed one of many methods being the Atomic Design method by Brad Frost. This allowed us to create many components that could be manipulated at a granular level and even repurposed/reconfigured for another component build.
Because this was a valuable but new concept to the company, the risk was high and the initial investment was small being around 250k with a 12 month window. This allowed for one designer, being myself, to create the components and instructional document, one in-house developer and some offshore resources and in-house support if needed.
Some specific goals we set out to accomplish
Reduce front-end development time by over 50%
Reduce UI inconsistency by 90% or more
Reduce client-side load time by 50% (2-3 seconds max)
After creating the styles and foundational rules we started immediately to see the results in consistency, ease of use, rapid prototyping in dev, and more. This also was well recieved because of the in-depth documentation within Storybook which provided a visual display of the components, allowed dev members and others to interact with each components, and review the CSS and HTML code that made the componenent function.
“This has easily reduced my development time by more than half.”
Only Build What is Needed
The scope of the Design System’s phase one was limited to what was needed for the new and improved corporate website. This split the one project into three parts:
- Create the website content, wireframes and UI with internal marketing team
- Break out all of the components from final screens and create the Design System phase one scope
- Develop final website within live production evironment
The website served as a testing ground for the system with little pressure ue to non-existent publicized deadline. Internally however our deadline was March 31st, 2020.
Documenting the System
This entire project only matters if it is documented and managed by a governance team. In this case we used Storybook to document all of our components, code (pulled in from GitHub) and how to use information.
Allowing all stakeholders to see what was available in “developer speak” as well as lamens terms gave everyone involved the opportunity to review and approve of everything that was finalized.
Managing the System Through Governance
The governance team extends beyond design and development to the business stakeholders such as the Director of IT, President, VP of marketing and even a Customer Representative.
During each monthly meeting, each one of these individuals offered a unique perspective including technical, business, design and from the end user’s perspective. This allows us to create without a biased toward a singular opinion of what is or isn’t acceptable.