I was first made aware of Postel’s law by Jeremy in his fabulous talk about design principles. Incidentally, he’s documenting lots of design principles here.

Postel’s law – or the Robustness principle - states:

Be conservative in what you do, be liberal in what you accept from others (often reworded as “Be conservative in what you send, be liberal in what you accept”). From Wikipedia

Jon Postel was talking about TCP and how implementations should follow this principle. Putting TCP and networks to one side for a minute, you can see how this principle can apply to many systems where there is input and output. Specifically, design systems.

The basic premise of Postel’s law is that what comes into a system can, and invariably, is a mess. Non-Compliant, delivered in a weird way, unconventional.

When thinking about this, I recall some work I did years ago on a ticketing system for a help desk. The single biggest hurdle, in order for the system to be successful was it had to be liberal in what it accepted. Tickets needed to be created from email, phone applications, web applications, voice recognition etc. The hardest part was getting stuff into the system. Only then could a single ticket be created - from various sources, in varying quality of data – in a single useable ticket for use with the large team.

Be liberal in what you accept (from emails, apps, voice, websites) and conservative with what you do (creating a single, well-defined ticket).

I see this same principle being applied to design systems.

Collaborating across an organisation to create a meaningful, impactful design system means you have to be liberal in what you accept from others into the system. Be it code, thoughts, design work, content, or criticism. That input can also come from many different teams, strategy, executives, products, people. You see, it’s a big mess! And the only way, really, to work with a system like this is to be open to all input from wherever it comes, in whatever form takes. To be liberal with what you accept.

This approach does a few things:

  1. Makes people feel involved, consulted, and listened to. This a good thing.
  2. Exposes the system to the dirtiest, out-of-date, horrendous use-cases possible. This is also a good thing. Mostly these use-cases are ignored because they are horrible.
  3. Helps turn a system that is owned, to one that is shared.
  4. Helps identify themes across an organisation.
  5. Helps the design system core team operate at a holistic level.

Policing a design system never works in my experience. It never works because people don’t like rigid systems, being told what to do, and will straight up do the opposite. Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.

So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable. It needs to turn the messiness of a liberal input into a defined, purposeful output that people can easily slot into their workflow and use.

Once again, I find myself in a place banging heads with how work happens rather than what the work is. Someone once said to me that ‘design principles are the stars to sail our ship by’. I’m certainly going to be using Postel’s law to sail my particular ship in the months and years ahead.