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.

But the cost of trying ideas has dropped dramatically. Better tools, design systems, mature frameworks, AI. When making is cheap, you can explore more, quicker. My process has shifted from narrow down, then build to build many, then narrow down.

Currently, 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, a fast-paced partnership. Customers had been asking for it for a while and were growing restless. We needed to ship quickly.

1. I started by brainstorming with the team. I took those rough notes and shaped them into different possible directions.
2. Over the next couple of days I built working prototypes. Not mockups. Rough but functional React code running in the app. They ranged from the smallest change possible to a full feature redesign.
3. I started with three directions, and each one had me explore more variations as I built it. The building was the ideation. I killed options for being too buried, too ambitious for the timeline, or too clever. Narrowed to the strongest and confirmed with the team.
4. A half-day of refining and polish, bouncing between Figma and code. I’m finding that the bigger the feature, the faster it is to prototype in code, but specific UI elements are still faster to nail down in Figma. The winning prototype turned into shipped code. Reworked, polished, tested for accessibility and responsiveness.

Concept to production, under a week.

The feature itself was an internal workflow for our team, not customer-facing. Shipping was the fastest way to get real feedback. Iterate with the people using it, in context.

I explored a wide range of ideas deliberately. 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, all our existing integrations rolled 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, scaled it back, and started migrating each integration one at a time. The exploration generated a roadmap for future projects.

When you can prototype that fast, the bottleneck isn’t execution. It’s judgment. Knowing which direction to ship. Process tries to make that call less subjective, and sometimes that’s helpful. But taken too far, 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 isn’t 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.