The Clock of the Long Now, by Stewart Brand

I’m thinking about writing a book, and the [1]nonfiction book I’m thinking about writing is about building design systems and making sure they’re accessible. [2]The list of fiction books in progress is embarrassing.

It’s a big undertaking. [3]Building a design system, I mean, not the book. Although I think the book will be a big undertaking too — it’s just that books tend to be finite creatures that you can finish, and design … Continue reading

It’s an undertaking that I’ve been involved with for three different companies now — as a consumer of the system at Vanguard, and as a designer at both Boomi and Vertex.

But really, I wouldn’t have made the jump from consumer to designer successfully at all if Jeremy Keith hadn’t given a talk in 2018 called The Way of the Web. [4]It is not one of his best-known talks and for that matter if I hadn’t found these sketchnotes I’d really be wondering if I made it up right now.

In that talk, Keith summarized the concept of pace layers, presented by Stewart Brand. It surmised that culture builds from a bottom layer of nature (which changes very slowly) through multiple layers until it reaches fashion (which changes almost too rapidly to track), and that by understanding the relationships between the layers, we can better understand how and where to effect change.

Keith’s suggestion in his talk was that a similarly-structured pace layer could be built from TCP up through Javascript and other scripting libraries, from the slowest changing layers of the internet through the fastest.

At the time I was prepping for my own talk so the idea kind of grabbed on to the back of my brain… and there it started gnawing on things.

Building a design system is often challenging and frustrating because some things about it (such as, for example, the organization’s voice and tone, or the corporate font) change rarely, but have huge impacts. Others, such as the fashion of flat design or the implementation of specific interactions, change frequently but only impact small subsets of the full design system. As a designer, I’ve found that understanding the difference between scheduling a change to the corporate font and scheduling a change to the 4th carousel owned by the 2nd subdivision of importance in the organization is the key to ensuring that the design system is given the budget to grow — and the key to ensuring that the design and development partners don’t want to string me up.

But to explain all of that, first I had to be able to explain pace layers. And while I was pretty sure I did understand them, if one wants to start writing a book it’s a really good idea to read the source material before running one’s mouth.

Then I bought the wrong book.

See,  my brain is a muddled mess of memories from various conferences and web events. Learning about pace layers is definitely one that sticks out. Another that sticks out is discussion of the Long Now Foundation.

This foundation is dedicated to taking the long view on time. The very long view. Like, a clock that runs for ten thousand years long. People who place bets that take a minimum of two years to prove out true long. Storing a sample of all the world’s languages in nickel long.

And while The Clock of the Long Now does, indeed, discuss pace layers in chapter 7, the bulk of the book is about taking the long view on what we put into the world. In the case of web design and development this can mean everything from choosing HTML as your primary markup language (and not coding everything in JavaScript) to deciding which companies and projects you’ll still be proud to be associated with 20+ years into your career.

(I also remember a lot of conversations about how future forward design is progressive enhancement from older technology, and a lot of men getting their pictures taken in a space helmet, but once again the terminology to find proof of these things eludes me tonight.)

It turned that reading The Clock of the Long Now was not a mistake on my part (more of a lucky accident) because it’s helped me understand and maybe even figure out how to explain that one of the biggest challenges with a design system is that it’s a system. You’re designing a system that, if successful, cuts design and development time for the whole organization. But that means you’re also designing a system that will require time to develop, time to adopt, time to grow, time to stress-test. It is not a short-term two-quarter project with a payout at the end.

In other words, it works in long time, but in corporate-driven show-me-the-returns time, it may be hard for our Product people to buy into.

One of the amusing things about the book is that the edition I read was published right after the turn of the millennium (or the year 2000 for you pedants, don’t @ me about when centuries start), which is itself a millennia in web years. The Long Now Foundation still exists, which is a bit of a relief because basing my ideas on design systems on a long vision that subsequently died in the 20 years since the book was written would’ve been embarrassing.

Brand did seem to go out of his way to not make predictions about what the future would bring, outside of the fact that it 10,000 years from now life will likely be very different from today.  Still, there was more than one point where something said would pull me out of the book. Brand seemed quite optimistic, that the web would have the power to prevent people in power from spreading lies, for example, at which point I almost spat my drink across the room.

The book’s thesis, that we should take a long view if we want to work together to solve problems, is still valid 20 years later, and has helped me better shape the kinds of discussion points I’ll need to get the funding necessary for a quality design system. (I’m pretty sure Brand didn’t see that coming, but then, he probably wouldn’t be surprised either.)

So it’s a good, relatively short read, not directly about the web but definitely about the underpinnings of being a developer or a designer, and I recommend it to anyone interested in the longer view.

Footnotes

Footnotes
1 nonfiction
2 The list of fiction books in progress is embarrassing.
3 Building a design system, I mean, not the book. Although I think the book will be a big undertaking too — it’s just that books tend to be finite creatures that you can finish, and design systems are not so much.
4 It is not one of his best-known talks and for that matter if I hadn’t found these sketchnotes I’d really be wondering if I made it up right now.

Presenting Design Work by Donna Spencer

Presenting Design Work by Donna Spencer captures everything I’ve learned about that harrowing process of presenting a web design for review and turned it into a six chapter book you can read over two lunch hours.

I am thrilled that this book emphasizes rigor in the craft of creating and presenting designs.

So many times I’ve sat through reviews where the designer couldn’t tell me what the business problem was, why the user needed the changes, how the user would get from place to place, or what the unhappy paths looked like. They failed to take notes (sometimes showing up without even a note-taking device, like, say, a pencil or a laptop), gave me a tour of our components on the page instead of telling me how someone would use it, and thanked everyone when done — but never followed up to let us know what they’d decided. Then, later, they complained that the product manager steamrolled their input on designs or ignored their feedback.

This book demands a lot of the person who wants to be successful. You have to think about your audience, practice presenting, take notes (or find someone who will), understand the problem you’re building against, understand the feedback you’re given, and be rigorous in your feedback decision-making process.

It also works. It works so very well. And it garners trust between us and our business and engineering peers way better than any less-rigorous process is capable of doing.

As soon as I started reading it, I started messaging people I know mentoring designers and said “yeah this book? this is the one you want.”

Now on The Interconnected: Back to Basics: Writing Design Guidelines

I’m doing a lot of writing design guidelines at work right now — essentially codifying in words the things we’re already doing. Paving the cowpaths if you will.

My June 28 post on The Interconnected is about where to put design guidelines when you write them, what application to write them in, what to put in them, and why nobody’s going to read them but you.

Read Back to Basics: Writing Design Guidelines on The Interconnected

Now on SuperYesMore: Preconditions

Alex Duloz, who was one of the brains behind The Pastry Box, asked me to participate in his 2017 project The Human In The Machine. He’s doing a look at productivity and how we handle it, with a post every day about productivity from a different author.

For my post, Preconditions, I thought about my daily routine and what things I do to set myself up for a productive day. Some of them are physical and environmental, like the way my desk is set up or how warmly-dressed I am. Others are about the work itself: is it ready to be worked? How do I know? The list goes on from there.

I don’t have any expectation that anyone else will use my process. More, it was nice to quantify the process I’m using and see it out on paper (well, electrons) so I could confirm it. And a little bit, writing it down helped me look at it and decide whether everything really was of value.