Nobody opens an app because they’re told to

Harri’s workforce app for shift workers has around 350,000 monthly active users, and until recently almost every one of them only ever opened it because they had to. They used it to check their rota, swap shifts and read announcements. It was an app of pure utility. It got opened at the moment of need and closed again, which produced usage without engagement and gave employers very little opportunity to develop their teams with it.

Enter rewards and recognition. It’s a product category in its own right, usually sold as a standalone platform and used in parallel to whatever workforce app a business already runs. At Harri it’s a module called Rewards, sitting inside Engage360, the engagement pillar of the platform, which meant we could do something the standalone products can’t. The rewards would live in the same app as the rota, the clock-in and the shift pool. That made it a commercial opportunity and a design problem at the same time, because an incentive only pulls someone into the rota or the clock-in if those screens feel like part of the same product. What started as a new module led to a wider redesign of the app.

We looked at other enterprise employee rewards apps to better understand the category. But that told us very little about how to design a motivating workforce experience, because none of them had to live alongside a shift pattern, a clock-in and a shift pool.

That showed us where the gap was, but it didn’t tell us what good looked like. What mattered more was that Harri’s app sits on the same device as Instagram, TikTok and YouTube, and gets judged against those.

So we benchmarked against the things people open voluntarily. We weren’t competing with other workforce apps. We were competing with everything else on a crew member’s phone, and with our existing utility UI, we’d have lost that comparison on every screen we had.

Two things in a workforce app could plausibly be opened without anyone being told to: rewards and learning. Rewards came first, and it was the obvious mechanism for boosting adoption of the utility features as well.

Rewards is configured by the operator, not by Harri. A client sets targets and campaigns against behaviours they care about, and employees earn points, badges and raffle tickets for hitting them. What matters is which behaviours they choose. Clocking in on time. Picking up an open shift. Responding to an ESAT survey.

Those are exactly the behaviours that utility apps struggle to get people doing, and they’re the ones the business most needs. So we crafted the game design such that the motivating layer carries the utility layer: the operator gets an operational instrument whilst the employee gets a reason to open the app and complete important actions.

Clients reward their people in very different ways, especially between quick service and full service, so Rewards has two currencies. Points are earned against ongoing targets and spent in a marketplace on whatever the employee chooses. Raffle tickets are earned in time-limited campaigns, like hitting a limited-time offer target three weeks running, and entered into a prize draw. Clients can use either or both, and decide which targets pay out in which.

Two currencies was a product requirement. How to present them was a design decision. Product’s first suggestion was to keep points as the headline balance and show tickets only inside the raffle views. We gave them equal weight at the top of Rewards instead, because a currency you can’t see is one you won’t work towards.

We also chose not to solve for fairness between someone working forty hours a week and someone working twelve. Any per-hour adjustment would have made points harder to understand, when the earning model was already the fragile part. Instead we reduced how much individual comparison mattered. For tenure, the leaderboard can be viewed by points earned this week as well as all time, so a new starter isn’t permanently behind someone with two years’ service. For hours, campaigns can be set as team goals, where everyone contributes to one target however much they work, or as one location against another. That moves the competition from individuals towards teams.

We dug into data from the two beta clients who ran it in early 2026: one quick service restaurant group in the US, and one in the UK. Late clock-ins fell from 4.54% to 4.21% at the US operator over 69 days, and from 9.8% to 7.5% at the UK one over 51 days. Neither had a control group and both compare a short campaign window against a longer baseline, so seasonality isn’t ruled out. But what makes this data worth something is that two unrelated businesses in two countries moved the same measure in the same direction.

App usage moved too. At the US operator, participating locations ran at about two thirds of the rest of the estate’s sessions per user in spring and finished the summer above it, while the rest stayed flat. At the UK operator the effect showed up as more people opening the app rather than each person opening it more. The app usage picture is less settled than the clock-ins, but it points the same way at both.

We surveyed employees at both betas, and 54 of them told us what they made of it. They rated Rewards 3.6 and 3.9 out of 5. They engaged with it and thought it was fine, but two comments mattered more than the rest. One crew member said they didn’t understand what tickets were or how to earn more, while knowing they got them for clocking in on time. Another said their shift covers didn’t count, because their manager rings them instead of using the app. The first was a legibility failure: we’d made tickets visible, but not understood. We addressed it by introducing a ‘Ways to earn’ screen. The second was the loop breaking due to unusual operational practices, and a reminder that the model only reaches behaviours that pass through the app.

Learning is the second motivating module and it’s in development now. It replaces Harri’s legacy LMS product, and it gives Rewards something new to aim at, because finishing a course becomes a behaviour a client can set a target against.

It’s built around short client-filmed videos, which we call Quick skills rather than microlearning. Product wanted an optional question after each video to reinforce it. I argued against putting that inside a scrollable feed, because an interruption in a reel either annoys people or stalls them, and I proposed a library instead, where you choose a video, watch it, answer, and come back.

My team disagreed and worked on the alternative. They pointed at how Instagram occasionally drops a survey question between reels, mocked the same pattern, and made the question mandatory before the next video rather than optional, so the interruption I’d objected to became the thing that guaranteed the question got answered. I was wrong, and my team’s prototype convinced me. We took it to Product and negotiated: one question per video, text only, no images.

Product also wanted a Duolingo-style pathway as a main view. We pushed back, because there’s no single linear progression through the course catalogue to illustrate, and a pathway that doesn’t lead anywhere is just decoration. We proposed a dashboard showing certificates and ribbons, courses in progress and the latest Quick skills, and built the pathway UI to work inside each individual pathway, where progression is real. We left out streaks deliberately, because a shift worker doesn’t control their rota, and a streak punishes them for one their manager wrote.

Three working design principles came out of this effort.

Balance engagement against efficiency, because Harri is a work app and we’re optimising for the client’s outcome rather than time on device.

Translate the domain terminology, so engagement feels like progress instead of compliance.

Leave room for the client’s own content, because their videos and images carry more personality than anything we’d draw.

These principles aren’t enshrined in the design system yet, and that’s deliberate. Codifying a standard before it’s been tested across enough of the product is how design systems end up enforcing early guesses. We revisit them in a weekly review with the product leads and lead designers instead, and we’ll formalise them once the pattern has earned it.

By this point, the moment someone crossed from Rewards into Schedule they left the product that earned their attention and landed in the one that didn’t. So we determined that the new theme treatment used in Rewards and Learning shouldn’t be reserved just for the modules that have something to celebrate. My principal designer led the work, with one other designer, the product manager and the engineers. I set the standard and made the case for spending the time, and reviewed it with them weekly.

The old screens led with utility. A white header, a functional title, some actions, and then the details. No summary and not much hierarchy, which left the work of digesting it all to the person holding the phone. We’d already tried to fix part of this. A basic Home screen shipped last October, and while it stopped dropping people straight into Schedule, it still behaved like a detail screen and made you go looking for the two or three things you actually came for.

What we generalised wasn’t the playfulness. It was the structure. Rewards had already established that a screen works better when it opens with an overview of where you stand, so every main module view now uses a taller coloured header with a floating summary card sitting across it. Home summarises the week’s hours, shifts remaining and open shifts. Schedule summarises total hours, total shifts and projected pay. Requests summarises what’s pending, approved and rejected. Drill-downs get a streamlined header with the same colour treatment, so the theme holds without a summary being forced onto content that doesn’t have one.

That distinction is the whole framework. One header for views that should orient you, another for views that should get out of the way, and a shared visual treatment across both.

The restraint mattered as much as the reach. Illustrated icons and encouraging copy stayed within the motivating modules, because a shift trade request isn’t an achievement and treating it like one would be worse than leaving it plain. What did carry across was a small set of accent colours, enough to make the app feel like one product without pretending every screen is a celebration. More, the overflow of everything that doesn’t earn a place in the bottom navigation, was the hardest test of that. There’s nothing to celebrate on it, but it still gets the header, the profile summary and the accent colours, and it still reads as the same app.

Rewards is live with a growing number of operators. Learning and the new app theme are both in development, with the theme due for release in Q4 2026.

Operators have always treated app adoption as a rollout problem, solved with mandates and manager nagging. The beta suggested it’s a design problem instead. Build something people open by choice, point it at the behaviours the business needs, and adoption is earned rather than enforced. Rewards showed that once. The theme is how we make it true everywhere else in the app.