Building a design system for a project management software startup


2 months


UI/UX Designer (4)

Engineer (2)

Product Manager




Adobe XD


Triyosoft builds software to help legal and financial organizations collaborate on projects. From January to April 2021, I was a UI/UX design intern at Triyosoft and 1 of 2 full time designers on the team. We were both interns.


While I was interning at Triyosoft, we were in the process of redesigning ~80% of the software. This provided an opportunity to simultaneously build a design system from the ground up.


~80% of design files in the organization are now linked to a design system library in Adobe XD with 100+ reusable components

It was now easy to update instances of a component across all design files by updating the library.

Cross-functional buy-in

Design team buy-in

While working on design projects for the organization, the design team found we were spending too much time creating and updating components in Adobe XD.

We agreed we were spending too much time updating component instances.

Instances of a component were not linked to the main component. Each instance had to be updated individually, which became repetitive. Within the second week of my internship, I was working on average 1+ hours overtime updating component instances.

We agreed we were spending too much time finding the correct styles for each component instance.

I was searching old design files for other instances of a component to find the correct styling. Because of minor inconsistencies, I often had to search for more than one instance so I could verify which styles to use. This process took an estimated 20+ min per component.

Stakeholder buy-in

To ensure the success of this project, we discussed cross-functional buy-in for our design system with the respective stakeholders and teams.

Management agreed they were spending too much time onboarding new design interns.

Because members of the full-time design team were all interns, design turnover at the organization occurred every four months. Managers on the product team noticed interns would ask or be confused about styling patterns or best practices. This often prolonged design onboarding by 1 extra week

Engineering teams agreed they were spending too much time asking designers for specs and assets.

Members of the engineering team noticed the handoff process was confusing. The team would chase designers down for missing assets. In a remote office setting, this delayed development by an estimated 15+ min per question.

The process

Design challenges + solutions

Challenge #1

Designers didn’t know what colours to use in their prototypes.


As we prototyped our projects, we noticed we were asking each other what colours to use so we could be consistent with one another while working on our independent projects. We realized establishing colours in our design system was a top priority and needed to do so before starting any independent project work.


Using Chrome developer tools, we conducted an inventory of all the colours currently used in the software and grouped hexcodes that we felt were intended to be the same colour. The inventory was used to create a final colour system of primary colours. We filled in the gaps as we prototyped if we required more or less contrast.

Challenge #2

As we built more components, our system was getting difficult to scale.


Some of components were making our system difficult to scale. For example, as we redesigned more of the software, we noticed the tile system we initially discussed could potentially blow up.


When this happened, we applied atomic design principles. We needed a tile component, but what was universal was the tile itself, not its contents. Tile contents could differ depending on its context of use, but border styles and states should be universal.

Challenge #3

Engineers didn’t know how to handle edge cases.


Even after components were documented in Adobe XD, we noticed engineers still had follow-up questions relating to edge cases, e.g. How might we handle scrolling behaviour in a dropdown menu? After researching best practices from companies like IBM and Google, we realized some components would need more detailed specs than others.


For edge cases deemed high-priority by our engineering team, we documented additional notes for their reference.



Because the design team was building the design system while working on our independent projects, we could simultaneously verify the usability and universality of our new components.

We noticed towards the end of our internship that questions from engineers could be quickly and successfully answered by directing them to the design system file. Overtime, styling-related questions decreased as engineers became accustomed to our single source of truth.


Taking the initiate to advocate for my own well-being as a designer

This wasn’t a project that was assigned to us. In fact, we already had a very intense workload and we were really worried how the team would react to our project proposal. But it was impossible to do good design work without a design system. We wanted to give our users a consistent experience, but simple UI decisions would take 20+ minutes when they could take seconds. Overall, I’m proud to have advocated for myself, while recognizing the needs of the organization, and taking those into consideration as well as we proposed this project.

Design systems are never really complete

The state of our design system is nowhere near IBM’s Carbon Design System or Google’s Material 3. But even these well-established design teams are constantly updating their design systems. As a product grows and evolves, so will the needs of the people who design and build the product.