This is a great analysis by Amy of the conflicting priorities tugging at design systems.
No matter how hard we work to foster these socialist ideals, like community, collaboration, and contribution, it feels as though we’re always being dragged to a default culture of individualism.
Katie shared this (very good) piece about service design on Slack at work today, and when I got to the bit about different levels, my brain immediately went “pace layers!”
- The Service
- The Infrastructure
- The Organisation
- The Intent
- The Culture
Working in a big organization is shocking to newcomers because of this, as suddenly everyone has to be consulted to make the smallest decision. And the more people you have to consult to get something done, the more bureaucracy exists within that company. In short: design systems cannot be effective in bureaucratic organizations. Trust me, I’ve tried.
Who hurt you, Robin?
Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it’s important, critical, or fundamental, write it up, don’t chat it down.
This one feels like it should be Somebody’s Law:
If your words can be perceived in different ways, they’ll be understood in the way which does the most harm.
The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:
It’s true many design systems are the blueprints for manufacturing and large scale application. But in almost every instance I can think of, once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. That’s why broad principles, just enough governance, and directional examples are far superior to locked-down cookie cutters.
The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.
This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:
Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.
Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.
That last part dovetails nicely with Jerlyn’s equally great piece.
This is great advice from Lindsay Grizzard—getting agreement is so much more important than personal preference when it comes to collaborating on a design system.
When starting a project, get developers onboard with your CSS, JS and even HTML conventions from the start. Meet early and often to discuss every library, framework, mental model, and gem you are interested in using and take feedback seriously. Simply put, if they absolutely hate BEM and refuse to write it, don’t use BEM.
It’s all about the people, people!
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.
An organisation has formed here in the UK as a response to the increasing threats to the web:
We are called to come together in response to growing political and social uncertainty, direct threats to the profession, and a lack of vocal and proactive representation to organise as a representative, independent, and politically responsible industry body.
The inaugural AGM is happening in Edinburgh tomorrow. Get along to that if you can. Otherwise, there’s always Slack.
I like their manifesto; let’s put it to the test-o.
Alla looks at a few different ways of organising the contents of a pattern library, based on her experience with the FutureLearn team.
When I got back from Bletchley Park yesterday, I immediately started huffduffing more stories about cryptography and code-breaking.
One of the stories I found was an episode of Ockham’s Razor featuring Professor Mark Dodgson. He talks about the organisational structure at Bletchley Park:
The important point was the organization emphasised team-working and open knowledge sharing where it was needed, and demarcation and specialisation where it was most appropriate.
This reminds of another extraordinary place, also displaying remarkable levels of collaboration, that has an unusual lack of traditional hierarchies and structure: CERN.
Bletchley Park produced the computer. CERN produced the web.
Want a Science Hack Day where you live? Make it so!
An excellent follow-up to the recent posts on the myth of mobile context.
You often hear about cutting content to cut clutter. I support this—if you’re cutting the clutter from everywhere, not just a mobile experience.
Maybe the answer isn’t cutting. Maybe it’s learning better skills for designing and structuring complex information to be usable and enjoyable in small spaces.
This is a really good initiative—a list of minimum expectations from conference organisers (although there’s clearly some differences between cheaper grassroots events and larger industry affairs).
Some thoughts on structuring your CSS for responsive designs.