Redesigning Supplier Network

Seamless onboarding isn’t just about reducing steps, it’s about building trust and confidence in the user.

Project Context

Beeline is a vendor management system companies use to manage their contingent workforce, including the staffing suppliers who fill open roles.

Supplier Network 2.0 is a standalone platform in Beeline’s ecosystem replacing the fragmented legacy Supplier Network 1.0, giving staffing firms, consultancies, and AOR/EOR providers a self-service home for onboarding, integrations, and performance data.

Problem

Clean isn’t the same as clear

The 1.0 experience is fragmented, creating friction for suppliers during onboarding and integration, and pulling heavy, recurring support from the BSN team.

Onboarding itself is manual and clunky. After a supplier pays for the product, they’re sent one login for training videos, another to set up a separate directory profile, and only then are they handed the login to their actual account, where onboarding finally begins.

Goal & North Star

Send suppliers to onboard in one place.

A supplier should never wonder "what am I supposed to do here?

Get suppliers to their first meaningful action as fast as possible, sequencing value before setup, without forcing them through a wall of forms.

  • Replace passive emptiness with active, contextual direction

  • Cut steps out of the old multi-login onboarding flow

  • Lead with value: get company profile and ATS/VMS connections done first, so API data starts flowing and users can invite teammates almost immediately

  • Reduce onboarding-related support tickets by 60%, directly targeting the confusion 1.0 caused

Process & Key Insights

Onboarding should be in one place.

I mapped and audited the old onboarding flow end-to-end and found the real problem wasn't a missing feature. It was sending the suppliers all over the place before they finally landed inside the product that lacked directional text or help documents.

Solution

Putting the Elements in Place

Four principles guided the design: flexibility over rigidity, support for both self-signup and admin-led invites, progressive (not all-at-once) onboarding, and hierarchy-driven visibility.

GUIDED EMPTY STATES

Every blank module explains what it's for and how to fill it, instead of just being blank.

ONBOARDING CHECKLIST

Modular and skippable, pre-seeded with one item already checked, showing real progress from the first login.

PROGESSIVE DISCLOSURE

Surface next steps as they become relevant, not all at once, with the highest-value actions (client and ATS/VMS connection) surfaced first.

NON-MANDATORY BY DESIGN

Checklist widget can be dismissed, hidden, or will disappear once a supplier no longer needs it or has completed all onboarding tasks, so it never becomes nagware

Reflections

The Reality of Why We Missed Our Deadline

We ended up missing the August deadline, and it wasn't for lack of design readiness. Architecture didn't lock down critical decisions in time, which left key parts of the system undefined well into the timeline. On top of that, the PM was reluctant to take ownership of decisions that needed to be made, so that ambiguity landed on me by default.


I ended up designing multiple competing versions of API access tokens and personal access tokens just to keep the project moving while those calls stayed unresolved.
Combined with poor communication across the team, some of that work got pushed back late, after it had already gone through significant design effort.

It was a reminder that a strong design solution can only move as fast as the decisions around it, and that when ownership is unclear, design often ends up absorbing the gap whether it's equipped to or not.

What I learned

Takeaway

  • Clean and clear are not the same thing: an uncluttered screen can still fail if it doesn't tell users what to do

  • Small progress signals (partial completion) do real psychological work; don't underestimate them

  • Good onboarding design is often about subtraction (fewer logins, fewer redundant steps) before it's about addition

  • When ownership is unclear on a cross-functional team, design ends up absorbing the ambiguity; naming that clearly, rather than just quietly solving it, is its own skill to build