Ethan Marcotte just wrote a great piece about design systems and how the promise that design systems would hugely improve collaboration between designers and developers never really materialized. Many teams are still working in silos, which means there is a clear separation between design and development teams. And, as Ethan points out, while our tools might have become better in supporting collaboration within the respective fields, many of them still fall short of closing the gap between the disciplines. There are a few exceptions to this rule, of course. Some design tools let designers pull in data from JSON files or APIs into their prototypes, for example, with plugins like Data Populator for Sketch and Adobe XD. Other tools like Framer or Supernova Studio tightly integrate visual design and prototyping features with production-ready code. Yet these tools are very much focused on certain technologies and frameworks and are therefore still limited to specific use-cases and projects. Not every project is built with React, for example.
Design systems shine in providing consistency and reliability. This alone makes them a tool worth investing in. But why do they often fail to provide the communicative link that closes the gap between design and development? What else could provide that link? And yet another interesting question: Do companies and teams even understand why close communication is the way to go in the first place? After all, change will only occur when there is enough understanding but also pain and pressure to leave the seemingly safe harbor of the status quo.
Designing and Making
If you want to build great products and services, designing and making really should be inseparable. The closer designers and engineers work together, the more they can work with and around the constraints of the material and come up with solutions that are thoroughly designed and engineered down to the last detail. This works because designers are less likely to design solutions that don’t respect underlying technologies, while engineers at the same time develop a deeper understanding of the importance of creating work that combines great engineering with the subtle nuances and design details that create great experiences.
Many organizations realize that a lot of their products don’t come out as expected and that collaboration and the flow of information between design and engineering needs to be improved. Yet their answer often seems to be to increase the complexity of the systems between us. They put stringent processes in place, require more documentation, or establish a sophisticated design system to save the day. Meanwhile, designing and making are still separated.
People over Processes
I get that we need a certain level of consistency and professionalism. And that it is human nature to prefer solutions that provide safety. But when it comes to collaboration, tools alone won’t save us. The most vital factor of good team collaboration is and always will be: People. How good they understand each other and their respective fields of expertise. How much they listen and try to understand each other’s perspectives. How much they learn from, inspire, and challenge each other. How much they trust and rely on each other. And how much they share common values and goals. When it comes to ingenuity and collaboration, a design system will only take you so far if you only see it as a tool. Yes, a design system could foster collaboration. And it could improve mutual understanding. But a design system in itself will not make up for poor team dynamics and interactions.
So instead of relying on processes and tools to fix team communications for us, we should mix our teams, remove the separations between departments, bust the silos. Smaller teams communicate better and often arrive at outstanding solutions much faster, especially if interdisciplinary team members know their talents well and supplement each other. The flexibility of a small team will also make it easier to deal with uncertainty and complexity – a much-needed skill in today’s fast-changing world of technology.
Complex vs Simple
We still need systems that enable communication, of course. But instead of trying to build complex systems from scratch, it might be smarter to first focus on establishing workflows and processes that reduce the friction to communicate and are as simple as possible. Always remember Gall’s law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Ask yourself: What is the simplest way to communicate? What is the simplest way to document our work? What is the simplest way to make changes to our product? What is the simplest way to test our assumptions and develop new ideas together? What is the simplest way to combine designing and making? Building a lot of prototypes in a small, interdisciplinary team can be one answer to those questions. Slowly building up a design system based on shared practices could be another one. And there are certainly many more.
With DevOps and DesignOps, we are already addressing the challenge of working and communicating within the separate teams. Maybe it is time to focus on “TeamOps” next.
-
This is the 33rd post of my 100 days of writing series. You can find a list of all posts here.
~
