Subscribe to the GoSquared newsletter.

Join 15,000 people. Get our latest posts delivered to your inbox every week.

  • THE BUTTON IS BACK. I now feel complete.

  • Ricardo Souza

    Hey, great transitions.

    I just had one issue, after clicking on reset password there was no way to get back to log in, so I clicked on the browser back button, the url was the initial one to show the log in but it still shows me the reset page.

  • themefisher

    Its not so user friendly 🙁 … not a successfully login redesign form.. 🙁

  • Florian

    May I propose to add something like “validating password” or “authorizing user”, etc. in the submit button along with the spinner? This way you give a reason WHY It takes some time. IMO spinners without explanation can easily be mistaken as a locked up processes (“something is not working correctly”), as you can to often see it in major OSs.

  • Great post! Thanks for all the detail – and it truly is an impressive login screen.

    Couple of things – why did you decide to make the login screen a new page rather than an overlay, or at least include an “X” button to give the impression of being an overlay? It breaks the experience that I have to click the “Back” button on my browser to return to the home page.

    Are you planning on redesigning your sign up page too? It’s such a nice login page, with such a distinctive look, that when I click on “create an account” the page it takes me to is so different, with completely different interactions that I almost wondered if I was on the same site.

    Finally as Ricardo mentioned, you’re unable to return to the login page once you’ve pressed “reset password”.

  • Florian, nice suggestion. It’s always a trade-off, but we feel the form would look a little more cumbersome with text in the submit button when it’s loading.

  • Very sorry to hear that, Themefisher.

  • Ricardo, you’re right, I think we can improve this – don’t be surprised if you see a back button the reset password screen very soon 😉 Thanks for the feedback!

  • Thanks very much for the kind words, Tom!

    The big reason for the login screen being on a new page is that we wanted the transition from signing in -> viewing your GoSquared account to be as slick and smooth as possible. We feel it’s more important for that to be slick than the transition from homepage to login screen. And we couldn’t have both!

    You’re right, the Join pages now look a little detached – things are always evolving, and we will continue to improve those areas of the site. It’s worth bearing in mind, though, that our Join forms serve a *very* different task to our login screen, and so, while we can bring their look and feel more in line, we must be careful not to mindlessly change our join forms without thinking about their own requirements.

    Thanks for the feedback – so good to hear these comments and see how we can make things even better in the future!

  • themefisher

    when I click the reset option and after that I want to back the main registration page. there is on option their.. Its a BIG UX problem. You should experiment this a little bit more..

  • polarblau

    Thanks for a nice write–up including some neat details. However, a login page really shouldn’t depend on JavaScript in my book. — Your version doesn’t render _anything_ at all if JS is disabled.

  • Candy Rendon

    button is now. button is life.

  • Thanks for the feedback! We definitely should have a better warning for visitors who don’t have JS enabled for sure. However, in terms of the reasons behind requiring JS for the form – the GoSquared application itself requires JS and cannot be used without it. Hope that helps!

  • Shane Provost

    Great post! Beautiful interface. To be honest though, I’m not convinced with the user ALWAYS needing to see the label–especially if there are only two or three fields to enter. If there are more than that, I get it! The email field is clear because of the email address characters, and the hidden characters makes it clear that it’s a password field. On the authentication code page, the title of the page makes it easy to identify what information you are putting in the box.

    All in all, great job! I think we just need to make sure that we don’t make our simplification overly complex!

  • Cheers Shane! We felt the labels just added some reassurance – especially when fields are autofilled, it helps clarify email and password are required.

  • This is pretty beautiful stuff! I have to say this is probably the most gorgeous login screen design I’ve seen. ever.

  • Wow, Elliot, thank you so so much! It makes all the effort worth it when we hear comments like that. Thanks so much!

  • gryntelyder

    animations. i *hate* animations. it is the web designers way of saying “I’m so arrogant I think everyone else appreciates the elegance of my login screen so much they want to hang out here and watch stuff move around the screen”.

  • Bob

    Transitioning the placeholder to a label is unnecessary, and poor design.

    Placeholders and labels are two different things entirely!

    “The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value” –

  • Putin

    1. Label animations should ease in, they’re a bit sharp.
    2. Your mailcheck boxes look out of place due to being taller than the input field
    3. You can be secure without taking the amount of time you do, just after the third failed login for an email or from a specific IP start putting delays in and then lock them out after a certain amount.
    4. Your spinner animation is just as bad as the dumb time based animations. If logging in takes so long, what can I expect about the performance of your application? Straight off the bat I’ve got a bad taste in my mouth.

  • I’ve tested the autofill behavior in Chrome: After selecting my email address (the username), Chrome autofills the password field. When I query that field in Chrome’s JavaScript console, I can get the password via the .value property normally. My observation conflicts with what you’ve written in the post.

  • JT

    I guess we could’ve explained it a little better: we’re not trying to achieve the same task as a placeholder, what’s really going on is we’re just positioning a label (with the purpose of a label) inside the rectangle of the input. It’s something lots of people do, and designers are especially fond of it as it cuts out clutter from having lots of text floating around outside the input.

    Most people achieve this by using the placeholder attribute, but this is a Bad Thing for exactly the reasons you say – the spec is very clear that the placeholder attribute is NOT for labels. The way we’ve actually implemented it is to use a and move it around in a way that we think achieves a balance of keeping the design clean while maintaining accessibility and providing information when necessary. So perhaps I confused things by even mentioning placeholder – it’s not a placeholder, it’s not implemented as a placeholder attribute, and it doesn’t serve the purpose of a placeholder.

    But hey, we’re always open to feedback – if people don’t like the way we’re doing things we can always tweak and improve stuff.

  • JT

    This’ll be because there’s multiple possible behaviours in Chrome – the example I described is if Chrome auto-fills *both* the email and password on page load – the gatekeeper thing ensures that a password field cannot have a value until you’ve interacted with the page at least once with the keyboard or the mouse.

    What you’re seeing is your password being filled *after* you selected your email address, which is an interaction so the gatekeeper allows the value property.

    I believe this is something that’s changed fairly recently in Chrome – depending on which version you’re running it may or may not be disabled behind a flag – see

  • JT

    1. – you’re right, they’re currently using the default “east” timing function in the CSS, that can be tweaked a little for sure
    2. – again yeah agreed this could do with a bit of tweaking, we’ll see what we can do

    I’ll take 3 & 4 together. First, I disagree that you can be secure and be fast (as in feels-immediate fast). Our password system uses a high work factor for verifying your password, so simply verifying your password takes a good few hundred milliseconds. If we were to speed that up by using a faster password hashing function then that would be less secure. Sure, we could have some throttling in place on the endpoint to ensure you can’t spam it, but what if someone somehow managed to steal our database? With a weak hash it’d be very easy to brute-force the passwords of all our users and then a would-be hacker has a huge list of email/password combinations. Not good. So that’s why we use a strong verification function. Personally I’d have a much worse taste in my mouth if logging into a service only took 100ms, because that means they’re not storing my password securely.

    Given all that, logging a user in takes *at minimum* a few hundred milliseconds. Probably more if lots of people are doing it at the same time (because we just published a blog post about our login process) and putting extra load on our servers. Then factor in roundtrip latency and everything we then have to do to serve the first page after logging in, and it’s usually somewhere around 1.5-2 seconds before you see the next screen. Maybe I should’ve said “a second or two” rather than “a good few seconds” but hey.

    Maybe we could make it a little clearer what’s going on by indicating “verifying password” followed by “wahey you’re in! Loading your account…” or something. It’s an iterative process, and we’ll continue to tweak and improve stuff.

  • Stuart Jones

    Thank you for remembering my email address when I’ve forgotten my password. A detail usually overlooked.

  • Hi Putin,
    1. This is subjective and would be a great question to test with users. I don’t mind it being fast. It doesn’t move far and doesn’t change otherwise, and the speed feels efficient and elegant. Surely it SHOULD be fast, to get out of the way of the user?
    2. Again, subjective. The size helps to say “this is important” without an annoying blood-crimson warning or icon. The contrast helps, as does the appearance in an otherwise blank space.
    3. I defer to the security experts on the technical details of this one but previous similar situations with users in tests I facilitated reveal that users are OK with moderate (2-3s) time used for security and purchasing. We are already used to the time taken to validate our credit card purchases in the real world, not to mention online, so that amount of time for a secure process is comforting, and familiar. IMHO. To some users, that time is reassuring. 🙂
    4. It’s better than a dumb progress bar, since it allows the time it takes to pass without assuming a time. Progress bars should be realistic, not assume the tine it takes, else it will look dumb. Saying that, the user needs to be easily notified, so giving the user an indicator and placing it on the thing they just touched (the button) sounds like reasonable steps to me. As for your final point, that it communicates slow performance, I have to politely disagree. For the reasons stated above, I would feel anxious if it authenticated me TOO quickly. Even my desktop password app, looking locally, takes a second or two to confirm my pass, which comforts me by opening that metaphorical ten tonne bank vault door very slowly. I would like to know if this feature was specifically tested for and whether users were OK with the time it took, JT?

  • Kyle

    Seconded. So dang smooth.

  • Guest

    The back button is broken if you click “forgotten your password?”. The URL will update from /reset to /login, but the form will remain the same. In addition, there is no separate link to return back to the login form without reloading the page. This is a bad experience for a user that accidentally clicks the link.

  • Jared Cubilla

    I too hate when animations take longer than they need to. However, I think it is important to note that when animations are done right (and don’t waste three extra seconds of my time), they can actually add to the interface as a whole.

  • Nice ! job

  • Long Nguyen

    thanks for sharing. We love the process of making much more than the shinny gorgeous UI.

  • Disabling javascript and expecting sites that require it to offer an alternative way to use said site is just ridiculous. The year is 2015…

  • Very nice login form 🙂

  • Loved this article. I included it in my monthly roundup of the best web design content. Thanks!

  • Guys this login screen is the bomb. I especially like the transition from email/password to 2FA. It’s very smooth!

  • James, you are too kind! Thanks man!

  • Thanks for the mention, Rachel, much appreciated!

  • Cheers!

  • Thank you for noticing 😉 Cheers Stuart!

  • Charlie Beckstrand

    I would suggest, similar to your sign up page. To set the cursor to “not-allowed” when they mouse over the “Sign in” button.

    I noticed on my site that when I disabled buttons until a form was complete, it confused a lot of people and they tried refreshing.

  • Thanks for the suggestion, Charlie, that’s a good call!

  • Lucho Molina

    Hi JT – Great post, I like what you did with the page. A lot. But I’m wondering… why did you invest time on this? I mean, aren’t there more important things to focus on right now? Especially with a small development team like yours. Maybe the old form was affecting your primary funnel somehow or there was a technical reason behind it. I know the old form had a somewhat big UX problem because it was missing a submit button, but you didn’t have to redesign the whole thing to fix that.

    I’m asking because in my company it’s hard to find time for this sort of little improvements, that always seem unimportant when put next to the tasks that are more aligned with our big, hairy, ambitious goals. Our development team is somewhat big and we still have a hard time pitching this sort of things to “upper management” (we’re still a startup so calling it that is kind of a joke), so I’d like to know if we’re missing some sort of bigger picture here, or if we’re not using the right arguments.


  • JT

    The main reason we decided to spend time on this was due to the fact that we’ve just added support for two-factor authentication, which required rewriting a lot of the code behind our login process anyway – and also our old login form and the backend handling it was built on an older system, and our visual style has changed quite a bit since then.

    In addition, we’d been slowly accumulating lots of little niggles, like the login button, like some of the behaviour with autofilling etc. that we knew *could* be better, but we simply couldn’t justify spending the time on them. So when we came to the point where we *had* to do a fair amount of rearranging, we took the opportunity to spruce up all the code, rearrange it a bit, and address as many longstanding minor issues as we could. In the end, if we’d tried to mash two-factor auth into our existing login code it probably would have taken about as long anyway, and we’d have ended up with a pile of untidy hacked-together code that’s harder to work with in the future.

    On the note of how to find time for small improvements, the kind that never get prioritised high enough to feature on your main roadmap, something we’ve experimented with here at GoSquared is setting aside one day or one morning per week (we called them Bugfix Fridays, although in reality they were more broad, Outstanding Todo Fridays maybe) purely for dealing with tasks like that – stuff that simply wouldn’t get done otherwise because it’s never *quite* high-enough priority. Can’t say it would work for all teams, but speaking for myself I find it incredibly satisfying and productive to be able to sit down and power through a whole pile of niggling tasks in one go like that.

  • Lucho Molina

    Thanks for your clear answer. Good luck!

  • Great UI guys, I’m sharing!

  • Steve

    I actually think a small delay specifically during authenticating adds a psycological feeling of security, like it’s a “heavy door”. It it just pops open into my account, idk maybe it’s just me but subconciously it feels less safe.

  • My opinion:
    1) It’s too small. On first load i wanted to zoom-in. Makes me feel uncomfortable.
    2) Sign-in button looks kinda bad compared to input fields. It’s not like i’m a superior designer, but i definetly can tell that somethig can look better, when i see it.
    3) Why you are not using transition for sign-in button hover? When i see instant button background-change on hover, i’m feeling like i’m in 2000s.
    4) Validation looks really cool, especially in mobile view. Great job!

  • Bartlomiej Bart Skrzyczek

    Hello, I would like to get to know, how did you produce these GIF-s on the page, during the process of designing, please? Is it simply Photoshop tool (as a digital representation of paper sketches, mockups) or did you use another one, please? Thank you very much!

  • Small Businessman

    good answer – if 2-3 seconds is too long to wait you should get counseling – take the time to check your blood pressure or have a healthy sip of water.

  • Christopher Bratt


  • Alexander Savchenko

    JT thank you for the post, your login form awesome. But we faced with the need to support ICANN-era generic top-level domains, as I see your email validation doesn’t do it. Pay attention to this 🙂

  • colaccc

    Hi JT,

    The login form looks really slick. Great job!

    I would like to learn how to make a login form like this one. I wonder if you can share what kind of animation libraries you used for the textbox appearing and label sliding.


  • Ninjadawn

    You left a huge footprint in my computer asshole. What goes around comes around. Believe that, may not be right away but expect it when you least expect it

  • John Johnissimo

    I’d not load a new form for the second step but have the new content appended. Also it’s now saying twice “Sign in” judging from the screens – that seems kinda awkward (“what went wrong before?”). Make it clear to the user he is facing a two-step process.

    So for me it would be on the second step dislplayed
    Mail field
    Password field
    Proceed-to-Login Button greyed out (pressed)
    Authentication code

    Please also be aware of the inconsequence to have a link say “login” but the title “sign in”. Just decide for one.

  • rob2d

    I really like the UI, but as a developer myself who is working on a project that meets pretty high level security standards I have to just say that… it should not be that slow 😛 Maybe there wasn’t time to optimize or something but decrypting a password, checking against previous hashes, etc should not require more than a second on a reasonably well thought out login system on a server.

  • JT

    You’re absolutely right, and this is probably largely due to me not being clear in the post.

    We tuned the work factors in our password hashing so that it takes roughly 400-600ms to verify your password. The main reason for it being a lot slower than this at the time of writing this post was due to the fact that that verification was being done on servers that were already under a lot of load serving completely unrelated workloads, combined with quite a lot of extra time spent fetching a lot of other data to serve the next page (i.e. all your other account data and everything necessary to show you the logged-in state), all of which wasn’t very well optimised.

    Since writing this post we’ve addressed these problems by making sure the password verification doesn’t get unnecessarily slowed down by load elsewhere on our systems, and by optimising the post-login fetching of data to make sure that doesn’t slow down your experience when logging in. The net result of which is that logging in takes roughly 600ms plus network roundtrip time to our servers, which I’m sure you’ll agree is much more sensible.