I am creating UI for a recipe app. I want to include customisation. Asking questions about diet, allergies and time available for preparation.

  • Should I include login/sign up before or after this onboarding process?
  • Is there a way to save this preferences and have favorite recipes list without the need of log in?
  • 1
    Usually you do after the customization process because the user feels more inclined to sign up after they spent so much time building up what they have. Also this gives the user an "out" if they don't feel comfortable to proceed with a sign up.
    – UXerUIer
    Nov 5, 2021 at 16:02
  • thank you! what do you mean by "gives an out"? Nov 5, 2021 at 17:27
  • What I mean is that if the user doesn't decide that they want to register and account and just test out the features at this moment (without committing to registration), they can gain access, but not have their details saved UNTIL they register.
    – UXerUIer
    Nov 5, 2021 at 18:05
  • ah, like pressing skip will take them to the homepage but the end of customising to signing up. Nov 5, 2021 at 18:59

4 Answers 4


I would suggest this:

Make a list of you competitors. There should be a lot of other successful and similar platforms out there, try to use and observe what they have done. Don't reinvent the wheel but give it a twist that fits your brand.

  • 1
    This is more of a suggestion than an answer to the question that uses supporting documentation. Suggestions should be left as comments.
    – Izquierdo
    Nov 5, 2021 at 19:25
  • To be honest, I haven't used ux stackexchange in three years, didn't think of this haha
    – Arianit
    Nov 5, 2021 at 20:31

Let the users browse the content of your app. This way they will get familiar with the app interface, the content and usability of your app.

Regarding your query:

Asking questions about diet, allergies and time available for preparation.

After browsing the content if the user finds your application useful and want to know something she/he is definitely going to register with your app or they will leave and uninstall the app too (hard reality).

Now it is up to you to ask the user to register first before submitting any question or let the user type the question and on touch of submit button ask for registration.

If your are going with the first option there will be no issue.

With the second option you will need to either store the data entered by the user locally on the device or you can even do the registration process with an overlay form over the page where the user had asked the question. In both these cases if by any chance your app crashed or get closed, I think the user will need to type the whole question again which will not be a good user experience.

My suggestion would be let the user browse the content and before submitting any kind of question ask the user to register because only those interested or required will try to type any question with or without registration.


It depends on what you business goals are.

You will notice that a lot of dieting apps will first have an onboarding experience or survey that capture the user details and before showing any results they prompt the user to sign up.

This is leveraging the sunk cost fallacy and can increase conversion ( sign-ups )


If it is technically feasible, by all means allow maximum interaction before signup!

Why you should allow interaction before signup

Three reasons:

  • Beware Minor Inconveniences: We are quite ready to drop out of a process if it even takes a tiny amount of effort to continue doing the part we are interested in, even if it makes 0 rational sense. Think not going for a run because your running shoes are in the next room (the horror). More here if you are interested.
  • Reciprocity: Human operate in social contexts with a concept of "you give me, I give you". So if you give users something (information, appreciation, a tip, a good experience) first, they are very much more inclined to give you something (their time and their data - both are costly!)
  • Fun: Your app is cool. Signing up is lame. You want the user to to as much fun stuff as possible when first encountering your app!

A word of warning!

There is actually a fourth factor, which could be described cynically as the Sunken Cost Fallacy (as others in this thread already describing). It refers to the fact that once users committed time and effort, they are unwilling to lose that - so they might signup or even pay so it was "worth". You may use this, but this is a double edged sword. To give an example:

If I am using some app promising me some fairly mundane service (say: Color Palette Generator), pretending to be free, and then only let me see the final result in exchange for significant data or even a credit card, I am gone very quickly never to return, mentally blacklisting that website.

This is also called a Bait And Switch - I would be careful with it, the number of users begrudgingly giving over their info might not be worth the reputation hit. Keep it wholesome! :)

Technical Feasibility

Good news! This whole thing is indeed fairly easy to do nowadays. You basically save data like preferences locally, then ask your server for recommendations and also save them locally (or just display them and load them again later).

Since you didn't specify a platform, I will give some general pointers:

  • This is usually called lazy signup. The tech you are generally using to store data without signup is called local storage or client-side storage.
  • There are basically two approaches, you have to decide which is appropriate for your case:
    1. lazy signup refers to actually creating some kind of temporary account which lives both on your server and the user device, just the creation is completely automatic. Meaning you auto-generate a user called something like eqsy*RBp8w$xjT^j, tell the user device to remember that, and then eqsy*RBp8w$xjT^j can actually have data and settings and friends and whatever in your backend (but if the reference to the user on her device is lost, she can never 'login' again)
    2. The simpler method is to just store data in the local storage without doing any user stuff (like a site remembering you like dark mode). That means there is just some simple data array {isVegan: false, likesPineapplePizza: true} living on the user device which you can access with frontend code. If the user creates an account, you then move that data over to the server.
  • If you are making a desktop app, it is very easy: Just save files on the hard drive of the user
  • If you are using any kind of JavaScript framework, there is usually a very simple API to do this kind of thing: Vue Example Plain JS/React Example
  • Some frameworks have libraries for this, that would be the home run. Django/Python Example (it's great)
  • iOS seems like a lil' pain, here is a thread
  • Android has LocalStorage

Important: Generally, the data will be saved in a kind of temporary storage (like cookies). Also, it is obviously local - since the user is not in your database, you cannot serve him his data on device B after he set his preferences on device A.

So you have to be very clear that data may be lost on software updates, over time, when restarting the device, closing the browser... and that data can only be accessed on that device.

That may be a challenge, because it is quite a technical explanation. However, do this well and you can use it to convince people to indeed signup!

Hope this helps, good luck :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.