Build Design Systems With Penpot Components
Penpot's new component system for building scalable design systems, emphasizing designer-developer collaboration.

medium bookmark / Raindrop.io |
A brief introduction: I’m Marcin: a former UX manager and now co-founder and CEO at UXPin — the full stack UX design platform. In this series of posts, I’m reporting on UXPin’s journey of creating our own design system. We went through the reasons to build a design system, building a design inventory, setting-up a unified color palette and managing the basic style properties. Today we’re going to take a step back and strengthen the foundation of our design system with design principles.
Right after setting up the basic style properties for our growing design system, our design operations team stammered. We wanted to move forward and clean up the typography, creating a crystal-clear typographic scale with corresponding Less mixins and variables. However, more fundamental questions started to pile up:
The more we engaged with these fundamental questions the more overwhelmed we started to feel.
This feeling of being trapped in design decision-making, reminded me of our late 2015 efforts to bring a completely new visual aesthetic to UXPin.
UXPin new aesthetic introduce in 2015/2016 as a result of using set of design principles
Working on the new version of UXPin back in 2015 brought a ton of design-process challenges. We had to coordinate the efforts of multiple designers and developers, multiple simultaneous feedback sources (usability tests, customer service feedback, sales feedback, analytics, multivariable split tests) and, of course, the differing opinions of stakeholders.
Our design team quickly agreed what kind of architectural changes we want to make. Our decisions were based on extensive user research and we knew exactly what we expected to see in the new interface. The aesthetic of this new interface was quite a different story.
The main visual designer on the project and I had a different sense of beauty. On every design review, we would end up in a subjective discussion of taste. It was leading us nowhere. To overcome this challenge, we decided to bring our discussion to a higher level and talk about principles. We used a simple process to establish our design principles:
After completing these five simple steps our design principles were ready to go! Here’s the final list:
UXPin Design Principles
1. No distractions. Every redundant piece of the interface (lines, buttons, shadows, animations) is a source of distraction. As such, should be eliminated to empower users’ creativity with well architected and inspiring design tool.
2. Design centric. Users’ designs should lie at the center of UXPin. Our interface should be unobtrusive to the point of transparency.
3. Adaptive interface. UXPin’s interface should act according to the context of use. All the ‘inactive’ features should remain completely hidden until user can use them (no inactive buttons and links!)
4. Space. UXPin’s interface should create a peaceful atmosphere, triggering creativity of users. This ambience can be shaped by leaving a lot of space around every piece of interface. Cluttered interface is the source of stress that produces cortisol and adrenaline,both blocks our creative powers.
5. Inspiration. UXPin design should inspire and, as such, can’t be a derivative of design of other SaaS apps. We should strive for an original aesthetic inspired by the best products ever created (some of the sources of our inspiration: Fountain Pen Pilot Vanishing Point Matte Black, speakers Harman Kardon Sound Stick, record player Pro-ject, speakers DALI Zensor).
6. Interactive Consistency. Interface components, icons, fonts should all be consistent to create predictable experience.
7. Predictable Architecture. Architecture of UXPin must be predictable and natural. Features should be placed in the right context to be easy to discover by new users. Example of predictable architecture: settings of canvas should be placed next to the canvas.
We started to use these design principles as a benchmark for our design decisions and a tool to measure ourselves against during design reviews. For example, we would ask ourselves whether a particular interface solution is predictable enough from the architecture point of view and whether it interferes in a negative way with users’ design project. Design principles provided quick feedback throughout the design process.
We also used these principles to explain our decisions to the entire team and stakeholders. Design Principles are extremely useful to lay out foundation of design decision-making without going into too many confusing details. Quoting after Luke Wroblewski:
“Design principles are the guiding light for any software application. They define and communicate the key characteristics of the product to a wide variety of stakeholders including clients, colleagues, and team members. Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the pieces of a project moving toward an integrated whole.”
Our principles were extremely important to bringing a new aesthetic to UXPin and they quickly became an integral part of the way we think about UXPin interface. All the subsequent projects reflected the line of thinking expressed in our principles even if we weren’t referring to them directly during our design reviews.
Design principles started to work on a subconscious level, which was fine, until we had to make more fundamental design decisions. Decisions that are going to affect the entire product interface. In this new context, we started to face familiar disagreements. Somehow, subconscious process working well during project work, failed us during the work at the design system.
To face this new challenge, we had to bring our design principles back to our consciousness and remind the team of them. We had to centralize our design principles and make sure they prevail not only across all the projects, but also across all the parts of our Design System. How one can achieve? It’s simple — design principles have to become part of the design system.
UXPin Design Principles are stored with other parts of our Design System
By now you can tell that we love design principles. At UXPin it’s a proven weapon against:
Somehow though, most of design systems do not include design principles at all. According to our research, just slightly above 40% of publicly available systems include design principles.
Among these 40% we have some of the most comprehensive design systems:
Salesforce Lightning Design System includes set of universal, high level design principles:
Design Principles in Salesforce Lightening Design System
Google Material Design approach to design principles is very minimalistic and focused on what makes Material Design so unique as an universal design system. Their principles are:
Google Material Design — Design Principles
Apple iOS has a very detailed and specific set of principles:
Apple iOS design principles
As you can see approaches to building a set of design principle varies a lot. From a set of rules defining what Material Design truly is, through set of inspiring (and aspirational) statements in Salesforce Lightning System to precise and strict definition of a good design in iOS Human Guidelines.
UXPin’s set of principles lies somewhere in the middle. Some of our principles point at specific design decisions that are expected from all of our interfaces (e.g. the principle of predictable architecture, which asks for placement of actions in the familiar context), other have more general nature and aim at inspiring (e.g. the principle of inspiration).
So which approach to design principles is the right one?
One canonical approach to design principles does not exist. Good principles are the ones that are meaningful to the team using them. As anything organized, or managed by design operations team, design principles reason to exist is to serve users and product organization (order intended!). If your team fundamentally refuses to use the set of principles, or just simply ignores them, they lose the entire value. While working on design principles, you have to check with the team and test usefulness of what you prepared.
If you and your team feel unsure about the general direction worth taking, Julie Zhuo created an ingenious set of heuristics for a good set of design principles:
“A good set of design principles, on the other hand, does the following:
1. Helps resolve practical and real-world questions around specific design decisions.
2. Applies to an entire class of design decisions, both things we can think of today, as well as questions that will pop up in the future.
3. Imparts a human-oriented sense of “why?” that is easy for everybody — including non-designers — to understand.
4. Has a point of view and a sense of prioritization that a rational person could disagree with.
5. Is generally paired with illustrative examples that show how the principle applies to specific decisions.”
Controversial? Maybe. Challenging? Definitely, yes. But after all we want our principles to be as challenging as possible, and Julie’s approach helps make them as sharp as possible.
While Design Principles are not the most typical part of the design system, I highly encourage you to consider them. Nothing sets a better foundation and guides the team through a creation and continuous implementation of a design system than a set of meaningful design principles.
AI-driven updates, curated by humans and hand-edited for the Prototypr community