Here, let me describe the process of creating a system for Soda, a PDF file editor, by Avanquest, circa 2025.
This story starts with a team that expanded a product’s toolkit over time, the interface (unfortunately) did not always keep their pace. Which meant outdated elements created a gap between what the tool could do and how it felt to use it.
There was a clear need for a single source of truth for visuals assets, that developers and designers could leverage to save time, which signalled the need for a design system.
My role: Process, alignment coordination, product design.
Context
When the initiative started, I realized the product lacked a shared understanding of its own structure, as it had evolved organically and without the practice of mapping user journeys or documenting the system.
Each product area had it’s own library, disconnected from the others, while guidelines existed mostly verbally, or had to be reversed engineered from the live product. This made the onboarding for new teammates hard and was often described as a “scavengers hunt”.To move forward, we needed to make the implicit explicit, so I facilitated workshops with key collaborators to narrow down the visual principles.
Process
The conversations helped us map out key guides and components, so we could act on them as a team. Each week we'd review new items, discuss what to add to the system, as I created and maintained a source file with bits of guidelines and patterns we could reference.
Developers checked feasibility and we'd adjust accordingly, rolling updates only into “maintenance” features. Meanwhile, with the PM and stakeholders I got the opportunity to start planning a bigger visual refresh and coordinate a rollout across an upcoming release.
Results
Because it got built incrementally, the system had the opportunity to emerge gradually through each platform's needs during new features or maintenance tasks, which kept it connected to the versions users were familiar with.
The browser environment for the editor was simple and new enough, so it was the first project to get the full refresh. After that when another team took on refreshing the desktop versions, we noticed their estimations reflected a quarter of the original timeline because the patterns established streamlined the tasks.
What the initiative covered
The project involved a mix of coordinating and putting in place design practices while creating a source of truth that documented patterns in visual format, one that PMs, designers, developers, and Scrum masters could use. Because of that, It had to function in different layers without disrupting existing libraries.
The work itself looked like this:
Aligned stakeholders on what mattered through workshops and UX materials
Surfaced the agreements everyone was already following but nobody had written down
Found where patterns broke and processes fell apart
Translated technical constraints into design specs
Partnered with designers, PMs, and POs to decide what got built and how we’d do it
Designed core components and patterns
Turned messy ideas into documented guides
Kept designers and other teams talking to each other
Adapting to the environment
To build robust guides that applied to the product, I took the task of mapping what existed across our projects, facilitated workshops to align on core principles, and created documentation, guides, components and patterns to serve as examples.
The impact of complexities
And like in the wild wild west of product work, a design system can't just take over, so rather than impose adoption immediately, we introduced the guidelines gradually through maintenance tasks with the dev team and the blessing of the Product managers, treating tasks as contained global UI updates. In other words, when teams needed to maintain features, the DS became both a resource and an opportunity to refresh incrementally.
Later on, we used a "tech core update" to release the new styles at full scale. This approach was slower initially but avoided resistance and prevented jarring change for users.
Take dialog boxes. The previous version had inconsistencies in how colour was used, different shades of blue throughout, and it wasn't clear which elements were active, on hover, or inactive.
It created confusion.
In the updated set, we standardized that and applied color treatment that transferred across product environments, refined styles, and updated how controls behave.
Here are some examples of before and after. In the dialog, the hover states weren't consistent, different treatments, shadows varied, typography wasn't aligned to a scale.
In the new version, we established rules.
We adapted hover states to become predictable, and unified background color, border treatment and shadows in order to sharpen the styles. Blue became the signal for interactive elements.
Final thoughts
A visual system's value is distilling what works and standardizing it. When teams align on what matters, they move together. Patterns built from many minds scale. It takes some work upfront, but saves time exponentially because the system is built for what the product actually need.
Something interesting I've noticed, when patterns are clarified and described properly, PMs and stakeholders tend to adopt them and become quality advocates in the process. The results then spread to places the design or dev teams wouldn't have reached alone, which is, in my opinion how great teams are born.
Thank you for reading, see you in the next case.