Why Scamp exists

I have been a UX designer and developer for over ten years. For most of that time I was stuck in the same frustrating loop: designing something I was proud of, handing it off, and watching it come back almost right but not quite. The spacing slightly off. The border radius wrong. The hover state that got cut because there was not enough time.

It is not a people problem. Every developer I have worked with has been talented and well intentioned. It is a tools problem. Design lives in one place, code lives in another, and something always gets lost when you move between them.

I tried everything. Better handoff tools, design tokens, detailed annotations. They helped a little. None of them actually fixed it.

Eventually I got tired of waiting for someone else to build the tool I needed, so I built it myself.

A little about me

I am a designer who got into code and never looked back. Over the last decade I have worked at startups as an individual contributor, built design teams from scratch, and led design at the VP and Director level at a few different companies.

What has stayed consistent across all of it is that I think about design and code as the same thing. I understand CSS the way a developer does. I approach problems the way a designer does. Scamp needed both of those things to exist, which is probably why no one else built it first.

How I build it

I use Scamp to design Scamp. That sounds like a gimmick but it is genuinely how I work. Every time something feels awkward I fix it. Every time a feature is missing I add it. The tool keeps getting better because I keep running into its edges.

It is open source, free to download, and built for designers who want to work closer to the code, with or without a coding agent helping them along the way.

If that sounds like you, come try it.

— Angie

@angie.uxdev on Threads ↗