Designing and Maintaining a Component Library
- Year2019
- CompanyADP
- PlatformBrowser/Mobile
- RoleUX Designer
Background
During an earlier project to move mobile development for StandOut in-house, we faced the problem of different engineering teams building very similar functionality. Although the design team used a Sketch Symbol Library to keep things consistent across Sketch files, this wasn't always carried over to development. There was a lot of duplicate styling, functionality, and general lack of consistency between sections (ex: there were multiple versions of navs, tabs, and modals), which created further slowdowns when we identified bugs or added new functionality. This challenge prevented us from iterating on features as quickly as we would like.
I felt that the critical problem was a lack of planning and communication between design and engineering, and I thought focusing on building reusable components would go a long way to accelerate development, improve consistency and maintain the sanity of everyone involved. When it came time to refresh the StandOut desktop application to reflect the changes we had made on mobile, I lead an ad-hoc team (the Integrated Design Team) which lead the effort to identify, design and build out the initial set of components and establish a workflow for maintaining them.
Process
The Integrated Design Team was composed of an engineering team-lead, 2 front-end developers, and myself. Since everyone involved was comfortable with Agile, we use the rituals of a daily standup and weekly grooming sessions to run the project. After doing research, we decided to use Bootstrap Vue as a starting point because we were already using Vue on the front-end, it had a good base set of components to start with, and it followed accessibility best practices (accessibility was an essential goal for the project). Design had already created wireframes for most of the StandOut desktop refresh, which we used to identify the components and layouts we would build.
The team-lead and I acted as temporary Product Managers, writing a backlog of stories and running grooming sessions to estimate the work involved. I would add designs to the stories isolated from the overall design, focusing on detailing all the states and basic functionality without worrying about the more complicated business logic that would be worked on later. The engineers would either modify a Bootstrap component or build an entirely new one. After that, we would review the built component for functionality and accessibility.
Results
The initial output of the team was a component library page to showcase and document components for engineering as well as some additional documentation in a Wiki. This way everyone in engineering, design, and product would have visibility into what components exist and how they should behaved. After that, the team disbanded, and the engineers went back to working in their original scrum teams.
Going forward, we established a simple approach to maintaining components once built. If there was a bug, we would write a new story, and someone from the IDT team would grab it as part of an upcoming sprint. If there was missing or new functionality that we didn't initially plan for (ex: we wanted to add show password functionality to the password input), we would write a new story, and the engineer implementing the component in a feature would work on it.
Takeaways
The main benefit of the component approach was that it allowed engineers to continue working on a feature even if a component wasn't 100% finished. We could add functionality or tweak the styling later on in the project. Components were a time-saver when we changed how we handled disabled buttons to make them accessible to screenreaders, or when we tweaked the styling of our chart components to make them more legible.
Another benefit was that by isolating a component and identifying all of its states during the design process, it was easier for engineers to implement them than when the components were part of a mockup, which could sometimes result in unhandled states. Also, since the components were decoupled from more complex business logic, it was much easier for me to go in and make design changes directly in the code, and also less stressful for the engineers reviewing my code.
Because of these benefits, components became the shared language between design, product, and engineering. I would wholeheartedly advocate using an approach like this going forward.
While the project was a success there are still improvements to be made. I am currently working on projects involving:
• Bringing components into our mobile app and administration and reporting tools
• Introducing design tokens to unify colors and spacing across the organization