Learn by doing, help by sharing.

There are so many theories about the do’s and dont’s of sign-in and sign-up forms. They are so simple and yet so difficult to get absolutely right. It seems like everyone has a different opinion about the right flow, the right placement, the right size, the right user experience. Why do we spend so much time thinking about them? Well, for one, they are a constant in almost all applications. The vast majority of web and mobile apps will ask you to create an account, which you then need to log into. They are also an essential step that all users have to go through, usually quite early in the process. You don’t want to lose users at that stage, to discourage them, to make it too difficult for them to use your service. Done right, the user won’t blink an eye and will become a potential customer. Done wrong, you’ve lost them forever. Why are they so tricky? They all look pretty similar, but they all have their own peculiarities. That’s where most of the difficulty lies. Should they have their own page or be inserted in the header? Should users be able to sign-up with Facebook, Google or Twitter? How much information do the users need to provide to sign-up? Do you ask them to create a username or will they log in with their email address? Should they confirm their password? Etc, etc. See, a lot of questions for such a simple form! Not so simple when you really think about it. My latest experience. No later than last week, I came across a conundrum with these forms. One of the projects we’re currently working on (launching in Bristol in August – keep your eyes peeled. It’s gonna be awesome!) has led me to the same eternal questions. There’s another twist: it’s a mobile-first app. The whole application was designed for mobile and then adapted to desktop. The mobile version is complete. We’re now reviewing every single page to make sure it works on desktop, as well. This is new for us, because we usually do desktop first and then adapt it for mobiles. Personally, I find that sign-in and sign-up forms are quite easy to get right on mobile. A lot more difficult on desktop though, because you have a lot of space that you don’t need. Quite often, your poor little sign-in form feels lost in the middle of a large blank window. How did we proceed? Step 1: Take a look at the mobile version, since this is where we started. This is what we have: Short, neat and simple. Step 2: Research – The UX of user forms is not my favourite subject, but there are a lot of resources out there about the ‘how’s’ and ‘whys’ of creating forms. It will give you a good insight about flow, ease of use, size and placement etc. Step 3: More research – This time, we’re researching what other apps do and how they do it. Step 4: Mock up some ideas – I usually use Balsamiq, which works nicely for simple, easy mockups and wireframes. In this particular case, I started with 5 different options, playing mainly around the size and positioning of the button. Step 5: Submit to the team – I’ve asked the team to take a look at all 5 options and give me their feedback. Which one(s) did they like best, least, and why? What could be improved? Which one should we use? Interestingly enough, I got very different responses. Denis and Nic agreed on the same one, Rob and I preferred another one, and Jess’s vote went to a third option (Julio and Gemma weren’t in on that day). They all backed their preference with what they liked and disliked about each suggestion. Step 6: Use the feedback – I took their feedback onboard, and created 2 new mockups. First, we decided to remove the sign-up link, since in this particular app, you can only create an account while going through the purchasing process. This allowed us to have the 2 remaining links (‘forgot password’ and ‘resend confirmation instructions’) side by side, centred.We also reduced the width of the whole form, as it looked too large and clunky. Step 7: Make a decision – Down to 2 options, it suddenly became a lot easier to make a decision. We went with option 1, then designed the sign-up page using the same style. Which one would you have chosen? Not perfect, but effective. The whole process of researching, drawing the various options and submitting to the team to get feedback took me a couple of hours. I’m not saying it is the perfect way to proceed – it certainly has a lot of flaws – but it allowed us to make a decision fairly quickly and be confident that we did the best we could with the resources and time that we could allocate to that particular task. I would love to hear about your ways of tackling this kind of task! Main image by Aurimas

Meet our new starters in testing, development and content

5 things to consider when building a mobile app

CookiesHQ partners up with Médecins sans Frontières UK

We're hiring!

Looking back on 2017

Why we use Segment with e-commerce platforms

Native apps vs mobile web apps: how to choose?

Fantastic tips and info shared at our last DBM event on Virtual Reality

Design | Build | Market #2: VR

Take a peek, the new Card Nest is live!

Welcome to our two (almost) new team members!

Sign-in and sign-up forms: from mobile to desktop

We solve problems and achieve goals.

It all starts with a chat