Tags: scaling

25

sparkline

Friday, July 14th, 2023

Why design systems fail by Karen Vanhouten

  1. No shared (and contextual) sense of purpose
  2. Overbuilding, or scaling too early
  3. Inability to make decisions and move forward quickly
  4. Lack of clear ownership and dedicated resources
  5. Lack of cultural alignment

The common thread among these issues is that none are related to technical or tooling decisions —or even to the components themselves.

Sunday, January 22nd, 2023

clamp() Calculator · Chris Burnell

Like a little mini Utopia:

Handy little tool for calculating viewport-based clamped values.

Tuesday, January 17th, 2023

Scalable CSS - Chris Coyier

Wise words:

Myself, I think some tools are a good idea. But as few as possible, and the easier they are to stop using, the better.

To paraphrase Michael Pollan:

Write CSS, not too much, mostly vanilla.

Sunday, November 27th, 2022

ongoing by Tim Bray · Bye, Twitter

I don’t like making unpaid contributions to a for-profit publisher whose proprietor is an alt-right troll.

Same.

I can see no good arguments for redirecting my voice into anyone else’s for-profit venture-funded algorithm-driven engagement-maximizing wet dream.

Friday, November 11th, 2022

Fediverse

Despite growing pains and potential problems, I think this could be one of the most interesting movements on the web in recent years. Let’s see where it goes.

I’m getting the same vibe as Bastian about Mastodon:

Suddenly there was this old Twitter vibe. Real conversations. Real people. Interesting content. A feeling of a warm welcoming group. No algorithm to mess around with our timelines. No troll army to destory every tiny bit of peace. Yes, Mastodon is rough around the edges. Many parts are not intuitive. But this roughness somehow added to the positive experience for me.

This could really work!

Thursday, April 1st, 2021

Meet Utopia: Designing And Building With Fluid Type And Space Scales — Smashing Magazine

An excellent explainer from Trys and James of their supersmart Utopia approach:

Utopia encourages the curation of a system small enough to be held in short-term memory, rather than one so sprawling it must be constantly referred to.

Wednesday, March 17th, 2021

Fluid Space Calculator | Utopia

Type and space are linked, so if you’re going to have a fluid type calculator, it makes sense to have a fluid space calculator too. More great work from Trys and James!

Thursday, February 4th, 2021

Continuous Typography / MK

Sounds like some convergent thinking with the ideas behind Utopia.

I think that the idea that that any typographic attribute (including variable font parameters) can be a function (linear, exponential, stepped, Bezier, random, or otherwise) of any given input variable (user preference, screen dimensions, connection speed, time of day, display language, or whatever else) is an incredibly powerful one, and worth exploring as an aesthetic as well as a technical proposition.

Here’s a demo you can play with.

Thursday, October 1st, 2020

Clamp | Utopia

Trys has been investigating how to incorporate CSS clamp() into the brilliant Utopia project. I won’t pretend to understand all the maths here—this is a very deep dive!

He’s also created a CSS generator Mark 2 if you want to use clamp() in your fluid type.

Friday, September 28th, 2018

What is Modular CSS?

A walk down memory lane, looking at the history modular CSS methodologies (and the people behind them):

Wednesday, July 25th, 2018

Beyond style guides: lessons from scaling design at TELUS

I like the questions that the TELUS team ask about any potential components to be added to their design system:

  1. Is it on brand?
  2. Is it accessible?
  3. Has it been tested?
  4. Can it be reused?

They also have design principles.

Saturday, May 26th, 2018

No, design systems will not replace design jobs — DesignSystems.com

No longer focused on recreating the wheel (or icon), designers can turn their attention to different types of challenges.

Wednesday, May 9th, 2018

Choosing tools for scaling design

Tools and processes are intertwined. A company or a department or an individual has a way of doing things—that’s the process. They also have software to carry out the process—those are the tools.

Ideally, they should be loosely coupled. You should be able to change your tools without necessarily changing your process. So swapping out, say, one framework or library for another shouldn’t involve fundamentally changing the way you work. Likewise, trying a new way of working shouldn’t require you to use unfamiliar tools.

When it comes to scaling design within organisations, the challenges are almost always around switching processes (well, really it’s about trying to change culture, but that starts with changing processes—any sufficiently advanced process is indistinguishable from culture). All too often, though, I see people getting hung up on the tools.

We need to get more efficient in how we deliver designs …so let’s switch over to this particular design tool.

We should have a design system …so let’s get everyone using this particular JavaScript framework.

I understand this desire to shortcut the work of figuring out processes and jump straight to production solutions. For one thing, it allows you to create an easy list of requirements when it comes to recruiting talent: “Join our company—you must demonstrate experience and proficiency in this tool or that library.”

But when tools and processes become tightly coupled like this, there’s a real danger of stagnation. If a process can be defined as “the way we do things around here”, that’s not something you want to tie to any particular tool or technology. Otherwise, before you know it, you’re in the frustrating situation of using outdated tools, but you can’t swap them out for newer or better-suited technologies without disrupting everyone’s work.

This is technical debt (although it applies just as much to design). You’re paying a penalty in the present because of a decision that somebody made in the past. The problem isn’t so much with the decision itself, but with the longevity of its effects.

I think it’s important to remember what a tool is: it’s a piece of technology that enables you to work faster or better. You should enjoy using your tools, but you shouldn’t be utterly dependent on any particular one. Otherwise, the tail starts wagging the dog—you are now in service to the tool, instead of the other way around.

Treat your tools like cattle, not pets. Don’t get too attached to any one technology to the detriment of missing out on others.

Mind you, if you constantly tried every single new tool or technology out there, you’d never settle on anything—I’m pretty sure that three new JavaScript frameworks have been released since you started reading this paragraph.

The tools you choose at any particular time should be suited to what you’re trying to accomplish at that time. In other words, you’ve got to figure out what you’re trying to accomplish first (the vision), then figure out how you’re going to accomplish it (the process), and only then figure out which tools are the best fit. If you jump straight to choosing tools, you could end up trying to tighten a screw with a hammer.

Alas, I’ve seen plenty of consultants who conflate strategy with tooling. They’re brought in to solve process problems and, surprise, surprise, the solution always seems to involve purchasing the software that their company sells. I’ve been guilty of this myself: I see an organisation struggling to systemise their design patterns, and I think “Oh, they should use Fractal!” …but that’s jumping the gun. They might be better served with something simpler, or something more complex (I mean, Fractal is very, very flexible but it’s still just one option—there are plenty of other pattern library tools out there).

Once you separate out the tools from the process, there’s an added benefit. Making the right technology choice is no longer a life-or-death decision. You can suck it and see. Try out the technology and see if it works. If it’s working, great! Carry on using it. If it’s not working, that’s okay too. Try something different.

I realise I’m oversimplifying things, but I honestly believe that the real challenge is not choosing the right tools, but figuring out the right process for your team.

Tuesday, May 8th, 2018

Process and culture

Cameron has a bone to pick. Why, oh, why, he wonders, are we so quick to create processes when what we really need is a good strong culture?

Strong culture = less process

To stop people breaking stuff: make a process for it. Want to make people act responsibly: make a process for it. Tired of telling people about something? Make a process for it.

For any single scenario you can name it’ll be easier to create a process for it than build a culture that handles it automatically. But each process is a tiny cut away from the freedom that you want your team to enjoy.

I take his point, but I also think that some processes are not only inevitable, but downright positive. There should be a process for handling payroll. There should be a process for handling promotions. Leaving that to culture might sound nice and nimble, but it could also lead to unintentional bias and unfairness.

But let’s leave those kind of operational processes aside and focus on process and culture when it comes to design and engineering. Cameron’s point is well taken here. Surely you want people to just know the way things are done? Surely you want people to just get on with doing the work without putting hurdles in their way?

On the face of it, yes. If you’re trying to scale design at your organisation, then every extra bit of process is going to slow down your progress.

But what if speed isn’t the most important metric of success when it comes to scaling design? You’ve got to make sure you’re scaling the right things.

Mark writes:

This is a post in defence of process. Yes, I know what you’re thinking: ‘urgh, process is a thing put in place to make up for mediocre teams’; or ‘prioritise discussion over documentation’; or ‘I get enough red tape in other parts of my life’.

The example he gives is undeniably a process that will slow things down …deliberately.

Whenever someone asks me to do something that I think seems ill-conceived in some way, I ask them to write it down. That’s it. Because writing is high effort. Making sentences is the easy bit, it’s the thinking I want them to do. By considering their request it slows them down. Maybe 30% of the time or something, they come back and say ‘oh, that thing I asked you to do, I’ve had a think and it’s fine, we don’t need to do it’.

I’ve seen this same tactic employed in standards bodies. Somebody bursts into a group and says “I’ve got a great idea—we should make this a thing!” The response, no matter what the idea is, is to say “Document use-cases.” It’s a stumbling block, and also a bit of a test—if they do come back with use-cases, the idea can be taken seriously; the initial enthusiasm needs to be backed up with hard graft.

(On a personal level, I sometimes use a little trick when it comes to email. If someone sends me a short email that would require a long response from me, I’ll quickly fire back a clarifying question: “Quick question: did you mean X or Y?” Now the ball is back in their court. If they respond swiftly with an answer to my question, then they’ve demonstrated their commitment and I honour their initial request.)

Anyway, it sounds like Cameron is saying that process is bad, and Mark is saying process can be good. Cody Cowan from Postlight thinks they’re both right:

To put it bluntly: people, not process, are the problem.

Even so, he acknowledges Cameron’s concern:

One of the biggest fears that people have about process is that something new is going to disrupt their work, only to be replaced by yet another rule or technique.

I think we can all agree that pointlessly cumbersome processes are bad. The disagreement is about whether all processes are inherently bad, or whether some processes are not only necessary, but sometimes even beneficial.

When Cameron talks about the importance of company culture, he knows whereof he speaks. He’s been part of Canva’s journey from a handful of people to hundreds of people. They’ve managed to scale their (excellent) culture along the way. That’s quite an achievement—scaling culture is really, really challenging. Scaling design is hard. Scaling culture is even harder.

But you know what’s even more challenging than scaling culture? Changing culture.

What if your company didn’t start with a great culture to begin with? What if you’re not Canva? What if you’re not AirBnB? What are your options then?

You can’t create a time travel machine to go back to the founding of the company and ensure a good culture from the outset.

You can’t shut down your existing company and create a new company from scratch, this time with a better culture.

You’ve got to work with what you’ve got. That doesn’t mean you can’t change your company culture, but it’s not going to be easy. Culture is pretty far down the stack of pace layers—it’s slow to change. But you can influence culture by changing something that’s less slow to change. I would argue the perfect medium for this is …process.

Once you know what values you’re trying to embed into your culture, create processes that amplify and reward those values. I totally understand the worry that these processes will reduce autonomy and freedom, but I think that only applies if the company already has a strong culture of autonomy and freedom. If you’re trying to create a culture of autonomy and freedom, then—as counter-intuitive as it may seem—you can start by putting processes in place.

Then, over time, those processes can seep into the day-to-day understanding of how things are done. Process dissolves into culture. It’s a long game to play, but as Cameron points out, that’s the nature of culture change:

Where culture pays off is in the long run. It’s hard work: defining the culture, hiring for the culture and communicating the culture again, and again, and again. But if you want to make a company where people are empowered, passionate, and champions of your organisation then it’s the only path forward.

Monday, May 7th, 2018

Design systems

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

  1. the problem being solved;
  2. when to use this pattern;
  3. when not to use this pattern.

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?

Sunday, April 15th, 2018

Keep Pixelated Images Pixelated as They Scale | CSS-Tricks

This is a potentially useful bit of CSS that I had no idea existed.

Tuesday, November 28th, 2017

Design Systems Handbook - DesignBetter.Co

A weirdly over-engineered online book with bizarre scrolljacking (I would advise disabling JavaScript but then all the links stop working so you won’t be able to go past the table of contents) but it’s free and the content—by Marco Suarez, Jina Anne, Katie Sylor-Miller, Diana Mounter, and Roy Stanfield— looks good:

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.

Friday, September 30th, 2016

GreenSock | “will-change” must change? Animators beware.

This will-change property that was intended to SOLVE problems for animators may end up doing the opposite.

It seems wise for the browsers to step back and let the spec authors fill in the implementation details and gain consensus before moving forward.

Thursday, September 29th, 2016

Building Resizeable Components with Relative CSS Units | CSS-Tricks

A thorough and compelling demonstration of why it makes sense to size all the properties of your components—font size, margins, borders, etc.—in ems or rems rather than mixing in pixels for some properties. It’s all about the scalability, innit?

Monday, March 28th, 2016

CSS and Scalability

Some good thoughts in here about writing scalable CSS …although the finger-pointing at sites (that are shipping at scale) reminds me a bit of that quote by copywriter Paul Butterworth: “Where the heck were you when the page was blank?”