Design systems, systems thinking, and the "curse of the gifted"

A friend of mine calls it "the curse of the gifted" -- a tendency to lean on your native ability too much, because you've always been rewarded for doing that and self-discipline would take actual work.

You are a brilliant implementor, more able than me and possibly (I say this after consideration, and in all seriousness) the best one in the Unix tradition since Ken Thompson himself.  As a consequence, you suffer the curse of the gifted programmer -- you lean on your ability so much that you've never learned to value certain kinds of coding self-discipline and design craftsmanship that lesser mortals *must* develop in order to handle the kind of problem complexity you eat for breakfast.

But you make some of your more senior colleagues nervous.  See, we've seen the curse of the gifted before.  Some of us were those kids in college.  We learned the hard way that the bill always comes due -- the scale of the problems always increases to a point where your native talent alone doesn't cut it any more.  The smarter you are, the longer it takes to hit that crunch point -- and the harder the adjustment when you finally do.  And we can see that *you*, poor damn genius that you are, are cruising for a serious bruising.

As Linux grows, there will come a time when your raw talent is not enough.  What happens then will depend on how much discipline about coding and release practices and fastidiousness about clean design you developed *before* you needed it, back when your talent was sufficient to let you get away without.

http://lwn.net/2000/0824/a/esr-sharing.php3

How Linus Torvalds works (as written in this post) is how I cook. ;) I don't measure, I eyeball everything. I do things until they "look right" and then I stop.

I would never ever ever do that fast, loose, play-it-by-eye-and-natural-talent with a design system, because I have learned that it just doesn't scale. In fact, I design... design systems specifically to avoid or mitigate the "curse of the gifted".

At the end of the day, a design system that isn't easy enough to use by all involved in the SDLC, so much so that it becomes the default pit of success that teams fall into together... is a failed design system. Or one that is currently failing, at any rate. Failures can be remedied, so there is that.

I see a disturbing tendency to approach design systems (especially for enterprise) with far too much reliance on 'the curse of the gifted'. This is especially evident when every piece of a design system is designed on an ad-hoc basis, with no regard to how it fits into everything else. If the designer's eye is good enough, they can skate by on the curse of the gifted - until they cannot, anymore. And their teams? God help their teams. 

When it comes to design systems - I want the opposite of skating by on talent. I want to help build design systems that enable delivery teams to fall into the pit of success together. The kinds of systems that improve collaboration for everyone, because of a clear, shared understanding of what it is we want to do, and what we have on hand to do it. Design systems where the default is usually the right choice, where guesswork is kept to a minimum... and yet where necessary changes can be made on the fly with the minimum of cost, or drama. And while I'm describing my ideal pony, I want to be able to stay and see such a system grow and evolve over time.

Right now, I'm still looking for that pony. Maybe I'll get lucky. ;)

Things to consider when defining default animation timings and easings for user interfaces

I meant to rewrite this nicely a long time ago, never got down to re-writing it. And yet... it seems like it could help people. So here's the original braindump version.



Default timing for animations == 200ms. Default easing == Ease In-Out

This is the simplest way to achieve what we want, in terms of animation.

What we are doing here can be considered "semantic" animation, as it is the animations that "explain" to the user why and how the map is being displayed to them. The equivalent is a book opening, or a page turning.

If possible, make the timings and the animation types customisable, with defaults.


Why 200ms?
Because when it comes to things we interact with mostly visually, 200ms is the amount of time it takes the human brain to register that something has come into view, or changed. At 200ms, UI animation feels almost instant.

Now, we could get pickier, and make it 300-400ms for XS, SM, and 200ms for MD, L, XL, because the distance travelled by the animated objects also influences how fast they feel. However, this lies in the realm of "fancy extras". They are nice, but if we start doing that, then to be consistent, we need to do it EVERYWHERE.

So 200ms. ;) For everything.

Please note that this is a visual thing. If you are writing with a stylus, and the lag is 200ms (or you're gaming! ;) ) 200ms, is way way way too slow. When writing with a digital stylus, or drawing with a mouse, the latency has to be as close to 0 as possible. Even 100ms feels laggy when you draw with a stylus or a mouse.


Why Ease In-Out?
Easing makes animations look more natural, by visually mimicking the laws of physics.

We're using Ease In-Out as the default, as it mimics physics, AND is less confusing for most people who aren't professional animators.

But whyyyyy! ;) Ok here's why...

If we wanted to be picky, when something animates INTO view, we should use Ease-Out. Ease-Out is when something moves fast at first, and then slows down. This mimics physics in the real world, where stuff loses momentum as it moves, due to friction. So it starts fast (because as it's animating into our view, it's already moving), and as it runs out of energy, it slows down.

Likewise, when something animates OUT OF view, we should use Ease-In. Ease-In is when something moves slowly at first, and then speeds up. Again, this mimics physics in the real world, where it takes time for stuff to build up momentum, and then it goes faster as it collects enough energy to overcome friction. So it starts slow (because it's charging up, while still being in our view), and then the animation speeds up as the item leaves our view.

^And yes, for stuff that comes INTO view, it's better to use Ease-OUT, for stuff that LEAVES our view, it's better to use Ease-IN. Yes. It's horribly confusing.

Ease In-Out to the rescue! ;) Our :X compromised best of both worlds. It's not really... but it's the least confusing to remember.

Ease In-Out is when something moves slowly at first, gets quicker... then slows back down. In UI terms, this is a nice compromise if we don't wanna be fancy, because as humans, we're lazy about how we perceive things.

When we use Ease In-Out for something that animates INTO view, the human-goldfish mind has most likely already stopped paying attention before the last "slow" in the slow-fast-slow sequence. So to the human-goldfish, most of the time it'll look like an Ease-Out.

When we use Ease-In-Out for something that animates OUT of view, the human-goldfish mind (you see where this is going) takes a while to notice what's going on. ;) So it likely doesn't notice the first "slow" in the slow-fast-slow sequence.*

*Updated on 28 Jan 2022 to change ease in-out to accurately reflect a slow-fast-slow sequence. I got sequence of what happens with ease in-out wrong originally, but using it still works, because the human-goldfish principle still applies.

Some samples, using 200ms and (naughty naughty, ALL ease-in).
Each click as shown is triggering a new 200ms animation to the next keyframe.

Gloriously lazy lemon blueberry egg white food processor cookies!

Yes! These cookies contain food processor! :P

Everything except adding the blueberries and shaping the cookies into balls is done in a food processor. You prolly want a sturdy food processor though, my last puny one died in horror at the thought of having to make a whole lemon tart.

Why egg whites? Because we had some left over and I wanted to get rid of them.

Why brown sugar? To make up for the lack of egg yolk.

Why not just cream the cookies? I was curious to see whether this 'reverse creaming' method works for cookies too. It works great for scones, cupcackles, and pie crusts after all. And also because washing the food processor is less work than beating in flour or folding it in with a spoon, and for me, the lazier a recipe, the better. Plus, this requires no planning (no leaving the butter out), and no guess-nuking to soften the butter. Lastly, I hate creaming butter, the sugar always tries to escape, and I get bored standing there with the hand mixer...

Chewy inside, crispy outside lemon cookie!
400g cake flour
100g salted butter (room temp)
150g white sugar
50g dark brown sugar
60g egg white
Zest from 1 lemon
Juice from half a lemon (50ml~)
Some dried blueberries (fresh ones will leak horribly)
Vanilla essence

  1. Throw butter, sugars, cake flour into food processor
  2. Pulse until breadcrumby
  3. Add lemon zest
  4. Pulse some more
  5. Add vanilla essence and lemon juice to whirring food processor
  6. Pulse until dough looks right - sort of like plasticine
  7. Mix in blueberries
  8. Plop in fridge for about an hour
  9. Preheat oven to 150-60C
  10. Make (large) truffle-sized balls, try to get at least one blueberry per cookie
  11. Plop balls about 2 inches apart on cookie sheet
  12. Bake for 20~ minutes, until edges are slightly brown


Mechanism design and the invisible influence of culture and power

From a rather interesting article from mckinsey.com - Leadership and behaviour: Mastering the mechanics of reason and emotion.

Eric Maskin: Mechanism design recognizes the fact that there’s often a tension between what is good for the individual, that is, an individual’s objectives, and what is good for society—society’s objectives. And the point of mechanism design is to modify or create institutions that help bring those conflicting objectives into line, even when critical information about the situation is missing.

An example that I like to use is the problem of cutting a cake. A cake is to be divided between two children, Bob and Alice. Bob and Alice’s objectives are each to get as much cake as possible. But you, as the parent—as “society”—are interested in making sure that the division is fair, that Bob thinks his piece is at least as big as Alice’s, and Alice thinks her piece is at least as big as Bob’s. Is there a mechanism, a procedure, you can use that will result in a fair division, even when you have no information about how the children themselves see the cake?

Well, it turns out that there’s a very simple and well-known mechanism to solve this problem, called the “divide and choose” procedure. You let one of the children, say, Bob, do the cutting, but then allow the other, Alice, to choose which piece she takes for herself. The reason why this works is that it exploits Bob’s objective to get as much cake as possible. When he’s cutting the cake, he will make sure that, from his point of view, the two pieces are exactly equal because he knows that if they’re not, Alice will take the bigger one. The mechanism is an example of how you can reconcile two seemingly conflicting objectives even when you have no idea what the participants themselves consider to be equal pieces.

The bit I quoted above really struck me as either lazy thinking, or unintentional blindness.

It bugs me that Eric Maskin uses children in a room with cake to generalise about human behaviour, without specifying important stuff.

Such as:
Where are the children from?
What are their cultural norms?
What is their relationship to each other?
Will their actions have any repercussions beyond getting less cake?

Happily ignoring all those things, Maskin goes on to apply this concept to management and organisations. Which means that power differentials and politics are also ignored, along with what I previously listed about cultural norms and relationships. It also focuses on an extremely short-term goal.

If the cultural norm is to appear generous...
...then Bob will cut an obviously smaller piece, which lets Alice choose the bigger piece if she wishes to. She may not, she may also wish to appear gracious, and take the smaller piece. But regardless of what happens, it's doubtful to me that the cake would be divided equally.

If Bob has more power - maybe he has the ability to beat Alice up without being scolded for it, even if he doesn't actually want to
...then Bob will cut whatever he thinks is fair, and count on Alice's fear of him, and understanding of the difference in power, to control which piece she takes. Which means that if Bob cuts an obviously smaller piece, he'll get a nice big piece. And if he cuts an even portion, then he'll get to feel good about himself. And in both cases, Alice's 'choice' isn't really a free choice.

Srsly Nugget? It's just cake!
You could argue that Maskin stated that 'Bob and Alice's objectives are each to get as much cake as possible', but it's pretty obvious that cake is a metaphor for money (or resources).

The fact is, in the real world, choices are rarely so clear and simple. There are always trade-offs. Of course every worker wants to 'get as much cake as possible'. ;) But maybe some workers will take less cake now, if it means a more reliable supply of cake in the future. (I.e. a foreign worker on a temporary visa will likely settle for less 'cake' until they're able to get a permanent visa.)

Humans are complicated. It's never just cake. ;)