Phontastic
Phontastic Design System
I initiated and am currently leading the development of a design system that helps unify the user experience across our product line, and improves the collaborative process between the UX team, dev teams and test team.
We are in the middle of this work, and though we have reached several important milestones, a lot of work remains to be done.
Deliverables
Design component libraries, color palette, icon font, documentation, term base, website design
Medium
Adobe XD
Confluence
Flavors
iOS apps
Android apps
Website with old code
New websites
The Journey in A Nutshell
Our design system started as a small UI kit for apps. But it slowly branched out to more products, onto more collaborative surfaces, and seeped into more processes involving more people.
Audit and First UI kit
As most designs systems do, ours began with an audit of the existing UI patterns in our products. They were many and inconsistent, plus we had about three different style languages.
The first UI kit focused only on apps for Android and iOS, because that was what we happened to be building most of at the time.
After some design system research online (this was 2018) it seemed that basing our style and principles in Google's Material Design would be the easiest way to get started. One of the main reasons was that it was constantly evolving with patterns, a lot of documentation and theory. That meant we did not have to create everything from scratch, and we could search, read and copy until we learned the principles.
By Demand + One Project At A Time
The design system has always been something we work on part-time, along our regular work. So we make most of our progress during projects on customer-facing products. Though it is slow, it works pretty well, since we immediately get to implement and get value out of what we add to the system, and it helps us communicate better during projects.
Growing Through Allies
We found that the key to keeping momentum in this work is to find people who truly think it is fun, and make them stakeholders. We have found at least one in every team, and they could do some of the evangelizing for us.
For me personally, getting a designer colleague was huge; both in terms of output but also the need to create and maintain structure in the processes and tools we are using.
Design Libraries
To speed up our design process and ensure consistency in the design specs, we created libraries of UI components and styles, that can be imported and used in any design project.
We are regularly designing for Android, iOS and the web. Also, we have one older web UI with some design restrictions that don't apply to our hot new web projects.
So our components naturally have to take on four different "flavors" if you will, and we decided to keep their components in separate libraries, which makes them easier to use for the separate projects.
By extension, we also have separate libraries for font styles, colors, icons, and illustrations.
Icon Font
We went from regularly exporting PNG icons in about eight sizes, to creating one single dynamic icon font. It was immediately adopted in new web projects, our existing apps and all design work. It got people excited, and was a boost in cross-team communication.
We decided early on to base our icon aesthetic on Google's Material Design icons.
Many icons are from that open icon set, but we also make our own in the same style.
Sharing Documentation
When the design system started living in processes outside our Adobe XD component library, it was time to consider who the users were and how they wanted to contribute to or access it.
Library of Web Components
In 2021 we launched version 1.0 of a live code library of reusable, adaptable components and styles for our web applications. It acts as a starting point for our web developer colleagues and links to other part of the design system.
My UX team was responsible for the website design, and one front-ender coded the site and the components it contains. The library is still in its infancy, but we have already used it for smaller web projects.
General Information and Guidelines
The best way we found of sharing information about the content of the design system, was to document it in our documentation tool, Confluence. We made a new space, just for this documentation.
It creates some extra work, but it is easy for people company-wide to search, access and follow. Also, no coding skills or special permissions required for editing.
Term Base
Confluence also worked well for starting a term base, but what worked for keeping it going was agreeing on the right process with the right people.
It started small: two designers and a product marketer who was also responsible for managing translations.
First, we wrote a list of who else would be contributors and who would be consumers. We wrote user stories for them and then created a table, with content from the translation files.
Product owners were at the top of our list of stakeholders, because they get to decide most terminology, so we brought them in early to receive feedback and agree on a process of expansion. This was written down, and then we kept going and brought the next group on board.
We are currently making our way down the list to involve more stakeholders.
Communication
As this design system has grown, the more clearly we are noticing that more engagement and more progress happens when we often include it in our regular processes and chats with other teams.
Little, Hands-On and Often
Short weekly UX-meetings with each dev team proved to be fruitful forums for also making progress on the design system.
When we were sketching solutions together, we started talking about component ideas early, and when we did hand-offs we went through the ins and outs of new components. It was never the main purpose of the meetings, but it seeped into the process naturally, and helped us build common vocabulary.
A Silly Side Note
Unorthodox perhaps, but we by chance discovered that putting our colleagues' pets into light-hearted empty-state illustrations caused an unexpected amount of goodwill and engagement during a period when many new components were replacing old UI elements in the code.
The moral of the story is perhaps that a design system requires but also improves relationships between those working on it.
What's Next
The list of what we want to do is long – a design system can be and do so much. Here are some of our current goals.
Tone of Voice
After establishing the term base, we are now looking forward to formalizing what tone of voice should be applied across our user touch points, preferably together with the marketing department.
Improved Versioning
On the design end, we want to move from our fairly informal way of updating the component libraries, to a more structured way of rolling out and rolling back changes.
On the dev end, there needs to be a more reliable process in place for communicating changes in the code to affected teams.
Better In Sync
There is not a perfect overlap between the components that exist in the design libraries and the component that exist in the various code bases. We are working on closing those gaps.
Dark Mode
One big goal we have is to properly implement dark mode in all our interfaces and across the design system, since it would benefit a lot of our users.