Notes

While working on Whimsical Dark Mode, I needed to expand our range of colors at both ends of the spectrum. Previously, this is something I’d do manually, but there is one big catch: we allow users to create custom palettes.

As a result, we need an algorithmic way to generate color palettes, since we can’t control what they choose at runtime. Given a single color, we need to infer a harmonious range of colors.

From previous work, I knew the oklch color space was the best bet.

• The lightness channel would form the basis for steps. A constant L value across colors ensures they have perceptually similar contrast. We also want to offer more colors at end ranges for layering and nuance.

• The hue channel would be chosen by the user. We’d infer this from a user’s choice.

• The chroma channel was the tricky part. We want to desaturate the colors as the approach the ends, so that they don’t look too vibrant. We’d also infer this from the user’s choice.

To achieve this, I spun up a Make app that lets me generate palettes parametrically. This lets me try out different easing functions for L and C channels before moving into code.

Being able to view multiple options simultaneously is a big part of my process. Today, I was exploring how to render file results in an action menu and found that it was not only easier to evaluate the pros/cons, but also it encouraged me to consider more alternatives.

As Whimsical has grown, the UI has become more complex. Early decisions to have large, airy layouts have led to it now feeling cramped — especially on smaller screens.

I’ve been exploring ways to put the UI on a diet. This includes using space better, lightening the UI font weight, and redrawing the icons.

Figuring out keyboard shortcuts is one of the design details that’s so hard to prototype in Figma. It’s one thing to choose available combinations, but it’s another to consider the ergonomics of where characters live on the keyboard.

Using V0 made it easy to spin up a prototype and test out different combinations for content folding, a feature we’re working on at Whimsical.

The visual details aren’t important here. In fact, it’s all fake content and design that was generated by the model. What’s important is getting a feel for what’s right.

Last week, as a cooldown project between cycles, I started building a prototype for Whimsical mobile companion app. This would be oriented around Tasks and Notifications, though in the future it would expand to access all files.

To build this, I relied on Claude Code. Here’s my approach:

• Own the architecture - I prefer to manually build out the layout, styling, and animation. As a designer, I don’t want to outsource these details or leave them to chance. Plus, nuanced visual changes are often too hard to describe to an LLM. I’ve tried the Figma MCP, but it doesn’t reliably produce the results I want.

• Break it down - As I’m scaffolding things, I’m intentional about breaking things down into components. Beyond maintainability and readability, it allows me to prompt LLMs with explicit, unambiguous names for things. Referring to an <ArchiveButton /> is more reliable than “archive button,” which is not always greppable. Aria labels help here too, especially for icon buttons.

• Codify components - Use a design system. More than ever, codified design systems are essential for steering LLMs toward desired output. They also help with maintainability, which is something easy to forget when vibe coding. I add instructions to prefer reusing these components to my CLAUDE.md file.

• Small, detailed prompts - I write prompts for small, specific changes. I’m far more successful with prompts like “Extract the notification loading and filtering into a NotificationProvider component” than “Make an inbox view.” The former is less open to interpretation, while the latter could result in very unexpected outcomes. Predictably, using engineering concepts and terms works better.

• Plan and act - For big changes, I hash out requirements with the LLM and send the output to a SPECS.md file. With this file, I ask the LLM to break down specs into tasks, which are persisted to a TODO.md. From here, I work through each task individually, committing when each change is complete.

I’m sure this process will evolve, but for now it works pretty well.