SYSTEM NOTICE

Auto translation by AI. Be sure, accuracy, nuances and authorial intent may not be fully reflected.
見出し画像

Text Fields - UI Design Checklist

crage株式会社（くらげ）

Hello. I am Nancy from the design team at crage Inc., a creative group that creates "new values" based on design, engineering, and direction.
At crage, we have a UI design checklist that we use to verify designs as we create them.
Because we adapt flexibly to each project, we do not consider this list to be absolute at all times, but rather provide it as a guideline.
This time, I will introduce the "Text Field" checklist. *Updated February 17, 2023

Please note that we plan to publish separate checklists for screens and UIs with many items to be careful about within text fields, such as member registration screens and search forms. This time, the checklist covers items that apply to most text fields.

If you feel like "there is something off about our company's UI...", please also make use of the free sessions currently being conducted by crage also.👇
👉 Click here to apply for the UI/UX issue discovery session

▼ Click here for the login page UI checklist

▼ Click here for the member registration page UI checklist


✅ Common Checklist

Is that text field really necessary?

Are you providing too many text fields because you want to know too much about the user?
Please think once more about whether that information is truly necessary.
I think it is often necessary as a requirement. In that case, please organize whether it is "required" or "optional" and make it clear what information the user can skip entering.

Is the font size appropriate?

For SP (smartphones), is it 16px or larger?
If it is smaller than 16px, the screen will automatically zoom in when you focus on a text field in iPhone Safari.
It is possible to avoid zooming on the implementation side, but my impression is that we often receive feedback that it will zoom if it is less than 16px.

Is the heading (item name) clearly visible?

Is it clear what the text field is for?
If you are using a placeholder instead of a heading to convey what the item is, be careful not to let the item name disappear when you focus on it. For example, you can use techniques like text fields like Material Design (Material 2 might be easier to understand because it has a demo).
However, in this case, it is important to note that the placeholder may not be read by screen reader software (screen readers read the <label> element).

If you are using a placeholder to convey what the item is, be careful not to let the item name disappear when you focus on it.

Image citation: Text fields – Material Design 3

For English headings, is only the first letter capitalized?

Headings that are all uppercase are difficult to read because the heights become uniform.
Capitalize only the first letter of the word.

Does the placeholder text support user input?

When entering text, the placeholder disappears. Be careful not to use placeholders as a substitute for labels. It is sad if the placeholder disappears and the user no longer knows what to enter. If there is no confirmation screen flow, the user will not know if their input is correct unless they delete it.
Also, the content can be things like the following. It is great if you can use them properly according to the use case.
・Content you want them to enter (Last Name, First Name, etc.)
・Specific input examples (Kurage, etc.)
・Content you want them to handle (Search Google or enter URL, etc.)
・Questions (What would you like to ask?, etc.)
I think usability is often influenced by placeholders.
Consider using Hint text or Supporting text separately from labels and placeholders as needed.
Note that the Apple Human Interface Guidelines do not have items like Material Design's Supporting text, and indicate in the guide that it should be placed on the text field like a placeholder.

Is the height appropriate?

The way of thinking is the same as for buttons. The criterion is "is it a size that is difficult to press with a thumb when checked on an actual device?"
By the way, it might be easier to find height and size in the accessibility section of each company's guidelines rather than within the text field section. This is because the idea regarding size for buttons and icons is also "whether it can be tapped or not."
In addition, the guidelines you want to refer to are specified as follows.
・Material Design → 48 x 48
・Human Interface Guidelines → 44 x 44
・Web Content Accessibility Guidelines → Minimum size is 44 x 44
However, in the case of things like search, once you focus on a text field, the main use case is that the user only touches the keyboard until they finish the series of actions. I sometimes feel that the height of the iOS search window is narrow, but I think the reason it doesn't become a problem is that there are few use cases where you keep touching the text field itself.

Have you prepared the states?

Have you prepared each state? For large-scale projects, I don't think it's necessary to create each state for every screen; specifying them as components should be fine (as tools like Figma make it easier for people in any role to view and check design data, having identical-looking screens lined up can make it difficult for non-designers to distinguish differences, makes it harder to find the target screen, and also makes the data heavier).
- Default
- Hover
- Focus: State while inputting
- Active: State after input, when focus is removed
- Disabled
- Error: Include an error message as well

In the case of an error, is feedback provided immediately after input is completed?

It is better to display form validation (the process of providing feedback to the user on whether there are issues with the input) at the moment the user finishes entering the text field and moves to the next input field.
I sometimes encounter forms that display errors while typing, but this can break concentration, make the user forget what they were trying to input, or cause them to panic to fix the error.
However, displaying it only after the 'Submit' button is pressed is like telling a user who has worked hard to finish their input, 'Submit again!' If it were me, I would think, 'You should have told me sooner...'
Also, when providing feedback to the user, you must not delete the input information without permission (details are explained in 'Have you specified the retention of input information?').

Is the error message written so that the user understands what needs to be corrected?

If form validation cannot be performed on the client side, make sure the areas that need correction are clear.
Being told 'There is an error in your input' doesn't help when the submission won't complete; I already know that.
Try to highlight the areas to be corrected or display common mistakes as messages to provide hints for correction, and be conscious of 'supporting the user's input' rather than 'throwing errors back at the user'.

Are the validation conditions clear?

If there are implementation requirements, such as phone numbers being numbers only with no hyphens, is that information communicated?
However, ideally, it is much kinder to not set restrictions on input information and accept anything.
This is because the user can change it themselves later, and things like whether a phone number has hyphens or not are merely conveniences for the service provider. Please appreciate the users who have worked hard to reach this point.
That said, there are considerations for implementation, maintenance costs, and delivery, so it is not absolute. While discussing the design with stakeholders, keep the perspective of User-Centered Design (UCD) in mind.

Have you specified the retention of input information?

Have you ever experienced having your input content disappear because you reloaded the page by accident or switched tabs out of curiosity?
It's sad, isn't it? You shouldn't make users feel that sadness.
Unless the user presses a button like 'Clear All' or 'Cancel', you should basically never delete the input content.
Since it is difficult to specify this with design data alone, be sure to include supplementary information regarding the behavior of 'what you want to happen' so that stakeholders can understand.


✅ For numeric input only

Is the input format more appropriate than a stepper, dropdown, or radio button?

What kind of numbers will be entered into that text field? What are the user's use cases?
Each UI has its own merits.
Consider combinations, including each UI + input format.

Does the input content ever start with 0?

If it starts with 0, even if you use <input type="number"> to input, the 0 might not be reflected.
Example) Input: 0001 → Reflected: 1
Consult with engineers to select the UI.


✅ For phone numbers

Is the phone number information really necessary?

We live in an era where we can communicate without phones. Even if a user has a phone number, they might not use it. Anxiety may also arise about whether they will receive phone calls.
Also, formats differ by country.
Check the requirements to see if it is truly necessary.

Is it set up so that the presence or absence of a "-" (hyphen) does not cause an error?

Users will likely copy and paste their input. Let's aim for a generous UI that accepts whatever they enter.

Is the numeric keypad set to display?

<input type="tel"> Using this won't guarantee it, but it will display a "numeric keypad" on smartphones. Since the numeric keypad does not have a hyphen, it reduces user anxiety about whether they should include one or not, and it should also make data cleaning easier. If you specify

autocomplete it may suggest previously entered phone numbers, allowing for completion with a single tap.


✅ For currency amounts

Is it set up so that the presence or absence of a "," (comma) does not cause an error?

There are many use cases where users are conscious of entering currency amounts correctly. Therefore, they will often copy and paste their input. If they have to edit the pasted content, there is a high possibility that they will enter a value different from what they intended. Even though the user is being careful, you should not force them to perform actions that lead to input errors.

Are decimal places, such as in dollar notation, not added automatically?

$10.00 and $1,000. These are two orders of magnitude different, but it's hard to tell at a glance. To ensure the user doesn't end up with an amount two orders of magnitude larger than intended, avoid automatically displaying decimal places.


✅ For passwords

Is the entered password replaced with "*" (asterisks)?

In reality, I don't think there are many use cases where someone is secretly peeking at the screen. However, to eliminate user anxiety, and so that previously entered passwords can be instantly recognized as passwords when displayed as "*" (asterisks) by input assistance features, keep the password hidden as a symbolic convention.

Is it possible to toggle visibility?

You should include a feature to display the password. This is because as users are required to create stronger passwords, the likelihood of input errors increases. Allow users to check for errors before they press the submit button.

In that case, it is safer to provide the visibility feature via a checkbox. The "Show/Hide" eye icon is ambiguous for users who want to set the display before entering the password, as it is unclear whether pressing the icon will show or hide it.

Are the password creation rules explained?

It is disappointing to return an error after a user has gone to the trouble of creating a password, only to then explain, "Actually, there are these rules..." Make sure to explain the password creation rules in advance so the user can understand them.

When registering or changing a password, a single input is sufficient

If you allow users to toggle password visibility, they can check if they made a mistake, and if you provide a password reset feature, they can change it later.
Always keep in mind to minimize the number of input fields as much as possible.

Is it possible to paste?

Sometimes you come across sites that don't allow pasting. This is a poor experience for two reasons.
1. A behavior that is always available (pasting) could not be performed. Unexpected, irregular behavior places a burden on the user. Let users use their devices as they always do.
2. The stronger the password, the more likely it is that users will copy and paste it. If they cannot paste, users will be tempted to use simpler passwords.

✨ Options

Add icons

It makes it easier to understand what the text field is for, which is convenient 🔍

Clear input button

This allows users to delete the entered text in a single action, which is convenient.

What is the best control (keyboard, etc.) for entering that text field?

For phone numbers, you definitely want to display a numeric keypad... Similarly, there are keyboards tailored to each text field.
However, users are accustomed to the controls in the environment they always use.
Rather than specifying them arbitrarily, you might want to talk to the developers about <input> elements so that controls appropriate to the user's environment are displayed.
Once you try out how to use <input> elements and sample code on a device the user is likely to use, it will be easier to get an idea of how it works.


📝 Reference articles and books

Guidelines

Regarding height

Regarding field names and placeholders

Regarding types of text fields

Others


🗣 Casual talk

The difference between "forms" and "text fields"

  • What is a form?

    • It is something where users input information and send that data to a server.

    • Therefore, strictly speaking, checkboxes and radio buttons are also "forms."

  • What is a text field?

    • A form that allows for only a single line of input.

    • Those that allow for multiple lines of input are called "text areas."

      • To ensure users can input comfortably without needing to use resize, carefully consider the expected character count of the content and determine the default size accordingly.

        • Forms themselves are a UI element that places a burden on the user. Because of this, they are prone to abandonment. Do not neglect careful attention to detail.

      • Note that in the Apple Interface Guidelines, these are referred to as "Text views."

The difference between 'forms' and 'wizards'

  • What is a form?

    • There are multiple input fields on the screen

      • The order of input is free

  • What is a wizard?

    • Step UI, also known as a stepper

    • Benefits

      • Allows for branching to subsequent screens based on the steps selected by the user

        • Reduces the user's cognitive load by eliminating the need for them to determine which fields are required or optional, or to select input items

          • Allows for a certain degree of personalization

      • Reduces the user's information processing cost because there is less information on a single screen

        • Forms known to be long can be discouraging. It is also a matter of sentiment.

    • Drawbacks

      • Some users may feel anxious because they cannot see an overview of the entire form

      • Depending on the situation, users may need to remember information from previous steps

      • Users must press a button to proceed to the next screen after each step of input

  • Reference Articles

🔖 Find other design checklists in our magazine


🗣 Do you have UI/UX concerns? Why not review them together from a third-party perspective?

Even when using UI improvement checklists like this one,
do you ever feel frustrated, thinking "I don't know where the problem is" or "Something feels off, but I can't put my finger on it"?
At crage, we are currently offering a complimentary 'UI/UX Issue Discovery Session'. We are currently accepting requests.

  • Verbalize issues while reviewing UI that concerns you

  • Objectively organize improvement points for your own product

  • Duration: Approx. 60 minutes (Zoom)

  • No deliverables, verbal feedback format (completely free)

👉 Click here for the application form


Why not join the crage team?
crage is currently looking for new members.
If you are interested, please apply!

We are looking for new talent.

Click here for the design team page


いいなと思ったら応援しよう！