Time simplified

WorkRippling · Time Standalone

Time simplified

Making enterprise-grade Time simple enough to be a small team’s first Rippling product

Before and after: legacy Timecards and the Timesheet Editor design that replaced it
Before and after: legacy Timecards and the Timesheet Editor design that replaced it

Project snapshot

My contribution

Role

Lead designer for Time; design DRI for Time Settings V2 in 2026

With

1 of 2 Time designers; 2 PMs and 20+ engineers, plus a Timesheets team of five and a mobile team

Constraint

An assigned late-October 2025 launch target; the deeper systems work continued into 2026

Settings and packaging

I led Time Unification, then shaped the Settings rearchitecture: one configuration model, defaults and exceptions, progressive disclosure, and the capabilities exposed at each Time tier

Timesheets, web and mobile

I designed across Timesheets Home, the Timesheet Editor and Time Entry Details on web, and redesigned mobile Time Entry Details and Shift Details with a separate mobile team

Code and support

I authored 12 production frontend PRs for Time Entry Details, and supported onboarding, the Time overview, Policies and Job Dimensions

Project details

Company
Rippling
Product area
Scheduling · Time & Attendance · Time Off
Discipline
Product design · Systems design · Web + mobile
Timeline
Summer 2025 → 2026
Status
Time Standalone launched; Timesheets rolled out to every customer; mobile details shipped; Time Settings V2 in progress
Timesheets scale
300k+ daily users across the broader Time customer base
Strategy
Top of funnel expansion the intent: Time as a way into Rippling
Estimated added cross-sell ARR
≈$10M · broader WIW initiative, Oct 2026

00 Overview

What happens when a powerful workforce product, built inside a much larger platform, has to compete with one a small business can start using with a name and an email?

That was the question behind Time Standalone: make Time work as a customer’s first Rippling product, and simple enough for a When I WorkA scheduling and time-tracking app built for small businesses, known for how little setup it takes. Rippling acquired it, and with it a steady flow of free signups and an established customer base. Those customers would move onto Rippling’s Time, so When I Work set the bar for how simple Time had to feel. customer to understand. I worked across the configuration model, Timesheets on web, the matching mobile details and, for one drawer, the production frontend.

01 Why Time stood alone

A new front door into Rippling

Rippling usually met small businesses through Payroll and HRIS, and few replace payroll often. Scheduling and time tracking they switch more readily, and When I Work showed how little setup that could take.

Strategic intent

  1. A small business needs time softwareScheduling, time tracking, time off; switched more readily than payroll
  2. When I Work’s customers
    Starts with Time StandaloneQuick signup, no Payroll required
  3. Rippling earns trustProves value on a tool used every day
  4. May expand into the platformHRIS, Payroll and more
FIG. 01Time as a first Rippling productStrategic intent, not a measured conversion funnel

Rippling’s acquisition of When I Work brought that low-friction product, a steady flow of free signups and an established customer base whose expectations were shaped by its simplicity. As the standalone workstream began in August 2025, the product experience and the go-to-market processes were being built in parallel.

When I Work, first run
Signup to scheduler in a few steps: a workplace, positions, a shift template and a team
FIG. 02Signup to scheduler in a few steps: a workplace, positions, a shift template and a team

02 The simplicity gap

When I Work made the simple case simple. Rippling made the hard cases possible.

The same intent, running a team, sat on very different foundations

Customer intentRun a team
When I WorkSimple customer intent
  1. Sign up · name + email
  2. Add team members · name + email
  3. Set a few basic rules
  4. Build a schedule
  5. Invite the team
  6. Track time
RipplingComplex product substrate
  • Legal entities
  • Employees
  • Employment data
  • Work locations
  • Countries
  • Roles
  • Departments
  • Managers
  • Permissions
  • Approval chains
  • Pay rates
  • Piece rates
  • Job codes
  • Job dimensions
  • Schedules
  • Policies
  • Pay periods
  • Overtime rules
  • Break rules
  • Leave accrual rules
  • Compliance
  • Payroll relationships
  • Feature entitlements
  • Org data
FIG. 03Same customer intent, different product foundationsRippling’s depth is a strength; it was also the onboarding gap

Parity, not a clone

Migrating customers needed the workflows they already depended on, from building a schedule to approving hours, now running on Rippling’s architecture. The question became how to keep that power underneath while the default felt close to what they knew.

When I Work timesheet

When I Work’s timesheet: one employee’s pay period, day by day, scheduled against worked

Showing image 01 / 05

FIG. 04When I Work’s timesheet and settings: each area on one page, a time off policy in one short dialog

03 The hidden platform

Time inherited the rest of Rippling

Inside Rippling, Time had never needed to stand on its own. Scheduling, Time & Attendance and Time Off relied on company data, rules, permissions and pay that another product had usually set up first.

Rippling platform

  • Company context
    • People
    • Entities
    • Locations & countries
    • Jobs
    • Org structure
  • Workforce rules
    • Policies
    • Overtime
    • Breaks
    • Leave
    • Custom pay
  • Control
    • Permissions
    • Approvals
  • Review & pay
    • Pay periods
    • Payroll-adjacent workflows
  • Product
    • Entitlements
    • Mobile
    • Packaging
Time
  • Scheduling
  • Time & Attendance
  • Time Off
A Time-first customerArrives before most of this is configured
FIG. 05What Time depended on, groupedTwo problems: work as a first product, and feel simple doing it

04 The constraint

Ninety days was the target. The system took longer.

The team was assigned a late-October 2025 launch date and raised feasibility concerns about the scope. We had to define a coherent first version under it.

  1. Standalone work begins
  2. Target
    Assigned launch deadlineWe raised feasibility concerns
  3. The system took longer
    End-to-end testing still finding system boundaries
  4. First When I Work migrations reported
  5. Rollout and parity; Timesheets live for everyone
  6. Continued work
    • Time Settings V2
    • Timesheets evolution
    • Mobile details
    • Implementation quality
    • AI explanations
FIG. 06Summer 2025 to 2026The deadline defined a first version, not the end of the work

05 Design thesis

Simple by default. Capable underneath.

The principle that connected the strategy to the screens

  1. DefaultThe ordinary customer succeedsOne set of rules that applies to everyone
  2. Only when needed
    ExceptionA specific need differsOne group, schedule or location set differently
  3. Only when needed
    AdvancedDeeper control is thereRanked policies, compliance rules, custom pay
FIG. 07Default, exception, advancedThree layers, one model

06 Time Settings

Stop making customers learn our policy model

Time Unification, which I led and designed from late 2024 to Q1 2025, brought Scheduling, Time & Attendance and Time Off under one roof. Underneath, configuration still worked three different ways.

  1. 06.A Fragmented model

    Admins learned the software, not their rules

    After unification, the Policies section alone had eight tabs built on three different conceptual models

    Policies, after unification · 8 tabs

    • Feature-specific policy rules

      • Scheduling
      • Attendance
      • Time tracking
      • Time Off

      Each feature had its own policy engine

      Every tab configured differently; no shared mental model

    • Cross-feature rules

      • Compliance
      • Custom pay

      Overtime, breaks, custom pay and state or local law

      Straddled Scheduling and T&A: which feature owned overtime?

    • Not really policies

      • General
      • Approval

      Work hours, weekends, holidays; approvals split between Timecards and Time Off

      General was settings; Approval was workflow

    Result

    Admins learned the UI, not the system

    FIG. 08Eight tabs, three modelsCompliance straddled two features; General and Approval weren’t policies at all

    A long-time Rippling admin could eventually learn where everything lived. A new standalone customer, especially one coming from When I Work, had almost no chance of finding it on their own.

    Time Settings and Policies, toured
    Configuration in two places: Time Settings’ three tabs, each with its own sub-navigation, then eight Policies tabs
    FIG. 09Configuration in two places: Time Settings’ three tabs, each with its own sub-navigation, then eight Policies tabs

  2. 06.B Two models

    Two mental models in one nav item

    Time & Attendance and Time Off both lived in Policies but configured nothing alike, and neither offered a simple “just turn on overtime” path

    Time & Attendance time tracking policies

    A heavy wizard just to set a default

    1. Default time policyApplies to everyone unless overridden
    2. Three-step setup wizard
      1. Details
      2. Permissions
      3. Approvers
    3. Custom policies per groupAssigned with Object Graph filters, e.g. Department = Product Design

    Time Off leave policies

    Four layers and ranking just to give someone PTO

    1. Country layerPolicies scoped by jurisdiction
    2. Rippling default policiesCompliance minimums to copy and customize
    3. Custom policies, rankedPriority order decides
    4. Employee-to-policy matchingOnly the top-ranked policy applies

    Same nav itemNo shared patterns, no consistent language

    FIG. 10Time & Attendance and Time Off configuration, beforeThe challenge: coherence across both, without collapsing their real differences

    BeforeTime Settings and Policies, before

    Time Settings, Scheduling tab

    Time Settings, Scheduling: schedules and their attributes, with labor cost, job codes, shift tags and open shifts in the side menu

    Showing image 01 / 11

    FIG. 11The two models in the product, before: Time Settings in three tabs, Policies in eight

  3. 06.C Settings simplification

    One place to ask how Time should work

    I pushed toward a single Time Settings, and we built it: the Policies tab went away, and a settings page with toggles and inputs replaced the setup wizard

    Before

    “Which policy object do I need?”

    • Time Settings3 feature tabs
      • Scheduling
      • Time & Attendance
      • Time Off
    • Policies8 tabs, 3 different models
      • Feature-specific policy rules
      • Cross-feature rules
      • Not really policies

    After

    “How should Time work for my team?”

    Time Settings

    Policies tab removed; one structure

    • Scheduling
    • Time & Attendance
    • Time Off
    • Permissions
    FIG. 12Settings and Policies, merged into one Time Settings

    Before

    Before: the time policy wizard
    Before: a time policy’s setup wizard, page by page

    After

    After: time tracking in Time Settings
    After: from the Time Settings index into time tracking, one page, with options appearing as settings switch on
    FIG. 13One setting, before and after: time tracking configured through a policy’s setup wizard, then on one Time Settings page
    Days, progressive disclosure
    FIG. 14Progressive disclosure: each workday cutover method reveals only the field it needs

  4. 06.D Defaults first

    One default, with exceptions on top

    A default applies to everyone; an exception changes only what differs for a group. The structure is the same at every tier: Lite admins learn the model, and Core adds exceptions on top.

    PriorityHigher wins

    Time & Attendance

    1. ExceptionCoreDepartment = Customer ServiceHighest priority
    2. ExceptionCoreDepartment = Operations
    3. DefaultLiteApplies to everyone elseClock-in methods, pay period, rounding

    Time Off

    1. ExceptionCoreCustom accrual, rankedCopied from a default; highest rank wins
    2. ExceptionCoreCountry compliance policiesRippling-provided minimums, by country
    3. DefaultLiteLeave types and simple accruale.g. 1 hr per 30 hrs worked

    Same structure at every tierLite admins learn the model; Core adds exceptions on top

    FIG. 15Defaults and exceptions, in Time & Attendance and Time OffThe behavior still differs between products; the mental model doesn’t

    The key decision was not to build two products: one information architecture that starts simple and reveals depth, so nothing a Lite admin learns stops being true in Core

    AfterDefaults and exceptions

    Time tracking settings, Core, empty

    Core, before any setup: an empty table of group-specific overrides above default settings still switched off

    Showing image 01 / 02

    FIG. 16Defaults and exceptions in the interface: Time & Attendance’s time tracking settings, empty and then configured

  5. 06.E The limit

    When the simple model stopped being simple

    Established customers already carried legitimate complexity, and for many there was no obvious default. In 2026 I became design DRI for Time Settings V2, now in progress, to serve both.

    New customer

    • DefaultMost of the team
    • Exceptionone group

    An obvious default

    Established customer

    • ScheduleWarehouse
    • ScheduleStores
    • ScheduleOffice
    • GroupHourly
    • GroupSalaried
    • LocationCA
    • LocationNY
    • ApprovalsBy manager
    • Default?

    No single obvious default

    FIG. 17Where a single default runs outNot a failure of defaults: the edge of the first model

07 Growing with the customer

Nobody should meet all of Rippling on day one

I helped define what belonged in Time Lite, what belonged at deeper tiers, and how upgrades could expose more capability without changing the model a customer had already learned

  1. Time LiteSimple entry
    • Basic scheduling
    • Simple time tracking
    • Straightforward time off
    • Defaults
    • Simple approvals
    • Invite employees
    • No Payroll required
  2. As needs grow
    More Time capabilityWhen needs grow
    • Exceptions
    • Compliance
    • Overtime rules
    • Advanced leave
    • Job structures
    • Permissions
  3. Broader RipplingOther platform products
    • HRIS
    • Payroll
    • More

Same model throughout

FIG. 18Progressive complexity, not a price list

08 Timesheets

Reviewing time had outgrown Timecards

Timesheets, formerly Timecards, ran on interaction patterns more than six years old. The problem wasn’t polish: managers needed to review quickly, understand what happened, edit only when necessary and approve with confidence.

  1. 08.A Starting point

    Built for a younger Rippling

    Review, editing, saving, approval, navigation and dense pay-period data all carried patterns from Timecards’ early years

    BeforeTimecards, before Timesheets

    Timecards list

    Timecards: every employee’s pay period, approval status and hours in one table

    Showing image 01 / 04

    FIG. 19Timecards before the redesign: the list, a timecard, an entry modal, and a dialog stacked on it
    1. ScanWhose time needs a look?
    2. UnderstandWhat’s off, and why?
    3. InvestigateOpen the day or the entry
    4. Edit if neededOnly when something’s wrong
    5. ApproveWith confidence
    FIG. 20What a manager actually has to doEdit only when necessary; approve with confidence

  2. 08.B Three levels

    One workflow, three levels of detail

    Worked hours alone aren’t enough to approve: a manager may need scheduled against actual time, leave, holidays, adjustments, exceptions, approval status and the entries behind a total

    1. OverviewTimesheets Home

      “What needs my attention?”

      Holds
      • Every employee’s pay period
      • Hours and approval status
      • Exceptions, counted
      One late clock-in
      One employee, Sep 1–152 exceptions · Pending
      • Scan
    2. Investigation + editingTimesheet Editor

      “What happened during this pay period?”

      Holds
      • Each day, scheduled against worked
      • Leave, holidays, adjustments
      • Exceptions, on the day
      Tue, Sep 2Scheduled 8:00 · in at 8:17 · late
      • Understand
      • Edit inline
      • Approve
    3. Record + actionsTime Entry Details

      “What happened in this record?”

      Holds
      • Jobs, breaks, shift inputs
      • Overtime and premiums
      • Change requests, comments
      8:17 AM – 4:30 PMLate clock-in alert
      • Investigate
      • Edit the record
    Corrections, totals and statuses roll back up
    More detail, only when needed
    FIG. 21Overview, investigation, recordThree layers of one web system, not three features

    AfterTimesheets, from overview to record

    Timesheets Home

    Timesheets Home: what needs attention, by employee and pay period

    Showing image 01 / 03

    FIG. 22Timesheets, from overview to record
    Timesheet Editor prototype
    Editor prototype: a break and a job edited from their chips, the same entry in Time Entry Details, then a new day’s times and job entered inline
    FIG. 23Editor prototype: a break and a job edited from their chips, the same entry in Time Entry Details, then a new day’s times and job entered inline

  3. 08.C Still evolving

    Live for everyone, and still evolving

    On September 22, 2026, Timesheets went live for every customer and legacy Timecards was retired

    300k+Daily usersAcross the broader Time customer base, not only standalone customers: every customer moved from Timecards by September 22, 2026, with 3.3M+ monthly page views shifting over

    Moving every customer off a product they used several times a day took the team 544 PRs across frontend and backend, and the rollout drew 114 support tickets, 95% of them closed. The work continues: real usage keeps exposing better ways to filter, act, edit and read dense data.

    One example is quick-editing a time entry’s attributes in the editor. Engineering’s first version used the design system’s standard grid pattern, and customers complained: narrow the Details column and the chips for jobs, breaks and shift inputs disappeared, with nothing to say they were there. I redesigned the interaction so a hover reveals the actions to add a job, a break or a shift input, and a narrowed column folds its chips into a +N count instead of hiding them.

    Before

    Before: the first implementation, a standard grid pattern. Narrow the Details column and its chips vanish with no sign they exist

    After

    After: the redesigned attribute editing
    After: a hover reveals actions to add jobs, breaks and shift inputs, and a narrow column folds its chips into +N
    FIG. 24One interaction, before and after: editing a time entry’s attributes in the Details column

  4. 08.D Web and mobile

    One domain, two surfaces, two teams

    Alongside the web Timesheets work, not after it, I redesigned mobile Time Entry Details and Shift Details with a separate mobile PM and engineering team. Both have shipped.

    Same period, in parallel
    Web workstreamPM · engineering
    • Timesheets Home
    • Timesheet Editor
    • Time Entry Details
    Shipped
    Decisions, specs
    Questions, edge cases found
    Design, across both teamsShared product context
    • Interaction model
    • Product behavior
    • Time Settings rules
    • Edge cases
    • Shared terminology
    • Cross-platform consistency
    Decisions, specs
    Questions, edge cases found
    Mobile workstreamPM · 2 engineers
    • Shift Details
    • Time Entry Details
    Shipped

    One domain modeltime entries, shifts, approvals

    FIG. 25Web and mobile work, running in parallel

    Mobile was central to the standalone experience. In a January 14, 2026 update, mobile accounted for 87% of early Project Lake sessions. The initial standalone delivery still fell short for employees and managers tracking and approving time on the job. I redesigned Shift Details and Time Entry Details to address those gaps, carrying the shared rules and terminology into mobile-specific interactions.

    This wasn’t making the desktop responsive. The mobile app had its own legacy patterns, so I adapted concepts rather than layouts: what each mobile view needed, and what a time entry meant on both surfaces.

    BeforeMobile, before the redesign

    Legacy mobile T&A home
    Before: the T&A home, a clocked-in card with Switch jobs, Take a break and Clock out
    Legacy mobile time entry
    Before: one time entry as a sheet of tabs and label-value rows for status, jobs, breaks and shift inputs
    FIG. 26The mobile app before the redesign: the T&A home and the time entry it opened

    AfterMobile Shift Details and Time Entry Details

    Shift Details, open shift requested
    Shift Details: an open shift someone has asked to take
    Shift Details, overnight and repeating
    Shift Details: an overnight, weekly shift with a drop request
    Time Entry Details, in progress
    Time Entry Details: in progress, with a late clock-in
    Time Entry Details, pending approval
    Time Entry Details: pending approval, with a change request
    FIG. 27Mobile Shift Details and Time Entry Details, redesigned: requests, overnight and repeating shifts, alerts, premiums and change requests
    Mobile, in production
    In production on a phone: a clocked-in shift's details, then the team's timesheets, and one time entry split across two jobs, saved and approved
    FIG. 28In production on a phone: a clocked-in shift's details, then the team's timesheets, and one time entry split across two jobs, saved and approved
    RoleNot submittedNon-approvedPending approvalApprovedNot paid or lockedRejectedPaidFinalized, locked
    EmployeeSelf-reports timesheetsEdit
    • Edit or delete the entry
    • Add breaks, jobs, comments, attachments, shift inputs
    • Submit timesheet, if required
    		Edit
    • Edit or delete the entry
    • Add breaks, jobs, comments, attachments, shift inputs
    • Submit timesheet, if required
    		Request
    • Can’t edit directly
    • Resubmit for approval, which starts it again
    • Request a change, if enabled
    		Request
    • Can’t edit; can review
    • Request a change or add an entry to correct it
    • Still counts in totals until an admin removes it*
    		View
    • View only
    • Contact a manager or admin for changes
    EmployeeDoesn’t self-reportRequest
    • Usually can’t edit
    • Request a change, if enabled
    • Submit timesheet, if allowed
    		View
    • Can’t edit; view only
    • Wait for approval
    		Request
    • Resubmit for approval while not paid or finalized
    • Request a change
    		Request
    • Request a change or add an entry to correct it
    • Still counts in totals until an admin removes it*
    		View
    • View only
    • Contact a manager or admin for changes
    ManagerDirect reportsEdit
    • Edit entries
    • Add breaks, jobs, comments, attachments, tips
    		Edit
    • Edit, until approved
    • Submit on the employee’s behalf
    		Edit
    • Edit if not paid or locked, with edit rights
    		Edit
    • Edit if not paid or locked, then resubmit
    		View
    • View only
    ApproverFrom the approval policyView
    • View
    		Decide
    • Approve or reject
    		View
    • View
    		View
    • View
    		View
    • View

    * A rejected entry still counts in totals until an admin removes it

    FIG. 29What each role can do to a time entry at each status

  5. 08.E Into production

    I followed the drawer into production

    Under timeline and frontend-capacity constraints, the first build of the web Time Entry Details drawer diverged materially from its design

    Time Entry Details, as designed

    As designed

    Showing image 01 / 03

    FIG. 30The drawer as designed, then an early build in June, and the same layout in production in August
    Time Entry Details in production
    In production after my frontend work: jobs, breaks, times and shift inputs edited inside the drawer
    FIG. 31In production after my frontend work: jobs, breaks, times and shift inputs edited inside the drawer

    12PRs authoredIn the production frontend, with Cursor, on web Time Entry Details and its supporting states, of the 544 the Timesheets rollout took

    Working in the codebase surfaced states, dependencies and interaction cases the design hadn’t anticipated, so the design kept moving during implementation. This is one layer of Timesheets, not all of it.

    OpenTime entry details UI cleanup

    Adrian Cortinas wants to merge 8 commits59 files changed+2,226−839

    From the PR description
    Changes in this PR: align the Time Entry Details drawer with the Figma design; merge Scheduled Shift into Adherence, show the parent schedule name and restyle jobs, breaks, shift inputs, comments, attachments and the edit and add cards; tighten section spacing, duration copy and related unit tests.
    1. Opened as one PR
    2. Split into smaller PRs for review
    3. Shipped in production
    FIG. 32Initial production PR for the Time Entry Details frontend, later split into smaller reviewable PRs

  6. 08.F Review to explanation

    The next problem wasn’t what happened. It was why.

    AI that explains the system’s results inside Timesheets, beginning to roll out

    “How was my overtime calculated?” “Why did this missed break trigger premium pay?” Questions like these are hard for managers to answer and add to the support burden. The explanations bring patterns from the Time AI Copilot work into a production workflow.

    The Time AI Copilot case study

    Explain with AI
    Explain with AI, in development: the policy rules and a daily breakdown behind an overtime total
    FIG. 33Explain with AI, in development: the policy rules and a daily breakdown behind an overtime total

09 Outcomes

Time became a new way into Rippling

Program-level results, shared across the team

  • A broader cross-sell opportunity taking shape

    By October 2026, the broader When I Work cross-sell initiative was estimated to have added approximately $10M in ARR. My contribution focused on the configuration and time-review experiences that made Time work as a first Rippling product.

  • Time Standalone went live

    Customers can start with Time, without first buying Payroll

  • When I Work customers began migrating

    The first When I Work migrations were reported in December 2025. By the October 7, 2026 report, 2,955 companies had reached cutover. Migration progress and sustained product usage remained separate challenges.

  • A foundation for configuration

    The defaults + exceptions model became the base for Time Settings V2

  • Timesheets, live for everyone

    Every customer moved to Timesheets on September 22, 2026 and Timecards was retired; across the broader Time customer base, it serves 300k+ daily users

  • Mobile details shipped

    I redesigned mobile Shift Details and Time Entry Details with a separate mobile PM and engineering team, addressing gaps in the standalone experience for employees and managers working on the job. Both have shipped.

  • From exploration to product

    Explanation patterns from Time AI Copilot are beginning to roll out inside Timesheets

2,955WIW companies cut overOf 3,258 companies in the October 7, 2026 migration report.

2,581Companies with login activityWithin the same 3,258-company reporting cohort, October 7, 2026.

What I learned

  1. Simplification wasn’t removing controls; it was deciding what a customer needed to understand now, what the system could safely handle underneath, and how the model should behave when the easy case stopped being easy
  2. The work kept crossing boundaries: platform architecture, Settings, Timesheets, web, mobile, and eventually production code
We’ve just crossed the $1.5M ARR mark in WIW cross sell, with a lot more to come in Feb. The pilot can help us accelerate that, and get to our $20M target this year - a big thank you to the Product & Design team for their incredible effort
— Will Sorg, GM, Feb 2026