01 · problem
An overview that hid the work to do.
Delta eSourcing is a product owned by BiP Solutions, used for public sector tendering and government contracts. If a school needs a roof repaired, it puts a tender on Delta setting out the requirements. Suppliers bid against it, and the school chooses from the bids it receives.
Its existing dashboard made it difficult to see relevant tenders, contracts and messages immediately after signing in. Users had to look elsewhere to understand what needed attention.
The platform ran on a codebase around twenty years old. Buyers and suppliers shared a need for visibility, but the details differed. A useful dashboard had to help each audience understand both its wider activity and its immediate tasks.
02 · research
Turning team research into a design direction.
The team used focus groups, questionnaires and Hotjar findings to understand the information buyers and suppliers wanted on arrival. I translated that research into three dashboard concepts.
Both audiences wanted visibility of organisation activity and pending work, but the priority content differed. Buyers needed an overview of tenders and contracts alongside messages and actions. Suppliers needed opportunities, live tenders and invitations as well as messages.
I developed the selected direction with the product owner and senior UX designer.
Buyer research
Finding: 78.6% of Buyers would like to see overviews of both Organisation Activity and Pending Activity on their dashboard.
Suggested action: Dashboard MVP to include functionality for both Organisation Activity and Pending Activity.
Finding: Across the three options presented to Buyers (Organisation Activity, Pending Activity and Both) the same four options show up as most popular.
Suggested action: Build these first for the Dashboard MVP, in order of preference, as shown in the comparison below.
Supplier research
Finding: 59.5% of Suppliers would like to see an overview of their Organisation’s performance on their dashboard.
Suggested action: Construct MVP for Dashboard.
Finding: 73.2% of Suppliers would like to see overviews of both Organisation Activity and Pending Activity on their dashboard.
Suggested action: Dashboard MVP to include functionality for both Organisation Activity and Pending Activity.
Finding: Across the three options presented to Suppliers (Organisation Activity, Pending Activity and Both) the same four options show up as most popular.
Suggested action: Build these first for the Dashboard MVP, in order of preference, as shown in the comparison below.
These figures are stated preferences from questionnaire research, not post-launch outcomes. They describe what buyers and suppliers said they wanted from a dashboard, before one existed.
Buyers wantedTender Types by Status and/or Value
Contracts by Status and/or Value
Suppliers wantedOpportunities
Live Tenders and their values
Buyers wantedNew Messages from Suppliers
Actions required on Tenders
Suppliers wantedNew Opportunity Invites
New Messages from Buyers
Items are in order of preference within each area: the same containers, with different work inside them.
Listening to the helpdesk, not only the users
The product owner asked for a dashboard. Research with both sides showed it needed two views: buyers wanted live tenders with bid counts and type filters; suppliers wanted to see their bids, filter them and identify successful ones. Each needed an overview without opening every record.
I also sat with the Delta helpdesk team. They said their largest category of call came from people who could not see their own live tenders in one place. Staff described how awkward it was to tell customers there was no solution. This was failure demand — contact caused by the service missing something rather than by a genuine need.
With the legacy platform, including accessibility problems such as tables running off screen, I designed a new layer over data it already held. A rebuild was not on the table.
After launch, the helpdesk team reported that this category of call dropped away, with remaining contact relating to unrelated defects. That is their reported observation, not a measured reduction from call-volume data.
03 · concepts
Explore alternatives before committing to a shared structure.
I developed three concepts and took them to the product owner and a senior UX designer. After a few meetings we agreed on the third concept, which used a shared framework with audience-specific content rather than treating buyers and suppliers identically.
The core design decision was to use a consistent framework while allowing the content to reflect each audience’s work. That avoided treating buyers and suppliers as if they had identical priorities.
Retrospective service view
Two audiences, connected through Delta
Scroll across to explore all stages → Lane labels stay in view.
01Identify and publish
Get a compliant notice out to the right market.
Defines the requirement, builds the notice, sets criteria and deadlines, publishes.
Notice creation, compliance fields, publication to the market.
Not yet visible to them. The opportunity does not exist until it is published.
Nothing yet.
—
Team research: focus groups, questionnaires and Hotjar. Placement within this wider lifecycle is inferred.
InferredTeam research, not mine02Find and register interest
Is anyone credible actually interested?
Waiting. Watches interest build, with no clear read on who is serious.
Opportunity search, saved alerts, expression-of-interest register.
Searches or receives an alert, reads the notice, decides whether to bid, registers interest, downloads documents.
Is this worth the cost of bidding?
Nothing needing attention was visible after sign-in. Suppliers had to go looking for live tenders, invitations and messages rather than being shown them. The helpdesk absorbed the cost, reconstructing each caller's list by hand over the phone.
Supplier questionnaire preferences are reported in the research section above. Helpdesk interviews: the largest category of inbound calls was users who could not see their own live tenders in one place.
Helpdesk interviews: my primary research03Clarify
Answer once, fairly, to everyone.
Receives clarification questions, drafts answers, publishes them to all bidders at once.
One clarification thread, published to every bidder for fairness.
Submits questions. Reads answers given to everyone, including competitors' questions.
Do I understand what they actually want?
Messages sat away from the work. A clarification answer is time-critical, and neither side saw it on arrival.
Messages named by both groups as priority dashboard content.
04Bid and submit
Are the bids in, and are they complete?
Waiting on the deadline. Cannot see part-complete submissions.
Document upload, version handling, hard deadline lock.
Assembles the response across colleagues, uploads before the deadline.
Get a complete bid in before the clock stops.
Pending actions were invisible. Both sides had to reconstruct what was outstanding from several areas of the platform.
Buyer questionnaire: stated preference for organisation activity and pending activity together. Finding and suggested action shown above.
05Evaluate and award
Score defensibly and award on time.
Opens submissions, scores against criteria, moderates, issues the award notice.
Evaluation workspace, scoring record, award notice distribution.
Waiting, with no visibility of progress. Then wins or loses.
Where do I stand?
No organisation-wide view. Buyers could not see tenders and contracts together; suppliers could not see how they were performing overall.
Supplier questionnaire: stated preference for an organisation performance overview. Finding and suggested action shown above.
06Manage and report
Keep the record straight for audit.
Manages the contract record and reports on activity across the organisation.
Contract record and organisation-level activity history.
Delivers, or reviews the outcome and looks for the next opportunity.
How are we doing across all our bids?
Reporting meant assembling it by hand from screens built for single records.
Stage inferred from the procurement lifecycle rather than from the research.
InferredTO VERIFYWhat the wider service view makes visible
The dashboard is a doorway to the stages, not a stage itself. This retrospective map places the dashboard in the wider procurement lifecycle. Both sides return to an overview to find work and then move into individual records. That helps explain why the dashboard needed to connect activity rather than act as another isolated screen.
The same structural preference, different content. The questionnaire findings above support one framework with two configurations. The shared containers stay consistent; the tenders, invitations, messages and actions inside them reflect each audience’s work.
Waiting is part of the service. The map includes buyers waiting for interest and submissions, and suppliers waiting for publication and award decisions. Those pauses make visibility of status and pending activity worth investigating.
The support desk exposed a gap analytics alone could not explain. Helpdesk staff described calls from people trying to find their own live tenders. That is failure demand — contact caused by the service missing something rather than by a genuine need. Their reported observation after launch provides qualitative evidence.
04 · decisions
Separate the overview from the action.
I designed buyer and supplier views for tenders, contracts, messages and pending activity. Views and filters helped users move between an organisation-wide picture and the items that required attention.
The shared design approach supported consistency, while the information presented reflected the different tasks on each side of procurement. The aim was to make relevant work visible on arrival, rather than require people to reconstruct it from multiple areas.
05 · delivery
Working through implementation constraints.
I connected the views and filters in an interactive prototype to work through how people would move between tender and contract information. The prototype was a way to communicate behaviour to delivery colleagues, not just a collection of finished screens.
I worked with backend development and functional QA as data-population and implementation issues emerged. The final design needed to make sense when connected to the product’s data, rather than only with the examples used in the prototype.
The delivered interface closely followed the final prototypes after those issues were addressed. My work continued through that translation from design into implementation.
06 · outcome
A shared framework for two distinct audiences.
The dashboard brought organisation activity, messages and pending work into a more structured view, with filtering for tenders and contracts. It made the intended next action more explicit in the interface.
The interface was delivered with development and QA. The helpdesk team later reported that calls about finding live tenders dropped away. This is a qualitative observation, not a measured call-volume reduction. Further user evaluation, including Useberry, was planned but is not documented as completed; no quantitative post-launch impact measure is available.
07 · learning
What I would evaluate next.
I would test whether each audience can identify its next task and locate relevant activity without leaving the dashboard unnecessarily. Buyers and suppliers should be evaluated separately because a shared layout can still work differently for each group.
I would also check how the dashboard behaves with sparse and extensive activity, and how clearly its filters communicate the current view. These are the questions I would prioritise in a next evaluation, rather than infer success from the number of screens or prototype connections.
The six lifecycle stages shown in the retrospective service map reflect a general public procurement lifecycle rather than Delta’s own information architecture. They provide context for the dashboard work, not evidence that every stage was researched or redesigned.