Workflow Automation for Global HR Ops
overview
The project ran 6 months from kickoff to beta launch, with a public beta in month 3.
01
May
Discovery & Validation
02
June
Design & Engineering
03
July
Beta Launch
04
September
Multi-Step Launch
Team
CEO (main stakeholder), PM, 3 backend engineers, cross-functional partners from Onboarding, Time & Attendance, and Payroll (for API endpoints), Marketing (for launch).
My scope
End-to-end design, from early discovery to shipped product. I made final design decisions autonomously, with daily alignment with PM and engineering.
Challenge
The products customers were using felt built for engineers, not HR teams. During customer interviews, one phrase kept coming up, a company managing 100+ global employees told us directly:
"Rippling's workflow builder feels like it was built by engineers for engineers. We'd prefer less customization in favor of ease of use."
The core tension: HR teams think in natural language ("remind me 5 days before someone starts"), but systems need database logic and API calls. My job was to bridge that gap without dumbing down the power.
Discovery & Validation
With limited time for discovery, we ran parallel validation tracks:
With existing research
Searched Dovetail for interview findings from other product teams, analyzed use cases from the Integrations team, reviewed user transcripts where customers explicitly requested easier automation, and synthesized feedback from CS conversations about workflow pain points.
With Customers
Presented early concepts to 15 companies in Remote's Customer Advisory Board: triggers, conditions, actions, Slack and email integrations. Their feedback directly shaped which triggers we prioritized: employee start dates, time-off requests, contract changes.
With APIs
I spent time in Postman learning Remote's endpoints, Slack's API, and how different platforms handle webhooks. This wasn't just curiosity: I needed to understand what feedback states users might see (loading, errors, missing permissions) so I could design for real system behavior, not ideal scenarios.
With AI (post-MVP validation)
Built a simple agent using a custom GPT to test whether our architecture could handle complex requests. I wrote a detailed prompt with constraints matching our data model, then threw increasingly weird scenarios at it. After a few adaptations, 100% of the time, it returned a valid workflow structure. This validated our long-term vision of AI-assisted workflow creation, a post-MVP feature, and confirmed the architecture would support it when we were ready.
Exploration
The main automation need could break into needs. This became our mental model:
Show everything upfront
The first explorations surfaced all options simultaneously: every condition field, every operator, every action type visible at once. The intent was transparency, users could see what was possible.
What broke: In testing, users with simple needs ("post to Slack when someone requests time off") got lost in complexity they didn't need. The interface was accurate, but it communicated you need to understand all of this before you can use any of it.
Progressive disclosure
We shifted to revealing the interface step by step. You start with just "Set up trigger." Options appear as you make choices. A simple workflow stays simple. A complex one reveals more controls as you go.
What this solved: Users could build a basic automation in under 2 minutes without ever seeing a condition builder. Power users could still reach full complexity, same power, different packaging.
Language translation
One specific decision made with the copywriting team that changed everything: replacing database field names with natural language. Instead of start_date timestamp with -5 day offset, users see "5 days before employee start date."
What users say
What the system does
"When someone starts..."
Trigger
the event
"...5 days before..."
Schedule
the timing
"...if they're in Colombia..."
Condition
the filter
"...notify their manager"
Action
what happens
What we cut for v1
The original scope included multi-step workflows and AI-assisted creation from day one. We deferred both post-launch. It meant customers like Very Good Ventures couldn't migrate their 39 Rippling workflows immediately. But it let us ship 6 weeks faster and validate real demand before building complexity. By September 2024, two months after launch, multi-step was live. The foundation we built made expansion straightforward.
Edge Cases
Dynamic condition operators
When I discovered that certain conditions (employment country, hire type, department) had different valid operators depending on the field type, I worked with engineering to make the condition builder context-aware. It dynamically shows only valid operators for the selected field. No dead ends, no error messages for things that shouldn't be possible.
API error states
Through Postman testing, I designed for real failure states, what happens when a Slack token expires mid-workflow, when a Remote endpoint returns a partial response, when a condition references an employee record that's since been archived. These weren't hypotheticals; they were things I found in testing before launch.
{
"error": "INCOMPATIBLE_EVENT_CHANGE",
"message": "selected_event_schema_mismatch",
"previous_fields": ["employee.start_date"],
"new_fields": ["expense.amount", "expense.category"]
}
UI Components
The workflow builder required UI patterns Remote's design system didn't have yet. I designed and contributed three core components to Norma, now used by other product teams.
I didn't design the component system from scratch. I built on top of Norma, Remote's design system, which is WCAG AA compliant. That was a deliberate decision: inheriting accessibility rather than reinventing it. Where I made explicit accessibility decisions: Status indicators (Active, Paused, Archived) use both color and label (never color alone), Keyboard navigation works through the entire builder flow with no mouse-only interactions, and Error states include descriptive text, not just red borders.
Dashboard Cards
Cards needed to show workflow status at a glance while remaining actionable without opening the full editor. I designed cards with four states: Active, Paused, Archived, and New Workflow (empty state). Each state is visually distinct but uses the same underlying anatomy.
Condition Builder Fields
Dynamic form inputs that change available options based on upstream selections. Contributed as a pattern, not just a one-off component.
Impact
Beta launched July 2024 to all Remote customers across HRIS, EOR, Contractors, and Global Payroll. Within 3 months: 10+ triggers, 15+ action types shipped. Customers previously locked into competitor tools expressed migration interest.
Three components contributed to Norma and adopted by other teams. One structured ideation session I facilitated produced a shared roadmap for future AI-assisted workflow creation, now a reference point for the team's next phase of work.