Ideal Process versus Reality

Matej Latin provides good advice for young designers. Namely, that the ideal process learned from books is not true to life.

[T]he double diamond design process which has been often cited as the design process doesn't reflect reality. It's the perfect ideal that designers strive for but rarely achieve. Designers simply don't have that much control over the influencing factors so a design manager reading through a perfect, cookie-cutter case study, even if it uses the double diamond process, knows immediately that it's fake.

Frankly, I sometimes see advanced designers demanding excessive adherence to process from their reports. I suspect that comes from a lack of faith in their designers, and also anxiety from not knowing every detail of the project. Delegating work means trusting that your staff can handle the job. Overemphasizing a double diamond process (or the related documentation) for every single thing creates a classroom-like environment. It feels less than professional despite being by the book.

Beirut on AI

Michael Beirut with a great take on a benefit of AI:

"A majority of the world is boilerplate, and that's a good thing," Michael says. "Because all of us are motivated by two opposing kinds of needs. One is the need for predictability and comfort. And the other is the need for surprise and excitement. If you get that balance wrong and everything is just comfortable and predictable, you get bored. And that's not good. But on the other hand, the antidote to that isn't 100% unpredictability, surprise, and entertainment, because then you get too overstimulated and start to freak out. There's a certain reason why you wouldn't want every building on Fifth Avenue to look like the Guggenheim. It just would be too crazy in an unpleasant way. This architect was admiring some anonymous building somewhere in Manhattan, and they said, 'You know, what makes a city great is its ability to put up and maintain something like this, a perfectly good kind of background building that actually does its job well and isn't calling attention to itself.' But if you examine the details, you see that they're sound and built to last, and the tenants are satisfied. And then down the block and around the corner, there's something more special and showy that provides a great foil for that.”

So maybe ChatGPT, Midjourney, and all of those other new generative AI programs can be responsible for doing the boilerplate really well. Now, you've got time to do something a little more interesting. "Everyone dismisses boilerplate as crap that's not worth anyone's time," Bierut says. "You could argue boilerplate makes the world go round, whether it's in architecture, design, or writing. Boilerplate makes things that are special look and feel more appropriately special. Maybe that's an appropriate way to think about the promise of AI, but I don't know."

This tracks with how I've been thinking about AI with respect to design (or any creative profession). It's going to be a tool which helps with boring, rote elements of a process. It'll be able to recreate and fuse older iterations of a craft in order to more quickly produce what had come before. It's just not going to be reliably able to make something humanist and new. At some point, the boundaries of what AI can produce will be obvious, and human beings will bend culture back to what is more fully human.

You can't believe the tech bros about this. They're going to claim AI will be possible of anything — including self-awareness and then becoming our new god. Whatever AI creatures they do eventually create will look and act like them, because people are only able to create gods in their own image. In the case of AI, that god will also be white, male, and techno-centric.

Personally, I'm looking forward to seeing how art and society eventually push back on the upcoming AI-obsessed culture. It should be really human. Really tactile and emotional. Think about how Grunge reset the table on music as we turned into the 1990s. AI stuff will always look clean and rich. It'll have a pristine quality to it, even when prompted to not. Because it's expensive. And it's run by rich people. The pushback to it is going to be a good time. It's going to be the Guggenheims on a street full of forgettable buildings.

A Small Design Success

Yesterday was one of those good days as a designer where a solution to a tricky problem falls into place, everyone is very happy with the results, and it looks good. It can be surprisingly hard to hit all three. Especially in a large organization with dozens of competing agendas.

This was for a small, repetitive piece of UI — a stack of 250px x 100px cards — each already dense with images, text, and other info. The requirement was to also include three to five new affordances; buttons for performing different actions. One of those actions would account for around 95% of the clicks, so preferably that one would be larger. After a couple dozen iterations, it all fell into place. Voilà. C'est fini.

Most of my work lately has been systems-level stuff. Cross-tooling design patterns and functionality. Or complicated workflows with numerous newsroom roles working in coordination. Or intra-department work where Editorial Tools and Consumer site design are partnering. These are all satisfying problems to solve. But there's nothing quite like the feeling when a piece of UI clicks into place right before my eyes. That's what pleases the soul of the art school student in me. Balance, weight, color, space, and purpose.

How Design Systems Can Fail

Marissa Christy had some smart thoughts on how design systems can fail (way back in 2018).

A project can go awry for a number of reasons — budget, resources, time, mismanagement — even turnover. But even successful design systems with organizational buy-in can fail. The pitfalls I am about to highlight feel inherent to the very idea of a design system, even in the most ideal of scenarios.

The entire article is worth your time. I felt a particularly strong resonance with these paragraphs:

When the timeline for implementation gets spread out over multiple months (and more likely, quarters or years), a lot can change. And from an implementation standpoint, front-end development is changing more quickly than ever before. The past few years have seen paradigms shift from utility-like reusable classes (think .margin-sm) to BEM syntax, from monolithic sass outputs to scoped styles within React components. And as the CSS spec adds more and more functionality, from grids to variables, the future is far from fixed.

I’ve seen several implementations of style guides fail because they simply couldn’t keep up with the front end. Bloated bootstrap-like files when everyone is worried about performance. A ruby gem at the moment that node was taking off. And even though React seems almost designed for componentized design systems, the changing nature of tech makes the whole notion of creating a permanent, forever system unlikely.”

It's important to remember that a Design System is a tool. It helps you build your product faster and more coherently. But, like everything else having to do with the internet, it's a tool with eventually diminishing usefulness. The more you keep that top of mind, the better off you'll be when it comes time to start over. At some point, _you will need to start over_. That's the straight truth of building software.

I've been thinking a lot about which kind of design system is better: A design system tightly entwining design and code documentation? Or a DS which is just design, agnostic to the code framework used? I lean towards the former: it provides the most immediate beneficial returns; but it requires constant maintenance and dedication to one framework. The later is great because it can outlast any one framework, but it doesn't save engineers much time.

There are clear cut trade-offs for either path you choose. But you have to choose one. You can't have both. And, eventually, either will fail. So it goes.

Path of Atomic Design

Josh Clark clarifies a misconception about Atomic Design, which helps explain exactly why its so useful. He explains:

Right from the start, when Brad was first developing his tools and methodologies in our designs of TechCrunch and Entertainment Weekly, our process constantly zoomed back and forth between page level and atomic level. It’s never a linear path from small to large; it’s a constant roundtrip between the two scales.

Atomic Design prescribes a small-first process, but, like Josh says, it's a cycle. Sometimes, it's pretty chaotic, with design play often driving the car. But the structure of Atomic Design means you're always going back to defining and redefining the smallest elements (atoms), which are then used to construct larger ones (molecules, organisms, etc.). By the time you have your sights on the finish line, you'll have a highly structured design and front-end code architecture for building out nearly anything else in the future.

I've seen this play out a half-dozen times or more now on large projects. If you pay close attention to the detail (the atoms), and maintain control over the depth and breadth of your style guide, what you build will be highly efficient and easy to work with going forward.