It’s possible to create components in a vacuum, but ultimately you have no idea whether or not those components can successfully address your user and business needs. I’ve witnessed firsthand several design system initiatives crash and burn due to components created in isolation.
Tuesday, July 17th, 2018
Tuesday, July 10th, 2018
Rachel goes into detail on how she uses pattern libraries—built with Fractal to build interfaces. I know it sounds like we paid her to say all the nice things about Fractal, but honestly, we didn’t even know she was writing this article!
After discovering Fractal two years ago, we have moved every new project — large and small — into Fractal.
Sunday, June 3rd, 2018
I’ve come to believe that the goal of any good framework should be to make itself unnecessary.
The ultimate purpose of PhoneGap is to cease to exist.
That makes total sense, especially if your code is a polyfill—those solutions are temporary by design. Autoprefixer is another good example of a piece of code that becomes less and less necessary over time.
But I think it’s equally true of any successful framework or library. If the framework becomes popular enough, it will inevitably end up influencing the standards process, thereby becoming dispensible.
querySelector without jQuery. The library proved the need for the feature. The same is true for a whole load of DOM scripting features.
The same process is almost certain to occur with React—it’s a good bet there will be a standardised equivalent to the virtual DOM at some point.
When Google first unveiled AMP, its intentions weren’t clear to me. I hoped that it existed purely to make itself redundant:
As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask “Why can’t our regular pages be this fast?” By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be.
Alas, as time has passed, that hope shows no signs of being fulfilled. If anything, I’ve noticed publishers using the existence of their AMP pages as a justification for just letting their “regular” pages put on weight.
Worse yet, the messaging from Google around AMP has shifted. Instead of pitching it as a format for creating parallel versions of your web pages, they’re now also extolling the virtues of having your AMP pages be the only version you publish:
In fact, AMP’s evolution has made it a viable solution to build entire websites.
On an episode of the Dev Mode podcast a while back, AMP was a hotly-debated topic. But even those defending AMP were doing so on the understanding that it was more a proof-of-concept than a long-term solution (and also that AMP is just for news stories—something else that Google are keen to change).
But now it’s clear that the Google AMP Project is being marketed more like a framework for the future: a collection of web components that prioritise performance …which is kind of odd, because that’s also what Google’s Polymer project is. The difference being that pages made with Polymer don’t get preferential treatment in Google’s search results. I can’t help but wonder how the Polymer team feels about AMP’s gradual pivot onto their territory.
If the AMP project existed in order to create a web where AMP was no longer needed, I think I could get behind it. But the more it’s positioned as the only viable solution to solving performance, the more uncomfortable I am with it.
Which, by the way, brings me to one of the most pernicious ideas around Google AMP—positioning anyone opposed to it as not caring about web performance. Nothing could be further from the truth. It’s precisely because performance on the web is so important that it deserves a long-term solution, co-created by all of us: not some commandents delivered to us from on-high by one organisation, enforced by preferential treatment by that organisation’s monopoly in search.
It’s the classic logical fallacy:
- Performance! Something must be done!
- AMP is something.
- Now something has been done.
By marketing itself as the only viable solution to the web performance problem, I think the AMP project is doing itself a great disservice. If it positioned itself as an example to be emulated, I would welcome it.
I wish that AMP were being marketed more like a temporary polyfill. And as with any polyfill, I look forward to the day when AMP is no longer necesssary.
I want AMP to become extinct. I genuinely think that the Google AMP team should share that wish.
In my experience, there’s no casual mode within React. You need to be all-in, keeping up with the ecosystem, or else your knowledge evaporates.
I think Dave is right. At this point, it’s possible to be a React developer exclusively.
React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.
And, as Jake points out, you either need to go all in or not at all—you can’t really incrementally add Reactness to an existing project.
Monday, May 7th, 2018
Ethan emphasises the importance of making a shared language the heart of any design system. I heartily agree!
This isn’t new thinking, mind: folks like Alla Kholmatova and Charlotte Jackson have been talking about this for ages. (And in doing so, they’ve massively influenced how I think about modular, pattern-driven design.)
Sunday, April 15th, 2018
A terrific talk by Adrian Holovaty. I really hope front-end developers talk its message to heart.
Tuesday, March 27th, 2018
The canonical example in just about every pattern library is documenting button variations. Here, Tyler shows how even this seemingly simple pattern takes a lot of thought.
Tuesday, February 27th, 2018
Wise words from Ethan on how to react when people create bespoke patterns instead of using something in an existing pattern library.
It’s easy for an organization to look at that one-off pattern as a problem of compliance, of not following the established rules. And in many cases, that might be true! But it’s also worth recognizing when a variation’s teaching you a lesson: namely, that your design system isn’t meeting the needs of the people who’re using it.
Friday, February 16th, 2018
Another brilliant talk from Frank, this time on the (im)balance between the commercial and the cultural web.
Remember: the web is a marketplace and a commonwealth, so we have both commerce and culture; it’s just that the non-commercial bits of the web get more difficult to see in comparison to the outsized presence of the commercial web and all that caters to it.
This really resonates with me:
If commercial networks on the web measure success by reach and profit, cultural endeavors need to see their successes in terms of resonance and significance.
Sunday, February 11th, 2018
Harsh (but fair) assessment of the performance costs of doing everything on the client side.
Friday, January 26th, 2018
Ben makes the very good point that template literals allow you to do a lot of useful stuff that previously would’ve required a library:
Template Literals afford a lot of power with no library overhead. I will definitely continue to use them when complexity of handlebars or similar is overkill.
Chris made a similar observation a little while back. Throw in a little script like lit-html and now you’ve got DOM-diffing too. You might not need insert-current-framework-name after all.
Kinda cool that these mini-libraries exist that do useful things for us, so when situations arise that we want a feature that a big library has, but don’t want to use the whole big library, we got smaller options.
Thursday, January 25th, 2018
Design ops for design systems
Leading Design was one of the best events I attended last year. To be honest, that surprised me—I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.
Seeing as the event was all about design leadership, there was inevitably some talk of design ops. But I noticed that the term was being used in two different ways.
Sometimes a speaker would talk about design ops and mean “operations, specifically for designers.” That means all the usual office practicalities—equipment, furniture, software—that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That’s good advice, as long as you understand what’s meant by design ops in that context.
There’s another context of use for the phrase “design ops”, and it’s one that we use far more often at Clearleft. It’s related to design systems.
Now, “design system” is itself a term that can be ambiguous. See also “pattern library” and “style guide”. Quite a few people have had a stab at disambiguating those terms, and I think there’s general agreement—a design system is the overall big-picture “thing” that can contain a pattern library, and/or a style guide, and/or much more besides:
- Styleguides, Pattern Libraries and Design Languages
- Design Systems vs. Pattern Libraries vs. Style Guides – What’s the Difference?
- Design Systems, Style Guides, and Pattern Libraries: Oh My!
- What’s the difference between style guides, pattern libraries, and design systems?
None of those great posts attempt to define design ops, and that’s totally fair, because they’re all attempting to define things—style guides, pattern libraries, and design systems—whereas design ops isn’t a thing, it’s a practice. But I do think that design ops follows on nicely from design systems. I think that design ops is the practice of adopting and using a design system.
There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term design ops, I think that’s what all of them are about:
- Why Design Systems Fail
- Tips for in-house teams in a free market software culture
- Putting your design system into practice
Clearly design systems and design ops are very closely related: you really can’t have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.
I realise that tying design ops directly to design systems is somewhat limiting, and the truth is that design ops can encompass much more. I like Andy’s description:
Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.
Now, in theory, that can encompass any operational stuff—equipment, furniture, software—but in practice, when we’re dealing with design ops, 90% of the time it’s related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term design ops works well …as long as everyone involved is clear on the kind of design ops we’re all talking about.
Monday, January 1st, 2018
Thursday, December 14th, 2017
Great advice from Una on getting buy-in and ensuring the long-term success of a design system.
Thursday, December 7th, 2017
When you start a redesign process for a company, it’s very easy to briefly look at all their products (apps, websites, newsletters, etc) and first of all make fun of how bad it all looks, and then design this one single design system for everything. However, once you start diving into why those decisions were made, they often reveal local knowledge that your design system doesn’t solve.
In this talk transcript, Rune Madsen enumerates the reasons for his informed scepticism towards design systems:
- The first concern, which is also the main argument of this talk, is that humans – especially designers and engineers – are obsessed with creating systems of order. This is not really driven by a demand from users, so they often tend to benefit the designer, not the user.
- My second concern relates to what I believe design systems is doing to our digital experience. We’ve always had trends in graphic design (Swiss design, Flat UI, etc), but I’m getting increasingly concerned that this broad adoption of design systems is creating a design monoculture that really narrows the idea of what digital products can be.
- My third concern is that with all this talk about design systems, there’s very little talk about the real problem in digital design, which is processes and tools. Designers love making design manuals, but any design system will completely and utterly fail if it doesn’t help people in the organization produce faster and better products.
Tuesday, November 28th, 2017
A design system unites product teams around a common visual language. It reduces design debt, accelerates the design process, and builds bridges between teams working in concert to bring products to life. Learn how you can create your design system and help your team improve product quality while reducing design debt.
Monday, November 27th, 2017
A table of design systems, pattern libraries, style guides, or whatever we’re calling them.
Thursday, November 16th, 2017
I think Dan is on to something here—design tools that offer pixel perfection at an early stage are setting us up for disappointment and frustration. Broad brushstrokes early on, followed by more precise tinkering later, feels like a more sensible approach.
With the help of a robust and comprehensive design system, I am certain that we could design in much broader strokes, and concentrate on making the finished product, rather than our design outputs, highly precise and reflective of our ideal.
Wednesday, November 15th, 2017
A collection of publicly available design systems, pattern libraries, and interface guidelines.
Thursday, November 2nd, 2017
The slides from Yesenia’s talk on scenario-driven design.