Hello and welcome back.
We're going to jump right in to some scenarios we often face with dealing with forms.
I'm going to teach you the best practices.
We'll go through some demonstrations on what not to do and we'll fix them together.
So before we even can start creating our own inputs and advanced inputs and buttons, we need to talk
about forms, all forms of essentially replaced conversations we have with each other.
So when you design a form, you should always keep in mind that they should feel like a friendly conversation
between your user and the product.
The first scenario we often find ourselves in is the amount of questions we have on a form.
So over here we have a little form.
It's kind of long and kind of demoralising when creating a form.
We need to keep it as short as possible and only ask the questions that are absolutely necessary.
Remember that there are some optional inputs that absolutely need to be there.
We should mark them as such and avoid using an Asterix if some inputs are optional.
Do you really need those inputs at all, though?
Asterix Mudie your design too, and create too much visual noise and sometimes they can be confusing
to others.
Let's take a look over here.
I think we can actually fix this form.
So I'm going to do is I'm just going to copy this frame, Comanche and V and there we go.
We have our frame.
So what I would do in this scenario is just reduce the amount of inputs, so I don't think if we're
creating a login form, you don't necessarily need to have country phone number.
Um, you may not even need the first name or last name.
You could have an input just for fullName.
And there you go, you don't need to ask questions and don't necessarily need to be there, so do your
best to only ask.
These are the absolute minimum.
So let's jump to our next scenario.
Remember what I said about making your forms a bit more conversational?
Well, they should also logically flow like a conversation.
What is the first thing you ask a person when you meet them?
Their name, you wouldn't ask for their address or their credit card information first, I don't know
if you would ask for their credit card information, but we should start with their name and then move
on over to some more sensitive questions.
So let's fix this input.
So we're just going to duplicate it.
We can just rearrange it.
So like a conversation.
You should be asking what seems logical first, it would be kind of weird to be asked your address or
credit card number before your first name or your full name in your email or any other information like
that.
So that's what I would do.
OK, so the next scenario we often find ourselves in.
Is with long forms, so sometimes you may be tasked with building a very long form or set of long forms,
then that happens and that's totally normal.
It happens there's a lot of different use cases like accounting software or just certain long registrations.
It really depends.
But it's a big no no to have all these inputs grouped together because we run the risk of confusing
our user.
So the solution, try to categorize relatable information so you don't necessarily need to break these
into separate flows.
But what you could do and let's just copy this over here.
You can actually just make these into.
Separate categories.
OK, so what I'll do is it looks like I have credit card information.
So this is a group on its own, a full name, address, city, postal code, country, state.
Let's just bring these down.
Well, I'm going to do is I'm going to break this first one into payment method.
And let's just give it a nice border.
That looks really good.
That's just a line that quickly.
So we have payment method, we can pump this up just a bit.
So it seems like a nice title.
To do that.
Oops.
This changes to board.
And we can even just decrease the capacity of this isn't.
In your face.
Let's just do that a little bit more.
OK, so we have one title over here for a grouping.
We'll bring that one down there and we could just call this.
Billing information.
And just like that, we've logically broken out each piece.
Into their own groups, and you can do this if there's multiple groups, but it just helps users digest
your information much more easily.
So if I were to come to a bunch of inputs like this, this is a lie and like I said before, in terms
of like longer forms and only asking the necessary questions, sometimes you have a large amount of
questions.
And this could be demoralizing just to see just a blank slate of a bunch of inputs.
So breaking it in to pieces allows users to easily understand that information and fill out all the
necessary inputs that they need to.
So let's move on to our next demonstration.
What do we have over here, so layout's.
Label applies to forms as well.
I've personally been guilty of this, where we have two columns now, form should always be a range
from top to bottom in a single column.
So it's easy for a user to read.
We typically read from top to bottom and left or right.
And this implementation makes me kind of wonder which direction I should start to fill the inputs to
go left to right or top to bottom and top to bottom.
So it's a little confusing just for users in terms of which way they should be filling out the information.
Like I said, this just copy paste that.
And we're just going to take these two inputs and just bring them right down here and there you go,
that's just much more easier to fill out.
And if users are tabbing through input's.
Like, if this is longer than where they are on the page, it gets confusing because the page could
be jumping around while they're tabi.
This just keeps everything really consistent.
They know that they're going from top to bottom, right down to the input, the button input at the
bottom.
So keep things consistent like that.
That's just much more easier for the user.
OK, buttons, these are your action buttons at the end of a form, and this is kind of up for debate
and I don't really sway either way in terms of placement of your buttons at the end of a form.
I mean, do have a preference.
I'll let you know in a sec.
Some people will argue that buttons should be left alone over here.
That's because we logically read from top to bottom and left.
Right, meaning that button will be right here waiting for you at the end of the form.
So if you're going to top to bottom, left or right, it's right there.
And it makes most logical sense.
But sometimes when you think about how we think about forms and proceeding to a next step, we generally
think about moving right as the next step and left us going back.
So this is where the debate kind of stems from.
So if this were a step within like a progress form, which has multiple steps, like three steps or
something like that, then sometimes I feel like if you were to click next, you would look for it on
the right rather than on the left.
Totally up to you.
I personally sway in the direction of having them left alone.
I do like them there just because I believe that it does logically help the user going from top to bottom,
left or right.
But it comes down to you testing with your users to so do that, make sure that whatever you have works
well and proceed in that direction.
Let's talk about the scenario we have here.
Another scenario we find ourselves in is that you may have two buttons like a simit and cancel.
And we have to make sure that both buttons are easily distinguishable to avoid the possibility that
a user clicks on the wrong button.
You can easily do that with a secondary button, and you should do your best to add micro copy whenever
possible and be descriptive with your button names.
So let's finish this.
Let's fix this up, so we're going to do is.
Go over here.
One thing I noticed, I'm going left to right, so one thing I did notice is that this is on the wrong
side.
So we're just going to bring that simit over and the council to the right first.
I'm going to fix the button here.
So this council is just way too late to the cement and I run the risk of having my user click one or
the other.
And that is a no no.
So let's just fix this up.
We can do is just have a second, everybody, so that is just easily distinguishable now and over here
we talked about having a better name for our copy or just a better copy for our buttons, just making
it more actionable and descriptive.
So this could be something like.
Perfect.
So this is much better than what we had before.
Let's take a look.
So here they are side by side.
We have a castle and segment on the wrong side, and they were too similar.
Now we can easily understand which one we should be looking and which one we could click if we needed
to.
So I'd emphasize the castle made the create account, stood out.
Let's jump to our next scenario.
So what do we have here?
So everything looks pretty good, right?
Remember how we covered long inputs and broke them out into different categories?
Well, sometimes forms are just too long that you need to split them into different pages entirely,
which is logical.
You don't want a user to infinitely scroll on one page to fill out a super long form.
And on mobile, we need to think about how we treat long forms.
We will probably treat them much more differently than we do on desktop.
So when you do this, you need to let the user know where they are within the flow and what they need
to do and how much longer they are to the end.
This can be done in a variety of ways, like there's progress, there's percentages and step counters.
We have this little form over here.
Right here.
And what we're going to do is we're going to fix this.
Let's take this out and let's just let's assume that this form is like step two of three within our
process.
I'm actually going to go back up and steal.
Sounds good.
So this password, I mean, you can just do.
We can remember that said doesn't really make sense and we can just say personal.
Information.
Let's just bring that down.
Actually, let's create a progress bar first.
So, like I said, there's a couple of ways you can do this.
I mean, I'm just showing you quickly and you could probably do a much better job than I'm doing right
now.
Here we go.
So there is progress bar that isn't very good.
OK, say this is step one.
Let's find a nice screen.
So that's about thirty three percent of the way.
And what you can do is you can make a little progress indicator.
Let's just bring down that size.
So you could do something like that where it just lets the user know that, hey, you are thirty three
percent of the way through so you can have that anywhere on your page.
You could also do like a combination of, like showing what steps they're in or which step they're in
within the flow so that I could look something like.
Let me just bring this out.
Oops, that's a little too late.
And I think I down 10 percent that that's good.
OK, so this is like kind of like a stepper.
And it could show something like.
This one could just say personal info.
And this kind of allows the users to just get a sneak peek at the type of information that they will
be asked in the future.
So there's personal information.
This could be like payment.
And this could be like shipping.
So this is another option, like I said, it's totally up to you and what you think is the best, like
what you've tested with what performs the best.
Another way to do this is to just kind of have a little stepper and this is usually like pretty much
all you need.
Most of the time I find you can do something like step one.
Of three.
So you could do something like that.
It just helps the user understand that, you know, if they're coming into this form, they have a good
understanding of how long the form process is going to be.
They don't want to be stuck in an infinite scroll and not know where to go.
It also allows you, if it's a really long form, you could implement some sort of save feature where
they could save at a certain step and they could easily remember.
So remember, if your form gets too long or if you're dealing with mobile, you need to break things
out just so it's just in bite sized pieces for your user.
So these are the best practices for forms and we'll jump into best practices for input's.