Amarpreet (Preet) Dhillon

A design engineer based in Montreal, Canada. Currently helping users build their worlds and write their stories at . I care about how software works and feels.

Work

Writing

Tracing AI's UI decisions
When an AI model builds a screen, most of it is fine. Then you spot a label nobody needed, the wrong font size, or a color token picked for its name rather than its role.
You can tell the model to fix it, and it will, once. The next screen has the same mistake, because nothing that produced it changed.
So when the model made a bad decision, I started asking it why, and followed the answer back to its source. It's a small habit, and it's the kind of systems thinking we need as more interfaces get built with AI.
The stronger fix, if you can afford it, is a stricter system. Models do better with prop-based components that only accept a fixed set of options. If text can only use the sizes in your type scale, there is no wrong font size to pick. The same goes for wrapping a plain div in a layout component. Polar's Building an LLM safe design system takes this all the way, down to checks that reject raw HTML before it's merged.
Writing03
Tracing AI's UI decisionsOct 2026
Velocity and craft
The tools are fast. You can design a user flow in a day and build a component library in a week.
That speed makes it easy to confuse producing work with knowing whether the work is good. The person looking at the result still takes it in at the same pace. A model can build what you ask for. You still have to see what is missing, decide what matters, and know when to stop.
The trap is that some of the work these tools remove is the work that teaches you to make those decisions. How do you take the speed without skipping the learning?
Production used to be a scarce skill because it was hard. As the tools make it easier, the ability to produce something tells us less about the person who made it. The difference moves to the decisions they make.
Writing02
Velocity and craftAug 2026
Design engineering a collaborate popover
I've designed and built many UIs over the years, so intuition plays a big role in recognizing when an interface can be improved. When something feels off about an interaction, that feeling is experience compressed into a signal. The noticing comes first. Theory and vocabulary come after, to validate and communicate what you noticed.
Still, validated intuition makes for stronger design decisions, and validation doesn't require a formal study. Lightweight methods like heuristic evaluation and discount usability testing[^1] surface most issues.
Take the example above, a share and collaborate popover. My intuition says it makes users work harder than they need to. Let's break it down.
The "Add people" input looks like you should be able to click it, type, and search for users to add. Instead, clicking it navigates to a second screen. It resembles the standard input field found everywhere on the web, so it should behave like one. The false affordance goes against Jakob's Law[^2][^3] and makes users stop and think about something that should be automatic.
Writing01
Design engineering a collaborate popoverJan 2026

Experiments