I feel for BaseCamp, I do. But give up on the native app path. Make sure your existing web interface is a good progressive web app and you can end-run around Apple.
Friday, June 26th, 2020
Thursday, February 6th, 2020
Design systems can often ‘read’ as very top down, but need to be bottom up to reflect the needs of different users of different services in different contexts.
I’ve yet to be involved in a design system that hasn’t struggled to some extent for participation and contribution from the whole of its design community.
Wednesday, February 5th, 2020
Design systems roundup
When I started writing a post about architects, gardeners, and design systems, it was going to be a quick follow-up to my post about web standards, dictionaries, and design systems. I had spotted an interesting metaphor in one of Frank’s posts, and I thought it was worth jotting it down.
But after making that connection, I kept writing. I wanted to point out the fetishism we have for creation over curation; building over maintenance.
Then the post took a bit of a dark turn. I wrote about how the most commonly cited reasons for creating a design system—efficiency and consistency—are the same processes that have led to automation and dehumanisation in the past.
That’s where I left things. Others have picked up the baton.
Dave wrote a post called The Web is Industrialized and I helped industrialize it. What I said resonated with him:
This kills me, but it’s true. We’ve industrialized design and are relegated to squeezing efficiencies out of it through our design systems. All CSS changes must now have a business value and user story ticket attached to it. We operate more like Taylor and his stopwatch and Gantt and his charts, maximizing effort and impact rather than focusing on the human aspects of product development.
But he also points out the many benefits of systemetising:
At the same time, I have seen first hand how design systems can yield improvements in accessibility, performance, and shared knowledge across a willing team. I’ve seen them illuminate problems in design and code. I’ve seen them speed up design and development allowing teams to build, share, and validate prototypes or A/B tests before undergoing costly guesswork in production. There’s value in these tools, these processes.
Emphasis mine. I think that’s a key phrase: “a willing team.”
A design system that optimizes for consistency relies on compliance: specifically, the people using the system have to comply with the system’s rules, in order to deliver on that promised consistency. And this is why that, as a way of doing something, a design system can be pretty dehumanizing.
But a design system need not be a constraining straitjacket—a means of enforcing consistency by keeping creators from colouring outside the lines. Used well, a design system can be a tool to give creators more freedom:
Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow?
I definitely share Jeremy’s concern, but also think it’s important to stress that this isn’t an intrinsic issue with design systems, but rather the organizational culture that exists or gets built up around the design system. There’s a big difference between having smart, reusable patterns at your disposal and creating a dictatorial culture designed to enforce conformity and swat down anyone coloring outside the lines.
Brad makes a very apt comparison with Agile:
Not Agile the idea, but the actual Agile reality so many have to suffer through.
Agile can be a liberating empowering process, when done well. But all too often it’s a quagmire of requirements, burn rates, and story points. We need to make sure that design systems don’t suffer the same fate.
Jeremy’s thoughts on industrialization definitely struck a nerve. Sure, design systems have the ability to dehumanize and that’s something to actively watch out for. But I’d also say to pay close attention to the processes and organizational culture we take part in and contribute to.
Matthew Ström weighed in with a beautifully-written piece called Breaking looms. He provides historical context to the question of automation by relaying the story of the Luddite uprising. Automation may indeed be inevitable, according to his post, but he also provides advice on how to approach design systems today:
We can create ethical systems based in detailed user research. We can insist on environmental impact statements, diversity and inclusion initiatives, and human rights reports. We can write design principles, document dark patterns, and educate our colleagues about accessibility.
Care applies to the built environment, and especially to digital technology, as social media becomes the weather and the tools we create determine the expectations of work to be done and the economic value of the people who use those tools. A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement. Tools are always beholden to values. This is well-trodden territory.
Well-trodden territory indeed. Back in 2015, Travis Gertz wrote about Design Machines:
Designing better systems and treating our content with respect are two wonderful ideals to strive for, but they can’t happen without institutional change. If we want to design with more expression and variation, we need to change how we work together, build design teams, and forge our tools.
Design systems are certainly a new way of thinking about product development, and introduce a different set of tools to the design process, but design systems are not going to lessen the need for designers. They will instead increase the number of products that can be created, and hence increase the demand for designers.
And in 2019, Kaelig wrote:
In order to be fulfilled at work, Marx wrote that workers need “to see themselves in the objects they have created”.
When “improving productivity”, design systems tooling must be mindful of not turning their users’ craft into commodities, alienating them, like cogs in a machine.
All of this is reminding me of Kranzberg’s first law:
Technology is neither good nor bad; nor is it neutral.
I worry that sometimes the messaging around design systems paints them as an inherently positive thing. But design systems won’t fix your problems:
Just stay away from folks who try to convince you that having a design system alone will solve something.
It’s just the beginning.
At the same time, a design system need not be the gateway drug to some kind of post-singularity future where our jobs have been automated away.
As always, it depends.
Remember what Frank said:
A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement.
The reasons for creating a design system matter. Those reasons will probably reflect the values of the company creating the system. At the level of reasons and values, we’ve gone beyond the bounds of the hyperobject of design systems. We’re dealing in the area of design ops—the whys of systemising design.
This is why I’m so wary of selling the benefits of design systems in terms of consistency and efficiency. Those are obviously tempting money-saving benefits, but followed to their conclusion, they lead down the dark path of enforced compliance and eventually, automation.
But if the reason you create a design system is to empower people to be more creative, then say that loud and proud! I know that creativity, autonomy and empowerment is a tougher package to sell than consistency and efficiency, but I think it’s a battle worth fighting.
Design systems are neither good nor bad (nor are they neutral).
Addendum: I’d just like to say how invigorating it’s been to read the responses from Dave, Ethan, Brad, Matthew, and Frank …all of them writing on their own websites. Rumours of the demise of blogging may have been greatly exaggerated.
Aaaaaand the circle is now complete.
It is a crisis of care.
As with anything, it’s not about the technology itself:
A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement. Tools are always beholden to values. This is well-trodden territory.
Another follow-on to my post about design systems and automation. Here, Matthew invokes the spirit of the much-misunderstood Luddite martyrs. It’s good stuff.
Design systems are used by greedy software companies to fatten their bottom line. UI kits replace skilled designers with cheap commoditized labor.
Agile practices pressure teams to deliver more and faster. Scrum underscores soulless feature factories that suck the joy from the craft of software development.
But progress requires more than breaking looms.
Tuesday, February 4th, 2020
Brad weighs in on what I wrote about design systems and automation. He rightly points out that the issue isn’t with any particular tool—and a design system is, after all, a tool—but rather with the culture and processes of the organisation.
Sure, design systems have the ability to dehumanize and that’s something to actively watch out for. But I’d also say to pay close attention to the processes and organizational culture we take part in and contribute to.
There’s a full-on rant here about the dehumanising effects of what’s called “agile” at scale:
I’ve come to the conclusion that “enterprise web development” is just regular web development, only stripped of any joy or creativity or autonomy. It’s plugging a bunch of smart people into the matrix and forcing them to crank out widgets and move the little cards to the right.
But a design system that optimizes for consistency relies on compliance: specifically, the people using the system have to comply with the system’s rules, in order to deliver on that promised consistency. And this is why that, as a way of doing something, a design system can be pretty dehumanizing.
Ethan shares his thoughts on what I wrote about design systems and automation. He offers this test on whether a design system is empowering or disempowering:
Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow?
Monday, December 9th, 2019
When people ask where to find you on the web, what do you tell them? Your personal website can be your home on the web. Or, if you don’t like to share your personal life in public, it can be more like your office. As with your home or your office, you can make it work for your own needs. Do you need a place that’s great for socialising, or somewhere to present your work? Without the constraints of somebody else’s platform, you get to choose what works for you.
A terrific piece from Laura enumerating the many ways that having your own website can empower you.
Have you already got your own website already? Fabulous! Is there anything you can do to make it easier for those who don’t have their own sites yet? Could you help a person move their site away from a big platform? Could you write a tutorial or script that provides guidance and reassurance?
Friday, August 2nd, 2019
Saturday, April 13th, 2019
Dave stops feeding his site’s visitors data to Google. I wish more people (and companies) would join him.
There’s also an empowering #indieweb feeling about owning your analytics too. I pay for the server my analytics collector runs on. It’s on my own subdomain. It’s mine.
Monday, January 7th, 2019
Dave on the opaqueness of toolchains:
As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming. When there’s a problem, it’s increasingly difficult to hop into the assembly line and diagnose the issue.
There’s a connection here to one of the biggest issues with what’s currently being labelled “AI”:
In the same way AI needs some design to show its work in how it came to its final answer, I feel that our automated build tools could use some help as well.
I really like this suggestion for making the invisble visible:
I sometimes wonder if Webpack or Gulp or [Insert Your Build Tool Here] could benefit from a Scratch-like interface for buildchains.
Thursday, September 13th, 2018
This is something I struggle to articulate to friends who are suffering because they feel tied to silos like Facebook and Twitter:
What self-publishing does is provide me a choice, which makes me feel good. I feel like I can step away from platforms at will and I don’t feel as shackled as I have done previously.
Tuesday, July 24th, 2018
A very thoughtful post from Stuart, ostensibly about “view source”, but really about empowerment, choice, and respect.
I like that the web is made up of separate bits that you can see if you want to. You can understand how it works by piecing together the parts. It’s not meant to be a sealed unit, an appliance which does what the owner wants it to and restricts everything else. That’s what apps do. The web’s better than that.
Tuesday, July 3rd, 2018
“I Was Devastated”: Tim Berners-Lee, the Man Who Created the World Wide Web, Has Some Regrets | Vanity Fair
Are we headed toward an Orwellian future where a handful of corporations monitor and control our lives? Or are we on the verge of creating a better version of society online, one where the free flow of ideas and information helps cure disease, expose corruption, reverse injustices?
It’s hard to believe that anyone—even Zuckerberg—wants the 1984 version. He didn’t found Facebook to manipulate elections; Jack Dorsey and the other Twitter founders didn’t intend to give Donald Trump a digital bullhorn. And this is what makes Berners-Lee believe that this battle over our digital future can be won. As public outrage grows over the centralization of the Web, and as enlarging numbers of coders join the effort to decentralize it, he has visions of the rest of us rising up and joining him.
Sunday, July 1st, 2018
Before social media monoliths made us into little mechanical turks for advertising platforms, we had organic homes on the web. We had pages that were ours. And they could look however you wanted. And you could write whatever you wanted on there.
There weren’t comments if you didn’t want them. There were no photo dimensions to adhere to. No 140-character limits. No BS. Or lots of BS. Either way, the choice was yours because you owned your site and you could do whatever you wanted.
Wednesday, June 27th, 2018
Between the utopian and dystopian, which vision of the future seems more likely to you? Which vision seems more true to how we currently live with technology, in the form of our smartphones and social media apps?
Saturday, June 23rd, 2018
If only all documentation was as great as this old manual for the ZX Spectrum that Remy uncovered:
The manual is an instruction book on how to program the Spectrum. It’s a full book, with detailed directions and information on how the machine works, how the programming language works, includes human readable sentences explaining logic and even goes so far as touching on what hex values perform which assembly functions.
When we talk about things being “inspiring”, it’s rarely in regards to computer manuals. But, damn, if this isn’t inspiring!
This book stirs a passion inside of me that tells me that I can make something new from an existing thing. It reminds me of the 80s Lego boxes: unlike today’s Lego, the back of a Lego box would include pictures of creations that you could make with your Lego set. It didn’t include any instructions to do so, but it always made me think to myself: “I can make something more with these bricks”.
Friday, June 1st, 2018
Beneath the URL shorteners, the web!
It’s increasingly apparent that a more digitally literate citizenry would be good for a thousand different reasons. A great way to start would be to make URLs visible again, to let people see the infrastructure they’re living in.
Wednesday, April 4th, 2018
When I’m asked to give an example of a beautiful piece of design, perfect in form and function, I often respond with “the URL.”
I love every word of this beautifully-written love letter from Brendan.
Friday, March 30th, 2018
A Firefox plugin that ring-fences all Facebook activity to the facebook.com domain. Once you close that tab, this extension takes care of garbage collection, ensuring that Facebook tracking scripts don’t leak into any other browsing activities.