Jobio · Product-design decision

Separating progress, visibility and history

Reworking application status so outcomes survive archiving and different screens apply consistent changes.

Project context: An AI-powered application workspace for understanding roles, preparing documents and tracking a job search. The work spans the application, marketing website, payment model and practical service delivery.

My contribution: Define the status vocabulary and separate archive visibility from application outcomes. Plan legacy migration, shared change behaviour and optional follow-up prompts. Introduce event capture as a foundation for future history-dependent work.

The original application model gradually accumulated overlapping meanings. A status could describe progress, an interview type or the decision to hide a record. The later addition of Archived as a status made the problem visible: tidying the list could replace the outcome the user wanted to remember.

Fixing the conceptual model first

I documented the competing meanings and the entry points that needed to agree. The list had a quick status action, the form saved a field and the workspace initially showed a read-only badge. A coherent model needed the same change to have the same meaning across all three.

The refactor kept a compact active/final vocabulary. Draft remained visible as a legitimate user-managed state. Interview type moved toward the per-interview model rather than becoming another overall application status. Archive became a separate visibility dimension, controlled by an explicit user action.

Alternative considered: Keep Archived in the status picker and infer previous outcomes later. That overwrote the meaning of the application and could not recover historical information that had never been recorded.
Deliberate choice: Keep status for progress/outcome, make archive a separate visibility dimension and record new changes as events.
Accepted trade-off: Separate dimensions require migration rules, explicit archive controls and consistent effects across all status entry points.

Connecting the model to interaction and migration

This allowed an application to be rejected and archived at the same time. Optional prompts could suggest archiving after a final outcome, but dismissing a suggestion did not undo a successful status change. Shared response hints kept those effects consistent without forcing every screen to reimplement the product rules.

Migration also required honesty. A legacy Archived record did not necessarily contain its previous outcome. The product could migrate it into the new structure, but it could not recover information that had been overwritten.

Explanatory reconstruction: Three questions, three meanings. Progress: Where is this application now?. Visibility: Should it remain in the active list?. History: What changed from this point on?. — Explanatory workflow reconstruction from project documentation; this is not a product screenshot. Example: Rejected + Archived retains the outcome. Old missing outcomes cannot be invented during migration.

Recording new history before displaying it

The refactor began recording changes as events so future history-dependent features would have data. This was deliberately a foundation, rather than an excuse to include a complete timeline in the same scope. Later interview and inactivity work could build on a clearer distinction between progress, visibility and recorded change.

Application status and archive visibility became separate concepts, with a shared status-change contract and event capture for subsequent changes.

Legacy outcomes were not reconstructed where the data did not exist. Event logging is a foundation and does not establish a shipped full-history, Kanban or analytics interface.

My contribution connected product rules, data modelling, migration boundaries and visible interaction. The outcome is a more coherent application model, with explicit limits on historical recovery and on features that remained future work.