“Need to find a better UX flow.”
The redesign separates a saved role from an application someone has started.
Job Hunt.
Know what’s ready. Keep your place.
A role, its documents and its application history, together. I designed how people prepare, review and return—even when a file changes, a handoff fails or the outcome is still unknown.
Coming back meant
starting over.
A role lived in one place, its documents in another. Every time I returned, I had to rebuild the context before I could move forward.
I wanted to come back to the work, see what was ready and know what still needed attention.
Designed for people managing several tailored applications across employer websites. The focus is returning to unfinished work with the right documents, a clear status and a next step.
One application needed one connected record.4 Oct 2026
The first native prototype brought jobs, answers and application state into one place.
Keeping the work
wasn’t enough.
The Android audit exposed the same task in two places. Three users used the Android base and gave feedback afterward: the next step and each application’s status were unclear. Their input helped guide Frosted Blue, which they also tried.
- Finding the next step
- A named action, with a reason.
- Interpreting the status
- Separate saved, preparing and pending.
Three users recruited from my personal network; feedback collected after use. No observed sessions or measured before-and-after results are claimed.
“Recommended next” + “Next in your queue”
The same role and Resume answers action appear twice.
“Follow-up due today”
The reason is visible. Review follow-up and Review application kit name distinct actions.
The audit identified duplication; user feedback reinforced next-step clarity. These are different design versions and fictional records, not a measured before-and-after task.
The resulting direction
Follow an application through.
Browse, prepare, review and return. Explore six connected journeys in the current prototype.
Opportunities
Prepare your application kit
Meridian Materials · Technical specialist
Start when you are ready. Nothing is sent.Saved roles · 2
Frosted Blue · Browse → prepare → review → handoff → recordFiles and employer handoff are simulated.
Inside the decisions.
The working notes, alternatives and native checks behind the experience.
Finding where the flow breaks.
I began with my own applications and an Android audit. Feedback from three users then reinforced two priorities: make the next step explicit and make each application’s status understandable.
“The UX flow feels interrupted.”
The redesign keeps the role, reviewed files and unfinished step together on return.
- My workflow
- Returning meant rebuilding context across roles, documents and follow-ups.
- Product audit
- Tasks repeated, snoozed work resurfaced and a stale draft could restore a cleared blocker.
- Feedback after use
- Three users tried the Android base, then Frosted Blue. Their input helped guide clearer next actions and status distinctions.
7 October walkthrough & audit · 11 October internal QA · Informal feedback after use, reported 1 November
Three decisions that shaped the flow.
I mapped saving, preparation and outcome as distinct steps, then designed for the moments when someone edits a file, leaves or returns.
Make returning dependable first.
The first useful boundary was preparation through recovery: work the app could preserve and explain while the applicant moved between employer sites.
Outside the appDiscover a roleJob boards & employer listings
First milestone
PrepareReviewResume
Local files, answers and one recoverable recordAt the employerComplete the formReturn to record the outcome
Deferred Cloud sync · Automatic AI · Multiple application attempts Keeping the first milestone focused on reliable state and recovery.
Saved is not started.
The earlier list blurred interest and progress. I separated saving a role from starting preparation.
Evidence Status confusion in user feedback · Overlapping destinations in the Android audit
“Jobs worth a look” + “In progress”
Discovery and active preparation share the same screen.
“Saved roles”
The role is on the shortlist. The named action is Start preparation.
“Application · In preparation”
Starting creates active work, with its own kit and next review action.
One extra action gives an application a deliberate beginning. Comprehension still needs testing. The historical and current screens use different fictional records; this is a design comparison.
An edit changes what is ready.
I separated application status, kit review and export freshness. Editing an answer renews overall review; an unchanged résumé keeps its own review.
Evidence Status clarity as a feedback theme · Exact review behavior established by native QA
Three separate facts
Application: In preparation
Kit r1: Reviewed
Files: Current
Only the affected approvals change
Application: Still in preparation
Kit r2: Needs review
Files: Outdated
Unchanged résumé: Still reviewed
The 11 October native check confirmed this distinction. These views demonstrate the current prototype’s state rules; they are not native acceptance captures or measured user outcomes.
when preparation begins.
- Opened is not submitted.
- I kept the outcome pending until the person records it. Returning to confirm adds effort, but avoids inventing a submission.A user report records what they say happened; employer receipt remains unknown.
Protect the work behind the screen.
I separated the interface, workflow rules and saved records so a new screen could not silently change what “reviewed,” “pending” or “submitted” meant.
- The same status, everywhere.
- I chose one shared workflow model over a full rewrite, keeping the rules consistent and existing records compatible.
- Save the whole change.
- SQLite transactions commit the application, pending state and history together. A failed write restores the last committed view.
- Verify before leaving.
- Every required file must pass verification before the employer opens. Cancellation keeps the work available to retry.
Decision records · ADR-001–003, 005–006
A small-file pass was not enough.
Native testing changed the file-transfer approach. A partial export had to stop the handoff, even when earlier examples had worked.
Provisionally accepted
Bounded file handles passed the small-file check.
- 10.5 / 20 MiBPartial output
The boundary failed
The 20 MiB test wrote only 11,010,048 bytes. The approach was rejected.
Kept the verified path
Retain the conservative write, then read back size and checksum before opening the employer.
6–7 Oct native acceptance · Explanatory sequence from ADR-006 and test records. The boundary failure’s underlying cause remained unresolved.
From finding roles to resuming work.
Each iteration changed what came first: search, saved roles, focused context, then a preparation action. Frosted Blue brings that progression into the current design.
Find a role
Separate saved from started
Keep the role in focus
Resume the work
One pattern. A precise promise.
Keep document identity and the action in the same place. Let review state belong to the exact file, so replacing it cannot inherit an old approval.
Résumé · version 1Needs your review
Résumé · version 1Reviewed · this exact file
Résumé · version 2Needs your review
Stable Identity · spacing · action position
Changes with state Version · review label · trailing icon
Explanatory component study · Frosted Blue visual language and existing prototype state rules · Read-only, fictional example
The earlier interaction studies · 18 preserved states
- Earlier problem
- The recommendation and task list could repeat work; overdue items did not consistently respect snooze.
- Design decision
- One ordered queue explains what needs attention. Snoozing changes visibility while preserving the deadline.
The 11 October candidate unified ordering and deduplication in one tested queue.
These 11 October states document a proposal and internal QA. Later informal feedback informed Frosted Blue; uncoached prioritization still needs evaluation.Earlier interaction studies · 11 October 2026 · Original Figma exports · Fictional data
Revisiting the starting point.
On 31 October, I compared search first, a combined list and separate spaces for saved and active work. This later exploration made the structural tradeoffs explicit.
Search leads
Discovery comes first. Work in progress is less visible.
One combined list
Everything is together. Saved and active work compete.
Separate the work
Carried forwardA next action, a shortlist and committed applications.
Current wireframe exploration · 31 October 2026
What the evidence supports.
Native checks establish specific behavior. Informal use by three users informed the redesign. Broader, uncoached evaluation is the next step.
- Built & checked
- The Android foundation supports local preparation, review and outcome state. Later 11 October emulator checks verified two exported PDFs by readback and retained pending work after restart.
- Designed
- Six connected Frosted Blue journeys. Files and employer actions are simulated; the redesigned flow still needs native implementation and acceptance.
Native test boundaries
Separate 11 October runs covered PDF viewing, review renewal, folder cancellation, later file export and saved state after restart. A renewed handoff through to a recorded outcome was not verified. Those native QA runs did not include real employer submissions or participant sessions; the earlier physical-device PDF-viewer issue remains unresolved.
The small moments are part of the flow.
Native interaction decisions cover leaving, typing and returning focus—not just the ideal sequence of screens.
Back offers Keep editing or Discard input. Saved work stays; an uncommitted choice does not become an outcome.
The lower-field check exercises the screen with the keyboard open. Android Back dismisses the keyboard before navigating.
Separate historical Android checks · Fictional QA data · ADR-005. Screens are not one continuous session.
Keep attention with the document.
A TalkBack check after résumé replacement exposed focus jumping to Back. The fix focuses the committed replacement summary; a manual phone retest was confirmed.
BeforeBack controlAfterReplacement summary
6–7 October · Documented device feedback & scoped retest · Not a full accessibility audit
Broader usability and hiring impact remain unmeasured. Cloud sync, automatic AI, multiple application attempts and automatic employer submission are outside this milestone.
Correct state is only useful
when people can act on it.
- Learned
The rules could be correct while the next step remained unclear. Feedback from three users echoed that gap.
- Changed
I made the next action explicit and separated application status, kit review and file freshness.
- Still to learn
Can someone unfamiliar with the project explain the status and complete a handoff without help?
Informal use informed the direction. A structured, uncoached evaluation and hiring outcomes are still ahead.
Explore the work.
Follow the design in Figma, or look through the workflow rules and tests behind it.
Workflow rulesRegression testsDesign decisions
Job Hunt · Designed, built and still evolving.