job-lab: Designing a Career Desk, Not Another Job Board
A local-first job-search operating system for senior designers applying from India
The first ask sounded like a job board: collect UX design roles, show them on cards, link out to the original posting. The useful product was somewhere else. A senior designer does not lose because there are too few job links. They lose time deciding which roles are real, whether remote includes India, what the application should say, who to reach, and whether the market is teaching them anything back.
What was broken
Most job products optimize for volume. They let you search, save, and apply. That is not enough for the user I was designing for: a senior designer in India trying to find roles worth a careful application. The hard problem is not discovery. It is judgment under uncertainty.
| User problem | Design response | Engineering response |
|---|---|---|
| Remote does not always mean remote from India | Separate remote, hybrid, onsite and city-specific roles instead of flattening them into one list | Normalize location text into workplace, city points and eligibility flags before the UI renders |
| A match score alone does not tell me what to do | Rename the score to Worth your hour and connect it to the next action | Combine role fit, freshness, application readiness, resume evidence and human-route signals |
| ATS advice is usually vague or dishonest | Give rewrite guidance only where the resume lacks truthful evidence | Compare posting language against resume, portfolio projects and reusable profile data |
| Networking turns into spam quickly | Design outreach as a decision path, not a send-more button | Generate templates from role, company, hiring-team clues and the user's portfolio proof |
My role
I designed and built the experiment end to end: source model, scoring logic, board IA, map interaction, ATS packet workflow, local storage, theme system, and validation scripts. This is the kind of design engineering I like most - the design decision is not a Figma note. It becomes a typed model, a component, a route, a test, and a build artifact.
The architecture is the product strategy
I split the product into three layers. The source layer reads public postings and cleans them into a consistent job object. The decision layer scores role fit, effort, readiness and human access. The interface layer turns those signals into a board, a detail view, an apply packet and a learning loop.
That loop drove the UI structure. The board is for triage. The detail view is for deciding whether to spend the hour. The apply packet is for shaping the evidence. The tracker is for learning whether the system's advice is working. Each view has a different job, so each view carries a different density.
Designing the board as a control room
The map became controversial for a good reason. The first version looked like decoration, and the India boundary was not acceptable for the context. I replaced that with an accepted world political map treatment and made India the default mental model: India boundary visible, remote roles separated, cities ranked on the right, and the ranked application list on the left.
- Decorative geography
- Unclear political boundary
- Remote roles plotted as if they had a city
- No connection to the ranked list
- Accepted political map context
- India-first view for the user's market
- Remote work counted separately
- Dots, city cards and jobs all agree
Interactive preview
Try the Worth your hour model
Worth a look, but fix the resume gate before opening the ATS.
Responsive design meant changing the job, not shrinking the screen
The desktop product is a control room: ranked list, filters, geographic context and split-view detail can coexist because comparison is the task. On a phone, I designed a different composition. Today becomes the compact starting point, five daily destinations stay in a safe-area bottom bar, secondary tools move into a progressive More sheet, and Board becomes list-first with collapsible filters. Opening a role creates a focused overlay with an explicit return path instead of compressing desktop panes.
| Product need | Desktop behavior | Mobile behavior |
|---|---|---|
| Choose what to do next | The wide shell can keep multiple navigation destinations and context visible | Today leads with the most useful actions and five daily destinations |
| Scan the market | List, map, city summary and filters share one control-room view | Board becomes list-first; filters collapse and geography becomes secondary context |
| Move across the workflow | All top-level destinations remain visible in the header | A safe-area bottom bar holds daily tasks; More reveals Advisor, Portfolio, Pay, Negotiate and Settings |
| Open a role and return | Detail and list can use the available split-view space | Detail becomes an isolated overlay with inert covered content, preserved context and an explicit Back to roles action |
The apply packet is where the product earns its keep
A normal job card ends at the apply link. job-lab starts there. The detail page turns a posting into an application packet: role fit, resume gaps, portfolio proof, hiring-team path, outreach draft, follow-up plan and interview prep. The interaction is designed to slow the user down before the external apply click, because that is where quality is won.
| Packet module | Design decision | Engineering detail |
|---|---|---|
| Resume match | Show missing evidence and safe rewrites, not fake ATS hacks | Compare JD terms, seniority and proof points against stored resume text |
| Portfolio proof | Ask for the two projects that answer this posting, not five random links | Match job keywords to saved project themes and generate a short advocacy angle |
| Who to contact | Move from 'networking' to a specific human route | Use public company/team clues and keep manual review in the loop |
| Write to them | Make the email specific enough to be useful and restrained enough to be ethical | Template from role context, profile data and portfolio URL instead of generic AI prose |
Interactive preview
Try packet readiness
Profile fit and seniority match the posting.
Paste resume once in Settings.
Two case studies map to the role.
Find one person before outreach.
Name, email and portfolio URL are ready.
Every feature in the suite
Designing recovery before documenting polish
A local-first product still fails. A required job file can be missing, optional evidence can be malformed, local storage can reject a write, filters can return nothing, and a user can reach a tool before adding a resume or profile. I separated those states instead of routing all of them to a generic empty card. Required-data failure blocks only what cannot be trusted; optional-feed failure degrades the affected advice; local applications and contacts remain untouched.
| State | What the interface says | Recovery behavior |
|---|---|---|
| Required board data fails | The Board is unavailable; local applications and contacts were not changed | Retry the failed source without clearing private local state |
| Optional evidence is malformed | The Board still works; affected Advisor or company evidence identifies what is missing | Reload that feed while preserving the usable product |
| Search or filters return zero roles | The roles still exist, but this view has no matches | Clear search and filters in one action |
| Resume, profile or portfolio proof is missing | The relevant packet module is blocked and names the missing evidence | Route the user to the field that unlocks matching, outreach or autofill |
| A form or storage write fails | The error stays attached to the action instead of implying success | Correct the field, retry the write or reset only the affected local data |
Accessibility became part of the interaction architecture
The accessibility pass changed structure, not only colors. I added a skip path and landmarks, repaired heading and control names, made map points keyboard-operable, implemented real dialog and tab behavior, trapped and restored focus, made covered list content inert behind mobile detail, supported horizontal arrow keys across tabs, preserved visible focus, added reduced-motion behavior, and kept a readable list alternative to the geographic view.
| User need | Implementation evidence | Validation |
|---|---|---|
| Navigate without a pointer | Named buttons, keyboard map points, tab semantics and logical focus order | Keyboard review across every primary view and all job-detail tabs |
| Keep context through overlays | Focus trap, inert covered content, explicit close/back action and focus restoration | Mobile detail and More-sheet open/close paths at 320 and 390 pixels |
| Read both visual themes | Semantic tokens for text, muted labels, status tones, focus and action contrast | Light/dark contrast, persistence and first-paint theme checks |
| Zoom and reflow | Compact cards and local table patterns avoid page-level two-dimensional scrolling | 320-pixel viewport and 200%-equivalent reflow coverage |
| Understand errors and state | Errors name the failed action, retain trustworthy work and provide a recovery control | Core-data, malformed-feed, empty-result, invalid-form and storage-state tests |
What I tested
I tested the product against common application platforms and the failure modes they create: Greenhouse, Lever, Ashby, Workday, SmartRecruiters, iCIMS, Workable and generic employer forms. That changed the product. Autofill can prepare a user. It should not pretend every ATS behaves the same, and it should not auto-submit.
I also wrote browser tests for the live app. The desktop smoke test checks the political map, split-view detail, application tabs and every top-level workflow. The mobile suite exercises the complete product at 390 x 844 and 320 x 720, including navigation, list-detail-return, all detail tabs, empty states, invalid forms, required-data failure, malformed nested data and optional-feed degradation. Accessibility coverage checks keyboard and semantic behavior, contrast, reduced motion and 200%-equivalent reflow. A production smoke after deployment confirmed mobile navigation, Today, no horizontal overflow and zero page errors.
What I can and cannot claim
This was a solo experiment, so I can show ownership, implementation tradeoffs and a working deployed system; I cannot turn that into a story about cross-functional leadership that did not happen. The product is also too early for an honest placement or conversion claim. The next outcome layer should measure time from role discovery to decision, packet completion, application-to-reply conversion, interview conversion and whether the daily cap reduces low-quality applications without reducing opportunities.
What changed after critique
The useful critique was blunt: the map looked bad, the India treatment was wrong, the mobile interface felt like compressed desktop, and the product needed to be more than an attractive happy path. That pushed the design from a visual concept into a full operating system: accepted map context, source credibility, ATS readiness, compact task-first mobile composition, accessibility, recovery, outreach, interview prep, outcome learning and burnout guardrails.