Designing for the person who doesn't want to use your app.

Design · 5 min read

Most app design advice assumes the user chose to be there. They downloaded the app. They signed up. They're motivated. They want to use it. But that's not always how it works. Some users are told to use your app. By their boss. By a site manager. By a company policy. They didn't choose it. They don't care about it. They just want to finish the task and get back to their actual job.

I worked on an app where the primary user was a contractor on a worksite. Welders, maintenance crews, people doing physical work in industrial environments. These are not people who want to spend time on a phone app. They want to do their job, get signed off, and go home. Every extra screen, every unnecessary tap, every bit of friction is a problem. Not because the design is bad. Because the user doesn't want to be there in the first place.

The reluctant user is your real user

In B2B apps, especially in industries like construction, manufacturing, and safety compliance, the person who buys the app and the person who uses the app are almost never the same. The site manager wants reporting, audit trails, and visibility. The worker wants to take a photo, tick a box, and move on. If you design for the buyer, you'll have great dashboards and terrible adoption. If you design for the user, you'll have an app people actually use.

That tension is real and you have to solve it deliberately. The manager side of the app we built had filters, dashboards, and exportable reports. The worker side had cards. Tap the card, do the thing, take the photo, done. Two completely different experiences for two completely different mindsets.

The worker side was designed to feel like a to-do list, not a software platform. Open the app, see what's assigned to you, complete it, close the app. That's the whole interaction. No onboarding tour. No settings to configure. No notifications unless something went wrong.

Fewer screens, faster exits

When I design for reluctant users, I count taps. Not because I'm obsessive about it. Because every tap is a moment where the user might get frustrated, confused, or just stop using the app. If a contractor can complete a safety check in four taps instead of seven, that's the difference between compliance and non-compliance. That's not a UX preference. That's a business outcome.

We stripped out everything that wasn't essential for the worker. No archive feature on their side. No notification bell cluttering the screen. No profile settings beyond the basics. The manager can access all of that from their dashboard. The worker just sees their tasks. If they have nothing assigned, they see a blank screen. That's it. That's the goal.

Research from the Nielsen Norman Group consistently shows that users in work contexts have lower tolerance for complexity than users in leisure contexts. When someone is being paid to do a job and the app is a hurdle between them and that job, your margin for error is basically zero.

Design for the person who didn't choose you

If your app has different user types, and one of those user types is being told to use it rather than choosing to use it, that changes everything about the design. Shorter flows. Fewer decisions. No onboarding that assumes enthusiasm. No features that assume the user wants to explore. Get them in, get the job done, get them out. That's the design principle.

Most first time app builders design for the enthusiastic user. The early adopter. The person who's excited about the product. And that makes sense when you're building a consumer app. But in B2B, especially in industries where the end user is on a worksite holding a phone with one hand, the enthusiastic user is the exception. The reluctant one is the rule. Design for the rule.

Sources
Mobile UX Design (Nielsen Norman Group) - Principles for designing mobile interfaces in constrained contexts.
Enterprise UX (Nielsen Norman Group) - How workplace software design differs from consumer product design.

Related blog posts:

Fewer screens forced better thinking →

Who assumes the complexity →

The default matters more than the option →