.png){kind=small}
January 2023- March 2024
Product Designer
.png)
Our vision was to revolutionize the biotechnology space by accelerating real-time automated biomarker endpoint analysis for clinical data. After Series 1, we had developed a computational platform that ----
But as the platform grew, so did our inefficiencies and design inconsistencies, which marked the beginning of this project.
The end product of this project involved developing a design system for the ecosystem of products. However through the process, I strengthened and improved collaboration, design education and product planning.
Like most start-ups, we had adopted a "functionality-first-approach" which allowed us to meet the demands of our growing customer base.
After conducting a retrospective, I uncovered that the communication loop between design and engineering was fragmented. Due to our short release cycles, engineers and designers quickly built components in silos focusing on meeting deployment deadlines.
The problem: We were building without a guiding design principle.
This impacted:
Scalability -Our solutions couldn’t scale due to a lack of guidelines and documentation
Workflows- Both design and development processes became time-consuming.
Collaboration- Design and engineering did not share a source of truth, which led to inconsistencies
Product Cohesiveness- Products within the ecosystem became visually disjointed.
The design team took the lead on this problem space and framed our design question as
“ How do we unify engineering and design environments to create consistency within our product and improve work efficiencies?”
Unifying design and engineering environments came with the need for understanding the product roadmap, resources and constraints needed for this effort.
Taking a look at our Monday board, I analyzed the company's product roadmap for 2024. My goal was to identify which quarter and within which release we could fit this effort into. I recognized that all 3 cross functional team involved in the effort had lower bandwidths for the 4.9 release.
.png)
Working with my product manager, we identified Quarter 2 and release 4.9 to be the best opportunity to release an MVP state of the system as both design and engineering had less tasks during this period.
With only 2 designers and 2 front end engineers on the team, it became apparent that our solution needed to be time effective and easy to implement. This was especially important for engineering counterparts as they were already falling behind in certain releases.
The other designer on the team and I began to research methods and tools that best fit our needs. I led the research efforts with a goal of prioritizing solutions that required low level of engineering and design effort but had a huge impact.
The first option I explored was utilizing open-source design systems. This solution offered us the benefit of efficiency, reduced maintenance effort, and established UX testing on basic design patterns and components. However, there were a couple of drawbacks.
Complex product - Open-source design systems could not support our designs. With the need for web-based data visualization and exploration tools we also needed customized components.
Incompatible tech stack- Many of the open-source tools did not fit into the existing tech stack used by the engineering team.
The second option was building a design system from scratch. With our product still being in in its infancy stage, we had a unique opportunity to define our own patterns and components.
However, with the time constraints and labor shortage discussed above, it was not the most feasible.
But there was a unique opportunity between both solutions
Although neither solution fully met our requirements on its own, combining them resulted in an ideal solution. When examining the design system from a broader perspective, we identified two primary components: atomic and composite.
Atomic components serve as the foundational elements of a design system and necessitate exceptional UX craftsmanship and strict adherence to design standards. Recognizing the challenges of creating these from scratch, we opted to utilize existing design systems for our atomic components.
For our more intricate features, such as visualization components, we will build them from scratch using these atomic components. This approach ensured that even our composite components maintained consistency and adhered to a design principle.
.png)
Once I had crafted this strategy, I shared it with the team during our alignment meeting to gain buy-in and, more importantly, to increase visibility about the work ahead, build trust, and create a shared understanding of the value and impact of the design system.
As we were working on defining the strategy for the design system, the product product team had to depioritize the effort in order to fit new customer feature requests into the release.
This meant that we no longer had a dedicated time commitment and resources.
However, knowing the importance of the design system on our process and product, I began to brainstorm.
“How do to implement a design system without dedicated resources”
I realized that instead of dedicating a separate effort towards building the design system, we could integrate it gradually within our existing engineering processes.
This "sneak it in" approach involved the engineering "feature releases" as opportunities to incorporate parts of the design system into the product.
This strategy worked well because of the nature of our product. Feature requests were often complex and required new sets of components, providing the perfect opportunity to implement parts of the design system.
For the engineering team, no extra time was spent in development since these components were integrated during their regular feature development. For the product team, features were still delivered on schedule. Lastly, for the design team, a consistent design principle would be established.
.png)
The first step in building the design design system was to conduct a component audit of our product and identify all the existing atomic and composite components.
Once the audit was completed, I began to prioritize components to tackle with the other designer on the team.
With the “productivity scale", we ranked components based on their impact on users' experience and workflow efficiencies. Engineering was looped into this process to understand better the level of effort required to refactor and integrate components into the codebase.
A huge aspect of the engineering and design collaboration was understanding the syntax and patterns of front end environments (Materials UI and Tailwind) in order to translate that into the designs for easy adoptability of the design system.
.png)
With previous coding experience, I was able to understand the codebase quickly and used their open-source resources to ramp up my understanding of the front-end environment.
The next piece of the design system was building the foundation collection of our platform by creating primitive and semantic tokens.
The collection served as the building blocks of our UI. The primitive tokens were standardized against the engineering codebase and stored raw values such as color hex values, corner radius, font weight, etc.
Conversely, the semantic tokens feed from the primitive collection to define how variables are used in the UI.
I made the decision to keep the foundation's collection simple and narrow, focusing only on current and future variables. To reduce the complexity of the design and development process, I kept tokens and variables unambiguous and familiar to both engineers and designers.
The foundation's collection was completed with accompanying documentation after nearly two months of dedicated effort involving thorough review, revision, and testing.
Accessibility checks -I conducted accessibility checks on our colors, components, and text size against the WCAG A, AA, and AAA requirements
Variable Library- Our old designs did not support variable states and interactions. However, working with engineering and product partners provided exposure to varying contexts.
Visualization Support- In addition to supporting the UI on the platform, I also created component libraries for visualization tools
The first set of components that were published were atomic components. By leveraging open-source tools, we were able to refactor existing components to conform with the changes made.
The composite components, on the other hand, required more processes. Because these components were more complex in nature, building them required constant testing and iteration to ensure that they adhered to industry patterns and guidelines.
As the only designer working on building the components, I sought a partner on the engineering team who was willing to commit extra time to ensure proper quality tests were conducted.
We collaborated outside work hours to test components on our dev environment using smoke test data, allowing us to identify error states, missing variables, interaction issues, etc., before the component was published.
A crucial part of this process was active documentation. Because I had worked on the design system alone, I documented every rationale, pattern, and behavior of everything I had worked on. I also leveraged tools to provide engineering specifications and guidelines on building components and took ownership of the system's governance.
.png)
After completing the designs and passing them to the engineering team, I updated our audit documentation to note the release of any new atomic and composite components.
This allowed effective monitoring and governance of progress and change.
I decided to postpone major updates, such as changes to text styles, colors, and button designs. These significant changes could potentially disrupt the user experience, so the plan was to introduce them at a later release cycle. This careful rollout strategy requires additional resources to ensure a seamless transition for our users.
Efficiency - The design team experience a 50% reduction in turn around time from 2 weeks to 1 week. The design system allowed us to create artifacts that were standardized and consistent.
Resources - In addition, we improved the quality of design resources. The design system allowed us to create well fleshed out wireframes, interactive prototypes, and style guides.
Product Mapping - Lastly, implementing our design system enabled us to discern different feature states, empowering design to comprehensively grasp the product flow and user experience.
Reduction in JIRA tickets - There was a 60% reduction in the number of JIRA tickets created during testing that were related to the UX and UI of the platform.
Efficiency - Not only did engineering record spending less time building components, development also became more efficient due to clearly defined reusable components.
Autonomy - Engineering now had access to accessible libraries with contribution guidelines.
Scalability - The codebase had a stable foundation to support new product lines and features.
.png)
.png)