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:
Makes people feel involved, consulted, and listened to. This a good thing.
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.
Helps turn a system that is owned, to one that is shared.
Helps identify themes across an organisation.
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.
This is Manchester. I grew up on the outskirts of Manchester. I have memories like this picture. Black and white. Snowing. Wildlings. It’s grim north of the wall.
But what this picture doesn’t show is the rich visual culture that Manchester had throughout the 80’s and 90’s. All that rain and grim weather makes people creative. It’s no accident most of the best music in the world came from the North West of England.
This is Tony Wilson. Tony was a journalist in Manchester, appearing on Look North West as a roving reporter. I have lasting memories of his wind-swept hair, stood in a gaudy cagoule talking to a farmer on some moor somewhere. He was on telly every evening at teatime when Look North West was an ‘appointment to view’ (as they call it in telly-land) across the region. But as well as being a journalist, Tony was also involved in Factory Records, founding it with Alan Erasmus in 1978. Factory went on to define an era of music in the 80’s and 90’s signing bands such as Joy Division, New Order, and the Happy Mondays. I’m not a big fan of the music, but of the graphic design produced at the time.
This work was everywhere in Manchester. On every street corner. In every record shop. In every music shop. There were posters, fliers, newspapers, TV adverts. The hum of the city became entwined with the output of Factory. And, without really noticing it, started to take on this DNA. It became Manchester’s design system. It’s visual life-blood.
Imposing order
The challenge with any design system is they normally don’t work, don’t get adopted, don’t grow or get used if they are imposed top-down without an awful lot of consultation. Like any language, they have to be adopted by the masses through continued daily use. The tricky thing for us designers is that is rarely how we’re engaged to create these things.
Normally the brief goes something like this:
We’d like you to design us a living style guide (replace with ‘pattern library’, ‘design language’, ‘brand guidelines’, ‘identity’). We’ll then use that to provide consistency to our entire product range – of which we’d like you to help us.
Now, this works in some circumstances if control is maintained by a marketing department or brand manager. But, it’s my experience, that unless design is valued then control is absent. Nobody has the authority to own this. They just have some budget and see a problem that needs addressing, but do not have the money, authority or organisational environment to make this work succeed. So what do you do then?
Well, you just do it anyway. But over the years – taking some inspiration from my home town – I have a few principles…
1. Repeat yourself consistently
Let’s get one thing out of the way first. Meetings are not bullshit. Suggesting that is actually bullshit. Meetings – where people talk and resolve things, plan, decide – are probably the most important thing you can do to get a design system off the ground in a difficult place.
Remember, you have no authority. Your client, or stakeholder, has no authority. You’re doing this for better, holistic good of an organisation that almost everybody there cannot see. So you have to persuade, provide insight and data, and in my experience you have to do it over and over and over again.
2. Establish a mandate
Over the last 10 years i’ve worked on quite a few, large scale design systems. In all of them, there was a distributed technical system that had grown organically. A few CMS’s here and there. PHP, .net, etc etc. It’s not like you could create a bunch of HTML and it would work everywhere. Far, far from it.
And then, editorially, many of the departments of these organisations were creating content without any joined up thinking. It was common for them to have their own budgets to create their own mini projects (yes, with their own CMS) and they’d hire a little design firm to do it.
From a branding perspective, there was normally a small, internal, over-worked branding team who were constantly and consistently putting out fires that the organisational structure creates. Everywhere you look people were degrading the brand.
In my experience, this is the norm. How do you create a design systems that not only gets adopted, but thrives, in this environment? You have to establish a mandate. An editorial, technical and brand mandate. A troika of disciplines working together to establish order.
3. Be where the creator is
In the case of Manchester, the work of Factory was in front of every young designers eyes. Everybody looked up to the work of Peter Saville and created work to replicate it. So, on every street corner, the inspired work appeared. All of a sudden, Manchester’s visual DNA expanded beyond the world of record shops and club night posters, and made it into plumbing brochures, margarine packaging and pub fliers. The bread and butter for jobbing designers in the North West.
This was because the work was accessible and in the places designers where looking for inspiration.
I like to apply the same thinking for the adoption of a design system: be where the creator is. A few examples:
Provide ready-made templates for design tools. Not just for in-house designers, but so external designers (you know, hired by the small department trying to use their budget before the end of the year) can use them too.
Provide tools to make things. If you’re building digital things, provide a UI library and maybe prototyping and deployment tools that make consistency easier.
Be where they are. If an organisation uses Sharepoint, or some other God-awful intranet software, then put your tools where they are and don’t try to force other documentation if it won’t fit.
How do you know you’ve been successful?
I get asked this a lot. How do you know if your work will stick? You’ve spent a year designing a new design system. How do you know it will really hold? I’ve learnt to look out for a few indicators…
The design system becomes how design is talked about in an organisation. It becomes a shared vocabulary. And not just by other designers, but by management and all levels of an organisation.
The quality of design (and editorial and technical) becomes self-policing. It’s no longer the responsibility of just one person or team, but ownership becomes distributed. People start to care.
Design and KPIs. Clear lines get drawn between good design and measurable outcomes.
Lagging and Leading indicators become more apparent. So you can better predict how those indicators affect quality, brand, product roadmap. In this case, design can help indicate the health of an organisation.
What’s Manchester got to do with all of this?
You may well ask. When I was growing up in Manchester, I never really took much notice of the graphic design around me. It was only when I left – or years later – when I decided to become a designer that this stuff leaked out of me. It was stored somewhere deep inside my brain and with it, I like to think, I absorbed some of that taste. By being part of the Zeitgeist.
What you do now for your client or in-house will have an effect that will be felt years later. You will change how people think about design. Change their relationship with the company they work for. All by consistently using Helvetica, or something. It’s not that hard. Is it?
In the 2012 Olympics, the UK cycling team dominated the track. Winning 12 medals: 8 Golds, 2 Silvers, 2 Bronzes. They also broke 7 World Records and 9 Olympic Records.
No, aside from the unbelievably hard work of the team, the superb conditions of the track and the humidity of the building, there was one person who was credited as the brains behind the performance; Sir Dave Brailsford. Sir Dave is also credited as instilling a culture of measurement, data, and, ultimately, well-being into the team. A key component of this was a philosophy of ‘Marginal Gains’.
“The whole principle came from the idea that if you broke down everything you could think of that goes into riding a bike, and then improve it by 1%, you get a significant increase when you put them all together.”
This is also something he applied to his job as manager of the Sky cycling team.
When Brailsford formed the commercial cycling team he had one goal: to win the Tour de France. Clean. Within five years. He did it in two. And then again. And again.
The challenge he had was this: cycling has long been a sport which uses performance enhancing drugs. In order to compete against teams using these drugs, Team Sky – and any other clean team – had to bridge a gap of about 16-19%, depending on which source you read. Regardless, that is an enormous distance in performance in any professional sport. And they did it through the aggregation on marginal gains. Looking at every aspect of an athlete’s life – their diet, weight, sleeping patterns, physiology, well-being, the pillow they use at night. Even how they wash their hands – they were able to bridge that gulf.
I’ve been a fan of professional cycling for a long time. Even before I owned a road bike and rode myself. But recently, I’ve become interested in how coaching has created this performance. How Team Sky’s, and before it Team GB, management team has created a culture for riders to succeed by the continued improvement of tiny, tiny little things. But, I’m also interested in the opposite.
Marginal Degredation
Here’s a few fun facts…
- Gorillas share 98.4% of our DNA
- Goldfish share 68%
- Bananas share 50%
Bananas. Are 50% the same as us.
Well, you think about it, it kind of makes sense. We’re all made from the same elements. The same star dust. Just arranged in different ways. But, we’re very, very different to bananas.
Let’s talk about design for a second.
What happens if 1.6% of your brand is left unchecked? Or 1.6% of your user experience of your product. Doesn’t seem a lot, does it? How about 32% Again, for some, this is within acceptable margins. Especially if your brand or product is growing quickly, acquiring companies here, there and everywhere.
But, 32% is the difference between a human and a goldfish. Even just 1.6% – probably acceptable margins for almost every brand or product out there – is the difference between a gorilla and a human. Think about that for a second.
Your brand or design is supposed to be a human, but people perceive it as a gorilla. Or a banana.
Applying Marginal Gains to brand or product design
What can you do about this? How do you stop a distributed organisation degrading itself? Well, entropy happens and this is always the struggle with any branding or design work on an ongoing basis. Like any garden, it needs tending.
But, here are some of the things I do to stop the rot:
Keep talking. To everyone. My job is to help create the environment in which marginal degradation doesn’t happen. I do this by talking to everyone across an organisation - so they feel involved, empowered, excited, free to be creative. I did this before working at Monotype too, but with other companies.
‘Show the mess’. Design work is not that scary. Expose people who are not designers to the design process. By doing this you get better buy-in, involvement, and culture.
Maintain a holistic view. It’s so easy to get dragged into the weeds. But sometimes, the weeds is exactly where some delightful little design problem exists. Who knows, maybe I end up doing some actual design work. You know, keeping my hand in. Well, no. Keep above the weeds.
Draw straight lines between design and KPIs. This is a big one. What design and brand do should be measurable. Not by some data Goloms like the Net Promotor Score, but by committing to understanding your customer’s behaviour. You can only make incremental tiny improvements on a foundation of understanding. Measuring against real-world indicators puts design in black and white numbers all levels of an organisation can understand.
Just be consistent. Even if you know it’s not ideal. It’s not something you’d do. Maybe you inherited a design system, or jumped on board half way through it’s creation. Maybe you just don’t like it anymore. That’s ok, you can take your time to get it changed, but in the meantime, be purposefully consistent.
If you do deviate, make sure you do it with a plan. If you plan on being a gorilla, and deviating that 1.6%, then do so with purpose, not just because you are lazy.
Plugging away at this tiny stuff is relentless. It’s the tiny details that, when viewed together, look big and insurmountable. But, taking one tiny improvement at a time, in the bigger scheme of things, you may be surprised at how quickly your product or brand starts perform. Not only that, but now you have a way to measure it.
It’s 1998 and I’ve just arrived in Bangkok and it’s 90F at night. I’ve arrived at a small hostel just around the corner from the Khao San Road and, just like everyone else travelling or on a gap year, I’m a walking stereotype. From my flip flops, overly loose trousers, consumption of banana fritters and cheap Thai beer. Oh, and well-thumbed copy of The Beach.
Like I said; a walking stereotype. Except for lugging around the 2kg A3 sized portfolio case rammed into my already weighty backpack.
It’s 1998. The web is still in its infancy, but it’s there and pretty good. Fireworks was on version 1. I used Internet Explorer 5 and Eudora The first iMac had been recently released. Not really the dark ages, but here I am, lugging around an additional 2kg of dead trees for two months around South East Asia. Why? Well, I wanted a good job when I got to Sydney. And, as a designer, a good portfolio – or ‘Book’ as it’s called in advertising – would get me one.
Let me back-peddle a bit to my first job as an intern at an ad agency in Manchester. There worked an Art Director called Tom. Tom was quiet mannered, quick to smile and laugh, and much quicker to point out a small opportunity for improving a design. Together with the other Art Directors, he taught me about hierarchy and how to make type fit on a page (this was a distinct problem when designing plumbing catalogues). But he also taught me the value of a good Book. How to design one; how to tell a story through your work; how to present your work and do enough in the portfolio to get you a foot in the door which is what junior designers needed so much back then.
“Leave your book and pick it up tomorrow”
My experience of looking for a job early in my career was probably quite usual amongst my peers: I never replied to a job advert. Instead, I was encouraged to get together a list of the places I’d like to work and then to sell my portfolio around them. So, there I was; fresh out of school, full of ‘I got a First Class honours degree’ confidence selling myself from agency to agency. It was a baptism of fire. I remember the first day was particularly horrific. Out of the six or so agencies I’d arranged to visit, only one was happy to let the art director see me rather than just leave my Book and pick it up tomorrow. And then, my work was systematically ripped to shreds by an Art Director with too little time on his hands.
Now, this isn’t meant to sound like ‘oh, woe was me and my hard time finding a job’. But, I am trying to recall how my portfolio was the start of a conversation. And, generally, a conversation I wasn’t there for. I didn’t really plan for that so had to adapt the work to invite that second meeting.
Oh, those soft skills
So much of what we do is working with people. Sometimes, though, I think I need to have experience in counselling or negotiation tactics in order to usher through design changes which impact organisations at their core. It’s difficult work. And, if you’re not the type of person who like talking to other people, then the impact of your work will only go so far. The question is, how do you demonstrate this in your portfolio? How can you demonstrate the value of design games, or collaborative moodboard exercises? Or that it took six months of negotiating with dozens of facets of an organisation in order for a content strategy to be adopted? My advice would be to write a story. Show photographs of workshops. Demonstrate how you approach these things. List the methods you’ve used and those that have worked. List those that haven’t and the reasons why.
This may seem odd for a portfolio, but if you think about it, design agencies have been doing this for decades. This is because they have similar problems. A lot of agencies sell the process of design, not the end result. In order to charge money for things like strategy, research, collaboration and what-not, all of which is difficult to show in a piece of design, they have to demonstrate it in other ways; case studies, stories, photographs. Packaging the work to show the full range of what was worked on.
A few pointers Tom gave me (and a few of my own)
Let me take you back to Manchester in 1995. I think it was early in a week in July. It was probably raining, as is usual in my home city. Anyway, Tom and I are discussing university and where I’d like to work and doing what. I start talking to him about my final year and the projects that await and he begins to advise me on not leaving my portfolio work too late. That I should be working on it throughout my final year and how I shouldn’t under-estimate the amount of work it will take. A year! Surely it couldn’t take a year, I said. It’s just a dozen prints after all. ‘No’, he said. ‘It’s probably the most important piece of work you’ll do in your final year, and one you won’t get marked on until you try and find a paying job’.
Over a nice hot cup of tea, he and I chatted for an hour or so about what makes a great portfolio and all of the things he considers when a dozen or so would land on his desk every single week. At the time, this was for a print portfolio, but looking at these now, you could easily see how they’d apply to all types of portfolio, including those for a small studio or agency.
Here are the highlights…
Snapshot
Who was the client? When did you work on this. What was the Date? What was your role? What was the value to the client? But keep this brief. This meta data way-finding is important when skimming through a portfolio.
Show a progression
Show work that didn’t cut it. Demonstrate your ability to change and iterate and show variance to get to a solution. This also demonstrates your graphic design capability, copywriting, and visual thinking.
Be honest
If you worked under a senior, say so. Talk about why projects might not have been completed. Honestly, if you bend the truth, it’ll catch up with you at some point.
Breadth
If your work is just a bunch of posters, of a certain type of client or work, then it’s easy to pigeon hole you. If you just design icons, that’s the type of work you’ll get. Demonstrate breadth, even if it means working on your own side projects or setting yourself your own briefs.
Fewer and better
Be very, very picky about what you show. If you only done three projects you are really proud of, then just show them. Talking passionately about how it went, what your contribution was, and what happened after it was finished will shine much brighter than ten single pieces of work. It’s easy to spot things made with care and love, even those commercial projects that fell short of the mark (and it’s ok to say that if you know the reasons why).
Walk the walk
If you can code, then demonstrate it. If you can’t, be clear about why you don’t think that’s applicable for your role and growth. Either way, conviction in your own abilities or not will tick boxes.
Work is more about pictures
The big difference between junior designers on the web and print is quite stark, but the more experienced you become, the roles become similar. It becomes less about pretty pictures, and more about facilitating a process from beginning to end. Think about how you can convey something before hand that isn’t a picture. This is where writing about your work trumps showing pictures. Because sometimes there just aren’t any pictures to show.
And, the last point I think nicely rounds off this post.
It’s the start of a conversation
This was applicable when I started my first job, when I ran a small agency, and now I work in-house at Monotype. Any portfolio is the start of a conversation. It needs to invite discussion, further questioning, and that all important call-back.
Going back to that stereotype traveller type, wandering around Asia with an extra 2kg in his backpack… Well, I arrived in Sydney. I had a very short list of studios I wanted to work for and proceeded in doing what I’d done before: making myself a nuisance until I had the opportunity to either leave my Book, or talk it through with someone. I managed to get the job I wanted with a great little company in Sydney called Spike. It was my first web design job. All thanks to Tom and his advice. And a sturdy rucksack.
A software SDK is a set of tools that allows the creation of applications for certain software, or video games, or a hardware platform. A hit could be as simple as a bunch of APIs or software that talks to embedded or proprietary systems. An SDK is a collection of tools to make something with. It’s a leg-up for development. And they’re needed for design, too.
Guide me, don’t tell me
When working with identity guidelines, pattern libraries, or styleguides, the biggest pushback I hear from designers is ‘I don’t want to be this specific. Point me in the right direction, but don’t be prescriptive’. The chances of a pattern library or styleguide answering every design problem that comes along is slim, but providing an overall understanding of a system is probably the best position you can put a designer in in order for them to do good work. That, and providing them with the right tools.
Giving someone a design SDK may be better than asking people to look for, navigate and understand an entire website dedicated to your design language.
For example, let’s say you work for a large bank in their in-house design team. Your design language is years old and grown organically to become a place of internal collaboration for stakeholders and silos – not really the place for external suppliers. One day, you need to get a very small web project designed and your team is maxed out so you outsource it to a freelancer. Now you’re faced with a problem.
Your design language documentation and collaboration site is housed internally, behind the company firewall, and you can’t give her access. You try to collect some material together for her, but it takes all morning before you even have an idea of what might be needed. And then you can’t find the logo in the right format. All you really need to do is send her what is needed and nothing more.
All of this takes too much time. And a styleguide doesn’t solve the problem. A design SDK is what you need.
A style guide is about providing the right help for every use case all in one place. An SDK is about providing the right help for a specific environment. In software development, APIs may have middleware wrappers like a PHP and Ruby. But regardless of the wrappers, the endpoint is always the same: the software at the end of the API. In the same way, a Design SDK should provide an end-point — a design language — typically via different methods such as HTML and CSS, or Sketch files, or Photoshop files, or text documents, or InDesign swatches.
The key to this is to be where the designer is. Learn where your designers and design partners do their work and provide tools that help get your design language adopted in those tools.
The problem with style guides
Style guides can be great for documenting a design system and providing a way for design to be consistent across multiple projects, products and people. But they can also be a shackle for creativity. A firehose of difficult to navigate content that compromises clarity for brevity. The key thing with style guides is they rely on you going hunting for what you need. They are everything for everybody. They are pull rather than push.
A design SDK I’m talking about is push rather than pull. It’s given to you, and it contains just what you need and nothing more.
What would be in a design SDK?
The key here is to provide just enough for someone to get going with their work. For some projects, this may be all of the following, but for others, it could just be a couple.
Moodboards and inspiration
HTML boilerplate
CSS or Sass snippets
Template assets
Suitable example images
Icons in various formats
Licensed typefaces or links to the correct typefaces
Branding identity guidelines
It would be ideal for me if an SDK could be created on the fly for different people based on project needs. So, for example, for freelancer ‘A’, I don’t want to send them HTML or CSS as I know they’re not building anything, so I just send them mood boards and inspiration, image assets and branding guidelines. For freelancer ‘b’, a front-end developer, I send boilerplate, CSS, template assets and icons. I mix and match and provide the design SDK, rather than send along a URL and expect them to know what they need and how to use them.
‘Isn’t this just for big, in-house teams and projects?’
No, I don’t think it is. There were plenty of times when I ran my design agency that we could use a design SDK as a deliverable for a client. Because, after you have finished working with them, chances are they will need other people to take forward your design in one way or another. And maybe the client isn’t the best person to determine what is needed to do that. A design SDK would be a great deliverable to ensure design integrity is maintained after you move onto other projects.
