> [!Abstract] TL;DR > Keyboard Shortcut Visualizer is a small web tool to visualize and export any macOS keyboard shortcut as a clean, shareable image. > [!Info] ==🔵`v1.0`== June 22, 2026 - [[../_patch-notes/v1.0 — KSV|Patch notes]] > Pick any Mac shortcut. Export a clean image. No install, no sign-up. # Intention ==🔵`v1`== A small tool to visualize and export any macOS keyboard shortcut as a clean, shareable, readable image, built because I needed shortcut visuals for [[../Articles/Building a MacOS setup I'm comfortable with]] and wanted quick way generate them.I think it was a pretty good use case to experiment with Claude. Even if I had to take time to polish some UI, the goal is to move quickly. It’s for personal utility, so scope needs to stay in check at a minimum. Rendering the Qwerty MacBook keyboard properly was the core of the work, since it was the only layout I needed. It had to be representative of the real physical keyboard: proportions, radius, gaps, appearance, with a few deliberate departures on the modifier keys, mostly for legibility on small screens and more consistent labeling. KSV came out of writing a piece that featured Raycast (and karabiner) prominently, and Raycast's hyperkey is itself customizable, so a generic keyboard diagram wouldn't have represented my actual setup. The keyboard needed to be as configurable as the thing it was illustrating: hyperkey mapping and left/right modifier distinction, so the visual could match whatever setup someone is using rather than a single default. The interaction model follows the same logic (one activation key, modifiers that stack, double-tap support) and covers the shortcut patterns the tool is meant to represent. Not possible to compose an activation key, but it could mean something if I continue down the road to a meaningful expansion. Because it emulates a desktop keyboard, a clean mobile layout was never really an option worth pursuing. Rather than break the board's proportions to force a fit, I kept it minimal and let it scroll horizontally. The keyboard is the artifact here, so reflowing it would have undercut the one thing the tool inbut by. # Design & technical choices - **Vanilla, no framework, no build.** Loads once in the browser, and everything resolves locally from there. - **Selector as source of truth.** Everything, the on-screen selector, the preview, and every exporter, is built from one selector keyboard, so nothing drifts apart. It holds at two levels: the logical grid (not pixel coordinates) keeps proportions identical across selector, preview, and export, and the ordered keycap list it produces (`KSV.caps(state)`) is what both the preview and every exporter read from. One geometry, one state, two consumers. - **Cheap to extend.** Once the keyboard exists as a single simulated source, adding a new way to read it is cheap: another format, another layout, another background, another rendering option, it's all just a new view onto the same state, not a new thing to build. That's less about what's available today and more about keeping the cost of adding the next variation low, whatever shape it takes. - **Accent-driven theming.** The whole UI derives from a single `--accent` CSS variable (dynamic favicon look neat). For the moment, it’s cosmetic, but it’s an opening : the same variable is what will let a future major version support multiple shortcuts in one image, each with its own accent. # The loop got faster The process, once I'd actually reflected on the problem, looked like this: prompt the base idea into Claude, specifying not just what the tool should do but how it should approach it (how it reasons about the keyboard state, how export should work, and so on), refine the behavior until it hits a baseline that validates the concept, then move to Claude design. Give it context with the repo, ask it to diverge, merge ideas from different layouts, explore others on paper. Settle on a layout and iterate piece by piece on features and UI. Once it looks right, export everything back into the repo: Claude bridges the gap and implements the UI and features that changed. Clean up, reread the architecture, keep refining (and add juice) with Claude code and the browser inspector, finish. What you end up with is a codebase you actually own. Stay careful about prompting and don't delegate everything, and the process fits comfortably in basic Claude scripting (Claude design been the most consuming of the bunch). The least fun part, the JS mechanics, is exactly the part any model can carry, which is what frees you to spend your attention on the parts that aren't mechanical. If AI hadn't made this cheap, I probably wouldn't have built it: a week for a small export tool only happens because the cost dropped. But the cost isn't what stuck with me, the loop is. I already explore ideas across paper, screenshots, Notion, Figma, whatever's closest at hand. What changed here is how fast that exploration could turn into something testable, and how fast testing it fed back into the next round: several passes in an afternoon instead of spread over days. That only works if you stay critical of the output. You can make just as much of a mess with AI as without it; what changed the result was staying nitpicky about what I chose to keep, and how I evaluated the result or the implementation. You can afford to be more demanding because being picky no longer adds dramatically to the workload. --- *This isn't meant to promote Anthropic. Claude is just the suite tools I've experimented with most, partly because of the kind of pressure that comes with being a designer right now. But the only future I find genuinely promising isn't one where a single company controls the whole pipeline, the model and the interface you're forced to use it through. People should be able to build small, personal things through whatever model they choose, including local ones. This piece describes what I went through on this specific project.* ## Gallery ![[../_site-assets/Keyboard Shortcut Visualiser (2026)/og-preview.png]]