OTORIO / OT Security Platform
Building a design system
and establishing a shared workflow
Mapping the existing workflow, defining a phased rollout, and building a shared Figma library with R&D.
- Sketch, Zeplin and constant sync meetingsOne Figma library for design, product, and R&D
- No reliable source for developersReady components that all development teams used
- A product rebrandUpdating the system was straightforward
I built the design system end-to-end.
OTORIO is an OT security platform, later acquired by Armis in 2025. I was solely responsible for the system and led the work.
The work covered three connected parts:
- Migrating from Sketch to Figma
- Rebuilding the component library
- Establishing a shared workflow across design, product, and R&D
The result was one source of truth for design, product, and R&D.
Design was a bottleneck.
Every delivery required multiple QA rounds, updates had to be made twice across two tools, and developers had no reliable source to work from.
Required constant sync meetings.
Slowed every delivery.
Caused discrepancies with stories, adding QA overhead.
Mapped what was broken before deciding where to start.
Gaps before components.
Alignment first
Expectations aligned before a single component was built.
Outcomes first
5 design principles defined together with product.
R&D from the start
Developers were part of the process early, not handed a finished system at the end.
From gaps to rollout.
I worked with the VP Product, the VP R&D and the development team throughout, to work out with them what was realistic. Beyond the components, I built a workflow guide and a Figma training for R&D, so developers understood the why behind decisions, not just how to implement them.
The plan was to roll out in phases. I then saw that not everything could be implemented, so I changed the approach, with Product's agreement: components were implemented together with the features being worked on, not systematically as I first planned.
Several tools, no single place and no orderly procedures, which led to bugs and a lot of development time.
Map the gaps first, rank components by how often they appear and how important they are, and check each rollout with R&D.
Ready components that all development teams used.
A dedicated Risk palette for security severity.
Colors & Typography
Five severity levels: Critical, High, Medium, Low, No Risk. One font family across all text levels, consistent scale.
Grid
12-column grid at 1920px, 64px margins, 20px gutters. Applied directly to the OTORIO dashboard: the grid isn't theoretical, it's how the product is laid out.
Component guidelines
Every component variation documented.
Five principles to help the team make decisions without escalating to design.
-
Focus
Minimize irrelevant data, provide smart defaults, keep the experience simple.
-
Consistency
Familiar patterns, standard icons, uniform terminology: reduce, reuse, don't redesign.
-
Efficiency
Build infrastructures, not islands of features.
-
Progressive complexity
Simple flows for new users, advanced options for experienced ones.
-
Meaningful copy
Users should always know what will happen before they click.
One place for design, product and R&D
Before, Sketch files, Zeplin updates and constant sync meetings kept the teams apart. Now they work from one Figma library, and four months into the project it became the single source of truth.
Developers build from ready components
All development teams used the ready components.
A rebrand that was easy to apply
When the product went through a rebrand, only the colors had to change. Because everything in the system was already organized, the change was easy to apply everywhere.
"I understand what to do from Figma, so I don't need to ask you any questions."
Senior developer
Getting people invested in the system was as important as building it.
The components were the output, the real work was convincing people it was worth doing, understanding what each stakeholder needed from it, and building enough trust that they'd actually use it.
I planned one thing, and in practice had to adapt.
When there was pushback, it taught me how to still insist on what I knew would improve the product.
I had planned to extend the system into Storybook so R&D could implement independently. The team did not have a front-end developer, and resources went to other work, so that part remained outside the delivered system. Changing habits takes time. Getting developers to trust one source of truth was already a significant shift.
