A dashboard that answers one question

The default design shows counts: applications sent, in review, rejected. A user reads those once and never again, because they do not tell them what to do.

Open with two or three specific actions: this application needs a follow-up today, this interview is on Thursday, this posting closes tomorrow. Everything else is available when asked for.

Cap the list deliberately. Twelve things needing attention produces a scroll and a decision to deal with it later; three produces three decisions, and if the queue is routinely longer than that the problem is upstream volume rather than the layout.

The wrong use is generating more content — insights, tips, encouragement — which adds to the reading load the user is trying to reduce.

The right use is compression: summarising twenty inbound emails into three things that changed, condensing an application history into one line before an interview, turning a long posting into the four requirements that matter for this candidate.

Compression only earns trust if the original is one click away. A summary the user cannot check is a summary they will eventually stop believing, and the link back costs nothing.

• Summarise inbound mail into what changed
• Condense a company history before a conversation
• Reduce a posting to the requirements relevant to this person
• Never generate commentary nobody asked for

The interview view is where a dashboard justifies itself. Everything relevant to one conversation — the posting, the exact CV that was sent, the free-text answers written at the time, who was spoken to before and what was said — assembled on one page.

None of that is reconstructable from memory eleven weeks later, and a candidate assembling it by hand the morning of an interview is spending their preparation time on archaeology.

It also has to show the version that was sent rather than the current one. A regenerated document is a different document, and the whole point is reading what the interviewer is holding.

Rejection counts, response rates and time-since-last-interview are all accurate and all demoralising during a difficult search. Displaying them prominently makes the product something people avoid opening.

Show what is actionable and keep the rest available rather than prominent. There is a real difference between a tool that helps and a tool that reminds someone daily how the search is going.

Never rank a user against other users. A percentile puts someone having a hard search at the bottom of a list, which is accurate, useless, and the fastest way to make them close the product for good.

Statuses inferred from email classification are sometimes wrong, and a dashboard that presents an inference as fact will eventually tell someone they were rejected when they were not.

Distinguish confirmed from inferred in the interface, and let the user correct it in one action. Their correction is better data than the classifier produced, and asking for it costs nothing.

Include the honest terminal states rather than an idealised funnel. Most applications end in silence, so a dashboard showing forty active when thirty-five are dead is presenting fiction — and "no response after the usual window" is a state the user can act on where "in review" is not.

Every classified email is not a notification. Recreating the inbox the user was trying to escape is the most common way these products become an additional burden.

Interrupt for deadlines and interviews. Batch everything else into a single daily summary, and let the user tune it down further without losing the interruptions that matter.

Rejections in particular belong in the digest. A push notification delivering news that requires no action is a needlessly unpleasant way to receive it, and it is the single easiest thing to get wrong in a product used by people already having a difficult few months.