Product case study: Digitizing a government procurement workflow for a US government agency.
A USA state government agency ran its entire staffing process on 6 paper forms, email chains, and spreadsheets. Three stakeholder groups (a centralized government agency, state agencies, and staffing contractors) coordinated through 15+ manual touchpoints per hiring cycle with no centralized database, no automated validation, and no real-time visibility across agencies.
I was brought in as the Product Strategist and Designer to digitize this process: translating a 30+ page government procurement process into a centralized, multi-tenant platform with deterministic workflows, role-based access, and automated process.
Stakeholder Management Business analysis Product strategy Information architecture (IA) User journey mapping Interaction design Development Coordination
1 x Product Strategist (me) 1 x Product Designer (me) 1 x Business Analyst Development team (post-handoff)
2025

Discovery & Requirements Analysis: Studied the existing procurement process documentation to understand the end-to-end workflow across 6 forms, 3 stakeholder roles, and 10+ embedded business rules. Used AI as a business analysis accelerator for process modeling and domain learning, with all outputs validated by a human BA for compliance accuracy.
Information Architecture: Created the initial IA in FigJam mapping the complete system structure: entities, relationships, user flows for all three roles, form dependencies, and state transitions. Refined through multiple rounds of stakeholder review before moving into detailed design.
Detailed Design: Defined how information would be presented to each user type, what fields each form would contain, which fields would transfer automatically between forms, how information should be prioritized on each screen, and what new statuses and state transitions the digital system would introduce that didn't exist in the paper process.
Key Product Decisions: Automated Form B generation from Form A data, eliminating the highest-volume manual task. Converted subjective candidate release decisions into a deterministic state machine. Built a status-driven action engine where UI buttons only appear when the action is valid for the current candidate state, task state, and user role. Embedded compliance directly into system behavior rather than relying on user discretion.
Testing & Iteration: Conducted phased testing aligned with Agile sprints. Phase 1 validated the core workflow. Phase 2 tested role-based workflows separately for each user type. Phase 3 verified governance controls.


15+ manual touchpoints reduced to 4 digital steps per hiring cycle
~80% reduction in repetitive data entry and form circulation
Evaluation turnaround projected from ~33 to ~16 business days
Form B generation fully automated (previously manual creation for every Task Order)
Real-time visibility across all agencies for the first time
KEY DECISIONS & TRADE-OFFS:
Why deterministic state management over flexible workflows? Government procurement compliance cannot rely on user discretion. Embedding business rules into the system architecture eliminates subjective decisions, ensures audit readiness, and prevents illegal state transitions. Flexibility in government hiring creates legal risk.
Why Phase 1/Phase 2 decomposition? The 6-form process had clear dependency chains. Forms A → B → C1 → C2 are sequential and required on every Task Order. Forms D, E, and F are conditional. Shipping the critical path first delivered value to all three stakeholder groups simultaneously.
Why auto-generate Form B from Form A? This was the single highest-volume pain point. Every Task Order required CGA to manually re-enter Form A data into a new Form B and distribute it to all active contractors. Automating this one step addressed the most repetitive work in the entire process.
Why status-driven actions instead of static UI? With 3 user roles, multiple candidate states, and strict compliance rules, showing all possible actions at all times would create confusion and compliance risk. Actions derived from the intersection of candidate state + task state + role permissions ensure users only see what they can legally do at any given moment.