Concept redesign · Federal · UI/UX
DIBBS — Modernizing Federal Procurement
A self-initiated redesign of the DLA Internet Bid Board System — the front door to billions of dollars in Defense Logistics Agency solicitations. Rebuilt from a database-oriented legacy interface into a task-oriented vendor experience, designed to Section 508 / WCAG 2.1 AA from the first screen.
Self-initiated concept. Not affiliated with, commissioned by, or endorsed by the U.S. Defense Logistics Agency or the Department of Defense. Created to demonstrate accessible design capability for federal digital services. All data shown in the mockups is illustrative.
01 / The challenge
Complex work deserves a clearer interface — not a simpler job.
DIBBS is a web-based procurement platform operated by the Defense Logistics Agency. Vendors use it to discover contracting opportunities, review solicitations, submit secure quotes, access technical data, and track awards. It serves first-time suppliers and career procurement professionals from the same set of screens.
Over time it had evolved into a highly functional but increasingly dense environment. Critical actions competed with reference material, technical resources, system terminology, and secondary navigation — making even routine tasks harder to find and finish. The goal was to modernize the experience while preserving the information density specialists depend on.
| Area | What we observed | Impact on vendors |
|---|---|---|
| Cognitive load | 81 links on the homepage — 62 of them inside 10 boxed category panels — plus a navigation menu holding 61 more destinations. | Primary actions are difficult to identify. |
| Task hierarchy | High-frequency actions such as finding a solicitation carry the same visual weight as help content and references. | The main job is buried in the supporting material. |
| Onboarding | First-time vendors must understand DIBBS terminology and system dependencies before they can respond to an opportunity. | A steep curve before the first quote. |
| Accessibility | Dense layouts, small interface targets, limited visual hierarchy, and legacy interaction patterns. | Barriers to readability and efficient navigation. |
| Small screens | Layouts built for a fixed desktop viewport, with no responsive treatment of dense procurement data. | Unusable in the field, on a phone or tablet. |
Counts taken from the live DIBBS homepage on 10 August 2026. Figures describe that page as published on that date.
The shift
Before & after.
The same entry point, in the same frame: drag the handle to wipe between the redesigned homepage on the left and the live board on the right. The redesign trades a wall of nested link lists for one obvious primary action and a small number of clearly ranked destinations.
02 / Our approach
From database-oriented to task-oriented.
Rather than organizing the experience around the system's own structure, we mapped the core vendor journey and rebuilt the interface around user intent. Secondary functionality stayed reachable — it just stopped competing with the actions that move a vendor through procurement.
- 01Find an opportunity
- 02Understand requirements
- 03Submit a quote
- 04Track an award
Design decision 01 — A clear starting point
From navigation-first to search-first.
Solicitation discovery is one of the primary reasons vendors open DIBBS at all, yet the legacy experience treats search as a system utility in the top chrome — a Database Search dropdown of 15 options, a value field, and a GO button, sitting above 81 links. We moved search to the center of the homepage and built it around the identifiers vendors already work in — NSN, FSC, and solicitation numbers.
The primary procurement action is available the moment a vendor enters the platform.
First-time vendors get an explicit route from registration to their first submitted quote.
Advanced tools and reference material stay accessible without overwhelming someone still working out what to do next.
Design decision 02 — Search built around decisions
From database queries to opportunity discovery.
The legacy RFQ experience split database search and solicitation-text search across multiple dense forms, exposing technical controls before a vendor could begin evaluating anything. We consolidated discovery into a single, predictable model: search → filter → scan → evaluate → act.
NSN, FSC, solicitation number, and keyword discovery all live in one consistent search experience.
Procurement filters — set-aside, solicitation type, closing window — remain available without competing with the search itself.
Solicitation type, set-aside status, technical data, quantity, and closing dates appear in the result, so vendors stop opening records just to check relevance.
Structured metadata, clear typography, status labels, and visible deadlines make long result lists easy to compare.
Design decision 03 — Across every screen
Responsive, not compressed.
Dense procurement data is where responsive design usually breaks down. Rather than squeezing the desktop layout onto a phone, the mobile experience re-ranks it: the search stays primary, result cards carry the fields a vendor needs to triage an opportunity, and the actions — view, sign in to quote — stay reachable with a thumb.
03 / Why it's compliant
Accessibility as a design constraint, not a final layer.
The redesign was built toward Section 508 and WCAG 2.1 AA from the start, with accessible patterns embedded across navigation, search, data presentation, forms, and responsive layouts. Each decision below maps to the success criterion it satisfies.
Text, controls, and interface states were designed against AA contrast targets, so dense procurement data stays readable.
Solicitation types, set-aside status, and closing deadlines carry text labels alongside color.
Navigation, search, filters, and primary actions were designed for keyboard use with visible focus states throughout.
Interactive elements were sized for touch and imprecise pointing, on desktop and mobile alike.
Quote and search forms use persistent labels, logical grouping, and clear validation and error messaging.
Semantic hierarchy, predictable content order, and consistent component behavior give screen readers a real structure to work with.
Responsive layouts preserve information hierarchy, context, and essential actions instead of compressing the desktop view.
Clear typography, stronger hierarchy, and improved spacing make large result sets easier to scan and compare.
The contrast floor applied across the concept — text against its background, controls and interface states against theirs.
Statuses that depend on color alone. Solicitation type, set-aside, and deadline urgency each carry a text label.
The target the patterns were designed toward, for Section 508-aligned implementation and later conformance validation.
These are the rules the concept was designed against, not test results. Conformance is a property of a built system — validating it would come after implementation.
04 / What changed
What the redesign asks of a vendor.
Every number below carries its source: the steps it takes to start a search, the links on the legacy entry page, and what a result carries before a vendor opens it. Two are counted from the live system, two from the figures on this page.
The legacy flow opens the Database Search control, picks one of 15 search types, enters a value, then submits. The redesign puts one labeled field on the homepage.
62 of them inside 10 boxed category panels, with a navigation menu holding 61 further destinations.
Solicitation type, set-aside, technical-data flag, solicitation number, item name, NSN, FSC, quantity, closing date, days remaining — all before opening the record.
Each mapped to the specific pattern that satisfies it, rather than asserted as a blanket conformance claim.