Mapped a full 3–5 week applicant journey from registration through submission.
Service design case study
Government Contract Bid
A service design concept for an applicant intake experience, focused on clarifying the system from user registration through application submission.
Connected user actions, backstage work, product requirements, and pain points.
Created a shared view for product, operations, and proposal stakeholders.
Translated service complexity into clearer MVP and implementation priorities.
Context
The interface was only one part of the experience.
The project explored how a high-volume hiring or applicant intake process could support users through account creation, identity verification, skills assessment, document submission, and final application package delivery. The core design need was not simply a screen flow. It was a system view that could reveal what applicants do, what internal teams need, where friction appears, and which requirements should be handled by the product.
Challenge
Make a complex public-sector process easier to explain.
- Show how the applicant moves through registration, verification, the application hub, assessments, document upload, and submission.
- Separate customer-facing actions from technology actions, external client actions, and supporting processes.
- Surface pain points and opportunities without turning the artifact into an unreadable process dump.
- Help stakeholders see dependencies before the team committed to an interface direction.
Method
Use service design to reduce translation loss.
The blueprint acted as a conversation tool. Instead of asking stakeholders to react to isolated screens, it gave them a shared system map: what the user expects, what the product must support, where operations need visibility, and which moments create risk.
- Applicant journey framing: Clarified the progression from first-time user setup to completed application package submission.
- Frontstage/backstage separation: Distinguished visible user behavior from internal operational and technology actions.
- Requirement capture: Translated pain points and process constraints into product requirements and implementation notes.
- Opportunity mapping: Highlighted places where UX, automation, content, or validation could reduce confusion.
Blueprint details
Service-design artifacts
The full blueprint is the primary artifact, but the viewer and slideshow pattern make it easier to inspect the document without losing page context.
Blueprinting
Mapped user actions, backstage work, pain points, requirements, and ownership so product teams could reason from the same system view.
Journey framing
Organized the experience into phases so stakeholders could understand the applicant’s progress and the operational handoffs behind it.
Product translation
Converted process findings into requirements, opportunities, and implementation considerations for a clearer product direction.
Outcome
A clearer narrative for proposal and product planning.
The artifact made the experience easier to discuss as a complete service rather than a collection of disconnected screens. It helped frame what the applicant needed, what the product had to support, and where operational requirements needed to be made explicit before delivery.
What it shows
My design work reaches beyond UI polish.
This case study demonstrates how I use service design to make ambiguity visible. That includes understanding role logic, handoffs, system constraints, product requirements, testing needs, and the moments where the user experience depends on teams or systems the user never sees.