So you did a great job with your website and now your customers want to get into contact with you. They actually want give you their holy grail and apply for a login. And that's where it usually starts to go south. So many things can go wrong with a registration form that your customer doesn't really feel welcome or safe. In this session we will debug a few real-life examples from a user-experience Point of View. By analysing that we will find ways to make the first contact of a user with our application a better experience. And you don't need to be a coder to see why and how to improve your next registration form.


Comments are closed.

Shaun Forsyth at 20:28 on 13 Jan 2021

Great guy, clearly knows his stuff!

I felt talk was a little laboured, it felt like it could be shorter.

One point back to the presenter.. around gender... Marketing is a very import aspect of data capture. Being able to sell to different demographics can make or break a company depending on the product.

While there has been research that shows password resets are bad, I have read them and they are right.. however I would urge people to consider... you don't know always know when your data was leaked. It may take a machine 2 years to break a password, people move on from companies, sometimes we forget to disable all their accounts or don't know everything they were logged into. There are still good reasons to have passwords expire. Try and breed a better password culture "Passphrases" password managers, but always consider expiry still has a place.

You might want to add Invisible reCAPTCHA as an ok option.. its invisible until It thinks it shouldn't be.

The underlying point of first impression is important and very strong, every developer, website owner and marketing person should understand this. Friction is lost business.

Good read around this is "Don't Make Me Think" by Steve Krug

David Lumm at 20:30 on 13 Jan 2021

Great talk! Lots of different things I've heard or thought of before, but really interesting to hear them in one talk and placed into context with each other. When devs build interfaces we tend to do them habitually, we add things because we always have, but it's good to remember to start with the bare minimum and only add things as and when you need them, for a known valid reason.

It was great to see an example, go into some depths, have some resources for further reading and then move onto the next related issue.

I have a feeling I may need to send that talk to people next time I'm involved in building some UI!