henrikwm

On 11.: also prevent leaking the account’s existence when someone requests a password reset. Otherwise it’s a great way of finding out who has accounts where if you know their email. Use the same text as receipt to the user after form submission.

You can, and probably should, go one step further and serve the same HTTP-response (size in bytes and response time) as well.

You can use this CLI to plan you haircut by browsing queue times for Cutters hair salons:

https://github.com/draperunner/cutters

Which enables you to run:

  $ npx cutters | grep Oslo | head -3

to get queue times in Oslo. Made by a colleague of mine.

Yeah, I agree that it can be a negative experience if it's implemented badly. Prompting too often and too aggressively is bad practice.

However if it's a quick, easily dismissed question, it can work when used sparingly

I've been a developer for 10+ years and this is very much in focus at the customer I work for at the moment, where we've created a login portal for our end-users. Recently this design pattern has spread to other sites as well. Over 50% of our users are on mobile devices and almost all of them are traveling. So our services needs to be fast, unobtrusive, responsive and capture just enough of user information. With as little cognitive impact on the user as possible. Travelling is stressful enough as it is without having to potentially struggle with bad UX on a website when you just want to see your flight details.

So the Login page, Forgot password page, Create user page etc. are all asking for one single piece of information at a time, with a clear single call-to-action. This interaction design pattern really works nice when you're conscious about the context the user is in. Be careful not to go overboard with the minimalism though. You still need a good page title, breadcrumb, texts and labels to explain the context where the form is shown.

Example:

When the user has logged-in to your website to shop, have a random step after sign-in that asks for a single piece user information (delivery address, phone number etc.) before they continue. It must be very easy to dismiss, unobtrusive, and easy to understand why you're asking. Some will enter their information, some will do it later. And that's ok because now they had the power of choice. And when they're ready to create an order, the time-to-order (conversion rate) will decrease because some of the information has been pre-filled.

Designing forms for data-capture is difficult and you need to decide on when it is appropriate to ask the user for the information you need.

I've made those God-forms before but never again. Serving the user a God-form with dozens of required input fields, however optimized for data-entry as you'd like, will only add to your drop rate, it will annoy the user and by re-designing how you capture user information you will improve your site's UX (and probably increase your profit as well!)

When designing a form next time, ask yourself: Do I have to ask the user for all of this information right now all at once, or can I capture this information in the context of the user working towards an end goal in other areas of my site?

Minimize cognitive load: https://www.nngroup.com/articles/minimize-cognitive-load/

Making the choice easier for users: https://www.interaction-design.org/literature/article/hick-s...