Instabot Design System
Establishing the internal design language for Instabot.io bot-building platform
Context
Instabot is a growing web-based chatbot platform for businesses. To build a reputable product, the product and development teams need a system to address design inconsistencies and inefficiencies. Without this system, the teams were losing time and effort with each new feature build (e.g. designer spends more time on maintaining styles instead of improving on interactions and UX improvements). To create a new system that’ll be approved and shared by all teams throughout the organization was the biggest challenge.
I led a proposal to create an internal Instabot Design System by getting buy-ins from key stakeholders, presenting the system to the team for critique, direction and inclusion, and then prioritizing on how to rollout the system incrementally in upcoming sprints.
My role was to thoroughly research and understand what design systems are and what are some of its best practices. Then, I worked extensively on drafting and sharing iterations of the system with the team.
Process
To build empathy at the start of the project, I carried out casual interviews with my product managers (2) and developers (2) to get preliminary set of requirements to answer questions such as:
“What common UX/UI components are you spending a lot of time spec-ing/developing each time?”
“What are the most glaring inconsistencies on the platform?”
After receiving team’s input, I used a problem statement to jump start project as it’s human-centered, broad enough to allow creative freedom, but narrow enough to be manageable: "How might we allow teams to design, realize, and develop a product with a single source of truth?
“How might we allow teams to design, realize, and develop a product with a single source of truth?”
Before I set out to actually do all the required research and design, I talked with the VP of Product and Lead Developer to get their official sign-off to undertake the project.
Next, I researched all I can about design systems and then shared it with the team. We decided to adopt the Atomic Design framework:
Atomic Design Methodology Diagram. B. Frost, http://bradfrost.com/blog/post/atomic-web-design/
I then layout the components in Adobe XD file (as not everyone works off a Mac) and upload the designs to Zeplin so the different teams can review it easily. After presenting the system to the team, allowing them to explore the file, and getting their feedback — I updated the design system several times to address their needs.
Once it was in a good place, the team and I sat down to figure out how to effectively roll out the design system to make the most impact on the platform.
Reflection
The biggest challenge was getting the teams to agree on a shared design system to speed up product design and development. I overcame this challenge by understanding the team’s pain points through interviews, actively including them for each iteration of the design system, and implementing the design system incrementally.
Since the team’s adoption of design system for four sprints (~2 months), members reported that they were no longer rehashing specifications for baseline UI/UX elements, delivered faster turnaround for builds as developers no longer need to estimate designs through trial and error, and the platform’s overall consistency jumped from 60% to 75% since implementation.
As the team’s only designer, it’s vital that I revisit it every quarter to keep it up to date as the platform evolves. While the master Adobe XD/Zeplin file was great for copying and pasting assets, the small implementation details and best practices for each component was still not crystal clear within the team. So for the next step, I’ll begin working on the second version of the design system (which has much more detailed documentation for each UI pattern) to improve the team’s efficiency.