Lukas
Opperman
Staff Systems Designer at Github
Lukas Opperman is a Staff Systems Designer renowned for his philosophy that simplicity is key to solving complex problems. With a passion for tackling new challenges, he believes the foundation of success lies in building and nurturing the right team.
His career in design spans from freelancing for diverse entities to teaching and speaking. Lukas has a rich history of engaging with style guides, which evolved into his current focus on design tokens, accessibility, and systematization. His dedication is fueled by the pursuit of innovation and, admittedly, good coffee.
Can you walk us through the current state of the design system you're involved with? What was the journey like getting to this point?
Our design system has been in place for over ten years. Despite its longevity, it's anything but static. Post-launch, a design system enters a state of continuous evolution—new requirements emerge, components are introduced or updated, and shifts in branding and design necessitate changes, not to mention the constant technological advancements.
In my view, when a design system hits the 1.0 milestone, it's not the end of the journey but a new beginning. It's a perpetual cycle of refinement and enhancement, with each iteration building on the last.
What tools do you use to build and maintain your design system?
OUR TOOLS:
Figma
Style dictionary
React
How do you balance the need for consistency with the desire for creative freedom among your designers?
To maintain a harmonious balance between consistency and creative expression among our designers, we employ a flexible approach. Our design system is structured to allow designers to craft custom solutions using tokens when the existing system doesn't quite meet their needs. When these new components prove beneficial across multiple teams, we incorporate them into the broader design system.
There are designated areas where creativity can take the forefront—such as dashboards, general layouts, and particularly on marketing pages. Yet, when it comes to building digital products, consistency is key. Product designers must grasp this equilibrium. Our role isn't to be artists per se but to construct accessible, consistent, and user-friendly flows that contribute to a product's success. For those who find this constraint challenging, focusing on branding, landing pages, or other projects that allow for more unique, creative solutions might be more fulfilling.
On a personal note, I channel my creative energy into side projects, which serve as an excellent outlet for that aspect of my work.
How do you stay true to your vision for the design system, even when faced with external pressures or trends (criticism or pushback against your design system)?
Staying true to the vision of our design system amidst external pressures and emerging trends involves a delicate balance of openness and steadfastness. I believe it's essential to be receptive to criticism. A design system isn't created in isolation; it's a collaborative effort, and often, criticism highlights areas of friction that need addressing. Engaging in dialogue is key—by actively listening and conversing with those who use the system, we can either integrate their feedback, find alternative solutions, or clarify why certain aspects of the system are designed as they are. Understanding often stems from context, which not everyone may have initially.
I'm convinced that if you're thorough in your research and genuinely listen to the users of your system, it becomes much easier to maintain the integrity of your overarching vision. It's about being informed and empathetic yet also clear and confident about the direction of the design system.
How does your team collaborate on the design system? How do you ensure that your design system evolves with the changing needs of your users and stakeholders?
Our team approaches the design system as a collaborative code project. In all the design systems I've contributed to, we've utilized an issue tracker—such as Jira or GitHub Projects—which allows anyone involved to add issues to our backlog. This system ensures that we're constantly aware of and can prioritize new requirements and bugs as they arise.
Open communication channels are also vital. We maintain accessibility through email, Slack, and other platforms, encouraging team members to reach out with questions, suggestions, or feature requests. This open-door policy fosters a culture of collaboration and continuous improvement.
Moreover, when developing new features, like a new token setup, I don't work in isolation. I actively seek input and involve relevant team members early in the process, both for research purposes and as beta testers. This proactive engagement ensures that the evolution of our design system is both inclusive and aligned with the changing needs of our users and stakeholders.
Are you tracking your design system? If you had to choose one metric to measure the success of your design system, what would it be and why?
Either adoption rate or, if possible, time saved.
Adoption rate
How many projects are using it and how much of their projects are made of design system components and tokens.
Time saved (which equals money saved)
So, how much time was saved by using design systems and design tokens? This does not only mean not having to build components in projects but also, if there is a fix/re-brand, etc., how much time is saved because the design system makes updates automatically?
If you could go back and change one decision you made in your design system journey, what would it be and why? How would that affect your design system journey?
I am pretty happy with how things worked out. But having released more tooling and knowledge earlier would been great. So, maybe I would have started publishing articles earlier and would have spent more time working on open-source tooling.
Do you use any kind of automation or AI tools?
We use a lot of tests via GitHub Actions. For example, to ensure color contrasts are still good after a design token was changed. Another example is using Zod to validate the design token JSON.
In the end, I feel that very often, we run into issues using AI or automation for more creative parts. I tried to build a solution to choose colors programmatically, but I always tweaked by hand because things also have to look good, and this just does not work with 100% code-driven approaches.
Where do you see design systems heading in the next few years?
Nowhere 😎. They will stay the way they are, with small incremental changes. I think integration in tools will get better and maybe also on the web platform. But I feel design systems are in a solid state. I don’t see big issues with the system at the moment, so there is little need for drastic changes.
What's one thing you wish more people understood about design systems?
A design system is like a product or a tool with only one goal: To make it easier for designers and developers to build products. If it fails at this, you need to change it.
In your opinion, what are the most overrated and underrated aspects of design systems?
Overrated
Often, people think design systems make it impossible to build unusable products. But this is not true. You can build bad apps, even if you use 100% design system components and tokens.
Underrated
Design tokens: this is the first thing I would start with. They can tie the entire system together with relatively little effort.
If you could have a coffee chat with any person from the design (system) space, who would it be and why?
I think I would love to talk to somebody outside of my field. Maybe Michael Bierut, who I am a big fan of. I am fascinated by how design used to be and love to hear stories from people who had a different way of getting to where they are now.
Coffee with Michael Bierut?
What's one piece of advice that you would like people to remember from this interview?
Owning the design system does not mean that you make all the calls. A design system is a product you build for your users, the designers, and the developers at your company.
Involve your users, do interviews, and be flexible. Your goal is to make their work easier, which ultimately counts.
What's your favorite thing to do when you are not in design systems?
I love running and bouldering. I enjoy good coffee and like to spend time with family. I have also recently picked up baking and plants, which I still have to master.
