Jobio · Product-design decision

From editing a record to working on an application

Evolving a list-to-edit interaction into a workspace that holds role information, preparation and progress together.

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: Reframe the saved job as a read-focused place to work. Evolve the prototype into a routable workspace with contextual company and recruiter information. Integrate later insights, documents, interviews and next-action guidance.

The early job list opened a saved record in its edit form. That was adequate for maintaining a database, but it made reading notes, understanding a role and preparing an application feel like variations of data entry.

Changing the unit of work

The post-MVP UX audit called out this “edit-mode trap.” I used that diagnosis to make the saved job a place to work. Reading and preparation needed a stable destination; editing could remain available as a deliberate action.

The work evolved through several stages. Early form improvements grouped information more clearly. A retained static prototype explored a workspace structure. The implemented job page then introduced a real route, loaded the saved record, handled errors and brought employer and recruiter information into contextual panels. A prototype tab was an idea at that point, rather than proof that every associated feature had shipped.

Alternative considered: Continue expanding the edit form with AI and preparation controls. The form mixed maintenance with reading and offered no clear home for generated work.
Deliberate choice: Open a saved job in a dedicated workspace and keep editing as an explicit action within that context.
Accepted trade-off: A richer workspace needs navigation, loading/error handling and contextual guidance as new capabilities are added.

Local demo workspace crop showing AI Insights, a next step to review saved tailored documents, a route to keep tracking and an example role-framing section. — Current local demo workspace: preparation sits within the saved job, with a route to review documents or keep tracking. Cropped to omit personal application details. Role analysis is generated example content, not verified company research or an assessment of Alex.

Growing the structure with the product

Role analysis, documents and interview rounds later gave the workspace more substantive work to hold. Status changes also became available in context, instead of always requiring the user to open and save a full edit form.

The information architecture needed continued adjustment. Recruiter outreach moved beside recruiter information, where the relationship context was already visible. Preparation guidance became a contextual next action rather than another competing feature block. The Dashboard acquired a way to resume work on a job instead of asking returning users to choose an abstract product area.

Explanatory reconstruction: Make the saved job a place to work. Open a job: A stable, routable destination. Understand: Details and role insights. Prepare: Documents and contact context. Update: Status, interviews and explicit editing. — Explanatory workflow reconstruction from project documentation; this is not a product screenshot. The workspace grew in stages. An early prototype is not evidence that all later features existed then.

A useful boundary for later features

The workspace gave new capabilities a shared object and destination. Saving a job, returning from CV setup, reading insights and opening documents could all refer to the same application. That made it possible to improve the journey incrementally without forcing every feature into the edit form.

A saved job became a routable workspace for its details, role insights, documents and interviews, with contextual company/recruiter information and later guidance for the next action.

The prototype, first workspace and later additions are different stages. A complete historical activity timeline is not established by the early prototype or event-logging foundation.

I owned the interaction and information-architecture work alongside AI-assisted delivery. This story demonstrates the evolution of the workspace, with its implemented capabilities and remaining boundaries. It does not claim a measured reduction in task time or treat the prototype's full activity concept as a delivered timeline.