Enhancing Data Table Components for Scalable Design
Supporting designers with easy to use and scale table components in Figma UI library to design data table experience for a rich, dynamic SaaS platform.
Primary role
Product Designer
Project duration
3 months
Company size
300+
Industry
Market research, B2B, SaaS
Tools
Figma, Google Doc, Jira, Confluence
Main collaborators
Design, PM, Engineering
Executive Summary
Prior to this project, it took 1hr+ for Suzy designers to design one data table using assets provided from the UI library. There was no consistency and scalability in the deliverables. I flipped the challenges by not only adding but advocating the scalable and flexible table components and its correct adoption in the design system library for all designers, significantly boosted design efficiency and product development speed.
Metrics of Impacts
Our focus was to improve designers experience by allowing them to design more efficiently for data heavy projects, we evaluated success through:
🚀 Pre- and post- design speed
⭕ Component adoption and error rates
🙆 Component consumers overall satisfaction
🔎 Design implementation accuracy
These are snippets of what we accomplished:
500%
Design speed
75%
Component adoption errors
80%
Usage satisfaction
200%
QA process
Visual Evidence of Impacts
Stakeholders from diverse disciplines contributed consistent components to the design library through smooth collaboration. At the same time, all designs were implemented in the product with pixel-perfect accuracy, elevating the visual and experience quality without compromising release timelines.
Styles and components consistently designed and documented
Platform look and feel significantly improved benefited by consistent components adoption
Read the short version of the story below 👇
Stepping Into Big Ambitions With Bold Responsibility
Imagine being the sole individual contributor responsible for establishing and managing our first design system, built on top of a 6-year-old product loaded with legacy tech debt. The initiative came with high expectations: to support full-cycle Agile development across 5 different product teams.
Our product scope was massive compared to the team's bandwidth: including 1 B2B SaaS product with 20+ unique features for S&P 500 enterprises and 1 B2C product serving 1 million+ active users.
An Urgent Call for Design Systems
Reducing legacy tech debt would be time-consuming, while leadership expected faster product quality improvements and scaling to new features.
In legacy products, there were over 25 different button styles!
To move quickly, we adopted a federated contribution model that enabled all designers to build components. However, for our compact, multitasking team, the federative contribution model created tension between speed and quality.
The Catalyst for Change
Initially, the federative model delivered components on time. However, behind the scene, it was accumulation of speed over quality and it became clear this model was unsustainable. Contributors were overwhelmed, product quality declined, and frustration among system consumers toward design system initiative grew. I recognize the warning signs: opposition, inefficiency, and burnout. It was time to act.
"Component were designed fragmented without any order, I would rather build something myself than spending time figure out how to use them properly."
M.B.
UX Designer
"The workflow is very obscure. We always found it confusing by the different development requirement from each designer."
S.H.
Senior Front-End Engineer
How This Was Affecting the Business?
Nothing more convincing than quantifying the impact. I partnered with engineering, business analytics as well as customer success team to calculate the cost of our flawed contribution model. The data clearly showed the business consequences, helping leadership understand the urgency for change beyond anecdotal complaints.
30%
UI quality complains from clients 😟
50%
Designers' system adoption confusion 😥
70%
Design-dev clarification meeting 💬
30%
Project rework after Beta release ⭕
We aligned on one conclusion:
"Something had to change."
Breaking Down the System Problem
I realized the component contribution model was too abstract to fix all at once, so I deconstructed the system problem into smaller factors to inspire actionable solutions:
I identified three key determinants in the design system contribution model: people, file setup, and process. The analyzation inspired me to interview and survey cross-functional partners involved, from designers, engineers, and product managers. Below is that I learned:
👦 Talent Misused Is Talent Wasted
We expected designers from different specialties to contribute at the same high standard, pushing them outside their strengths, under pressure to even move quickly.
🗃️ An Environment That Worked Against the Team
We used a single, monolithic Figma file, which created a risky, unscalable environment. This reduced clarity and ownership, and increased the chance of errors and file breakdown.
📋 Many Hardworking Hands, No Common Thread
We lacked structure in how design, engineering, and product communicated. Inconsistent terminology and informal follow-ups made even a mature startup feel like a chaotic workshop.
Understanding the Constrains
I shared initial thoughts to the team but realized there were few constraints that inherited from the state of business and wishes from the leadership.
❤️ Respecting team bandwidth by avoiding extra workload to a busy team.
🤝 Growing the design system together and letting everyone take a piece of the design system responsibility to build team consensus and growth.
🌎 Adapting work mode, the contribution model should be designed for our remote first, globally distributed team.
🖥️ Prioritizing user experience over design system perfection. The system was meant to serve the best user experience on end products.
Focusing on the system factors making up the problem:
How can I improve the contribution model across these three areas?
Assigning Responsibility Where Talent Thrives
To get everyone involved while maximizing individuals' potential. I created a dual-role component design model: Builder group(Product designers, engineers) were responsible for component construction with high technical fidelity. The tester group(UX designer and managers) focus on audit, experience level feedback, and validation. This model ensured the right people worked on the right tasks, raising quality and efficiency without extra burden.
Laying the Groundwork for Sustainable Growth
All processes should be able to scale. To make ours teachable, repeatable, and future-ready, I documented the key stages of component design, focusing on audit workflow and build criterias. This created a reliable foundation for consistent collaboration and seamless onboarding as the team expanded.
Check out the component design quality after re-assigning the responsibility!
This aligned contributions to individual strengths while encouraging mutual learning. Over time, the gap narrowed as team members gained cross-functional skills.
"I like now being able to focus on design audit and pointing out UX problems upon my strength, we are able to consider component design with more comprehensive considerations."
K.K.
Senior UX Designer
"I can see the components built are more consistent and much more scalable than before, it finally brought efficiency to my design process."
K.S.
Senior Product Designer
Setting Up Risk-Free File Environments
To reduce risk and give contributors clearer ownership, This model ensured the right people worked on the right tasks, raising quality and efficiency without extra burden I researched how mature design system handle SaaS product level of complexity. I adopted a headless file setup, where each component lives in its own dedicated file, allowing contributors to focus on their tasks without interfering with others, while still maintaining centralized oversight of the full library.
Extending Structure From File Level to Component Level
Realizing the opportunity, I did not stop at organizing the overall file structure. Additionally, I took it a step further by templating the internal structure of each component design file. Each template included sections for audit checklists, asset organization, and engineering inspection. This gave contributors a clear, repeatable workflow, reducing ambiguity and ensuring every component was built with the same level of care and consistency.
Standardizing the Process to Bridge the Component Adoption Gap
Imagine being the builder while multiple teammates request new components to be added or updated all at once, which request should be processed first? This was a critical and recurring problem to us. On top of that, a pixel-perfect UI library has little value if it isn't implemented correctly on product. To truly drive adoption, we needed a standardized process to prioritize and deliver components effectively.
Business driven prioritization
After discussions with department leads and managers, we introduced a business-driven metric to evaluate each component request. It was based on two key factors: project impact and development effort. This framework gave us a clear, objective way to prioritize which components to work on first, ensuring we focused on what mattered most to the business and the team’s capacity.
We implemented the prioritization labels directly in Jira, giving all stakeholders clear visibility into the status and progress of each component request. This transparency fostered better alignment and collaboration across teams.
Setting up the bridge between design and engineering
I collaborated with engineers to create a standardized design handoff template that highlighted the information such as component specs, structure, and variants. To reduce manual effort and ensure consistency, I leveraged the DesignDoc (Spectual) Figma plugin, which significantly streamlined the documentation process.
With 30% of our engineering team outsourced across different regions, time zones, we always missing ways to communicate effectively. To ensure effective collaboration in our global remote environment, I set up dedicated Slack channels and created communication templates using standardized terminology to guide cross-functional conversations. I also introduced a development status page in Storybook, providing all stakeholders with a centralized source of truth for tracking component progress and implementation.
Evangelizing, Implementing and Refining the Vision
I believed in transparency and iteration over "big reveal" moments, especially for something as collaborative as a design system contribution model. Success depended on team alignment and shared ownership. To build trust and momentum, I shared progress and learnings daily in Slack, hosted weekly syncs, and actively participated in design sessions across teams. These efforts helped foster comfort with the new model and sparked enthusiasm not just among contributors, but across the company.
After we implemented the new contribution model:
Where Did the Solutions Take Us?
More Consistent Product Experiences
The systematic change to the contribution process created a ripple effect across teams. Streamlined component design made collaboration easier and engineering handoff clearer, leading to better-built components and, ultimately, a more consistent, user-friendly product experience.
90%
UI quality complains from clients
"Suzy’s user-friendly intuitive interface is significantly cleaner and more easy for us to navigate and extract valuable insights."
C.A.
Senior Marketing Manager from Sachi&Sachi
Faster Development Cycle
All new design system components were built to minimize cognitive load for both design and engineering teams, enabling faster product builds and easier iteration for component consumers.
200%
Design-dev clarification meeting
"Yay to the meticulous process Eric helped to implemented, developing and iterating design files are with much more clarity."
B.P.
Creative Technologist
Maturing as A Team
Hardworking teammates finally felt like a unified team! I received messages and shout-outs from cross-functional partners who shared how this initiative improved remote collaboration and eased their workload. The team felt more supported and confident, and that made all the difference.
30%
Designers' system adoption confusion
70%
Collaboration satisfaction
Reflecting on the Successful System Solution
The success of this project came down to two key principles: first, breaking down an abstract, complex system problem into actionable parts; and second, resolving the most critical obstacles through solutions tailored to our team’s context. Just as important was maintaining frequent, open communication with collaborators, that allowed me to design standards and processes that truly served our workflow.
Every team and organization is unique. A successful design system isn’t just about best practices, it’s about deeply understanding your people, your product, and your business needs, and shaping the system to fit them. That’s what ultimately drives adoption and impact.
Thank you for reading!
I would love to know what you think! Feel free to hit contact below and I am excited to learn from your feedbacks.
