Case study / Enterprise workforce operations
From feature parity to an operational system.
Meralis is a fictional identity for a confidential workforce operations product. Over 4+ years as its sole Product Designer, I turned evolving requirements across HR, staffing, payroll and compliance into one connected operational model.
Good morning, Irene
Approval queue
View allSole Product Designer, responsible for turning stakeholder requirements into product models, workflows, interface decisions, prototypes and implementation guidance.
Bespoke SaaS connecting agency teams, clients and workers across operational workflows with different permissions and responsibilities.
4+ years, 8 core roles and 30 workflow maps across a product replacing processes previously spread across 3 legacy platforms.
01 / The Challenge
The request was a feature list. The problem was an operating model.
The agency relied on separate HR, payroll and staffing platforms. Stakeholders wanted one internal product that could cover the complete operation, while still feeling familiar enough to replace established tools.
The design thesis was to build the smallest coherent operating system for the agency, not a replica of the software they happened to know.
Context
Complexity came from roles, states and constantly expanding scope.
The product needed to support one worker across multiple active assignments, different truths by role, high-stakes state changes and a scope that could expand indefinitely.
One worker, multiple contexts
Documents, permissions and operational obligations may differ for each assignment.
Different truths by role
HR Admins, representatives, proxies, safety coordinators, clients and workers need different visibility and authority.
High-stakes state changes
Payroll, banking, signatures and eligibility need continuity, traceability and recovery.
Scope could expand indefinitely
Without shared primitives, parity requests would become disconnected screens.
Team + Ownership
A long-running product maintained by a multidisciplinary team.
I worked with 1 Product Manager, 2 Product Owners and 3-4 developers, turning incoming requirements into product decisions.
1 PM · 2 POs · 1 Designer · 3-4 Developers
Requirements came through stakeholders, the PM and Product Owners, then moved into workflows, prototypes and implementation discussions.
From requirements to decisions
I collected requirements, proposed workflows, designed in Figma and validated through prototypes and later interactive HTML prototypes.
02 / The Product
One operational layer across the employee lifecycle.
The differentiator was not any single feature. It was the connection between workforce data, client operations, communication, payroll and compliance.
People & assignments
Profiles, placements, eligibility and client context.
Payroll operations
Batches, tips, overtime, paystubs and approvals.
Time off & documents
Policies, requests, eSign and compliance records.
Announcements
Operational updates targeted across the organization.
Global settings
WC codes, insurance catalogs, paycodes, tax and policies.
03 / Approach
I made evolving requirements inspectable.
I organized incoming requirements into flows, challenged requests to copy existing products and used prototypes to turn conversations into testable decisions.
Decision Framework
Create global state and behavior rules instead of fixing each screen independently.
I used a repeatable process: audit symptoms, map actors and units, assess risk and leverage, then encode the decision into states, guardrails, tokens, components and documented behavior.
Separate symptoms from systems
Distinguish local defects from patterns that repeat across the product.
Define actors and units
Clarify whether an action applies to a person, assignment, client, batch or document.
Prioritize by risk and leverage
Evaluate behavior fidelity, frequency, operational impact and reuse.
Encode the decision
Turn the answer into states, guardrails, tokens, components and documented behavior.
04 / Core System
Payroll was not a feature. It was a product inside the product.
I designed the payroll experience end to end. The hardest part was not the initial launch: it was creating a structure that could absorb requirements discovered through real use.
- Launch: establish batch model, employee rows and processing states.
- Learn: capture requirements revealed by live payroll operations.
- Extend: add pay concepts without rebuilding the IA.
- Protect: keep status, totals and ownership visible for HR Admins.
August 11-17, 2026
| Client / batch | Employees | Pay items | Status | Total |
|---|---|---|---|---|
| Northstar Retail Madrid / #248 | 126 | Hours / OT / Tips | Pending approval | $192,830 |
| Caldera Foods Valencia / #249 | 38 | Hours / OT | Ready to process | $62,170 |
| Atlas Services Barcelona / #250 | 20 | Salary / Tips | In progress | $31,420 |
05 / Enterprise Configuration
Global settings connect compliance data to daily operations.
WC Codes classify work across states, while WC Catalogs store insurance carrier and policy metadata. The challenge was making global data reusable without hiding where it applies.
Global Settings → EOR → Company & Sites → Position & Assignment
HR Admins configure reusable records and apply them through the EOR and company structure.
WC Catalogs
| Catalog | Carrier | Policy | Effective | Status |
|---|---|---|---|---|
| North East 2026 | Atlas Mutual | WC-8831 | Jan 1, 2026 | Active |
| West Coast | Harbor Insurance | WC-2194 | Mar 1, 2026 | Incomplete |
Add WC Catalog
06 / Deep Dive
One employee can represent several legal contexts.
The critical move was separating employee-level identity from assignment-level obligations. “By Group” operates at assignment level; “Everyone” remains employee-level.
- Classify the template as employee-aware or assignment-aware.
- Constrain the audience so assignment-aware templates cannot use Everyone.
- Resolve active matches and exclude people without a matching assignment.
- Count employees and generated requests separately.
Send for signature
Assignment-aware3 people excluded — no active matching assignment
07 / Deep Dive
Risk should be visible before it becomes an error.
Status, permissions and canonical roles were designed as one operational safety system, not isolated UI controls.
People flags
GuardrailSignal + enforcement
Jon Bell is not selectable in assignment controls.
Roles
CanonicalOne source of truth
Support includes HR Reps and Safety Coordinators, not proxies.
08 / Deep Dive
Automation can assist the decision. It cannot own it.
A reversible Direct Deposit approval flow protects payroll continuity while keeping the human reviewer accountable.
- The verified method remains active until approval.
- Current and requested data share one decision surface.
- A rejection reason reopens the edit/review loop and triggers notification.
- AI extraction and match confidence support, but never replace, the reviewer.
Reviewer workspace
Pending reviewBanco Santander
•••• 4832ProtectedBBVA
•••• 9017Account holder: Maya Chen09 / System Delivery
The UI system is becoming a shared delivery mechanism.
The product grew for years without consistent foundations. The recently globalized system is now being implemented to reduce UI drift, repeated decisions and avoidable errors.
Implementation contract
React + TypeScript
styled-components / Vite
color.surface.card var(--surface-card) border.subtle var(--border-subtle) shadow.card var(--shadow-card) space.400 16px radius.300 12px
Semantic tokens
Roles describe intent, so future changes do not rewrite every screen.
Behavior included
Empty, loading, error, disabled, read-only and permission states are specified.
Change is explicit
Contribution rules and QA checks reduce drift.
Part of done
Contrast, keyboard, focus and responsive behavior are documented.
10 / Outcomes
A broader product, with less operational fragmentation.
The platform continues to evolve after more than four years. Teams increasingly use one product for workflows that previously depended on separate systems.
Complexity made explicit
8 roles and 30 workflow maps established a shared operating model across assignments, payroll, documents, eSign and compliance.
Less operational fragmentation
More workflows are handled inside the same product, teams depend less on separate software and the design system is reducing inconsistency.
Reflection
I would establish shared product documentation before design begins.
The biggest lesson was that a long-running enterprise product needs a documented operating model as much as it needs polished interfaces.
Meralis is a fictional identity. Product details have been anonymized to respect confidentiality.