Redesigning a Login Screen (UI Case Study)
Let’s do something a little different here. If you’re reading this, you’ve likely read my design hacks, perhaps my take on color theory, maybe even my 3,000 word article in which I design a single button. Today, I want to get even more in the weeds (whattttttt).
Simple exercise: we’re going to take an awful design and make it look good. At each step, I’m going to explain:
- What are the biggest UI issues that I see?
- What techniques am I using to solve these issues? (These are things you can take away for your own “design toolkit”)
- What are the most common mistakes beginning designers make when designing similar things?
The Before: from a homework assignment submitted by a student in Learn UI Design, my course on user interface design. With all due respect, it’s pretty nasty (the design, that is — jury’s out on the course). OK, it’s not actually the submitted homework, but it’s real close.
The After: What we’re going to build today.
Ready? Let’s dive right in.
(Right off the bat, someone’s asking: why on Earth are you designing on an iPhone SE-sized screen!? I get it. iPhone X is huuuuge compared to the 320x568 screen here. But that’s exactly the point. It’s harder to make everything fit on a smaller screen, therefore, we’re going to start designing on a smaller screen. Scaling it up is easy, and scaling it down? Well, we don’t have to.)
Web Design is 90%…
If this was your job to redesign, where would you look first? Ten bucks says you shout “color!”, but that’s $10 you just lost, my friend, because the biggest problem here is typography.
Fixing the color is easy. Just take it all away (“black and white first”, remember?). But does it actually look nice now?
Better, but not by all that much. So while fixing the colors is simple, fixing the typography is… not so simple. That’s why we focus on it.
Now when I’m redesigning something like this, my analysis of the text styles is all in my head. But I’ll make it explicit for you. Watch what happens when I replace each piece of text with a description of its style.
What do you notice? Specifically, what styles seems weird or could be improved? Actually try and come up with an answer before reading on.
(I know you didn’t… It’s OK, cheater, I wouldn’t have either)
Here’s what I’ve got.
A note on fonts: our title is a bit garish, sure. And the rest is set in Tahoma, a default web font that has a sort of “default, unstyled” look. But while the complaint about bad fonts is the easiest to see, it’s also the easiest to fix (sound familiar? It’s like calling out the purple/green right away).
In other words, broke: “your font sucks!”; woke: “there’s a lot of font size inconsistency we can clean up here”.
It’s WAY more useful to get good at recognizing how to STYLE text than call out the Comic Sans of the world.
With that in mind, let’s (a) strip out everything, then (b) add the elements in again, one by one, keeping things neat as we go, and not adding the next element until the current screen looks good. Note: that’s actually a method that I’ll use to design many screens. I don’t stick by it 100%, but it can be a useful way to think of design process. Beginning designers, write that one down.
So first: the title. This page is more for signup, so instead of “Succulent Garden” the app name), let’s just say “Sign Up”.
So what style should we put it in?
Well, this is an iOS app, so we’d want to follow — or at least be “heavily inspired by” — the iOS guidelines. What size are titles on iOS apps? Fortunately, I just published Font Sizes in UI Design: The Complete Guide to answer questions like that. If you select iPhone, you’ll see that titles on iPhone apps are sometimes 34px before scrolling, but after scrolling, most centered titles are 17pt — and a slightly heavier font weight to boot.
So let’s do that. But what typeface to use?
How to Pick a Great Typeface
For a lightning-fast website, use default web-safe fonts. For an app, it’s not as big a deal. So we can either go Apple-native with their default font SF, or pick our own. Let’s go the latter route, for sake of example.
For an app whose brand is largely going to be clean, modern, simple, we want a font that matches those attributes. It will very likely be a sans serif font. There will be a very slight range of character among these fonts, but a respectable case could be made for many different typefaces.
At some point, you just call it with these things. I’m going with Work Sans, a clean yet friendly (and underused!) Google font.
I highly recommend installing a tool like WhatFont and starting to notice what fonts you like around the web. Building your mental repository of good fonts is the best way to generate ideas when the time comes to pick one.
It’s a good start. In the original, there’s a “Welcome!” text, but let’s drop it — we’re going to add the bare minimum first, then see what else feels necessary.
(the “SIGN IN” button will likely be a link below the form — that’s more typical for this sort of thing. So we’ll skip adding it for right now)
The Form Controls
Alright, the form controls. Let’s cook up the meat of the page here.
What size is a form control? Let’s refer to our Font Sizes Guide to see that on iPhone, the typical value is 17pt, normal weight.
Just to keep things simple, we’ll use Matt D. Smith’s ingenious “Float Label” pattern, where the label of the input is inside the textbox, even once it’s filled out (BONUS: this also keeps the page from feeling too cluttered).
The savants among you may notice I actually used 16pt text, not 17pt — why?
- Because Work Sans is a pretty wide font with a nice, high x-height, making it highly legible compared to other fonts of equivalent size. Seriously, 16pt Work Sans is closer to 17pt San Francisco than if they’re equally sized. Try it at home, kids.
- The float label pattern requires the form control label and the value to fit into the text box. Easier to do with a slightly smaller font size.
OK, design trick alert: the labels (“Name”, “Email”)are 70% opacity. The lowered opacity helps me distinguish label text (always 70% opacity) from user-inputted text (always 100%). For a 201-level variation, use color instead of opacity.
If the tiny labels are 12pt and the larger, more important text is 16pt, what do I have room for in the middle? Answer: 14pt paragraph text.
Skipping a size makes it crystal clear to my users what role the text plays as soon as they see it. If you’re making a DESIGN SYSTEM (buzzword bolded/uppercased for the skimmers), you’ll want to do the same: skip a size between smaller styles.
OK, so far so good.
The next step is to add in the terms-of-service checkbox.
For this, my first hunch is to make height of the checkbox the exact same as the height of the textboxes. Beginning designers, remember this: consistency always wins. I’ll also slightly darken the background (in HSB, a flat gray with 90% brightness), a good indicator that something is depressed into the screen.
What font size do we use? In this case, I like the think of the relative importance of elements. We could use the 16pt we saw in the text inputs, but “I agree to the blah blah blah” feels a little less important than a user-fillable text box. A little more fine print than front and center. So let’s bump it down a notch (remember: skipping a font size) to 14pt.
Golden. Next is the “Sign Up” button, which I can do by simply duplicating the text box, adding some colored background, and (a) centering and (b) bolding the text.
Cool. We’ve got the bulk of the page elements onscreen and everything looks good so far.
Adding the “or sign up with” text is next — there my two options are already set for me:
- Use the “important snippet” size of 16pt
- Use the “body text” size of 14pt
I will try both and go with whatever I like better, since this seems to play sweeper between those two cases.
We went with the 16pt size.
(I also added a back button, as that’s a pretty default iOS way of navigating to where you can sign in with an existing account. This means we can remove the “Sign In” button entirely.)
(The facebook and twitter buttons are as consistent as possible with the Sign Up button — same height, same border radius, same shadow — just different content and width. Consistency always… say it with me… wins.)
I’m going to spice things up with a background image, which will also help give this app more of a unique feel (or, as clients say, “pop”).
The best place to get free images? Unsplash, without a doubt. (I hear some of you sighing — freakin’ hipster. Hey! Designers will be designers…)
The only simplistic succulent image I can find (in keeping with our theme) doesn’t fit very well on the screen.
One little trick is to sample the image colors at the top-left and top-right corners of the image, them create a rectangular left-to-right gradient to fill in the whitespace.
This is already looking really good, but I’ll add a transparent rectangle on top of this border and give it a background blur, so as to make the difference between the image and the gradient all but unnoticeable.
But it’s not perfect yet. The black header text appears messy on the image background. When in doubt, always go with white text on colored backgrounds. So let’s change that too.
Whoa. Not very legible, is it? One way to fix this, while still keeping the mood of the app, is to add a background for the header that’s a darker shade of the same blue.
In this case, the fill is 100%-opacity black, yet the layer itself is given a blend mode of Overlay with 90% opacity. This means we’ll get a nice, slightly darker variation on the blue behind it.
Alright, bam. Done. No sense prolonging this any more than we need to.
We’ve just completed a major facelift on this screen, and determined a couple of styles that we can bring over to other screens from the same app. In the process, we’ve covered a whole bunch of great heuristics for designing UI, like:
- Add elements one at a time, keeping things simple and clean at every step of the way. At any point, did our design look bad? No. Start good, stay good.
- Consistency always wins. Adding a new piece of text? Start by styling it like an existing piece of text, and adjust — if necessary — from there.
- Design small, then scale up. It’s easier than the reverse.
- Some other stuff, IDK, you just read it, right?
What do you want to see redesigned next? Give me a shout (via the email address listed in the images throughout this article), or hop on the Design Newsletter and reply to the warm and welcoming email I’ll be sending you the moment you do.
Originally published at learnui.design.