Find freedom not in infinite choice, but in working a single seam until you strike gold: conducting dozens, even hundreds, of iterations within a tight parameter space—not in search of more, but in search of better.
I don’t normally link to articles on Medium—I respect you too much—and I do wish this were written on Mike Hall’s own site, but this is just too good not to share.
And don’t dismiss this as a nostalgiac case study from the past:
At no point did the constraints make the product feel compromised. Users on modern devices got a smooth experience and instant feedback, while those on older devices got fast, reliable functionality. Users on feature phones got the same core experience without the bells and whistles.
The constraints forced us to solve problems in ways we wouldn’t have considered otherwise. Without those constraints, we could have just thrown bytes at the problem, but with them every feature had to justify itself. Core functionality had to work everywhere, and without JavaScript crutches proper markup became essential.
This experience changed how I approach design problems. Constraints aren’t a straitjacket, keeping us from doing our best work; they are the foundation that makes innovation possible. When you have to work within severe limitations, you find elegant solutions that scale beyond those limitations.
Design systems as codified constraints.
If you treat data as a constraint in your design and development process, you’ll likely be able to brainstorm a large number of different ways to keep data usage to a minimum while still providing an excellent experience. Doing less doesn’t mean it has to feel broken.
Designing your design process:
- Know your strengths and focus resources on your weaknesses.
- Learn to identify the immovable objects.
- What has to be perfect now and what can be fixed later?
Talking about scaling design can get very confusing very quickly. There are a bunch of terms that get thrown around: design systems, pattern libraries, style guides, and components.
The generally-accepted definition of a design system is that it’s the outer circle—it encompasses pattern libraries, style guides, and any other artefacts. But there’s something more. Just because you have a collection of design patterns doesn’t mean you have a design system. A system is a framework. It’s a rulebook. It’s what tells you how those patterns work together.
This is something that Cennydd mentioned recently:
Here’s my thing with the modularisation trend in design: where’s the gestalt?
In my mind, the design system is the gestalt. But Cennydd is absolutely right to express concern—I think a lot of people are collecting patterns and calling the resulting collection a design system. No. That’s a pattern library. You still need to have a framework for how to use those patterns.
I understand the urge to fixate on patterns. They’re small enough to be manageable, and they’re tangible—here’s a carousel; here’s a date-picker. But a design system is big and intangible.
Games are great examples of design systems. They’re frameworks. A game is a collection of rules and constraints. You can document those rules and constraints, but you can’t point to something and say, “That is football” or “That is chess” or “That is poker.”
Even though they consist entirely of rules and constraints, football, chess, and poker still produce an almost infinite possibility space. That’s quite overwhelming. So it’s easier for us to grasp instances of football, chess, and poker. We can point to a particular occurrence and say, “That is a game of football”, or “That is a chess match.”
But if you tried to figure out the rules of football, chess, or poker just from watching one particular instance of the game, you’d have your work cut for you. It’s not impossible, but it is challenging.
Likewise, it’s not very useful to create a library of patterns without providing any framework for using those patterns.
I would go so far as to say that the actual code for the patterns is the least important part of a design system (or, certainly, it’s the part that should be most malleable and open to change). It’s more important that the patterns have been identified, named, described, and crucially, accompanied by some kind of guidance on usage.
I could easily imagine using a tool like Fractal to create a library of text snippets with no actual code. Those pieces of text—which provide information on where and when to use a pattern—could be more valuable than providing a snippet of code without any context.
One of the very first large-scale pattern libraries I can remember seeing on the web was Yahoo’s Design Pattern Library. Each pattern outlined
Only then, almost incidentally, did they link off to the code for that pattern. But it was entirely possible to use the system of patterns without ever using that code. The code was just one instance of the pattern. The important part was the framework that helped you understand when and where it was appropriate to use that pattern.
I think we lose sight of the real value of a design system when we focus too much on the components. The components are the trees. The design system is the forest. As Paul asked:
What methodologies might we uncover if we were to focus more on the relationships between components, rather than the components themselves?
The slides from a presentation by Drew on all the functionality that browsers give us for free when it comes to validating form inputs.
Half the battle of the web platform is knowing what technology is out there, ready to use. We’re all familiar with the ability to declare validation constraints in our HTML5 forms, but were you aware there’s a JavaScript API that goes along with it?
A social network for snippets of JavaScript effects in canvas, written in 140 characters or fewer. Impressive!
Hit this URL to give yourself a design constraint (or obstruction). Kind of like Brian Eno’s oblique strategies but with different categories of constraints: formal, methodological, and conceptual.
Rachel takes a look back at twenty years of building on the web. Her conclusion: we’ve internalised constraints that are no longer relevant, and that’s holding us back from exploring new design possibilities:
Somehow the tables have turned. As the web moves on, as we get CSS that gives us the ability to implement designs impossible a few years ago, the web looks more and more like something we could have build with rudimentary CSS for layout. We’ve settled on our constraints and we are staying there, defined by not being print.