Enterprise SaaS

Workforce Systems

Ethical Design

Multi-Role

Mobile + Web

BiometricPRO

Designing a responsible workforce system built on trust transparency and care where biometric technology supports workers instead of surveilling them.

Enterprise SaaS

Workforce Systems

Ethical Design

Multi-Role

Mobile + Web

Role

Product Designer (UI/UX) | Sole Designer

Platforms

4 Web Portals + 4 Native Mobile Apps

Roles Designed

4 Role-Based Systems

Company

M TECHUB LLC

Most biometric systems are designed to catch people. I designed one to protect them.

Eight application surfaces. Four role-based systems. Two payment flows. One design system. One designer. The product shipped and is live.

My Role

Full product ownership. No PM. Just the work.

The product manager was on maternity leave when the project came in, so I took on end-to-end design ownership across research, information architecture, UX flows, visual design, client communication, and developer handoff. I worked directly with the client and internal leadership to move the product from requirements into implementation.

I worked directly with the client throughout the project, submitting deliverables for review and approval as each part of the system evolved. The client reviewed the work directly and approved the direction throughout the process. Feedback was incorporated as the product developed, but there were zero redesign requests requiring the approved product direction to be reworked.

When development began, I prepared full documentation and version documents, presented the reasoning behind the major design decisions to the development team, and remained involved for developer questions, edge cases, and implementation decisions. During my time at M Techub, I saw the core Admin, Company Admin, and Worker experiences move through development and into initial release across web and mobile. Development continued after I left, with the remaining work and smaller refinements completed later.

“The design did not stop at handoff. I stayed involved as it moved into development and saw the core systems begin shipping before I left.”

The product manager was on maternity leave when the project came in, so I took on end-to-end design ownership across research, information architecture, UX flows, visual design, client communication, and developer handoff. I worked directly with the client and internal leadership to move the product from requirements into implementation.

I worked directly with the client throughout the project, submitting deliverables for review and approval as each part of the system evolved. The client reviewed the work directly and approved the direction throughout the process. Feedback was incorporated as the product developed, but there were zero redesign requests requiring the approved product direction to be reworked.

When development began, I prepared full documentation and version documents, presented the reasoning behind the major design decisions to the development team, and remained involved for developer questions, edge cases, and implementation decisions. During my time at M Techub, I saw the core Admin, Company Admin, and Worker experiences move through development and into initial release across web and mobile. Development continued after I left, with the remaining work and smaller refinements completed later.

The Problem

A system that technically works and humanly fails

Biometric workforce systems become harmful when system failures are treated as worker failures. A location mismatch can become an absence. A failed biometric check can look like non-attendance. A deduction can appear without enough explanation. And when there is no formal way to challenge those outcomes, the worker carries the consequences of decisions they cannot see or correct.

I was brought in to design the workforce platform from scratch. The brief was about attendance and workforce management. The deeper design problem was accountability: how do you give administrators the controls they need without leaving workers powerless when the system is wrong?

Research and Discovery

Four failure scenarios that shaped every decision

I studied existing HR and biometric platforms before designing anything. The pattern was consistent: every system concentrated power in the admin dashboard and offered workers either no visibility or a read-only view with no recourse.

Failure Scenario

What it caused

Location mismatch

Worker arrives at assigned task location. System rejects check-in. Absence recorded. Worker penalised for admin's error.

Biometric failure

Device or network fails during check-in attempt. System records missed check-in. Default assumption: worker fraud.

Unexplained deductions

Worker receives less than expected. No documentation, no reason, no formal way to question it.

No recourse path

Workers could complain informally. There was no structured mechanism to raise issues and receive documented responses.

Core finding: These were not edge cases. They were the default experience for any worker in a system with no recourse architecture. The product brief was about attendance. The design problem was about accountability.

Users and the power dynamics I designed for

Super Admin

Governance, compliance, payout approvals. Highest authority, least daily interaction.

Company Admin

Attendance approvals, financial records, workforce management. Daily operational power.

Worker

Attendance tasks financial visibility. Fewest permissions but never without a voice.

Account Executive

Referral tracking, commission wallet, payout requests

Process

How I kept four systems consistent without a PM

Before a single screen was designed I mapped all four systems as separate workflow diagrams in FigJam Super Admin Company Admin Account Executive and Worker each with detailed flows and annotation notes. This was the foundation. Without it designing four separate applications in parallel would have created contradictions that only surfaced during development.

Low fidelity wireframes came next. Because the systems were separate consistency had to be deliberate not assumed. Every time I found a flow or pattern mapping differently between two systems I resolved it at the wireframe stage before it became a built screen. Contradictions are cheap to fix in wireframes. They are expensive to fix in Figma and catastrophic to fix in code.

Once all four wireframes were consistent and complete I researched design systems and typography before touching the visual layer. I selected the component foundation established the token structure and built the Figma variable system before designing a single high fidelity screen.

I designed Super Admin first a deliberate sequencing decision made with the development team. Starting with the highest authority system meant the development side could validate what was technically possible before the other three systems were designed. What was possible in Super Admin set the boundaries for what could be promised in the others. The component library tokens and Figma variables built for Super Admin carried directly into every other system unchanged.

Before a single screen was designed I mapped all four systems as separate workflow diagrams in FigJam Super Admin Company Admin Account Executive and Worker each with detailed flows and annotation notes. This was the foundation. Without it designing four separate applications in parallel would have created contradictions that only surfaced during development.

Low fidelity wireframes came next. Because the systems were separate consistency had to be deliberate not assumed. Every time I found a flow or pattern mapping differently between two systems I resolved it at the wireframe stage before it became a built screen. Contradictions are cheap to fix in wireframes. They are expensive to fix in Figma and catastrophic to fix in code.

Once all four wireframes were consistent and complete I researched design systems and typography before touching the visual layer. I selected the component foundation established the token structure and built the Figma variable system before designing a single high fidelity screen.

I designed Super Admin first a deliberate sequencing decision made with the development team. Starting with the highest authority system meant the development side could validate what was technically possible before the other three systems were designed. What was possible in Super Admin set the boundaries for what could be promised in the others. The component library tokens and Figma variables built for Super Admin carried directly into every other system unchanged.

Before a single screen was designed I mapped all four systems as separate workflow diagrams in FigJam Super Admin Company Admin Account Executive and Worker each with detailed flows and annotation notes. This was the foundation. Without it designing four separate applications in parallel would have created contradictions that only surfaced during development.

Low fidelity wireframes came next. Because the systems were separate consistency had to be deliberate not assumed. Every time I found a flow or pattern mapping differently between two systems I resolved it at the wireframe stage before it became a built screen. Contradictions are cheap to fix in wireframes. They are expensive to fix in Figma and catastrophic to fix in code.

Once all four wireframes were consistent and complete I researched design systems and typography before touching the visual layer. I selected the component foundation established the token structure and built the Figma variable system before designing a single high fidelity screen.

I designed Super Admin first a deliberate sequencing decision made with the development team. Starting with the highest authority system meant the development side could validate what was technically possible before the other three systems were designed. What was possible in Super Admin set the boundaries for what could be promised in the others. The component library tokens and Figma variables built for Super Admin carried directly into every other system unchanged.

Four systems. One component library. Zero contradictions between them at handoff because the contradictions were found and fixed at the wireframe stage not the development stage.

Key Design Decisions

The decisions that made the system responsible

Decision 01 — Most Strategic

Four separate systems, not one system with permissions

Permission layers hide actions. Separate systems make every action visible to the right person only.

The standard approach to multi-role enterprise software is a single product with permission layers. The problem with this architecture is invisible actions. An admin can take financial or attendance actions that the worker cannot see, cannot question, and cannot appeal.

I designed four completely separate applications. Each contains only what that role actually needs. Nothing else is visible. Nothing else can be stumbled into.

This also meant each interface is cognitively manageable. Users are not scanning a dashboard looking for the relevant section. Everything visible is relevant to them.

The standard approach to multi-role enterprise software is a single product with permission layers. The problem with this architecture is invisible actions. An admin can take financial or attendance actions that the worker cannot see, cannot question, and cannot appeal.

I designed four completely separate applications. Each contains only what that role actually needs. Nothing else is visible. Nothing else can be stumbled into.

This also meant each interface is cognitively manageable. Users are not scanning a dashboard looking for the relevant section. Everything visible is relevant to them.

The standard approach to multi-role enterprise software is a single product with permission layers. The problem with this architecture is invisible actions. An admin can take financial or attendance actions that the worker cannot see, cannot question, and cannot appeal.

I designed four completely separate applications. Each contains only what that role actually needs. Nothing else is visible. Nothing else can be stumbled into.

This also meant each interface is cognitively manageable. Users are not scanning a dashboard looking for the relevant section. Everything visible is relevant to them.

"Four separate systems. No role can see what does not concern them. No action goes unaccountable."

"Four separate systems. No role can see what does not concern them. No action goes unaccountable."

Decision 02

Request-based architecture so no worker is ever silent

Workers in most systems have one option when something goes wrong: complain informally. I built a formal channel.

I designed a request system that gives workers a formal channel for four specific situations: manual attendance requests, attendance disputes, salary or deduction questions, and leave exceptions.

Every request creates a traceable record. The admin must respond with a written reason and supporting proof. No decision happens invisibly.

Most HR software treats worker complaints as noise to be managed. This system treats them as records that must exist.

I designed a request system that gives workers a formal channel for four specific situations: manual attendance requests, attendance disputes, salary or deduction questions, and leave exceptions.

Every request creates a traceable record. The admin must respond with a written reason and supporting proof. No decision happens invisibly.

Most HR software treats worker complaints as noise to be managed. This system treats them as records that must exist.

I designed a request system that gives workers a formal channel for four specific situations: manual attendance requests, attendance disputes, salary or deduction questions, and leave exceptions.

Every request creates a traceable record. The admin must respond with a written reason and supporting proof. No decision happens invisibly.

Most HR software treats worker complaints as noise to be managed. This system treats them as records that must exist.

"The worker raises it. The admin responds. Both sides have a record."

"The worker raises it. The admin responds. Both sides have a record."

Decision 03

Location-aware task assignment with mandatory conflict resolution

Workers were being penalised for errors the system made. I designed the system to catch its own mistakes first.

The standard approach to task assignment has no awareness of where the worker is verified to operate. A worker assigned to a location outside their radius gets penalised for a conflict the system silently created.

I designed the assignment flow so that when an admin assigns a task at a location outside the worker's verified radius, the system surfaces an alert before the assignment is saved. The admin sees the conflict before it becomes a problem for the worker.

If the admin proceeds the system does not silently override the worker’s attendance record. Instead it routes to a mandatory resolution step is this a new permanent location for the worker or a one day exception. The admin must choose explicitly. Neither path allows the conflict to become an unrecorded absence.

Every valid punch clock in break start break end clock out must occur within the worker’s verified location. Outside that radius it is flagged not assumed.

The standard approach to task assignment has no awareness of where the worker is verified to operate. A worker assigned to a location outside their radius gets penalised for a conflict the system silently created.

I designed the assignment flow so that when an admin assigns a task at a location outside the worker's verified radius, the system surfaces an alert before the assignment is saved. The admin sees the conflict before it becomes a problem for the worker.

If the admin proceeds the system does not silently override the worker’s attendance record. Instead it routes to a mandatory resolution step is this a new permanent location for the worker or a one day exception. The admin must choose explicitly. Neither path allows the conflict to become an unrecorded absence.

Every valid punch clock in break start break end clock out must occur within the worker’s verified location. Outside that radius it is flagged not assumed.

The standard approach to task assignment has no awareness of where the worker is verified to operate. A worker assigned to a location outside their radius gets penalised for a conflict the system silently created.

I designed the assignment flow so that when an admin assigns a task at a location outside the worker's verified radius, the system surfaces an alert before the assignment is saved. The admin sees the conflict before it becomes a problem for the worker.

If the admin proceeds the system does not silently override the worker’s attendance record. Instead it routes to a mandatory resolution step is this a new permanent location for the worker or a one day exception. The admin must choose explicitly. Neither path allows the conflict to become an unrecorded absence.

Every valid punch clock in break start break end clock out must occur within the worker’s verified location. Outside that radius it is flagged not assumed.

"The system flags the conflict before the assignment is saved. The worker is never penalised for a decision the admin made."

"The system flags the conflict before the assignment is saved. The worker is never penalised for a decision the admin made."

Decision 04

Every financial action is explainable and visible to the worker it affects

Showing a number without showing how it was calculated does not build trust. It confirms the number.

Every organisation admin needed a financial record system covering salary payments, deductions, reimbursements, and pay slips. The instinct is to build a record table the admin manually fills. That is the wrong starting point.

I designed two payment flows and one payout system covering three different financial contexts.

Every organisation admin needed a financial record system covering salary payments, deductions, reimbursements, and pay slips. The instinct is to build a record table the admin manually fills. That is the wrong starting point.

I designed two payment flows and one payout system covering three different financial contexts.

Flow 1:- Pay through the system.

The admin clicks Pay Now. A modal captures salary type worker and amount. The system initiates the actual payment through Stripe or PayPal and simultaneously writes the record worker salary type amount date method status automatically. The payment and the record are one action.

Flow 1:- Pay through the system.

The admin clicks Pay Now. A modal captures salary type worker and amount. The system initiates the actual payment through Stripe or PayPal and simultaneously writes the record worker salary type amount date method status automatically. The payment and the record are one action.

Flow 2:- Record a payment made outside the system.
The admin selects the worker. The system fetches their salary amount. The admin adds salary type and attaches supporting proof. The system calculates the paid amount against the worker's salary record and writes the entry. The external payment is documented without the admin rebuilding the data manually.

Account Executive wallet:-
Account Executives earn incentives as a percentage of new user revenue. Those percentages accumulate in a wallet. At the $100 minimum threshold, the Account Executive requests a payout routed to the Super Admin, who processes it through the same Pay Now flow and adds the record accordingly.

BiometricPRO does not hold money. It records every financial action with a written reason, a payment status, and supporting documentation. The payment happens through Stripe or PayPal. The system is the record layer, not the transaction layer. That scope decision kept payment processing outside BiometricPRO and reduced the regulatory surface by relying on external payment providers.

Account Executive wallet:-
Account Executives earn incentives as a percentage of new user revenue. Those percentages accumulate in a wallet. At the $100 minimum threshold, the Account Executive requests a payout routed to the Super Admin, who processes it through the same Pay Now flow and adds the record accordingly.

BiometricPRO does not hold money. It records every financial action with a written reason, a payment status, and supporting documentation. The payment happens through Stripe or PayPal. The system is the record layer, not the transaction layer. That scope decision kept payment processing outside BiometricPRO and reduced the regulatory surface by relying on external payment providers.

"Every financial action creates a record with a reason. The system is the record. Stripe and PayPal are the transaction."

"Every financial action creates a record with a reason. The system is the record. Stripe and PayPal are the transaction."

Every organisation admin needed a financial record system covering salary payments, deductions, reimbursements, and pay slips. The instinct is to build a record table the admin manually fills. That is the wrong starting point.

I designed two payment flows and one payout system covering three different financial contexts.

Flow 1:- Pay through the system.

The admin clicks Pay Now. A modal captures salary type worker and amount. The system initiates the actual payment through Stripe or PayPal and simultaneously writes the record worker salary type amount date method status automatically. The payment and the record are one action.

Flow 2:- Record a payment made outside the system.
The admin selects the worker. The system fetches their salary amount. The admin adds salary type and attaches supporting proof. The system calculates the paid amount against the worker's salary record and writes the entry. The external payment is documented without the admin rebuilding the data manually.

Account Executive wallet:-
Account Executives earn incentives as a percentage of new user revenue. Those percentages accumulate in a wallet. At the $100 minimum threshold, the Account Executive requests a payout routed to the Super Admin, who processes it through the same Pay Now flow and adds the record accordingly.

BiometricPRO does not hold money. It records every financial action with a written reason, a payment status, and supporting documentation. The payment happens through Stripe or PayPal. The system is the record layer, not the transaction layer. That scope decision kept payment processing outside BiometricPRO and reduced the regulatory surface by relying on external payment providers.

Decision 05

Biometric failure is never assumed to be fraud

Standard systems mark a failed scan as absence. I changed the default from accusation to process.

These are not office workers whose attendance is self managed. They are field operatives plumbers electricians on site technicians whose every action requires face scan and location verification. Clock in break start break end clock out task start task completed each is a verified event. The conditions in which they work make failure predictable and legitimate.

A worker travelling to a client site finds the client absent. The task cannot be completed. The worker has no fraudulent intent they have a failed circumstance. The standard system response is a missed punch and an absence on record.

I designed the failure state to immediately surface a manual request flow. The worker records what happened attaches proof and submits a request manual punch location exception task status update with full details. The default is not absent. The default is pending review.

The request routes to the admin. When the admin approves the approved punches appear in a dedicated manual punch module. The admin selects from the approved list the worker’s submitted details breaks logins task records pre populate automatically from the request. The admin does not reconstruct the record. They confirm what the worker already documented.

This decision changed the accountability direction of the entire system. The burden of proof shifted from the worker to the process.

These are not office workers whose attendance is self managed. They are field operatives plumbers electricians on site technicians whose every action requires face scan and location verification. Clock in break start break end clock out task start task completed each is a verified event. The conditions in which they work make failure predictable and legitimate.

A worker travelling to a client site finds the client absent. The task cannot be completed. The worker has no fraudulent intent they have a failed circumstance. The standard system response is a missed punch and an absence on record.

I designed the failure state to immediately surface a manual request flow. The worker records what happened attaches proof and submits a request manual punch location exception task status update with full details. The default is not absent. The default is pending review.

The request routes to the admin. When the admin approves the approved punches appear in a dedicated manual punch module. The admin selects from the approved list the worker’s submitted details breaks logins task records pre populate automatically from the request. The admin does not reconstruct the record. They confirm what the worker already documented.

This decision changed the accountability direction of the entire system. The burden of proof shifted from the worker to the process.

"A failed scan is not an absence. It is a pending review with a documented path to resolution."

These are not office workers whose attendance is self managed. They are field operatives plumbers electricians on site technicians whose every action requires face scan and location verification. Clock in break start break end clock out task start task completed each is a verified event. The conditions in which they work make failure predictable and legitimate.

A worker travelling to a client site finds the client absent. The task cannot be completed. The worker has no fraudulent intent they have a failed circumstance. The standard system response is a missed punch and an absence on record.

I designed the failure state to immediately surface a manual request flow. The worker records what happened attaches proof and submits a request manual punch location exception task status update with full details. The default is not absent. The default is pending review.

The request routes to the admin. When the admin approves the approved punches appear in a dedicated manual punch module. The admin selects from the approved list the worker’s submitted details breaks logins task records pre populate automatically from the request. The admin does not reconstruct the record. They confirm what the worker already documented.

This decision changed the accountability direction of the entire system. The burden of proof shifted from the worker to the process.

Decision 06 — Most Operationally Distinctive

Live location and attendance unified into one component

An admin watching a field team should not have to switch between a map and a table to understand what is happening. I combined them.

Field workers operate across multiple locations simultaneously. The standard admin response is two separate views a map showing where workers are and an attendance table showing their punch records. The admin has to mentally join them to understand what is actually happening in the field.

I designed a unified component where the map and the attendance table are the same view. Every worker visible on the map is also a row in the table. The table shows live punch status clock in time break start break end current task location verification status for every worker currently active. Selecting a worker on the map highlights their row in the table. Selecting a row on the table centres the map on that worker.

The component updates in real time. An admin managing fifteen field operatives across a city sees at a glance who is on task who is on break who has a flagged punch and where each of them physically is in one view without switching screens.

This decision was not about aesthetics. It was about reducing the cognitive load of managing a distributed field team from a single dashboard. Location data and attendance data are the same event viewed two different ways. The design treats them as one.

Field workers operate across multiple locations simultaneously. The standard admin response is two separate views a map showing where workers are and an attendance table showing their punch records. The admin has to mentally join them to understand what is actually happening in the field.

I designed a unified component where the map and the attendance table are the same view. Every worker visible on the map is also a row in the table. The table shows live punch status clock in time break start break end current task location verification status for every worker currently active. Selecting a worker on the map highlights their row in the table. Selecting a row on the table centres the map on that worker.

The component updates in real time. An admin managing fifteen field operatives across a city sees at a glance who is on task who is on break who has a flagged punch and where each of them physically is in one view without switching screens.

This decision was not about aesthetics. It was about reducing the cognitive load of managing a distributed field team from a single dashboard. Location data and attendance data are the same event viewed two different ways. The design treats them as one.

"What the map shows and what the table shows is the same event. Combining them means the admin never has to join them manually."

Field workers operate across multiple locations simultaneously. The standard admin response is two separate views a map showing where workers are and an attendance table showing their punch records. The admin has to mentally join them to understand what is actually happening in the field.

I designed a unified component where the map and the attendance table are the same view. Every worker visible on the map is also a row in the table. The table shows live punch status clock in time break start break end current task location verification status for every worker currently active. Selecting a worker on the map highlights their row in the table. Selecting a row on the table centres the map on that worker.

The component updates in real time. An admin managing fifteen field operatives across a city sees at a glance who is on task who is on break who has a flagged punch and where each of them physically is in one view without switching screens.

This decision was not about aesthetics. It was about reducing the cognitive load of managing a distributed field team from a single dashboard. Location data and attendance data are the same event viewed two different ways. The design treats them as one.

The Design Principles I Applied

Every principle backed by a specific decision

Transparency over control

→ Applied in Decision 02 and 04

Every request creates a traceable record. Every financial action requires a written reason.

Consent over enforcement

→ Applied in Decision 03

Location conflicts are resolved through explicit admin decisions not silent system overrides.

Traceability over ambiguity

→ Applied in Decision 01 and 04

Separate systems mean every action belongs to a specific role. No hidden decisions possible.

Explain, never accuse

→ Applied in Decision 05

A failed biometric scan becomes a pending review request not a recorded absence.

Transparency over control

→ Applied in Decision 02 and 04

Every request creates a traceable record. Every financial action requires a written reason.

Consent over enforcement

→ Applied in Decision 03

Location conflicts are resolved through explicit admin decisions not silent system overrides.

Traceability over ambiguity

→ Applied in Decision 01 and 04

Separate systems mean every action belongs to a specific role. No hidden decisions possible.

Explain, never accuse

→ Applied in Decision 05

A failed biometric scan becomes a pending review request not a recorded absence.

Outcome

What shipped

Application surfaces: 4 web portals + 4 native mobile apps

Role-based systems with completely separate architectures

Internal payment custody. Transactions are handled through Stripe or PayPal while BiometricPRO remains the record layer.

Application surfaces: 4 web portals + 4 native mobile apps

Role-based systems with completely separate architectures

Internal payment custody. Transactions are handled through Stripe or PayPal while BiometricPRO remains the record layer.

BiometricPRO had already shipped into active deployment with organisations before I moved to my next role. The parts released during my time at M Techub were being used by active organisations, users, clients, and subscribers while development of the broader product continued.

I stayed involved throughout the implementation happening during my time there, supporting developer questions, edge cases, design reviews, and implementation decisions. I saw the Admin, Company Admin, and Worker experiences move through development and into deployment across web and mobile before I left. The remaining development and smaller refinements continued afterward, with the complete product finished later.

The core architecture carried forward through development: four role-specific systems, the worker request architecture, manual-punch resolution, location-aware attendance, the shared design system, and the external-payment record model.

I do not have deployment-scale usage figures because the client does not share that data externally, so I do not use unverified adoption metrics in this case study.

BiometricPRO reinforced that responsible design is expressed through architecture, not a principles statement. Giving workers a formal request path, making failed biometric events reviewable instead of automatically punitive, and keeping payment processing outside the product all changed how power and accountability worked inside the system.