Automox Design System
Automox is a security start-up that tasked me to create a unified design language. As a burgeoning company they were evolving with many potential paths. This was the biggest challenge. Shifting business models and capabilities means specific goals are less clear, but the benefits a custom design system go beyond branding to serve specific goals. At first glance improved branding was about the most this design system could accomplish over any off-the-shelf options. However, as I gathered more information from Automox employees, a different problem to tackle was revealing itself: could a design system address their specific moment in this shifting future?
The final goals of this design system:
make it easy to evolve
lay some foundations of good UX
make it easy to participate
kick it off with accessibility in mind
make it POP (kidding, but there is a branding element)
make it easy to digest
Examples of the deliverable below:
Figma, used by designers and front-end devs alike, acts as the single source of truth.
Highlighting “What is interactive” helps set mental models regardless of future UIs.
Generalized but applicable guidelines for designing pleasurable digital tools.
Putting accessibility on their radar from the get go.
I set this Element format to be concise and predictable - but the “General comments” section garnered the most intrigue. People felt good about the ease of participating.
For some universal tools I dove deeper and taught the front-end devs how to measure and inspect in Figma, streamlining documentation and future hand-offs as well.
My hand-off message to the director of UX:
I would leave you with this final note in terms of the Automox Design System: less is more and stick to it! There will be many times designers want to break the rules or expand what's possible, but I urge you to stay strong and lean toward finding solutions that are already supported. Evolve what you need to evolve of course, but I have seen the slippery slope and the more variations allowed the less beneficial a design system becomes. Paradoxically I have also seen documentation and edge cases become so robust that the design system in whole becomes less effective - if you allow designers some wiggle room and they do something poorly, treat those as teachable moments and not reasons to create more rules within the design system.
Here’s some unsolicited feedback received out of the blue:
The design system is awesome and I'm having a blast working with it and getting it implemented!
You’ve received praise from our marketing team on the foundation you started by the way!
Poking around note: Figma requires a desktop browser