01 / THE CHALLENGE
One employee record. Several kinds of time.
AMS is an internal application for Exsilio. It brings employee IN/OUT records, attendance, Timewidget logs, leave, holidays, and equipment into a shared workspace. These records answer different questions: being inside the office is not the same as logging time against a task.
The interface needs to help someone find a person, choose a period, and understand the record before taking action. A missing punch or a mismatch should be easy to spot without presenting it as a conclusion about the employee.
02 / MY ROLE & APPROACH
I owned the frontend design system and its execution.
My responsibility covered the full frontend design: theme, colors, typography, components, page layouts, and responsive behavior across devices. I carried the visual system through the application so attendance, time tracking, and inventory feel like parts of the same product.
The work needed both a broad view of the product and attention to small, repeated decisions: the position of a date filter, how a status reads in a table, and how a form reorganizes on a phone.
Project timeline · design phases
- 01
Map the workspace
Organize employees, attendance, time records, leave, holidays, and assets around recurring administrative tasks.
- 02
Set the visual foundations
Establish the light and dark themes, type hierarchy, spacing, status colors, and shared navigation.
- 03
Build the components
Apply consistent controls, filters, tables, cards, forms, dialogs, and feedback states across modules.
- 04
Adapt and review
Refine the frontend at different widths, keeping actions reachable and dense records understandable.
03 / INFORMATION ARCHITECTURE
Organized around people, time, and workplace operations.
People & presence
- Employees and devices
- Attendance and IN/OUT events
- Missing-punch review
Time & availability
- Timewidget / biometric comparison
- Leave and WFH requests
- Holiday calendar
Workplace operations
- Inventory and assignments
- Equipment requests and repairs
- Reports and exports
04 / USER FLOW
From a time mismatch to the records behind it.
The time-tracking view keeps the employee and date range above the comparison. It separates logged task time, biometric presence, confirmed overlap, and time needing review, so the viewer can follow the reason for a flag.
- 01Choose an employee and dates
- 02Compare task and presence time
- 03Inspect the flagged interval
- 04Review the supporting records
An IN or OUT record is missing
The missing-punch view provides a separate route to request regularisation with a corrected time and a reason. A flag is a review prompt, not a final judgment.
The asset journey
- 01Raise a device request
- 02Review available inventory
- 03Assign an asset to a person
- 04Track return or repair
A device needs replacing
The request retains the current asset and the reason for replacement, while inventory retains its condition and assignment history.
05 / DESIGN DECISIONS
Make the distinctions visible.
Keep time sources separate
Timewidget and biometric records have different meanings. Separate labels and comparison rows make that difference explicit before the interface highlights an exception.
Use a shared shell, then adapt the workspace
The same sidebar, header, spacing, and primary-action treatment connect the modules. The main area changes with the task: a calendar for holidays, comparisons for time, and forms plus tables for inventory.
Pair status color with language
Labels such as Pending, Assigned, Available, and Under Repair carry the meaning. Color helps scanning, but the user should not have to remember a color key to understand a record.
Design for the smaller screen early
The frontend includes responsive navigation, stacked cards and forms, and contained scrolling for wide records. The hierarchy stays recognizable when the desktop workspace becomes a narrow screen.
06 / THE WORK
Inside the operational workspace.
These views are rendered from the project’s frontend components with sample records.
Time tracking: compare before acting
Employee and date filters establish context before the Timewidget and biometric comparison. Summary rows distinguish confirmed time from intervals that need attention.
Missing punches: an exception with a next step
Employee, date, and missing direction stay together in the record. The regularisation action provides a route to supply the corrected time and an explanation.
Holidays: availability at a glance
A shared calendar presents holidays alongside their type and audience. The surrounding controls support maintaining the schedule without creating a separate visual language.
Leave and WFH: requests in context
Balances, request details, and approval status share a workspace. The structure gives employee requests and administrative review a consistent set of controls.
Inventory: from a request to an assigned device
The asset workspace brings requests, purchase details, assignment, condition, and maintenance status together. Each device remains connected to the person using it.
The same system on a phone
The holiday view reflows at a mobile width: summary cards stack and the calendar stays within the available space.
07 / DESIGN INTO DEVELOPMENT
Reusable pieces, consistent behavior.
The React frontend separates the application shell from individual modules. Shared input fields, dropdowns, date controls, tables, buttons, and dialogs carry the visual language into day-to-day use. Theme styles cover both light and dark surfaces rather than treating dark mode as a separate set of screens.
My role was the frontend design and its responsive execution. The case study focuses on that layer: what an employee or administrator sees, how information is grouped, and how the interface adapts.
08 / REFLECTION
Exceptions need context, not just emphasis.
The most important distinction in AMS is between showing a discrepancy and explaining it. Separating the time sources, keeping filters visible, and placing an action next to the relevant record gives the interface a clear basis for review.
Across attendance and inventory, the same principle applies: a status is more useful when the person, date, and underlying record remain close to it.