Job search
JobBot
A working product that turns a fragmented job search into a configurable system for discovery, ranking and follow-up.
I started by looking at the workflow I was already repeating every day.
JobBot began as a tool for my own job search, so the discovery phase relied on self-observation, workflow analysis and comparison of the platforms I was already using rather than formal user interviews.
The same friction kept appearing: repeated searches across different sources, inconsistent role names and location formats, useful information placed differently by each platform, and no shared workflow for deciding what to save, dismiss or revisit.
- The same search had to be repeated across multiple job sources.
- Titles, locations and work modes were inconsistent between platforms.
- Relevant decision signals were distributed differently by each source.
- It was difficult to remember why one opportunity looked stronger than another.
- Make opportunities comparable.
- Reduce repeated decisions.
- Keep ranking understandable.
- Preserve control over what “relevant” means.
- Optimize the interface for repeated scanning.
The opportunity was not another job board. It was a layer above the job boards.
I reviewed the sources I was already using to understand what each one did well and where the experience broke down when they were combined. Some platforms had better filtering, others exposed more useful metadata, while others mattered because they covered a specific market.
Today JobBot reads 13 sources in three ways, depending on what each one offers. Indeed is the main source: JobBot subscribes to job alerts for specific roles, reads the emails and keeps only the listings that fit. Crypto boards (Web3.career, CryptocurrencyJobs.co, CryptoJobsList), remote boards (Remotive, We Work Remotely, Jobicy) and country sources (Adzuna, Arbeitnow, the German Bundesagentur and Swiss job sites) are read through their public APIs or directly from the sites.
I reframed the task from “find more listings” to “continuously collect opportunities, normalize the information I care about and surface the most relevant ones first.”
Bring multiple job sources into one recurring scan.
Translate different role, location, language and work mode signals into a common structure.
Apply configurable priorities, bonuses and penalties to each opportunity.
Filter, understand, save or archive the results from one interface.
Personalization
Preferences are part of the ranking model, not just filters on top of the results.
The configuration separates high, medium and optional role priorities from target countries, preferred cities, languages, remote regions and profile strengths.
Chip-based inputs keep a fairly complex profile editable without turning the settings into a technical form. This lets the dashboard stay simple while the ranking remains specific to the search I actually want to run.
Explainable ranking
A recommendation is more useful when I can understand why it was recommended.
In the list, JobBot uses qualitative match labels instead of exposing a raw score everywhere. When more context is needed, the match expands to show the signals that contributed to the priority.
The goal is not to present the ranking as objectively correct, but to make its reasoning inspectable enough to decide whether I agree with it.
The list stays scannable instead of becoming a wall of numbers.
The detailed rationale only appears when I ask for it.
Role, country, work mode and profile fit remain visible enough to question the result.
The interface is designed for fast evaluation, not exploration.
I focused each card on the signals that affect a decision: relevance, recency, work mode, location, seniority and listing language. Status tabs separate active, saved, archived and expired opportunities, while filters and sorting change the current review set without introducing a separate management layer.
Favorites and archive actions support lightweight triage. Scan status and source diagnostics also make the automation visible instead of hiding whether the system is actually working.
Responsive UX
The mobile layout was reorganized around the same scanning task, not simply scaled down.
Search becomes full width, the two primary filters stay paired, status navigation can scroll horizontally and card actions become equal-width controls.
The most frequent controls stay available without opening a separate filter sheet.
Match, date and work mode remain the first signals encountered.
Save and archive use full-width controls at the bottom of the card.
Research continued through repeated use of the working product.
Because JobBot started as a tool for my own search, repeated use became the main feedback loop after the initial workflow analysis. Friction in everyday use led to clearer status navigation, editable preference chips, more understandable match labels, explainable ranking, cleaner metadata, better source diagnostics and a more deliberate mobile hierarchy.
This makes the case study useful for a different reason than a formal usability study: it shows how observation becomes product rules, how those rules become interface decisions, and how the decisions are revised when they meet real use.
If JobBot were opened to other users, I would move from self-observation to external research: interviews around existing job search workflows, task-based usability testing of ranking explanations, and validation of which preference signals people actually understand and want to control.