Deel

Leading the redesign of the mobile app for workers

The real problem

The brief could have read "redesign the mobile app." The actual problem was narrower and harder: Deel's mobile app was a shrunk-down version of the web platform, built first for HR admins managing global teams, then ported down to a phone screen. It carried the same information density, the same navigation depth, and the same feature list as the web product. For a worker who opened the app to check a payslip or request a day off, that meant wading through structure that had nothing to do with what they came to do.

The app wasn't broken in an obvious way. It worked. It was just slow, in the way that confusing things are slow: too much to parse, too many paths to the same action, no sense of what mattered most in the moment someone opened it.

Context

Deel runs payroll, contracts, and HR for a global, distributed workforce, across more than 100 countries and multiple worker types. I joined Deel in January 2026 to lead design on the mobile app, and this redesign became the main project I worked on for my first six months.

My scope was twofold. I was the sole dedicated designer on the mobile app itself, driving the vision, the interaction model, and the core worker flows (pay, time off, payslips, approvals). At the same time, because "mobile" at Deel cuts across every product area (HR, payroll, contracts, time tracking), I was also responsible for aligning more than 20+ designers and their PMs across the org around a single mobile-first direction, so that each team rebuilt their area as a native mobile experience rather than porting their web feature over as-is.

I worked closely with the head of product, engineering leads, and PMs on scope and sequencing. The bigger, and honestly harder, part of the job was cultural: getting 20+ teams to stop asking "how do we fit this feature on a smaller screen" and start asking "does this feature belong on mobile at all, and if so, what does it look like when it's built for it."

The problem space

The starting assumption, inherited from how the web product had always worked, was feature parity: whatever existed on web should eventually exist on mobile, just resized. That assumption is what had produced the bloated app in the first place, and it was the first thing I had to argue against.

Usage data gave me the argument. Web sessions were long and multi-tasking, the kind of behavior you'd expect from an admin managing payroll for a team. Mobile sessions were short and task-driven: someone opened the app, did one thing (checked if they got paid, submitted an expense, requested time off), and left. Workers weren't using mobile as a smaller version of web. They were using it completely differently, for a much narrower set of jobs, and the app needed to be designed around that reality instead of the web's feature set.

That reframing changed the goal for the whole project: stop chasing parity, and instead reduce the time workers spend on the platform, get what they need done, and let them get on with their day. Web and mobile became two different products with two different jobs, not one product in two sizes.

It also meant I was doing two things in parallel that don't usually happen at the same time: building a mobile design system from scratch, while using that same system to ship the new app, while also being the only designer dedicated to mobile full-time. Six months to rebuild something this foundational, inside a company moving this fast, with a design system that didn't exist yet and 20+ teams to bring along, was the actual shape of the problem.

Deel

This case study is password protected