Making the case
for the app.

Show the value.
Then ask for the next step.

On Indeed’s Employer Mobile App, I proposed most of the alternative A/B-test designs for app promotion. I worked through the reasons behind those alternatives with our PMs and Engineering Lead.

The starting point was the employer’s hiring task, not the download button. What could the app help them do? How could we show that before asking them to switch from the web?

The wider journey mattered too: finding the hiring app, understanding why to use it, and deciding whether to enable notifications. A/B-test proposals, onboarding-flow reviews and usability-testing designs addressed different parts of that journey. The focus here is app adoption, not a paid upgrade.

Make the hiring route
easy to find.

Some employers were arriving through the job-search app. They could already have an Indeed account—even use it for both job search and hiring—without knowing where to find the employer tools.

The surrounding onboarding-flow review distinguished new Indeed users, existing account holders using the app for the first time, and returning app users. Account history alone did not tell us what someone wanted to do.

The design notes called for clearer separation between job-search and hiring routes, and flagged employer and job-search actions sitting too close together. For an app invitation, that creates a question before the download itself: does this person know which app they need?

The core sign-in and onboarding flows were cross-team reference material. Their relevance here is the route into the employer app, rather than a separate claim that I designed the job-search onboarding.

Make the benefit part
of the hiring task.

The employer was already reviewing a candidate on the web. Generic app copy would ask them to leave that task without giving much of a reason.

I proposed alternatives that showed what the app could offer: keeping in touch with candidates, hiring away from a desk, and reviewing profiles on the go. The aim was to explain the value before asking for a download, not to add another promotion to the page.

The designs varied in both message and format. A compact banner made a short invitation; a bottom sheet or full-page treatment had more room to show the product.

The alternatives.

Use the left and right arrow keys to browse alternatives. Select a screen to enlarge.

Image-led sheet

Original proposed variants with fictional names and messages. Figures in the designs are promotional copy, not results from these tests.

What should the alternatives help us learn?

A larger promotion could explain more, but it also interrupted the task. A compact banner left more of the candidate page visible, but had less room to make its case. I brought these trade-offs to our PMs and Engineering Lead so we could discuss what each approach was trying to change.

Some proposals change both the format and the message. They compare overall approaches rather than isolate the effect of one headline or illustration.

Put the invitation
back into the task.

The discovery-testing material explored a generic app invitation alongside messages about candidate review and staying connected through notifications. A candidate-review task gave those messages a hiring context, rather than presenting the promotion on its own.

That distinction matters to the design question. A message about keeping up with candidate replies makes a different case for the app from a general promise of hiring on the go. The point is to understand whether the benefit makes sense at that moment, not just whether someone likes the wording.

The file also contains a later, post-usability-testing design stage. I’ve kept it separate from the A/B alternatives above: revising an experience after usability testing and comparing live variants are different parts of the work.

Design-review context, not a test readout or a claim of improved conversion.

Ask after the value
has become clearer.

The push-notification work looked at opportunities beyond the onboarding prompt. Someone opening the app for the first time may not yet know how notifications would help them.

The alternative was to ask after they had used the app, when the benefit could be easier to understand. The design work explored contextual opportunities around employer actions, rather than relying only on the first-run experience.

First-message opt-in design with fictional content; not an A/B comparison.

After sending a message, the employer has a reason to care about the reply. That gave us a more relevant moment to explain notifications than asking for permission without that context.

Bring the reasoning
into the conversation.

I used the alternatives to work through the choices with our PMs and Engineering Lead. A screen made the idea tangible; explaining why I proposed it gave us something to challenge and refine.

The task

The employer is reviewing a candidate or waiting for a reply.

The benefit

The app supports hiring on the go; notifications help them keep up with replies.

The question

Which message makes that benefit clearer, and when is the request relevant?

My role was to connect those decisions to the experience, rather than treat a download prompt or permission request as an isolated screen.

From proposed alternatives
to live work.

The app-download alternatives, app-promotion testing and contextual push-opt-in work went live. My contribution centred on proposing design alternatives and aligning their rationale with product and engineering.

The thread through the work was giving employers a useful reason to take the next step: first to download the app, then to stay connected through notifications.