KpiClock — Design Case Study

01 · Users and constraints

Who uses it, and what it had to fit

Who it's for

Admins: Owners and admins: the Admin dashboard, settings and approvals.
Team leads: The Team dashboard, and leave approvals for their team.
Employees: Track time in the desktop app, check in and out, and request leave.
HR: Attendance, rosters, documents and e-signature. HR approves rosters.

What it had to fit

New product: No earlier version to start from: every screen was designed from the first wireframe.
Three tools in one: Time tracking, HR and e-signature had to feel like one product, not three bolted together.
Small team: Two designers, two engineers. I set the UX and guided the other designer's work.
Privacy: Teams on NDA client work couldn't expose their screens, so monitoring needed a blur mode.
Time: V1 had to reach beta in about three months.

02 · Structure

From time tracking to a full HR product

I mapped the information architecture for V1 first, then grew it for V2. The structure stayed the same; HR areas were added beside the time tracking ones.

V1 · time tracking

DashboardMy, Team, Admin
Clients
Projects
Tasks
Users
Teams
ReportsActivity summary, hours tracked, working hours, web and app usage
SettingsProfile, company, plans and subscription, payments, roles and permissions, rated web and apps
Help and support

V2 · adds HR and e‑signature

Calendar
AttendanceAttendance, shift, roster
LeaveStatus, applications, public holidays
Departments
Organogram
DocumentsTemplates, document requests, e-signature and reminders
Announcements
ReportsAttendance, leave, employee activity, documents
SettingsLeave, notifications, organogram, documents, workflow

Information architecture: V1, then what V2 added

User flow for inviting a new user: from the dashboard, invite by email or copy an invitation link; the invited person creates an account, continues with Google or signs in, with one-time-code checks and password recovery, and ends added to the company — User flow: inviting a new user, from the dashboard to joining the company, with sign-up, sign-in and password recovery paths

03 · Design decisions

Approvals, rosters, privacy and attendance

The problem behind each one, the decision, why, and what it cost.

Approval flows each company configures itself

Settings, Work Flow: a leave approval flow with three completed steps (Department, Division, Human Resource) and a fourth being set up, with its title, statuses for approval, rejection and pending, and who approves: the employee's own unit, a specific higher level (Human Resource Manager), or another department and level — Settings · approval flow for leave: steps, statuses and who approves each step

Problem: Every company approves leave and rosters differently. With several approvers, a request can sit in a queue with no one sure whose turn it is.
Decision: A workflow builder in settings. Each company adds its own approval steps (for example department, division, then HR), sets the status for approval, rejection and pending, and chooses who acts at each step: the employee's own unit, a higher level, another department, or a named person.
Why: One fixed approval path would fit almost no company. Making the steps configurable let the same product serve teams of every shape, and showing each approver's status means no request disappears.
Trade-off: More to set up before the first approval runs.

Roster conflicts caught when the roster is created

Create Roster: an employee roster for October 2026 with shifts across the month for nine employees, colour-coded by work slot (morning and evening general work) — Creating a roster: shifts across the month, colour-coded by work slot

Roster conflicts dialog listing employees whose new shifts overlap existing ones, with the existing shift and the changed shift side by side — A conflict flagged at creation, before the roster is submitted

Problem: If shift overlaps only show up after a roster is submitted, HR has to send it back and start again.
Decision: Check for conflicts while the roster is being built, and show the existing and the changed shift side by side.
Why: A bad roster never reaches approval, so HR approves rosters instead of fixing them.
Trade-off: The roster screen has to check every change as it happens.

Monitoring with privacy built in

Problem: Managers want proof of work, but teams on NDA client work can't expose their screens.
Decision: Screenshots with a blur mode.
Why: Teams under NDA could adopt KpiClock at all.
Trade-off: Less visual detail for managers.

Attendance that follows the time tracker

Feedback: After launch, the client saw people start the time tracker but forget to check in, so attendance showed them absent while they were working.
Change: Starting the time tracker now checks the person in. One action starts the workday instead of two.
Why it mattered: Attendance follows actual work, with a single record of time.

04 · Time tracking (V1)

The tool teams open every hour

V1 replaced Hubstaff. Time tracking shipped complete first, because it is the tool teams open every hour.

Desktop tracker: a list of projects, the tasks of the selected project with time tracked on each, the running task at the top with time worked today, a timer and a start button — Desktop tracker: pick a project and task, start the timer, see time worked today. Windows, macOS and Linux.

Team dashboard: time tracked, meeting time and manual time, a working patterns bar through the day, and the top projects by time — Team dashboard: time tracked, working patterns through the day, and top projects

05 · HR and e-signature (V2)

Attendance, rosters and documents in the same product

V2 replaced BambooHR and DocuSign, inside the same navigation and design as time tracking.

Calendar for October 2026 showing work shifts, holidays, leave, an absence, a work-from-home day and a check-in status line under each day — Calendar: shifts, holidays, leave, absences and daily check-in status in one month view. One calendar for everything time-related, so employees don't check three screens.

Employee roster details for a sample employee: each day's work slot with its approval status (approved or pending), lock status, and who created and approved it — An employee's roster: each work slot with its approval and lock status, and who created and approved it. Locked slots can't change after approval, so payroll and attendance stay in step.

Roster approval: a month calendar with the selected shift, and an approval timeline showing the department and HR approvals done and the admin approval pending — Roster approval: every approver's status visible. The timeline shows whose turn it is, so nothing waits silently.

Creating a document template: a sample employment agreement with highlighted fields for each signer, and settings listing each contact's required actions (signatures, text and dates) — Document template: fields for each signer, highlighted on the contract, with each contact's required actions. Each signer's fields are colour-coded, so it's clear who fills in what before anything is sent.

Send Request dialog: the sender and two contacts with their required actions, an email subject and a message, and a Send button — Sending a document for signature: who signs, what each person must complete, and the message. The signers and their tasks are confirmed in one step before sending.

Monthly attendance report with sample data: average attendance rate, late arrivals, present, absent and leave days, overtime hours, a monthly summary chart and the attendance trend through the month — Monthly attendance report: attendance rate, late arrivals, overtime and leave, with the month's trend. Sample data.

06 · Design system

What the screens are built from

Base: Built on Ant Design 5, themed for KpiClock with its green primary colour.
Components: A components overview covering general, layout, navigation, data entry, data display and feedback components, plus local variables.
Consistency: Time tracking and the HR modules use the same components, so V2 looks and works like V1.

07 · Reviews and changes

From review rounds to after launch

Research: Before the first wireframes, I collected reference flows for onboarding (Notion), project detail (Bonsai) and sidebar navigation, then mapped 12 user flows in FigJam: sign-up and sign-in, onboarding, inviting a user, clients and projects, tasks, teams, users, roles, reports, settings, the user profile and the company profile.
Reviews: The V1 design went through a product review (26 August 2025) and a CEO review (29 August 2025); the revised design was ready 8 days after the first review (3 September 2025).
Beta: During beta, the client's own company and two partner companies ran their daily operations on it.
After launch: The client saw people start the time tracker but forget to check in, so attendance showed them absent while they were working. Starting the time tracker now marks attendance automatically.

Results

900+

Companies

25,000+

Users

3

Tools replaced

3

Desktop platforms

V1 reached beta in about three months; V2 added HR and e-signature after it.

The design in numbers

200+

Screens designed (web V1, V2 HR modules, desktop)

12

User flows mapped

9 + 7

Product areas in V1, added in V2

8 days

From first review to revised design

1

Action to start the workday, instead of 2

Counted from the Figma files and the information architecture.

08 · What I'd do differently

Design one scheduling foundation from day one

I'd design the calendar, workflow and roster as one shared scheduling foundation from the start. Shifts, leave, holidays and rosters all depend on the same time rules, and designing them as separate modules meant reconciling them later.