The Art of Building (or Burning) Product Bridges

This article was first published on the User Defenders podcast Bi-Weekly Bugle.

image via LucasFilm

We spend a lot of time designing software. But how much time do we spend building the bridge required to get users aboard it?

Do you remember the scene in Indiana Jones when he found himself in the middle of the rope bridge with enemies on either side?

He had two choices: Be captured and put to death, or cut the bridge and hang on for dear life. You’ll remember he chose the ladder…I mean latter.

Bridges exist for one purpose–to get humans safely from one side to the other without them falling, possibly to their death.


I grew up in California which happens to be a comfort zone for fault lines. I’ll never forget the visual of watching the top deck of the Bay Bridge collapse onto the cars on the lower deck during a big SF quake in 1989. Disturbing indeed. Bridges are not supposed to collapse.

Do you have an onboarding experience to your app or website?

Yes?

You are a bridge-builder.

Evaluate It

When was the last time you inspected its design and structural integrity? Is it a rope bridge that could fail at any time?

Are your users (not unlike Indiana Jones) in the middle of crossing when the bridge is cut only to leave them hanging on for dear life back on the side they started from?

Today’s superguest and user onboarding expert Samuel Hulick says it perfectly:

“There’s a sense of hope every time we try someone’s software to be a better version of ourselves.”

Here’s some common ways we cut the rope in our onboarding experiences thus preventing our users from becoming better versions of themselves:

  • Require unnecessary data upfront (at least by me dinner first!)
  • Extraneous form fields
  • Lose trust by making the user feel like they just went somewhere else in the process
  • Unclear CTA’s
  • Making the user work and think hard to to use the software

Simplify It

Maybe your onboarding experience is strong overall, but there are enemies on either side surrounding your users and preventing them from crossing.

“What enemies? What are you talking about?”

The enemy of complexity.

If your software experience requires an overlay with more scribbles than Mike Ditka’s chalkboard, I promise you…there’s a problem with your software.

Most humans only have the capacity to recall 7 ± 2, and sometimes even that’s asking a lot.

Test It

Just like Samuel and I discuss in his User Defenders podcast interview, your company or client is spending a lot of money on the software–why phone-in the onboarding experience? It’s a tragic waste of ROI not to mention the combined effort of many.

  • Revisit that experience
  • Observe your users trying to get onboard
  • Review analytics

If you’re seeing a downslope in conversions, your bridge may be failing.

userdefenders.com/035

Galvanize It

Maybe your numbers are fine, and there’s no decline–but there’s also no incline in your conversions either. Perhaps there’s a huge missed opportunity that with a few small tweaks could really cause that inflection point to peak once again.

It could be as simple as removing a few unnecessary form fields. It could also be as simple as removing an unnecessary step from the process.


Thanks to reader Vinish Garg for reminding me in the comments that I left out one more very important detail in crafting an effective onboarding process. It’s one that I bring up in the interview, but forgot to write here:

It’s the importance of “message architecture”. How we craft the right words that guide the user across the bridge to our product. Always remember that your UI is a conversation. Thankfully we’re seeing the dawn of “UX Writing” where this critical issue has become forefront of product design…from now on hopefully.


Talk to your manager and/or stakeholder about conducting an experiment. Run a split test against control and see what kind of lift you get. Use the data to get buy-off to revamp the experience.

That small investment in time, could yield huge dividends for your business.

In Conclusion

In closing, I’ll leave you (and me) with a question:

When designing software that requires an onboarding experience, are we a “Dread Pirate Roberts” making our users walk the plank, or are we a Charles Ellis (Golden Gate Bridge) building one of the most structural, beautiful and functional bridges around?

Our users are holding onto hope, and possibly hanging on by a rope for us to find out.

Did you like this and think someone else might too? Virtual bear hugs if you click the 💖