Design Systems Are a Language. Product Is a Conversation
The Language of Experience
To say that language plays a special role in the development of our species is to say nothing.
Language is the ultimate medium of our culture. Language helps us communicate, remember, learn and evolve. Language defines us.
Since the dawn of civilization, language has been associated with creation. Creation of stories, progress, change and, as some religions believe, the creation of the universe itself. This creative nature of language naturally extended itself to modern times and allowed us to create new digital worlds and a new digital economy thanks to a new forms of language — programming languages.
Today, with programming languages, we can generate new universes and live in them. We struggle, though, with the most fundamental aspect of these new universes.
We struggle to create the language of experience.
We’re constantly seeking the connection between the visual representation of ideas and their functional expression in code. Some focus on the constant translation with prototypes, wireframes and documentation. Some call for the elimination of the visual form to work directly in code. Others try to ignore the issue and work around it.
And we all fail.
We fail to see that code and design are like written and spoken words. Both represent the same ideas, but through different mediums.
We exemplify this failure in our eternal debate over ‘Should designers code?’. Hundreds of articles, thousands of discussions and we still don’t know the answer.
We don’t know because this is not the question we should ask. Design and code represent the same thing and therefore must be connected. It doesn’t mean though that they require the same person to take responsibility of both, just as the songwriter and the singer can be two different people creating one masterpiece.
As Alan Cooper pointed, the question ‘Should designers code?’ should be replaced by the debate about the way we build software. And we know that the way we build software often leads from a slow process to an inconsistent experience. This problem requires the constant attention of our industry.
Fortunately, there are people who actively work on the solution. Thanks to the work of Nathan Curtis, jina anne, Brad Frost, Dan Mall, Jon Gold and other design systems luminaries, we’re getting close to finding a scalable solution.
We know that by reflecting the dynamic nature of software development (with all its building blocks, elements, rules, conventions and decisions) in a living design system, we can overcome the challenges of scaling software development. A design system unifies communication on the team, removes misunderstanding, and enhances creativity without harming consistency.
Design system gives your team one voice. It becomes the language they speak.
Design systems are the language of software development.
The Linguistics of a Design System
If design system is a dynamic language, then reflecting it in a documented form is like creating a dictionary. And in fact this is how creating the UXPin Design System felt like.
Since the beginning of the year, I’ve been acting as the leader of UXPin’s Design Operations team. We’re building our design system in bi-weekly sprints, delivering small ‘definitions’ as soon as they’re ready. The language continues to grow and with every sprint it improves the communication throughout the product team. It’s almost like we’re all gradually learning how to speak the same language. And we’re doing it with a growing dictionary in hand.
The difference between a natural language dictionary and a design system is, of course, that the latter changes much faster. Software changes and grows daily. A design system needs to reflect this dynamic to stay useful (and not turn into a zombie). What takes decades or centuries in a natural language takes just hours, in software.
To tackle this challenge, a design system doesn’t just codify the rules of the language, it also reflects the truth about the current user experience.
A design system is a dynamic dictionary that describes the ever-changing current state of the language, prescribes the proper usage of it and invites all the users of the language to extend it.
A design system is alive. Just like any language is. And just as any language, it can be divided into logical, linguistic, parts (bear with me, I studied philosophy in college):
As you can see, treating a design system as a language suggests that design, code, and documentation form one thing — a word, that can be used to communicate with users. All three, while often managed by different people, reflect the same idea.
Since they all serve the same purpose, you could argue that functionally, they are the same.
A design System is a language. A product is a conversation with users.
If you’re placing a button in your product, it’s represented by some design, code, and implementation rules. All three form the final button that users interact with.
The closer we connect all three in our product development process, the more powerful our language becomes — and, as a result, the faster the process becomes. Code and design describe the same thing, just like spoken and written word describe the same concepts.
The ultimate task of a design system is making the entire product team speak the same language.
Formulating of a unified and actionable language is the ultimate task of a design system. Once we get there, software development will change forever.
Is it going to be perfect? No. But everything we know about design systems tells us that once we get to the shared language, software development will be faster and user experience will be more consistent.
Connecting the disconnected
The practice of building our own design system and the research that we’ve done in the past year, encouraged the team at UXPin to build our own turnkey solution.
I’m extremely excited to announce that we’re ready to show you the first part of what we’ve worked on for months:
The first release of Design Systems by UXPin allows software development teams to build an actionable design system that connects design assets and documentation, keeps teams in sync and automates the documentation process.
Whenever you use a pattern from your design system, documentation follows to your project. This connection creates a much needed, and automatic, connection between design, code and documentation. The start of the language of experience.
This is the first release of many. We’re committed to help you and your team speak the same language. Whatever it takes, we’re here for you.
Early Access?
If you’re interested in giving UXPin Design Systems a try, soon we’re going to start letting people into our early access program. Sign-up here.
And if you’re curious about our own design system, I’m sharing our sprint stories:
- Design Systems Sprint 0: The Silver Bullet of Product Development.
- Design Systems Sprint 1: The Interface Inventory
- Design System Sprint 2: One Color Palette to Rule them All
- Design System Sprint 3: Managing the Basics
- Design System Sprint 4: Design Principles
- Design System Sprint 5: Managing Typography
- Design System Sprint 6: The Fastest Icons on Earth
Hope you’ll join us in the next frontier of design and development!
