Boundary objects as the new prototypes

Citing from one of those work situations in the past: Our team had a catchup to discuss the problem statement; but then right after that; the UX jumped the gun and presented a “prototype” to the team for inputs. They didn’t co-create the user-journey, nor did any user story mapping, neither were there any wireframing/low fidelity mockups that were sketched.

This did upset various other disciplines (product leads, business analysts, tech leads) as to how the UX could have presented something internally without agreeing and aligning on the direction in the first place.

I’ve been thinking about this particular example more recently; and have been in two minds as to whether this was a right approach or not.

After all, what are “prototypes” anyways? Aren’t they just tools for enquiry? Is presenting a prototype to the team before presenting a user-story map, that much of a cardinal sin?

How does this sequence of actions matter anyways if we’re getting closer to the truth?… A year ago, I would have been the first to slam the brakes: “No prototypes before consensus!” But the perspective has shifted a bit.

If you’re plugged into the Twitter / Hacker News echo chambers, you might have already seen some of those vibe-coded apps being spun up in hours, not weeks. They’re slick, high-fidelity, and disposable. Tools such as Lovable/Bolt have vaporized the old sunk costs. Now, building an MVP is less like constructing a cathedral and more like tossing up a pop-up shop—quick, cheap, and easy to tear down (and build again right away)

With this added context, coming back to the original story where the team I worked with felt violated when we skipped a few steps of co-creative user-story mapping and headed straight to building a prototype: would the thinking be different if it costs nothing to build a high-fidelity MVP?

I think it’s okay to do so.

I would definitely add a huge caveat by saying, “hey team, this is just a tool for enquiry for us to think about the user story map better, and we’re not skipping any steps, and even if this is absolutely wrong, we can start from a blank slate, AS THIS COSTS US NOTHING TO BUILD, IT’S QUITE FAST!!!”

I wish I could call this object a “prototype” (for something tangible you build before define what the problem is; or before you define what the user journey is). It’s not about skipping a few steps, but about reducing the number of steps we should take to reach the ideal state.

The traditional design-thinking narrative is that, you don’t “solutionize”, and prematurely optimize; but that’s not the case. These are cheap, disposable apps that help us get closer to what the solution could be. While searching for a good definition, I found the term “boundary object” close enough.

Boundary objects help as we don’t always have to go linearly from understanding the problem to finalising the solution; there could be a co-evolution where problem and solution can evolve hand-in-hand and reach an equilibrium state. Boundary objects help gain faster traction with this co-evolution.

Not discounting (or) discarding the traditional design process; with it’s emphasis on low-fidelity prototypes. It’s not going obsolete anytime soon. But boundary objects can help capture the nuances of user experience, helping elicit better feedback than wireframe-y sketches (sometimes). It need not be used everytime; but can be used in some occasions (it’s a straight jacket, not a life jacket).