Fast Tools

I learned the design process the way most of us did. Research, define, ideate, prototype, test, iterate. It’s a good framework. It taught me to slow down, to ask questions before jumping to solutions, to listen to people who aren’t me. Process gave me rigor. It strengthened my empathy. It taught me to ask the right questions.

I’ve started to believe that when your tools are fast enough, the hard part isn’t making things. It’s knowing which thing to ship.

The cost of trying ideas has dropped dramatically. Design systems, AI, mature frameworks, and tools that keep getting faster. When making is cheap, you can explore more, quicker. My process has shifted from narrow down, then build to build many, then narrow down.

In my current role, I’m the only designer on a small software team. Nine engineers, a product manager, and me. I spent the last decade in design management and took this role to get back to making things.

I had a project recently. A third-party integration that customers had been asking for. The first piece to build was an internal workflow for our team, not customer-facing yet. We needed to ship quickly. Here’s roughly how it went.

1. I brainstormed with the team, then shaped those rough notes into a few different directions.
2. Over the next couple of days, I built working prototypes. Not mockups. Rough but functional React code running in the app, ranging from the smallest change possible to a full feature redesign.
3. Each direction branched into more variations as I built. The building was the ideation. I killed options for being too buried, too ambitious for the timeline, or too clever. I narrowed to the strongest and confirmed with the team.
4. A half-day of refining and polish, bouncing between Figma and code. The winning prototype turned into shipped code. Reworked, polished, tested for accessibility and responsiveness.

The bigger the feature, the faster it is to prototype in code, but specific UI elements are still faster to nail down in Figma. Concept to production, under a week.

Shipping was the fastest way to get real feedback. Iterate with the people using it, in context.

Small incremental additions slowly degrade a UI without anyone noticing. One more button here, one more panel there. Sometimes the right answer really is the smallest change. Sometimes the whole thing needs rethinking. You don’t know until you see the full spectrum.

One of the prototypes I killed was a full integrations hub that rolled all our existing integrations into a single view. I wanted it to work, but building it showed me how much rework the other integrations needed to fit the new pattern. It was the right direction but the wrong scope. The version I shipped was the least change that still made the integration feel substantial. I’ve since revived the hub idea and scaled it back. I’m now migrating each integration one at a time instead of as one big change. The exploration generated a roadmap.

When you can prototype fast, the bottleneck isn’t execution. It’s judgment. Knowing which direction to ship. Process tries to make that call less subjective, and that’s valuable. But when process becomes a substitute for judgment, it dismisses everything a designer spends their career developing. Taste, empathy, a feel for quality. You take in the research, the feedback, the data, and then you decide what to act on and what to set aside. That’s the work.

My process doesn’t always look like a diamond diagram. It’s a set of values.

• Stay close to the materials. The code, the users, the data.
• Explore more than necessary.
• Decide with conviction.
• Follow the work, not the role.