Creating a separate recruited user task flow


Hi UX Mastery team,

I’m really stumped on a project at the moment and I was hoping people out there might have some insight or reference that could help me.

I have designed a market research app that is open to the public but I need to tweak this for my agency to allow for a collaboration with recruiters.

This means that there needs to be a separate task flow for participants who access the app from recruiters. Reasons for this are because we will have less available to the recruited users so we cannot effectively “poach” them for our own projects. They will also be automatically signed out as soon as they have completed their questions and will be re-signed up every time the recruiter gets them involved on a new set of questions.

We are currently debating using unique codes sent to these recruited users to keep them separate. But I would love to know if any has any experience creating separate task flows for something similar to this. Or if you have used an app that had a different flow depending on your user type.




Gnarly question! Is it at all an option to publish the subset as a separate app? Or does that defeat a significant part of the purpose? I’m also assuming you mean a mobile/tablet app, not a web app—there are some good reasons for keeping apps focussed on core audience.


Hmmm very good question, I’ll ask my developers what they think of that. I would argue off the top of my head that it might make things ultimately more complicated having to manage the two separate apps.

It’s currently a mobile app only.

Looking back I think it might have been better to make it purely for recruited users and then open it up to the public later but things got turned around on us after the launch so it’s a bit too late to redesign it in that way. There’s also something to be said for allowing access to the public so that over time we are slowly building up a public user base of our own.


From what I’ve understood of the app, the recruited users have a lot less to do than public users.
The recruited user’s enter a code, and quickly get into the main part of the app - answering survey questions. once done, the system exits them from that flow.
So there could be one main task flow, which a recruited user “joins” and “exits” in the middle.

(the vertical lines are tasks the user performs)

PS: Sorry for the poor mock-up.


Hi @enlightened_06, your totally onto it, that’s exactly the process we need to perfect at the moment.

You did help me to realise that my main struggles are centred around how they enter into and leave that process. For instance, are there good alternatives to needing a new code every time they start their new research task.

I can’t think of any example off the top of my head of other apps that have something similar.


@leighrubin Glad that I could help.
I can think of some ideas instead for the code:
If the participants have some way to sign-in, you could probably take them right to the latest survey they’re recruited for. This way, they sign in once, and it saves the user (typical to most apps today). This however leads to a different set of problems - what if they’ve been recruited for multiple surveys and they haven’t checked any?

Other than that, the referring link could have the unique code right in the url. When the user taps it, the code is transferred to the app automatically, eliminating the need to type it in. This could also be coupled with the sign in for other advantages (maintaining records and such).

I’ll add to this if I can think of other ways I might’ve observed.


Hi again @enlightened_06

We ended up kind of using a mix between the two you suggested in the end along with a mix of other solutions :slight_smile: Our devs are trying to determine how the unique code in the eDM can populate within the app once tapped. I’ll let you know how our progress goes.

Thanks for your suggestions!! They were really helpful and made me think harder about a good solution


Thats awesome! Glad my suggestions helped :slight_smile: