BRD Design Mocks

Employee Lifecycle Management — design mocks

Static HTML mocks covering every screen in the TalentVare BRD v1.0 (dated 28 July 2026). Built to match the running TalentVare app: the same design tokens, component shapes and table conventions, so what is approved here can be implemented without redesign. All data is hardcoded — nothing connects to a backend.

22 screens BRD §1–§5 complete 5 modules Best viewed at 1280px or wider
New — a guided walkthrough

A click-through tour spotlights the key decisions and BRD callouts across all 22 screens, in the same order as the sections below — recruitment through onboarding and offboarding, one continuous flow. Quicker than reading this page top to bottom.

How to read these. Every page carries an amber ribbon at the top naming its BRD section and whose view it is drawn from. Dialogs, steppers and segmented controls work — click them. Dimmed sidebar items are existing shipped screens or not-yet-drafted sections; they are inert by design so nothing links nowhere. A dashed switcher appears on candidate-portal pages so you can see states a real candidate would only reach one of.
Anything marked Proposed is an addition to the BRD, not a requirement from it. Anything marked Decision is a design call that needs confirming — the eight of them are listed at the bottom of this page.

Start here 1 screen

Home Existing app All employees home.html The current TalentVare home screen, rebuilt as a mock to establish the baseline the new modules sit inside. Navbar, hero banner, quick links and broadcast panel.

Pre-boarding BRD §3 7 screens

Hiring request through to a finalised candidate. Lives in the new Recruitment tab, with the approval inbox in Approvals.

Hiring Requests §3.1 Dept Head · HR hiring-requests.html List of requests plus the Raise Request form, which previews the full approval route before submit. Proposed Positions count · fulfilment tracking (§3.1 gives an approved request no end state) Hiring Request Approvals §3.1 Exec Director · MD approvals-hiring-request.html The approver inbox. A new inbox alongside the five shipped ones, so it reuses the Approvals module rather than inventing anything. Reject has its own dialog with a required reason. Candidates §3.2 HR candidates-list.html Pipeline list plus the Invite Candidate form, with a duplicate-email guard and a preview of the invitation email. Resume Search §3.3 HR resume-search.html Faceted search. Checking a skill reveals a minimum expertise-level picker, so “VAT at level 4 or above” is expressible. Decision 1 Decision 2 Result list not a table · age facet Interviews §3.4 HR interviews-list.html Schedule with auto-numbered cycles, panel picked from the approval hierarchy or ad hoc, and physical/virtual branching to office room or Zoom/Teams. BRD ambiguity resolved §3.4's panel-source sentence fuses two ideas; the form makes it an explicit choice Interview Feedback §3.5 Panel member interview-feedback.html Comments and a Yes/No, exactly as §3.5 specifies — no invented scorecards. Previous cycles are visible to the panel member, not just to HR. Decision 5 Feedback blind within a cycle Candidate Profile & Finalisation §3.5–3.6 HR candidate-detail.html Resume, all cycles with feedback retained, and the Finalize dialog whose three outcome buttons switch the form. Salary and joining-date variances against the request are warned inline. Proposed Hold-until exit path (§3.6 names Hold but defines no way out of it)

Offer BRD §4.1 3 screens

Generation, MD signature, then sending. The gate chain is stricter than it looks — approval applies the signature but does not send the offer.

Offers §4.1 HR offers-list.html All offers by stage, including the “Signed — not sent” resting state HR most reliably forgets about. The Accepted row links through to its onboarding case. Offer Letter Generator §4.1 HR offer-generator.html Name, salary and joining date are read-only with their provenance — editing them here would detach the offer from the decision it must reflect. Merged values are tinted in the letter preview. Offer Review §4.1 Managing Director approvals-offer-review.html The three fields §4.1 asks the MD to check, pulled out above the letter with variances flagged. Approve-and-Sign states plainly that it does not send. Decision 3 Send-back as versioned re-issue, not an approval-engine rewind

Candidate portal BRD §3.2, §4.2 3 screens

External, pre-employment. No module tabs, no sidebar, no employee identity — the one part of the BRD with no precedent in the existing app. It reuses the app's visual language deliberately, so a candidate's first contact still looks like Transvare.

Invitation & Email Verification §3.2 Candidate portal-invite.html Token landing, 6-digit code, password creation. Four states switchable at the top. Un-specified states drawn Expired link · already used — neither mentioned in §3.2 Resume Builder §3.2 Candidate portal-resume.html Six steps, all walkable. The expertise scale carries word labels — Basic through Expert — because a bare 1–5 means nothing to someone outside the firm. Offer Response §4.2 Candidate portal-offer.html The signed letter with only Accept and Reject available, per the §4.2 criterion. Four states switchable. Rejection's reason is optional on purpose. Un-specified state drawn Offer expiry — the letter states a validity date, so the buttons must stop working

Onboarding BRD §4.3–4.6 5 screens

New Lifecycle tab. One case, one page: checklist items are grouped by owner and only actionable if you own them, so every role sees the whole picture without being able to tick someone else's box.

Onboarding Cases §4.3–4.6 HR onboarding-list.html All cases with per-owner progress. No Create action — cases are generated automatically on offer acceptance. Onboarding Case §4.3–4.6 HR · read-only for others onboarding-case.html The pattern-setting screen. Five owner-grouped sections, activation gated on mandatory items. Five more screens inherit this shape. My Onboarding §4.3 New employee onboarding-my-details.html Employee self-service: personal, contact, emergency contact, education, bank details, documents. All six sections walkable. IT Onboarding Tasks §4.4 IT Administrator it-checklist.html A queue across cases, not case-by-case — IT works a worklist. Mailbox creation and asset assignment. Application Provisioning §4.5 Administrator provisioning.html Per-app accounts and roles across TalentVare, TaskVare and SalesVare, with pre-flight checks that satisfy the “duplicate accounts are prevented” criterion.

Offboarding BRD §5 3 screens

Separation through to a deactivated, archived employee. Same case pattern as onboarding, pointed the other way.

Separation §5.1 HR separation-list.html Cases plus the Initiate Separation form, which warns up front if the leaver manages people or owes approvals — discovering that at the deactivation gate is what causes deadlock. Exit Clearance §5.2–5.3 HR · read-only for others exit-clearance.html Four department clearances plus the pending-transaction gate, styled as a hard block rather than another checklist because it is what actually stops deactivation. Proposed ×2 Approver reassignment · audited override — without both, §5.3 can deadlock permanently Deactivate & Archive §5.4 HR · IT deactivate-archive.html The terminal screen. Automated versus manual revocation, the Active→Inactive transition, and what is retained for audit versus what stops immediately. Decision 6 Retention split — 7 years for documents, indefinite for transactional history

Decisions needed 8 open

Design calls made to keep the mocks coherent. Each is reversible, but each should be confirmed or overruled before build.

1 Resume Search results are a list, not an AppTable Every other screen is a table because it is a worklist. This is browse-and-compare: skills, levels, institute and location need to be visible at once, which a fixed-width row cannot carry. The one deliberate break from the app's convention. resume-search.html
2 Keep the Age search facet? §3.3 lists age as a filter, so it is built — but filtering candidates by age is a discrimination exposure in several jurisdictions. Needs a call from whoever owns compliance, not a UI decision. resume-search.html — hint sits on the facet itself
3 Offer send-back as a versioned re-issue, not an engine rewind Sending back closes v1 as Returned and HR issues v2. Every other TalentVare flow terminates on rejection, so adding rewind for offers alone would be new approval-engine behaviour. This way costs nothing and yields a version history the audit trail wants. approvals-offer-review.html
4 Recruitment and Lifecycle placed after Employee Directory in the navbar The commented-out stubs in the app sit at the end of the tab list. Placing them early makes the nav read in lifecycle order; moving them back is a one-line change. shell.js — visible on every mock's navbar
5 Interview feedback is blind within a cycle A panel member sees earlier cycles but not a colleague's feedback for the current one until they have submitted. Not in the BRD — but a panel where the second member reads the first's verdict is not collecting two independent opinions. interview-feedback.html
6 Retention splits by data type Identity documents and bank details get a 7-year statutory default; timesheets, leave and approval history are kept indefinitely so historical reports keep resolving names. §5.4 says only “historical records remain available for audit” — this is an interpretation a compliance reviewer should confirm. deactivate-archive.html
7 Proposed  Approver reassignment and an audited override on §5.3 A departing approver's pending approvals belong to other people's requests, so waiting can never clear them — they must be reassigned. And a termination sometimes must complete despite an unresolved expense claim; security should not wait on bookkeeping. Without both, §5.3 as written can block a deactivation permanently. exit-clearance.html — both tagged Proposed on screen
8 Proposed  A way out of the Hold outcome §3.6 names Hold as an outcome but defines no exit, so a held candidate would sit in the pipeline indefinitely. Hold-until plus a reason turns it into a dated reminder while the resume stays searchable. candidate-detail.html — Finalize dialog, Hold branch

Gaps in the BRD itself

Not drawn, because the document has no screen for them. Raised here so they are decided rather than discovered during build.

No employee-initiated resignation. §2 names “Separation / Resignation”, but §5.1 is HR-initiated only — there is no screen for an employee submitting their own notice.
No notification matrix and no non-functional requirements. Roughly fifteen email templates are implied across these flows — invitations, interview invites, offer delivery, clearance nudges, reminders — and none are specified.
Reports and master data are out of scope here. Recruitment funnel, onboarding status and exit status reports, plus a Manage Data asset register, offer templates and checklist templates, were recommended during the architecture review but are not BRD requirements. Not drawn.