Thoughts

Notes on what I'm learning.

Monthly dumps of what I'm thinking about: articles that stuck, people worth following, tools I'm obsessed with. And a long-form series on building the design system behind this site.

October 2026Design system series -01

Why I'm building a design system for my portfolio site

I want to get better at building design systems, and I want a base system I understand well enough to reuse, extend, and theme for each new side project.

Besides, what is a personal project for a designer if not a potentially unnecessary deep dive?

This series will document how I structure the system from the simplest first steps, the principles and resources I'm using, and the nitty-gritty details about accessibility, responsiveness, architecture, and best practices. My goal is to learn in public and create a useful resource for others building a system of their own.

Where it started

In 2019, GoDaddy was developing a new themeable backend that leadership wanted to implement on the new GoDaddy Pro experience. I was an associate designer who liked systems enough to take on the challenge.

Working with my design director, we redefined main-brand tokens for the new theme and built components around those values. We assumed the structure of the new theming system aligned with the existing design system, but the new system used a completely different architecture.

That mismatch made implementation near impossible without changing how we structured our design language. It taught me that a system is not only its colors, type styles, and components. The naming, organization, and relationships between values form an architecture, and that architecture needs to make sense in the technology that implements it.

That lesson is shaping this project. Before defining components or polishing visual details, I'm diving deep into the best practices for design system structure in 2026.

What’s next

The next post maps the foundations of my design system and how the tech stack shapes them. They're the tokens that form the basis of a system, organized into three layers: primitive, semantic, and component.

I'll also cover:

  • How I'm designing the system to expedite work in other tools like Claude, Figma, and Paper.
  • How I make accessible choices.
  • How token decisions translate into reusable foundations and components.
  • What changes as I build, test, and revise the system in real time.

You can also follow the work in progress on the Design System page.

September 2026Monthly notes

September Dump

Reading about design systems

I've been reading about where enterprise design systems are heading in 2026. Supernova's rundown is a solid overview of what's shifting:

  • Tokens are standardizing on the DTCG three-layer architecture: primitive, semantic, and component.
  • Teams are reorganizing Figma for cleaner engineering handoff.
  • Executable documentation is replacing static sites.

This is feeding directly into the design system series. More in the next few essays.

A talk that stuck: Kalyca Zarich on skills and AI employees

Kalyca Zarich gave a talk at Workuity on how she thinks about writing skills and building AI employees. A few things that stuck:

  • Four ways to write a skill: explain what you want, give step-by-step instructions, upload someone else's skill, or record your screen while you work through the task.
  • Every skill should include a continuous learning clause so it gets better over time.
  • An AI employee is just a project with instructions, context, connectors, scheduled tasks, and an approval mode. Connectors go to things like CRM, email, calendar, and ads. Flip approval to automatic and the employee becomes autonomous.
  • Example employees people are building: sales analyst, PR assistant, customer support rep, content strategist.

On color: Matt Strom-Awn

Reading Matt Strom-Awn's “The least wrong colors, version 2.” A great read on how to choose colors that hold up in a system.

Currently obsessed with

Buzz, a Slack alternative that looks interesting.

August 2026Monthly notes

August Dump

A month of networking

August turned into a month of networking and resource hunting. Some of the places I've been showing up:

  • Workuity: Tuesday AI talk sessions. A great way to keep up to date with what's happening with new AI tools and models. It's more business-focused than design-focused.
  • Ship AI: a workshop series led by Santos Hernandez. It's been a great resource if you're looking to start something up yourself.
  • Heatsync: Wednesday coffee and coworking. This coworking space is unique: you can work on your computer, but also make physical things like 3D printing and laser cutting. Engineers of all types hang here.
  • Design Mob: monthly convos that just started up in Phoenix. Any excuse to talk shop with other product designers is welcome. The next meetup is Sept 24th, location TBD.
  • Design Shaped: portfolio reviews with Tim and Nate through Design Buddies. They are both knowledgeable and kind. You see a range of levels reviewed, and their review of my site helped immensely.

A simple way to think about writing Skills

When working with AI like Claude, I have a simple way to think about skills and saving them:

  • What do you want out of this thing?
  • What does success look like?
  • Save that as a skill.

You have a task the AI is helping you with, one you'll do again. Work back and forth with the tool until you reach the outcome you're looking for. Save it as a skill. In the skill, defining “I want [fill in the blank]” and “success is reached when [fill in the blank]” helps train it.

If you run the skill later and don't get the exact outcome you want, work with it until you do. Then debrief: ask the AI to confirm what it did differently and save that back into the skill.

A skill vs a design.md

Vercel's blog article “How our agents build on-brand pages with design.md” is a great read on a file that does what skills do. The two pair well, but they're not the same thing. A skill is task-triggered and has a definition of done. A DESIGN.md is always-on context that describes what your system looks like, not how a task ends.

Currently obsessed with

facetflow.io is a tool for jewelers that has me thinking about the future of crafting and making. I heard their talk at JOGS, a gem show in Tucson. It automates planning for jewelers: budgeting a new piece, generating images from sketches, pulling current market prices for gold and silver.

I tried it, and the image generation was powerful. It was especially helpful when I was talking to my client about the different color stones we could use.

July 2026Monthly notes

July Dump

Something I've been mulling over lately: Design goes where it's already valued

“The uncomfortable idea is that design tends to move toward places where it's already valued, not where it's most needed. It's easier to refine a checkout flow than to redesign a system where the value of design isn't even recognized yet...So we end up improving convenience at scale, while clarity in critical moments remains under-designed.”

sources: Reddit thread, Substack essay

Skillchains, with Kyle Chalmers

Kyle Chalmers of KC AI Labs presented at Workuity's AI center. He automates AI workflows for businesses and walked us through skillchains: the output of one skill becomes the input of the next. It's a way to automate big multi-step jobs.

Things that stuck about writing skills:

  • Sometimes you need to provide a definition of done to a skill: “a skill is done when you complete this” you can also say “you are a skill within this process”
  • Don't try to write the skill upfront. Work with the agent to get the thing done correctly first, then tell it to turn that into a skill.
  • When you notice yourself repeating something, that's the signal to make it a skill.

Kyle was nice enough to meet with me a few days later when I had some questions about skills. Check his work out: kclabs.ai.

Resources from his presentation:

  • Excalidraw flowchart by Cole Medin
  • Skill chain by Kyle Chalmers

Rethinking case studies

Loving Dive Club's interviews lately. This piece from Ridd is an older article, but it's shifted how I'm thinking about writing my own.

Currently obsessed with