As Intuit marched toward being recognized as One Intuit brand, the need for the products to speak a similar language arose.
The Intuit Design System team was tasked with the work of delivering a system that was flexible enough to satisfy requirements for each product team, while maintaining familiarity to unify the company’s design language. IDS served over 450 Designers and thousands of developers.
My primary role on the team was creating native mobile components and driving adoption in our community.
Designing components for native mobile
The process for each component project loosely followed these basic steps:
Audit of component use - Which Intuit apps are using it? How? What rationale did the original designers have?
Industry research - Any guidance from the Android or iOS platforms on use? How are other companies using the component?
Document specifications - Design the component, as well as provide usage guidance in documentation.
Team reviews - Does the component meet the consumers’ requirements? Any glaring issues to be addressed?
Quality assurance - Partner with developers to ensure coded component matches the specifications.
This is a simplified overview of the basic framework applied. I was involved in each step from defining the scope of work in the project brief through to testing the coded component against the intended specifications. The tools most used were Sketch for mockups, Abstract for file management and collaboration, and Framer X for interactive prototypes.
Banner, anchored
Banner, page
Tabs, fixed width
Tabs, scrollable width
The biggest work of being on the Design System was not creating the components; instead, it was serving designers and developers to ensure successful adoption.
Supporting the community
Like any other product or service, the ultimate success is not defined by the product alone - but how it solves problems for the intended audience. For us, our intended audience was both Intuit designers and developers looking for reusable components to accelerate their work.
The tool to facilitate working with designers and developers around the organization was Slack. We also leveraged Jira to track self-reported bugs and feature requests, but Slack was the primary channel consumers could interact directly with the Design Systems team.
In the Slack channel, we would have to field questions of all sorts - feedback, debugging, change requests, and more. Although we didn’t have a set process at the time to field community inquiries, I was sure to acknowledge the first message and get back with an answer within one business day. Resolving these issues were rarely something I knew or could solve alone. It typically required doing research into the intended design, asking dev partners for guidance, or searching for the right person to contact.
These small gestures kept the community engaged and opened an avenue that helped shrink our feedback loop. As well, it fostered adoption since the components were covered with support.