The Small Team Design System in the AI Era

Recently, I’ve been leading the implementation of several UI-heavy projects. As more features landed, I found myself thinking more and more about design systems.

The entire Apple team at my current company consists of around 30 people, including directors, managers, and engineers. Together, we’re responsible for two platforms (iOS and macOS), two apps, every product feature, testing, CI/CD, releases, maintenance and infrastructure. We simply don’t have the luxury of having a dedicated design system team. So the question has became:

How do we get the benefits of a design system without spending multiple sprints building one?

This question is becoming much more relevant in the AI era. AI is fundamentally changing how software gets built. Small teams can now ship products that previously required significantly larger engineering organizations. We’re seeing more fully-fledged products being built by just a handful of developers working alongside AI.

But while the way how softwares get built has changed dramatically in the past year, much of the advice around design systems hasn’t. This post shares how I think about building a design system without having a design system team, and why I think AI changes the way small teams should approach it.

Snapshotting SwiftUI Views on macOS (Three Approaches and an ImageRenderer Gotcha)

You have a SwiftUI view on macOS and you want to turn it into an NSImage for some downstream use: a tab preview, a thumbnail cache, an offline export… This post walks through the three pipeline designs, when each one fits, and where the sync-vs-async trade-off shows up.

Code Sample on Github

When Things Are No Longer Working: An Engineer's Approach to Speaking Up About Work Friction

Every engineer has a version of this story: It’s the third review round on the same proposal. The questions keep coming back — only that they aren’t really questions. They’re objections wearing question marks. The thread closes without a path forward, and the people on it aren’t aligned on what a path forward would even need to look like.

Each round had the same shape. Questions phrased to expose and object, not to contribute and converge. Skepticism with no alternative attached. “I don’t really see what this is solving.” “Aren’t these basically equivalent?” “I’m not convinced this is even the right problem.” “That’s a false choice.” Any one of these, in isolation, might be a fair technical concern. But stacked together week after week and round after round, they weren’t pushing for a path forward. They were a wall built one brick at a time.

It’s a painful moment and I had just lived through one. My usual instinct is to swallow it and keep moving, quieter than I started. But this time the cost was too high to absorb. I decided to speak up, and it saved a whole team of engineers and a critical project.

Measuring Best-Effort Features: How Good is 'Good Enough'

You finished your day of hard browsing and casually clicked ‘Clear My Data’ on your browser. Behind the scenes, 16 different systems spring into action—cookies, cache, browsing history, autofill data, site permissions… along with a cool fire animation. A few seconds later, the animation completes and you close the browser.

My analytics dashboard says: Clear Data Button Clicked: 1.

However, it doesn’t tell me something I really care as a developer: Did your data actually get cleared? Did one of those 16 systems fail silently? Did you wait 30 seconds staring at the spinner and give up? Did you trust that it worked, or did you immediately check your history to verify?

I have no idea. And that’s a problem.

2025 - Year In Review

I can’t remember where I saw my first Year in Review. It was probably Google’s, sometime around 2008, back when Google was a big part of the search and internet scene in China, and when I was still a primary school kid running around on summer afternoons, thinking nothing about jobs or life.

Fast forward to 2025, Year in Review is everywhere: Spotify, Instagram, LinkedIn…… even ChatGPT. I expected it to feel awkward, but OpenAI handled it surprisingly well.

I’ve always found retrospectives useful, both for clarity and for growth. So here it is: my reflection on 2025.

The Small Team Design System in the AI Era

Recently, I’ve been leading the implementation of several UI-heavy projects. As more features landed, I found myself thinking more and more about design systems.

The entire Apple team at my current company consists of around 30 people, including directors, managers, and engineers. Together, we’re responsible for two platforms (iOS and macOS), two apps, every product feature, testing, CI/CD, releases, maintenance and infrastructure. We simply don’t have the luxury of having a dedicated design system team. So the question has became:

How do we get the benefits of a design system without spending multiple sprints building one?

This question is becoming much more relevant in the AI era. AI is fundamentally changing how software gets built. Small teams can now ship products that previously required significantly larger engineering organizations. We’re seeing more fully-fledged products being built by just a handful of developers working alongside AI.

But while the way how softwares get built has changed dramatically in the past year, much of the advice around design systems hasn’t. This post shares how I think about building a design system without having a design system team, and why I think AI changes the way small teams should approach it.

Snapshotting SwiftUI Views on macOS (Three Approaches and an ImageRenderer Gotcha)

You have a SwiftUI view on macOS and you want to turn it into an NSImage for some downstream use: a tab preview, a thumbnail cache, an offline export… This post walks through the three pipeline designs, when each one fits, and where the sync-vs-async trade-off shows up.

Code Sample on Github

When Things Are No Longer Working: An Engineer's Approach to Speaking Up About Work Friction

Every engineer has a version of this story: It’s the third review round on the same proposal. The questions keep coming back — only that they aren’t really questions. They’re objections wearing question marks. The thread closes without a path forward, and the people on it aren’t aligned on what a path forward would even need to look like.

Each round had the same shape. Questions phrased to expose and object, not to contribute and converge. Skepticism with no alternative attached. “I don’t really see what this is solving.” “Aren’t these basically equivalent?” “I’m not convinced this is even the right problem.” “That’s a false choice.” Any one of these, in isolation, might be a fair technical concern. But stacked together week after week and round after round, they weren’t pushing for a path forward. They were a wall built one brick at a time.

It’s a painful moment and I had just lived through one. My usual instinct is to swallow it and keep moving, quieter than I started. But this time the cost was too high to absorb. I decided to speak up, and it saved a whole team of engineers and a critical project.

Measuring Best-Effort Features: How Good is 'Good Enough'

You finished your day of hard browsing and casually clicked ‘Clear My Data’ on your browser. Behind the scenes, 16 different systems spring into action—cookies, cache, browsing history, autofill data, site permissions… along with a cool fire animation. A few seconds later, the animation completes and you close the browser.

My analytics dashboard says: Clear Data Button Clicked: 1.

However, it doesn’t tell me something I really care as a developer: Did your data actually get cleared? Did one of those 16 systems fail silently? Did you wait 30 seconds staring at the spinner and give up? Did you trust that it worked, or did you immediately check your history to verify?

I have no idea. And that’s a problem.

2025 - Year In Review

I can’t remember where I saw my first Year in Review. It was probably Google’s, sometime around 2008, back when Google was a big part of the search and internet scene in China, and when I was still a primary school kid running around on summer afternoons, thinking nothing about jobs or life.

Fast forward to 2025, Year in Review is everywhere: Spotify, Instagram, LinkedIn…… even ChatGPT. I expected it to feel awkward, but OpenAI handled it surprisingly well.

I’ve always found retrospectives useful, both for clarity and for growth. So here it is: my reflection on 2025.

A Walk through Foggy Midsummer Nights - Written at the End of a Job Hunt

In early 2025, as layoffs swept the tech industry and gen-AI loomed over everything, I left the role I had held for five years and took a leap into the unknown. I packed my life (and dog) into two suitcases and flew from downtown Toronto to the quiet countryside near London, where, with my new neighbors - swans, geese, and ducks (hint, hint), I went through a season of interviews, self-doubt, small triumphs, and quiet resilience. There were tears—many—and at times it felt like walking through a foggy forest at night, where the moon was hidden, but somehow, the moonlight remained.

On June 18th. 2025, I signed the offer that marked the end of this chapter. This is the story of the season of the job hunt.

(Friendly Geese)

What Happens when the User Taps on Screen?

I was recently asked this question in an iOS engineer interview. Instead of the simple answer regarding responder chain, the interviewer requested the answer to be as detailed as possible. After the interview, I digged through internet archives, UIKit documentation as well as answers from ChatGPT to look for information, and this is an revisited version of my answer to the question “What happens when the User Taps on Screen?”

Book from 2024

At the start of 2024, I made a promise to myself to improve my reading habits and rescue my dwindling attention span from the clutches of mindless scrolling through Instagram reels and TikTok videos. To support this, I kept my Kindle charged and in pocket as much as possible. Despite all this effert, in true deserter fashion (kidding!), I began numerous books but only finished 20% of them. Here are a few:

What I have learnt from leading a 6-month-long project

1:30 pm EDT, Auguest 2nd, 2024, Toronto Canada. I wrapped up my morning with the final project meeting and treated myself to a Baskin Robbins Strawberry Cheesecake Scoop in a waffle cone to celebrate. I don’t often indulge in sweets for health, but today was an exception because it marked the end of my six-month journey as the project lead.

For companies that have adopted the Sprint process and prioritize fast and efficient value delivery, a six-month-long project is uncommon. In my five years as a Software Engineer, leading countless projects, most feature projects have run from two to four months, with only a few extending to five months before starting experiments. For the longer platform projects, most reach a milestone around four to five months. A six-month-long project is truly exceptional and deserves to be named the Project of the Year.

From a Jekyll blog to Ruby (Basics)

For someone who works primarily around Python & JavaScript (and recently started iOS dev with Obj-C and Swift), setting up this blog with Jekyll is my first experience to interact with everything Ruby. I had some struggles during development around understanding some terminologies and setting up the environment, but I found comparing them with what I know in Python and JavaScript works well for me.