Throughout my career as a designer, I’ve experienced a recurring struggle with the concept of process.

I used to look at process as something sacred: a holy calculus through which I could find the right answer to a problem every time. All I needed to do was remember the steps and apply them in just the right way. Wash, rinse, repeat.

Maybe this idea stems from my background in programming, or maybe it’s just an attempt to comfort my own fears and insecurities, but I wanted my work to follow a clearly defined algorithm.

I know now that’s an illusion.

Jenny Wen recently wrote a great piece about this. I’ll quote a bit of it here:

The way I’ve seen great work made isn’t using any sort of design process. It’s skipping steps when we deem them unnecessary. It’s doing them out of order just for the heck of it. It’s backtracking when we’re unsatisfied. It’s changing things after we’ve handed off the design. It’s starting from the solution first. It’s operating on vibes and intuition. It’s making something just for the sake of making people smile. It’s a feeling that we nailed it.

For me, overly relying on process might also have been borne out of a distaste for what I perceive to be the opposite of process: vision. Blue sky design visions, if not done with care, can turn into uninformed expressions of ego and hubris.

If you’ve worked within a large design organization, you’ve probably seen this play out. A designer, usually one with lots of tenure or clout, goes heads down to produce a north star for the design direction of a product that is usually impressive but disconnected from both the needs of users and the realities of building real software.

Visions too often fall out of a coconut tree, not existing within the context of the current product or what came before it. (Sorry, I had to.)

Of course, vision work can be useful as an instigating factor: to excite stakeholders, secure funding, or drive alignment by raising key questions. But too often these visions are taken more seriously than they should, and they get handed down to other teams in place of an actual roadmap.

I think that the act of designing and shipping real solutions happens somewhere in between process and vision. It’s not a carefully defined algorithm, and it’s not a moonshot.

So how might we talk about that in between state?

I recently read an excellent piece by Henrik Karlsson called Everything that turned out well in my life followed from the same design process. Henrik discusses what Christopher Alexander referred to as unfolding:

If you want to find a good design—be that the design of a house or an essay, a career or a marriage—what you want is some process that allows you to extract information from the context, and bake it into the form. That is what unfolding is.

Click through for a more details explanation of how unfolding works.

Henrik goes on to say that unfolding is the opposite of vision, but I like to think of vision and rigidly defined process as two ends of a spectrum, with unfolding sitting somewhere in the middle.

The opposite of an unfolding is a vision. A vision springs, not from a careful understanding of a context, but from a fantasy: if you could just make it into another context your problems will go away.

None of this is to say that there is no place for more formal processes. When unfolding a problem we need to establish feedback loops and respond to those in a way that resembles improv, but the act of responding may itself leverage repeatable processes.

We might choose to think about these recurring patterns in our work as frameworks, which are applied to solve specific problems or answer certain questions.

For example: unfolding a problem might present a difficult decision that needs to be made, and that’s when leveraging a decision making framework might be useful.

Should every decision that needs to be made have that framework applied to it? Absolutely not! And it’s our job as designers to know what parts of our work should be scripted and what parts should be improvised.

I’m trying to let go of my conditioning to attack every problem with process, and these ideas are helping me frame my work in a way that invites spontaneity and is less concerned with artifacts of the work that aren’t actual software. Because at the end of the day, any artifact that isn’t the product itself should be in service of the product, not any one person’s process.

Programming note: the domain for this website has changed! chasem.co is out, and chsmc.org is in.

All existing links and feeds should redirect automatically, because good URIs don’t change, but please let me know if you see otherwise.

Why the switch? A few things:

• Pronouncing my email address (@chasem.co) always resulted in spelling it out anyway, and “do you mean .com?” was a frequent response.
• chsmc is increasingly the handle I’m using online whenever chase is not available (so, most of the time).
• The equivalent .com was too expensive, and the .net is taken.
• I was inspired by some of the great blogs I read that use .org domains. kottke.org, marco.org, waxy.org, macwright.org, pketh.org all come to mind.

My hope is that this is a move to my forever domain, but if someone at JPMorgan Chase wants to chat about donating a better domain, they can find me (and so can you) at [email protected]

I recently showed a few friends around Chicago, and as we passed by the Art Institute and the two lions guarding the entrance, I wondered if they had names like the lion sculptures outside the New York Public Library.

Those lions are named Patience and Fortitude, and were modeled by Edward Clark Potter in time for the library’s dedication in 1911.

New York’s lions have had several nicknames throughout their lives, but received their current names from Mayor LaGuardia in the 1930s based on the qualities he thought New Yorkers would need to have to survive the depression.

So what about the lions in the second city? Strangely enough, they were also created by a sculptor named Edward.

Edward Kemeys didn’t names to these lions, which took their places in 1894, but did assign them unofficial designations based on their poses. The lion on the north pedestal is “on the prowl,” while the one to the south is “in an attitude of defiance.”

We don’t seem to assign names to the objects around us as much as we used to, but I think it’s an important part of creating meaning and connecting to our environment and our history.

Next time you’re in downtown Chicago, don’t forget to say hi to Prowl and Defiance.

Figma announced a host of new AI-powered features this week at their annual conference, and they have been received by designers with both cheer and dismay.

Tools like the ones that were announced are showing up across the industry, but as the most popular tool for modern product design, Figma will make them commonplace, and we’ll soon be taking them for granted just like any other advancement in design tools over the past several decades.

Some folks are panicked, some are excited, and some are indifferent. I’m somewhere in the middle, but I do have concerns that are exacerbated by these new tools and capabilities.

To explain those concerns, I’ll draw a distinction between two types of AI-powered features that Figma announced this week:

1. Using AI to eliminate or reduce the time spent on constructing designs and prototypes in Figma.
2. Generating UI designs from scratch, based on a text prompt, using models trained on common product interfaces (and, in the future, the work created by Figma users, unless they opt out).

I’m excited for and have very few concerns about type #1, because the job of product designers is not to create Figma mockups—it’s to solve problems and ship software.

To the degree that new features allow us to spend less time creating ephemeral artifacts that are merely a stop on the way to a final destination, I’m sold.

Those features involve things like automatically wiring up prototypes, filling in a mockup with fake data, translating strings into other languages, automatic layer naming, generating placeholder images, etc. These are all good and helpful, and are geared towards saving designers time to spend on things that they are uniquely positioned poised to do.

But what about type #2, the feature that Figma labels in its UI as “Make designs”? This allows anyone to enter a prompt and have Figma create a mockup from scratch. In the future, the company plans to train their models on designs created by users.

Some are concerned that this type of feature might take jobs away from product designers, and some see it as simply another way to automate away the tedious parts of a designer’s job in order to give them more time to do what they do best.

I think it’s both, and/but I don’t think it’s because of AI.

There are many companies, and the number seems to be increasing, that are more than happy to turn the jobs of designers over to folks who are able to wield tools to produce a facsimile of what a designer is actually capable of.

For those that see the primary value of designers as producing interface mockups, the advent of new AI tools in the vein of Figma’s “make designs” button will absolutely seem like a viable replacement for the work of a designer. And this isn’t limited to AI—as design tools become more accessible and approachable to everyone (which I consider a net positive on the whole), the barrier to creating something that looks, on the surface, like the work of a designer is lowered.

Canva is an excellent example of how this is not strictly because of AI, but might certainly be accelerated by it. The commodification of design as a practice began long before the widespread availability of generative AI.

Product managers, engineers, and others are now able to produce designerly artifacts easier than ever before, and too many companies are willing to accept the sub-par solutions that result in order to cut costs and move faster.

Machines will not make our jobs obsolete, but corporations will, and they’ll use smarter and smarter machines as an excuse to do so.

I’ve remarked before on my gratefulness for CSS as the ubiquitous and expressive visual language of our times, a sort of design Esperanto (that is actually widely spoken).

One would struggle to find a more perfect example of this than Scribe, by Stephen Band. Scribe is a custom element (<scribe-music>) which renders responsive music notation in HTML and CSS grid.

Here’s an example, rendered inline via Scribe:

To really understand the magic happening here, you must read Stephen’s excellent blog post about how it all works.

It’s remarkable that this is possible using CSS, and even more remarkable that the language itself morphs to become a syntax not for describing elements on a web page, but to describe pitch over time. CSS as interface for the natural world.

Under the hood, Scribe uses markup like this to represent music in time:

<div class="stave bar">
  <svg class="clef" data-pitch="B4">…</svg>
  <svg class="flat" data-beat="1" data-pitch="Bb4">…</svg>
  <svg class="head" data-beat="1" data-pitch="Bb4">…</svg>
  <svg class="head" data-beat="2" data-pitch="D4">…</svg>
  <svg class="head" data-beat="3" data-pitch="G5">…</svg>
  <svg class="rest" data-beat="4" data-pitch="B4">…</svg>
</div>

Elegant, useful, and thanks to the hard-won stability of the web platform: durable for generations to come.

One might wonder, what other natural or mathematical systems might we be able to represent in CSS? Another example that crossed my feeds recently is time-based CSS animations by Yuan Chuan.

Yuan creates a variable in CSS representing time, and uses keyframe animations to increment the value of the variable by 1 every millisecond. Suddenly CSS has a timer, something powerful for generative art and animation where time itself is used as an input variable.

Need to adjust the frame rate? Easy:

/* 8 fps */
animation-timing-function: step(calc(86400000 / (1000 / 8)));

Yuan has some great examples of how this can be combined with functions in CSS like min(), round(), and newly added trigonometric functioned like sin(), cos(), etc. to create all sorts of useful effects. My favorite example is using all of this to create a clock with a perfectly ticking second hand.

In terms of representing natural systems in CSS, this reminds me of how often I’ve wanted to be able to generate and use random numbers in CSS at runtime. To my delight, it looks like that’s in the works.

There are two new features coming to CSS that will make it much easier to further avoid JavaScript when implementing animations:

1. Animating to and from display: none; for the sake of enter/exit animations.
2. Animating to and from the intrinsic size of an element (such as height: auto;).

Traditionally, animating something into or out of the screen (as opposed to just hiding it visually) required JavaScript to remove the element from the page after waiting for the animation or transition to complete. No longer!

When these new features land in browsers, you’ll be able to animate to display: none like any other property using a keyframe animation:

.item {
  animation: fade-out 0.5s forwards;
}

@keyframes fade-out {
  100% {
    opacity: 0;
    display: none;
  }
}

Neat!

You can also do the same thing with a CSS transition, but you’ll need to set the new transition-behavior property to allow-discrete for that to work. I can see something like * {transition-behavior: allow-discrete} becoming a part of my CSS reset in the future to enable this behavior by default.

But what about the opposite case? You have an element that’s currently not displayed and you want to animate it as it appears. Again, we typically use JavaScript for this today to ensure the initial styles are set properly and our element doesn’t display visually on the page before it has animated.

Now, we can specify the starting style like this:

.item {
	@starting-style {
    opacity: 0;
	}
	
	opacity: 1;
  transition: opacity 0.5s;
}

Elegant and useful. If you want to learn more about these new powers, I recommend checking out this post on the Chrome for Developers blog.

The second new feature coming to CSS is the ability to animate to and from an element’s intrinsic size. The most common use case for this is collapsible areas: we want them to be height: 0px when closed, and when opened their height should be automatic based on the contents.

Because CSS has historically not allowed for animating to height: auto;, we’ve had to use JavaScript to measure the height of the contents and animate to that pixel value.

When this feature lands in browsers, we’ll instead be able achieve this like so:

.item { 
  height: 0; 
}

.item.open { 
  height: calc-size(auto);
}

The magic comes from the calc-size function, which is a curious API choice—why not just use the existing calc() function? Here’s a comment on the CSS working group’s draft for this feature that explains why.

These features are just a few of the many ways that CSS is growing and becoming more powerful and expressive. To learn about all of the other great new things coming, check out this excellent video by Una Kravets from Google I/O.

Una says that we’re in the golden era for web UI, and I couldn’t agree more.

Many of my online acquaintances know that I live in Chicago, but I suspect they might not know that I’m from a small university town in Mississippi called Starkville.

Starkville is home to Mississippi State University, where I attended college and studied Computer Science. In 2017 I graduated and moved to Chicago to start my career.

At the time I was excited to escape the place where I spent so many of my formative years, a place which was the symbol of mundanity for me and my youthful ambitions.

Seven years later and I’m having coffee and catching up on my inbox when I happened to find the latest issue of Claire Evans’ newsletter: a delightful story about moon trees—that is, trees grown from seeds that traveled to space and around the moon 34 times during the Apollo 14 mission.

Claire traces the history of the seeds, which were germinated into seedlings and given out to foresters across the country before being largely forgotten about and then eventually rediscovered and catalogued by NASA.

(By the way, don’t miss out on the wonderful website created to track the trees by a NASA archivist.)

Today less than 100 moon trees remain, but as Claire goes on to describe, there is a second generation of moon trees (so called “half-moons”) grown from the seeds of original trees that remain today.

The location of one of these mother-trees, though, is what caught my attention: it’s on the campus of Mississippi State University, my campus. All the times I walked past this humble tree I had no idea it had been to space.

It’s such a pleasant surprise to have this story appear in my inbox and show me something new about a place where I spent so much time.

While I lived there, I often felt suffocated by the mundanity of my home town. This has reminded me that there are things to appreciate and interesting stories (of perhaps cosmic proportion!) to discover in even the most mundane of places. We just have to keep our eyes open and remember not to take anything for granted.

If you’d like, you can buy a seedling Sycamore moon tree online descended from the one on the MSU campus.

Hearty congrats to Robin Rendle who has turned his wonderful CSS-focused newsletter into a good, old fashioned blog. The Cascade is beautiful, and is already full of great content for CSS nerds like me.

The site is, generously, free to read, but member supported for $10/year. Subscribing, for me, was an absolute no brainer.

I liked this bit from an issue of Robin’s personal newsletter that he sent after the launch:

There’s not enough words in the English language to describe how cool it is to build a little publishing machine. That rare, lightning-in-a-bottle feeling of throwing a few services together and building something greater than the sum of its parts.

It’s never been easier to create a website (a publishing machine!) for yourself or your interests. The feeling of ownership you’ll have compared to publishing on someone else’s platform is a powerful force in and of itself.