Approaches on having a sign in, sign up, and guest form in mobile app with as little annoyance as possible

Question

At a university class we are to create an application for mobile devices for an actual client (a municipality). The app allows inhabitants of said municipality to file complaints concerning roadway damages, problems with ticket machines, et cetera.

On implementing, I stumbled upon a problem concerning the design of the sign up/in form. As per the client’s requirements, entering at least an email address to use the app is mandatory so the client can get in touch with its users for further inquiry or letters of gratitude. Therefore, there are three scenarios to implement:

1. Ideally, users create (-> registration) an account containing at the very least an email address and a password to later on see the status of their complaint
2. If they already have an account, they can login with said credentials
3. To just file a complaint without the hassle of creating an account there’s a semi-anonymous option where just the email address is mandatory

The following is what my group and I have come up with so far, but I’m not too satisfied with the outcome yet as I want to make the experience as pleasant as possible (which ideally would require not having to sign up at all, but that’s quite another cup of tea).

On tapping on the sign up button, a registration form containing the same two input field opens up—as inputting other personal data (address, name, …) is optional I decided to give that form a prominent place within the in-app settings. The app is basically a single-purpose app without too many options anyway, to it’s not too hard to find it.

Question: Can you think of a better way of implementing the three scenarios? And how can I communicate which fields are mandatory (sign up or -in: email and password, guest: email)

I thought about using the login form as a multipurpose form for signing in and up but found that this leads to too much confusion.

(This is not a “please do my homework” kind of question—I’m genuinely interested in making the user experience better; UX isn’t even the class’ purpose)

Answer 1

Provide a default action and update to the user's preference from there.

The least amount of information required is an e-mail, so just let them enter that inline with the rest of the complaint/concern form. The user can now just enter an e-mail, enter their complaint and hit submit. Quick and easy.

^{download bmml source – Wireframes created with Balsamiq Mockups}

A mechanism to enter a password can be easily added. Let's assume a user's e-mail is their username (a lot of places do this, so I'll make it easy and assume that is true here). Give the user the ability to quickly enter their e-mail/username and then tack on their password. The new field does not have to reload the page, it can easily be shown inline with the rest of the form. It is out of the way for people without a password, but quick to add for those that do.

Lastly, provide a clear way to go through the more complex process of creating an account. Assuming this would require a dialog box, or navigation away from the page, make it a visually distinct button. You also say you want them to ideally have an account, so making it visually clear on how to do it will encourage people to sign up.

Ideally, users create (-> registration) an account containing at the very least an email address and a password to later on see the status of their complaint

While this is the preferred mechanism, is it the most common? If you truly want to cater to the users' preference, make sure you know what their preferred method. In the example above I assume people would prefer to just enter an e-mail and be done with it. I personally wouldn't plan on using this website a lot (unless the kids will simply not get off my lawn), in which case I don't want to go through the long process of signing up.

However, sometimes business decisions trump user preferences. If the municipality really would prefer people go through the long process of registering, realign the form to put focus on the login with the anonymous method more tucked away.

This would fall to something very much along the lines of what you already have. It just depends on how you decide the best way to lay out option orders are.

^{download bmml source}

This gives the user instant access to the preferred login method, is clear about how to create a new account, and still gives a way to just complete the form with an e-mail.

A side note - don't call it "anonymous" if it isn't anonymous. Providing your e-mail isn't anonymous.

Answer 2

In a way, this is very similar to how online purchases are made.

The store, or in this case the municipality, would prefer if the user created an account.

In this case the municipality asserts that the user would prefer to create an account but that probably won't be the case as complaints are reactionary and usually preferred to be made anonymously.

Either way the complaint is made, an email address is required. The only real benefit to logging in is to check the status of a complaint after it has been made.

Also similarly to an online store, you might consider sending the user a link to the status of the complaint/order, or email them updates, so that even if they wish to remain anonymous them can still stay up to date on the status/package-delivery.

Because logging in is completely optional and an email address is required anyways, the simplest first step is to just display the complaint form including the email address, skipping the Anonymous or Logon step.

During complaint composition, if the user wishes to log in, that should be permitted, but saving the info that they have already entered. So the email goes to email field and the complaint is persisted after logging in.

Additionally, just because a complaint is made without being logged doesn't necessarily mean they don't have an account, so if the email entered matches up with an existing account, when that user logs in, consider treating that complaint as belonging to that user.

Ditto to complaints made before an account is created. If I create an account for an email address that already has filed complaints, consider treating those complaints as belonging to the new account.

Answer 3

I would agree with most of the comments already written, but I'd like to add a little more in case it's useful to you.

There are some great articles that suggest you 'delay requiring the user to login until absolutely necessary' (see: http://www.sitepoint.com/improving-apps-onboarding-ux/). Similar to the iTunes store, AirBnB, Quora, and others, try to think of ways you can show what value your application provides users before they even login, and only at the point that it's absolutely necessary, they can login. In your case, this might be viewing results of resolved submissions, submissions themselves (if they are made public), or at least writing the complaint (as you seem to already have suggested), for example.

In terms of the login form itself, here are a few suggestions:

• login with trusted 3rd-party (i.e. OpenID, Google, Facebook, etc.)? There are good reasons why you may not want to go down this road, but it could provide convenience for many of your users
• don't require a username before successfully registering - they can do this afterward (if it's even necessary)
• allow users to unmask their password rather than repeating their password
• use a reverse captcha to stop robots, rather than a regular captcha that hassles humans

(source: http://www.smashingmagazine.com/2011/05/05/innovative-techniques-to-simplify-signups-and-logins/)

Finally, there is notable research into what makes a good user experience after registration and login. Known as the 'Goal Gradient Effect' in psychology, providing users with already completed goals makes them feel like they've already built up momentum and are more likely to complete their tasks. This is based on 2006 research by Kivetz, Urminsky & Zheng, who published 'The Goal-Gradient Hypothesis Resurrected' and found that "A 10-space coffee card pre-stamped twice will be completed faster than an 8 with no pre-stamps." (see more info: http://coglode.com/gems/goal-gradient-effect).

In your case, there only seems to be one kind of task, but you could consider visual 'rewards' for users completing more submissions (e.g. users submitting 5 complaints are 'gold' users). This may be well beyond the scope of your project, but it's a useful principle to consider if you want to build it out more.