Native Competitive Bidding
Senior Product Designer · DeepStream · 2021 · 3 min
Teams running competitive bids were leaving DeepStream to do it in spreadsheets, email chains and standalone tools, then reconciling results back by hand. I led the design of a native auctioning feature that pulled the whole process into the platform. In the first 12 weeks, setup and monitoring time dropped 25% and supplier participation rose 20%. The insight that shaped all of it: the real problem was not speed, it was trust.
Context
DeepStream is an enterprise procurement platform for sourcing and supplier relationships. Competitive bidding was a core workflow the product could not actually do, so buyers and suppliers improvised with external tools and paid the reconciliation tax afterwards. I owned the design end to end, from research through to launch, as the senior designer on the project. The brief looked like an efficiency job. It was not.
What research changed
I interviewed 15 procurement professionals and ran a survey that drew 56 responses. The finding that redirected the project: the pain was not mainly about time, it was about trust. Buyers did not trust that every supplier was seeing the same information. Suppliers did not trust that evaluations were fair. A faster tool that ignored that would have shipped the same suspicion with a nicer interface.
I set transparency as the design goal, not speed. Speed became a by-product of getting transparency right.
The decisions that mattered
Auction setup. A competitive bid has many moving parts: specifications, bid rules, timing windows, invitations, evaluation criteria. The spreadsheet workaround was messy but flexible; the risk was rebuilding that mess as one monster form. I structured setup as a guided, step-by-step flow instead. More screens, usually a thing to avoid, but in testing it cut errors sharply. People set up valid auctions on the first attempt.
The live bidding interface: the hardest part, because real-time multi-user bidding is unlike anything else in DeepStream. I explored three approaches:
All-bids dashboard
Everything updating at once: visually busy, hard to scan under pressure.
Feed-style activity log
Timestamped events: reads as a stream, not a comparison.
Live-updating table
Matches the Excel mental model (scan rows, compare values) that procurement teams already had.
The key iteration came from testing. Suppliers did not just want their current standing; they wanted the pattern. Were competitors front-loading aggressive bids or making incremental cuts? So I added a bid-history timeline alongside the table, showing the full progression rather than only the latest number. Under both decisions sat one constraint I held to: the feature had to feel like a native part of DeepStream, not a module bolted on.
What testing caught
We ran a closed beta with 10 users across both buyer and supplier roles. The problem that surfaced was notifications. Suppliers were not reliably aware when they had been outbid or when a window was about to close, quietly undermining the whole point of a live auction. We rebuilt the notification hierarchy to separate urgent alerts (being outbid, a deadline approaching) from informational updates, and added persistent in-app indicators so nobody depended on email alone. That round was what made us confident to launch.
Impact
Measured over the first 12 weeks: bid management time fell 25%, mostly because buyers no longer reconciled data from external tools. Supplier participation rose 20%, with more suppliers bidding per auction now that responding in-platform was lower friction than email. Satisfaction rose 30% across in-app surveys and follow-up interviews. Both sides described the process as more transparent and more trustworthy, which had been the actual goal all along.