Native Competitive Bidding for Procurement Platforms
DeepStream is a procurement platform that helps companies manage sourcing and supplier relationships. Before this project, teams running competitive bids had to leave DeepStream and use external tools spreadsheets, email chains, or standalone auction platforms and manually reconcile the results back into your system.
I led the design of a native auctioning feature that brought the entire competitive bidding process into DeepStream, eliminating tool-switching and giving both buyers and suppliers a single source of truth for bid activity.
Senior Product Designer
Jan - Dec 2021
Web
Procurement
50+
Challenge
The core design challenge was twofold:
Complexity for buyers: Setting up a competitive bid involves many variables. Things like: item specifications, bid rules, timing windows, supplier invitations, and evaluation criteria. The existing workaround (spreadsheets + email) was messy but flexible. A native feature needed to handle the same complexity without feeling heavyweight.
Real-time experience for suppliers: Bidders needed to see live updates, understand where their bid stood, and respond within time windows. This meant designing for a real-time, multi-user interaction that is fundamentally different from the rest of DeepStream's interface.
The design constraint was that this feature had to feel like a natural extension of DeepStream's existing workflow, not a separate module bolted on.
Results
We measured impact over the first 12 weeks after launch:
Bid management time reduced by 25%. Buyers spent significantly less time setting up and monitoring competitive bids, primarily because they no longer needed to reconcile data from external tools.
Bidder participation increased by 20%. More suppliers were submitting bids per auction, likely because the in-platform experience was lower friction than responding via email or separate systems.
User satisfaction increased by 30%. Measured via in-app feedback surveys and follow-up interviews with beta participants. Both buyers and suppliers reported the process felt more transparent and trustworthy.
25%
Reduction in Bid Management
20%
Increase in User Engagement
30%
Increase in User Satisfaction
Process
Research: Understanding both sides of the bid (3 weeks)
I interviewed 15 procurement professionals and ran a survey (56 responses) to understand pain points in competitive bidding. The most important finding was that the problem wasn't just efficiency — it was trust. Buyers didn't trust that suppliers were seeing the same information, and suppliers didn't trust that bid evaluations were fair. Any solution needed to address transparency, not just speed.
Defining the workflow (2 weeks)
I mapped the end-to-end auction workflow from both the buyer and supplier perspectives. The key design decision was to structure auction setup as a guided, step-by-step flow rather than a single complex form. This added more screens but dramatically reduced errors in testing — users set up valid auctions on the first attempt instead of needing to go back and fix configuration mistakes.
Prototyping the real-time experience (3 weeks)
The hardest design problem was the live bidding interface. I explored three approaches: a real-time dashboard showing all bids updating simultaneously, a feed-style activity log where each bid appeared as a timestamped event, and a table with live-updating cells that felt closer to a spreadsheet. We tested the table approach because it matched the mental model procurement professionals already had from working in Excel. Users were used to scanning rows and comparing values, not reading a feed. The key iteration was adding a bid history timeline alongside the table so suppliers could see the full progression of competing bids over time, not just the current standing. In early testing, suppliers told us they wanted to understand bidding patterns. It didn't matter whether competitors were front-loading aggressive bids or making incremental reductions because it affected their own strategy.
Beta testing and refinement (2 weeks)
We ran a closed beta with 10 users across both buyer and supplier roles. The main issue that surfaced was that suppliers found the notification system unreliable. It was clear that they weren't always aware when they'd been outbid or when a bidding window was about to close, which meant they were missing opportunities to respond. We addressed this by redesigning the notification hierarchy to distinguish between urgent alerts (outbid, deadline approaching) and informational updates (new bid received, auction status change), and adding persistent in-app indicators so users didn't have to rely solely on email notifications. After this round, we were confident enough to launch to all users.
Conclusion
This project taught me a lot about designing for multi-sided interactions. The buyer and the supplier have fundamentally different goals and mental models, but they're using the same system in real time. The most effective design decisions were the ones that made the process more transparent for both sides simultaneously.
If I were doing this again, I'd invest more time in the post-auction reporting and analytics experience. We scoped it down to a basic summary screen due to time constraints, but after launch it became clear that buyers wanted detailed reports on bidder behaviour. It would be things like: who bid when, how prices moved over time and which suppliers were most competitive. That data was all there, we just hadn't designed a proper way to surface it. It would have strengthened the value proposition significantly, especially for repeat users running auctions regularly.