Locked

This case study is locked. Ask me for the code.

Menu

Fifteen years, four toolchains

Photoshop slices and Flash timelines, then Sketch, a shelf of prototyping tools, then Figma, and now mostly code because AI made that a reasonable place to stand. What transferred, what died, and why designers will go further with this than most industries.

13 min

I am in my mid-thirties and I have rebuilt my entire toolchain four times. Photoshop, Sketch, Figma, and now mostly code. That is not a flex, it is a warning about what to get attached to, because every one of those rebuilds threw away years of muscle memory and kept almost nothing except the way I think about the work.

The raster years

When I started, a user interface was a picture of a user interface. You built it in Photoshop at a fixed width, because the web was a fixed width, and then you cut it apart. The slice tool and Save for Web were core skills. You were literally chopping a flattened image into pieces a browser could reassemble.

Fireworks was better at this than Photoshop, which is why a certain generation still goes a bit quiet when you mention it. Adobe killed it in 2013 and a lot of us went looking for somewhere else to live. Anything that moved was Flash: separate file, timeline, some ActionScript, effects authored in a completely different environment from the layout. Adobe did not switch off Flash Player until the last day of 2020, but it had left serious product work years earlier.

What that era teaches you, mostly by hurting, is that a picture has no states. No components, no variants, no source of truth. If a client wanted a hover state you drew a second picture. If a screen needed an empty state, and most of mine did not have one, you drew a third. Plenty of what I handed over could not be built the way I drew it, and I did not experience that as a problem, because everyone worked that way.

Sketch, and the systems habit before it had a name

Sketch was not a hard sell for me. It clicked the first week. Vectors instead of pixels, artboards instead of one enormous canvas, shared styles, symbols. Reuse became a first-class idea inside the tool rather than a discipline you imposed on yourself with layer groups and willpower. It had been around since a private beta in 2010 and won an Apple Design Award in 2012, but Fireworks dying in 2013 is what pushed a whole cohort of us over.

This is where my systems habit started, and nobody around me called it a design system. It was symbols plus a written spec: a page in the file, or more often a separate document, saying what each symbol was for, which states it had, and what it must never be used for. I have described that as doing design systems before design systems existed, and I should be more careful, because that is not quite true.

The practice is older than me. Pattern libraries and style guides existed years before I touched a symbol. What is true is narrower and more interesting: the vocabulary had not settled. Brad Frost coined atomic design in 2013, Google launched Material Design in June 2014, Salesforce shipped Lightning in 2015, and Frost's book in 2016 is roughly when design system became the phrase everybody used. So a lot of us were doing something we could not name, reaching the same conclusions separately, and hitting the same walls independently. That is a normal way for an industry to learn something.

The constraint that shaped me most was mundane. Sketch had no nested symbols until 2016, and no shared libraries across files until Sketch 47 in late 2017. So for years a system lived in one file and traveled by copy-paste, and the only thing holding it together across a team was the document describing it. I learned that documentation is the system and the components are just what it contains, because the tooling gave me no other option.

The prototyping years, which were a whole circus

Running alongside all of this was a parallel industry that existed purely to make static screens move, and I used most of it.

Axure was the one that bought me credibility with corporate clients around 2012 to 2014. You could put a conditional, data-driven prototype in front of a steering committee, click through a real flow with real logic, and watch the temperature of the room change. People who had spent a decade approving printouts suddenly understood what they were buying. Axure itself was not new, it had been around since the early 2000s. It was new to them. That gap between a tool being mature and an industry noticing is a pattern I would see over and over.

Then InVision, which launched in 2011 and became how design got reviewed for the better part of a decade: upload screens, get clickable flows and comments in one place. Principle for motion, where I built fully animated mobile interfaces on a timeline and they looked genuinely great. Zeplin for handoff, because the design file was not something you could actually give a developer. Flinto, Marvel, Origami, UXPin. There was a shelf of these and most teams owned three.

Every one of them solved exactly one seam in the pipeline. Make it clickable. Make it move. Make it commentable. Make it hand-off-able. Which meant four tools, four subscriptions, and four separate sync problems, because the moment a design changed you were re-exporting into all of them. I once spent most of a Friday rebuilding the same animation three times because the spec kept moving upstream.

Figma did not win by being better at any one of those jobs. It won by deleting the seams. That is also why InVision died rather than shrank: it announced its shutdown in January 2024 and closed its services on the first day of 2025, with Freehand sold off to Miro. Nothing about it got worse. Everything it did became a checkbox inside somebody else's canvas. It was a wild stretch of years, and I do not miss the sync problems. I do still miss Principle a little.

Figma, which I was wrong about

Figma opened an invite preview at the end of 2015 and released publicly in September 2016, and I was skeptical for a good while. It ran in a browser, which felt like a compromise. It felt slower. Sketch was already doing what I needed and doing it natively. I had a coherent argument and I was wrong.

What I underestimated was not any single feature. It was pace. Components, then auto layout, then variants, then dev mode, release after release, each one closing a gap I had been using as a reason to stay put. I was comparing a snapshot against a trajectory, which is the specific way experienced people get this wrong. That cadence is what killed Sketch, not one killer feature. I still open Sketch for side projects and it is still a lovely piece of software. It just is not where the industry lives any more.

The other thing Figma changed was quieter than multiplayer: the file stopped being a file. No more emailing versions, no more being the person who happens to have the current copy. Meanwhile the industry finished catching up, and somewhere between 2017 and 2019 design systems went from a thing enthusiasts blogged about to a line item in job descriptions with a budget attached.

What Figma genuinely solved was shared truth and real reuse. What it never solved, and maybe cannot, is the gap between the artifact and the running product. A component in a design file and a component in a codebase are two separate things that agree by convention and drift by default.

Where I actually work now

Figma is still the source of truth for components and the repository of record. I have not left it and I am not telling anyone else to. The version of this story where a grizzled designer abandons his tools for a terminal would be both untrue and irritating.

But most of my exploration has moved into code, because AI made that a reasonable place for a designer to stand. To be precise about the claim: I did not become an engineer. I prototype, build, and test visually in a code environment where an assistant handles the parts that used to cost an engineer an afternoon and therefore never got asked for.

What changes is the quality of question I can answer. Real data volumes instead of six polite rows. Awkward breakpoints instead of 1440 pixels. Interaction latency, which no static frame has ever communicated. And something that behaves, in front of a stakeholder, which ends arguments that documents keep open forever.

The surprise was that working in code made me more rigorous, not less. A prototype that actually runs will not let you defer the empty state.

A static frame lets you postpone every unglamorous decision: no data, bad data, too much data, loading, failed. Something that runs asks immediately and keeps asking until you answer. Twelve years ago I would have called that a constraint. Now I think it is the main benefit.

This is not a personal quirk, which I checked before writing it down. Figma has spent this year shipping code layers, motion, and direct integrations with coding agents, and Figma Make can now edit production codebases through Git with pull requests. Their own State of the Designer report for 2026 puts generative AI use in prototyping and motion work at roughly seventy-two percent of designers. The vendors are dissolving the boundary themselves.

What actually transferred

Four toolchains in, the pattern is embarrassingly clear. Almost nothing I learned about the tools survived, and almost everything I learned through them did.

  • What a component actually is, learned painfully through symbols and not from any tutorial.
  • That intent has to be written down, learned because Sketch had no shared libraries and the document was all I had.
  • That you design states, not pictures, learned because Photoshop could not represent a state and the omission kept costing me.
  • That you read the domain before you draw anything, which no tool has ever helped with and none ever will.

What did not transfer: every shortcut, every plugin, every clever file-naming scheme I was quietly proud of, and a lot of speed that took years to build and weeks to lose. Four times. That is the real cost of a long run at this and nobody puts it in a job description.

On being old at this

I am wary of treating length of service as expertise. It is possible to accumulate fifteen years of the same year, and I have met people who have. Surviving four toolchains is not a qualification by itself.

What the time buys, if you are paying attention, is calibration about which changes are real. Flash dying was real. Photoshop losing interface design was real. Responsive killing the fixed-width comp was real. A great deal of everything else was noise that felt identical at the time, and the only way I know to tell them apart is to have been wrong a few times and to remember it clearly.

Which is why I keep bringing up Figma. The characteristic failure of experience is pattern-matching a new thing onto an old dead thing, and I nearly did it again with AI, for recognizably similar reasons. It looked like a shortcut, and shortcuts had burned me before. The tell, both times, was that I was arguing about the current version rather than the direction.

Designers will go further with this than most industries

Here is a claim I will put my name to: within a couple of years design will be a more AI-driven discipline than almost anything else, further along than engineering, marketing, or operations.

The reasons are structural rather than flattering. Our output is visual, so we can evaluate a result in a second rather than reasoning about whether it is correct. We already work in short iterative loops, so more iterations is just more of the thing we already do. The cost of a bad output is a discarded artifact, not a production incident, which makes the experiment cheap in a way it simply is not for someone touching a payments system. And designers are constitutionally drawn to new tools. We are a profession that changes its entire stack every five years and then argues about it online.

The lag will not be us, it will be the organizations we work inside. That is the Axure pattern again: individual designers running years ahead of their employer's process, waiting for procurement, review cycles, and someone's security questionnaire to catch up. It is uncomfortable and it is also completely normal. Organizations adapt slowly and then continue adapting, long after the people inside them have moved on.

None of which touches taste or intent. Knowing which thing to make, and why, and what it will cost to maintain, is not getting automated. What is getting automated is the distance between intent and artifact, and that distance used to be most of the job. I expect the tools we are all excited about right now to feel archaic within a couple of years, in the way a clever 2018 plugin now feels like a museum piece.

What I am watching, and where I am skeptical

The interesting open question is what these tools decide to be. Anthropic put out Claude Design in April 2026 as a research preview, a visual canvas with prompts to prototypes, and by June it had design system imports and a two-way link with its coding agent. Figma pushed from the other side, with Make editing real codebases through Git and pull requests. Two credible routes to roughly the same place.

I am more cautious than the demos are. Part of the pitch, on several of these products, is aimed at people without a design background, and that framing gives me pause. Not because non-designers should not make things. Because producing a screen was never the hard part. The hard part is knowing which screen, and why, and what it costs to keep alive for four years. A tool that removes the production bottleneck without touching the judgment bottleneck has moved the constraint rather than removed it.

A lot of this looks excellent in a demo and does not quite read the room, the room being a team with a backlog, a legacy component library, an accessibility standard, and a compliance reviewer who has opinions. That is a whole separate article and I will write it once I have used them long enough to be fair rather than merely quick.

There will be a fifth toolchain. I have no idea what it looks like and I have stopped predicting the shape of them. What I do know is that the job underneath has not moved once in fifteen years: understand a domain well enough to structure it, then make that structure legible to the people who have to live inside it. Every tool I have named was a different way of doing that one thing, and every single one of them felt permanent while I was using it.

Working on something this touches?

If the problem in front of you looks like the one above, that is the conversation I find most useful.