The 5-inch clock does not have a camera.
Facial recognition should never appear on a clock that cannot use it.
A time clock that gets out of the way.
I redesigned Humanity's shared Android clock around a task most people finish in a few seconds. It had to work at arm's length, on a 640 × 360 screen, with whatever punch hardware that clock actually had.
- UX/UI designer, working directly with the Android engineering team.
- Embedded product system
- Android kiosk · 640×360
- 2025
Most of the useful detail was hiding in the small notes.
The request looked like a visual cleanup. The notes told a different story. Hardware varied, the app was Kotlin, and the clock needed to recover cleanly after every punch.
The app is Kotlin. Icons need to become Vector Drawables.
The handoff had to fit the Android pipeline, not stop at a Figma file.
What happens after a punch or a timeout?
A repeated task needed a deliberate ending and a clean return home.
Remove the choice this clock could never complete.
Every method competed for attention, including facial recognition on a clock with no camera.
The home screen leads with PIN and only shows punch methods the device can complete.
A clock-in should need one clear answer.
My first confirmation still asked too much of someone already leaving. A greeting, the recorded time, and the next useful action were enough. I pulled the history out and let one message do the job.
- Two panels compete for attention
- Too much to read for a repeated task
- One clear confirmation
- Large enough to read while moving
Simple for a worker. Complete for an administrator.
Workers needed speed. Administrators needed depth. I reused the same bars, cards, tables, and status patterns across both so every new screen did not become a fresh invention.
The employee path stayed shallow. Admin work could go deeper.
A worker could punch, check a schedule, or choose a labor level without entering the admin side. Managers could still reach users, enrollment, history, settings, and device controls.
- Home, sign-in, and punch-method selection.
- Clock-in confirmation, schedules, and labor-level selection.
- Users, enrollment, punch history, settings, and theming.
I built the kit beside the product.
Every screen exposed another piece the Android team would need. I pulled those decisions into one small library as we went, including buttons, auth tiles, tables, status banners, and the PIN pad.
Brand Blue
Midnight
Success
Error
Warning
Blue 25
Green 50
Gray 50
Clock in, Bob.
Clock in, Bob.
Clock in, Bob.
Clock in, Bob.
Customers can change the colours without breaking contrast.
A clock could inherit a customer brand colour. That created an obvious risk: an on-brand clock nobody could read. I made the theme control test contrast before saving and offer safer presets when a colour failed.
Ready to save.
Saving blocked. Safer colours shown.
Four rules I kept returning to.
One main action per screen.
Workers glance at the clock on their way in or out. Each screen leads with the next action and keeps status easy to read from a distance.
Contrast is checked in the product.
Customers can change the theme, but they cannot save a colour that fails the 4.5:1 contrast minimum.
Each clock shows what it supports.
Camera options disappear on devices without a camera, so workers never reach a path the hardware cannot complete.
Design for the Android build.
I exported icons as Vector Drawables and built components around the way the Kotlin app is structured. This reduced translation during handoff.
The handoff is real. The performance numbers are not mine to invent.
I do not have recorded task times or adoption numbers for this work. What I can show is the shipped design and handoff: employee and admin flows, device-aware behavior, contrast rules, and an Android-ready component set.
Designed to clock in fast, and get out of the way.
I was not designing a screen people wanted to spend time in. Success meant a worker could trust the answer and leave. That constraint made the work better.