Storybooks became our design tool for today

Today I was documenting user research interviews when an engineer came over with a problem we needed to solve.

It was a small inline CRUD experience. The details are not important here, and I can't share the product specifics anyway. What was interesting was how we approached the problem.

He already had a Storybook prototype running. The UI elements were there. It worked. But once we started looking at the actual experience, we found some interaction problems around creating and abandoning a new rule.

So we started working through it together.

Not as a designer handing requirements to an engineer.

Not as an engineer asking a designer to make the UI.

We just worked on the problem.

The artifact was already running

There was no Figma file between us.

We had a Storybook environment, a component we could interact with, and a problem to solve.

That changed the conversation immediately.

I could point at something and say, "What if this happens?" He could change it. I could try the new version. We could find another edge case. He could explain a constraint I hadn't considered. We could try another approach.

The component itself became the thing we were discussing.

That sounds like a small distinction, but it felt very different from the usual design-to-engineering handoff.

We weren't discussing what should eventually be built.

We were discussing what was in front of us.

We stopped splitting the problem by discipline

The interesting part wasn't that I was doing some engineering or that he was doing some design.

Neither of us suddenly became the other profession.

I was still bringing product and interaction thinking. He was still bringing technical knowledge and implementation constraints.

The difference was that neither of those perspectives was treated as a separate phase.

We both contributed to the solution.

I could suggest a change because I thought it would make the interaction clearer. He could push back because of something happening underneath the component. Then we could test the idea instead of debating it abstractly.

There was no point where I needed to say, "This is the design part, now you take it."

We were just trying to make the thing work.

Storybook became a collaboration tool

I usually think of Storybook as a place for engineers to develop and document components.

Today I experienced it differently.

It was a shared workspace.

Because the environment was already set up, we could make changes and immediately see what they meant. We didn't have to translate an interaction from a static frame into an implementation before we could discover whether it actually worked.

That matters particularly for small, interaction-heavy components.

When there isn't much screen real estate, every state and transition matters. You can describe an interaction in a design file, but actually using it exposes things that are easy to miss.

The browser is unforgiving in a useful way.

The collaboration was the design process

I think this is the part I want to remember.

We didn't collaborate after the design was finished.

The collaboration was the design process.

We explored the problem together. We tried things. We found constraints. We changed the interaction. We considered different use cases.

The artifact wasn't the output of the collaboration.

It was the medium through which the collaboration happened.

That feels closer to how I want to work.

Maybe the boundary is the problem

There's a lot of conversation about designers learning to code and engineers learning design.

I understand why.

Those skills are useful, and having more overlap between disciplines is probably a good thing.

But I'm starting to think the more important shift is somewhere else.

Maybe the goal isn't for designers and engineers to become interchangeable.

Maybe it's for both of them to be able to contribute to the same working artifact.

The designer doesn't have to become the best engineer in the room.

The engineer doesn't have to become the best designer in the room.

They just need enough shared understanding to work on the problem together.

And the thing they're working on should be real enough to push back.

From handoff to partnership

I've written before about how the handoff is changing as design work gets closer to code.

Today made that idea feel more concrete.

A handoff assumes that one person or discipline finishes something and another takes it from there.

What we did today was different.

There was no baton to pass.

There was just a problem, a working component, two people with different perspectives, and a shared goal of making the experience better.

Maybe that's what the gap between design and engineering looks like when you stop trying to bridge it with more artifacts.

You just start building together.