We have a service that involves syncing between devices. You can either: a) sign-up on the web, download the client and sign-in b) download and sign-up within the client c) download a mobile app, sign-up, then sign-in to the web, download the client and sign-in

This means that controlling the first use experience becomes really tricky and, as with all sync services, explaining the to the user how to sign-up and install the various client apps becomes complex and unwieldy.

Should I choose one way to sign-up, force people through that process and retain control and provide a good first time use, or should I relax and embrace this complexity as it gives the user more options for service discovery and use?

3 Answers 3


You should let users sign up through whatever means they come to your service. Any impediment to their current inclination to sign up is a further chance that they just won't do it at all.

Once they've signed up, let them know how else they can access the service. On the web, tell them they can download the desktop and mobile apps and give download links; on mobile, put the same sort of information in the tutorial. With the current amount of widely-used file syncing services, I think this is a model that the majority of people are either already accustomed to or can grok easily.

  • Thanks, I guess I kind of know this because that's what we already do but it's definitely an 'educating the user' piece that we need to work on. Commented May 3, 2012 at 16:59

This sounds similar to the Evernote signup process. Evernote allows user to signup via the web directly, through there client or through there mobile app (IOS or Android).

Embracethis complexity and allow users to signup the way they feel that is best. Of course educate them about all the different features your services provides.

  • It is kind of like the Evernote process, same kinds of complexities. Like I've said before, it's the education piece that I think we need to work on so thanks for your comments. Commented May 3, 2012 at 17:00

Sounds like you need to rethink your back-end architecture to enable all the platforms to use a single database to store credentials.

Unless your using some 3rd party (FB, Twitter, etc) that has a separate API that needs to be accessed, you should have a single sign in process for any/all of the gateways to your service. Whether someone goes to your mobile app, client or through the site, it should be one native sign in for each method.

Is there a reason you have to go to the site and sign in to download the client? Is it restricted or something?

  • We have SSO, it's not the back-end that's the issue it's the front. Mostly it's the complexity of educating a potential user that in order to get the most from the service they need a client on every device they want to sync AND they can access their stuff via a web interface as well. Commented May 3, 2012 at 16:57

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.