Usability issues and optimization of 4 UI elements in iOS

For reference, the thinking mode and even the spirit behind this kind of article is what you should learn the most, and the content itself is secondary; the more you read such things and the more representative product cases you experience in practice, the more you will find that design, in many cases, is neither bright nor dark, neither right nor wrong. There are only specific products, specific resources, specific situations, specific user groups, and all these factors mixed together, and there are various possibilities that need to be constantly weighed, strived for, or compromised. Let's get to the main text.

Large software companies, such as Apple, Microsoft, Google, etc., usually provide a series of design guidelines for third-party app designers. The purpose of doing so is to:

• On the one hand, designers and developers can more easily create products that at least meet the "basic standards" in terms of quality without having to rethink and verify new design patterns and UI elements.
• On the other hand, if all products on a platform follow unified design rules, users will also benefit from the consistency of interface appearance and interaction methods.

Complying with the design guidelines is almost an ironclad rule. However, in practice, the "official standards" may not be well applied to all situations. We don't know why some elements appear in the design guidelines. Maybe it's because the official testing is not thorough enough, or these elements and patterns are the most basic and applicable solutions to a certain type of design problem.

The four UI elements mentioned in this article are all used by Apple in its own apps, and some of them also appear in the official design specifications; naturally, countless designers will follow these usages. On the other hand, we (Nielsen Norman Group) have also found usability problems caused by these elements in usability tests again and again.

Maybe the Apple gods will strike us with thunder, but we still recommend that designers consider using these UI elements more carefully or try to optimize/alternate them, because these elements do have problems in usability testing:

• Page number indicator (small dot)
• Done button in the navigation bar
• Plus (+) icon
• Drag Icon

1. Page number indicator (small dot)

The page indicator of iOS is a horizontal row of dots, which are used to represent a series of paging views that can be browsed by swiping horizontally. Among them, the dot representing the current view is highlighted, and the others are dimmed and semi-transparent.

iOS system home screen, the page number indicator is used to indicate the total number of pages and the current location. We often see this example of using the system home screen to demonstrate the use of page number indicators. In fact, there are not many interface environments where page number indicators can be perfectly applied, and the system home screen is one of them, because users clearly know that their phones have many apps installed and the first screen cannot be fully displayed, and they need to swipe horizontally to view more.

Many apps or web pages use this element to suggest that users can view other pages of the same level by swiping horizontally, and some use it in specific areas of the interface to imply that there is more content. It cannot be denied that this form of page number indicator is very popular in the interface design of apps and mobile web, but it should be noted that it is also one of the interface elements that users are most likely to ignore. In a series of usability tests we conducted, users often found it difficult to find these dots that are too small in size, and then missed the content or function entrances that can be viewed by swiping horizontally. Therefore, we believe that page number indicators in the form of dots should at least not be used as the only way to navigate key functions and content.

Although iOS allows you to render these dots in other colors, it is still very difficult to make such a tiny element stand out in the interface at a glance, unless you can make sure it is placed on a high-contrast solid color background. Many products place dots on colorful banners, making these already difficult-to-notice elements blend into the background unconsciously, further reducing discoverability. If you must do this, you must ensure that there is always a high contrast between the dots and the background color, and it is best to use a solid color background.

Zappos for iOS. In the first image, the page number indicator is already very weak, and in the second image on the right, it is almost completely gone.

Some products have taken further liberties based on iOS, changing dots to squares or other shapes, and making the layout more casual. Imagine that even if users are used to the small dots of iOS, now even if they find these small elements in the interface, they have to guess whether these squares represent the old dots - the discoverability has not been significantly improved, and it has also caused cognitive difficulties. If you want to use page number indicators, try to use the dots that users are already familiar with, and center them below the corresponding content.

Fab in Android borrows the small dots from the iOS model, but places them on the right side of the content, making them harder to be discovered than if they were centered.

Even if users can notice the page number indicator, there are some potential problems here. For example, the dots can let users know how many views of the same type of information there are and the current position, but they cannot provide any information related to the content itself. In addition, users have very little control over the interaction. They must browse one by one in order and cannot jump directly. Therefore, if these experience elements are more important in your needs, then the dots may not be your best choice.

Given some usability issues with the dot page number indicator, we recommend:

• First, consider whether your content is suitable for browsing in sequence through horizontal scrolling, or whether it can be structured through other more complex and flexible navigation methods.
• For content that can be scrolled horizontally, try to expose part of the content on the right edge to strengthen the hint of "more" instead of relying solely on page number indicators.

2. Done button in the navigation bar

Many buttons representing "complete" operations in iOS are often placed on the right side of the navigation bar, including the submit button in the form interface. Now this pattern has also begun to subtly affect some apps on the Android platform.

According to the conclusions drawn from our usability testing, we do not recommend placing the "Done" button here, not to mention the cross-platform influence, just for iOS itself, for the simple reason that placing the final operation at the top of the interface goes against the top-down information flow. When users fill out a form or edit content, the interaction behavior is usually from top to bottom, and when they are about to finish, they also expect to see the end of the process at the end. In most cases, when people cannot find such a function at the end, they will be confused and start looking around.

#p#

In the following examples (Pinkberry on the left, Nordstorm on the right), after filling out the form, the user needs to click on the login or order button. This layout is what we call a top-down information flow. The user's full attention gradually moves down along the form, and finally finds that there is no completion operation at the end, and the rest is at a loss. You know, even on a small screen device like a mobile phone, it takes a lot of extra attention to look around for a certain UI element; placing the completion button directly at the bottom of the content is the most intuitive approach.

Of course, from another perspective, placing the Done button in the navigation bar also has its own advantages: because the navigation bar is fixed at the top, users can click it at any time when editing content, and when the content area is long, the button placed at the top will not be blocked by the keyboard. If users do not need to fill in all the content to complete the operation, then you can consider fixing the Done button at the bottom and it will move accordingly with the rise and fall of the keyboard. The disadvantage of this method is that it will take up a certain amount of vertical space, but the advantages are also obvious: it is intuitive and visible at all times, and it is easier to click with one hand than the position at the top right.

In view of some usability issues with the Done button in the navigation bar, we recommend: placing the button at the bottom of the content; if the content is long, try to fix the button position and prevent it from being blocked by the keyboard so that users can click it at any time.

3. Plus (+) icon

The more apps you see, the more you will find that the plus sign icon often represents different functions in different environments. When the plus sign is in the navigation bar, it usually means "New"; if it is placed in a list unit, it either means adding the content to a certain group or expanding the details. Whether in different interfaces of the same app or between different apps, the same element carries different functional meanings, which is a burden on users' cognition and memory.

The usability of the plus sign icon depends largely on where it is located in the interface. When located in the navigation bar, the plus sign usually conveys the exact meaning, that is, creating a new content of the same nature as the main content. However, when the plus sign appears in the main content, the possibility of multiple meanings may confuse users.

For example, in a previous version of Any.do, a plus sign icon was placed on the right side of the to-do group title. In this environment, you didn't know whether clicking this icon would expand all the items in the group or create a new item in the group. In the most recent version, they put the plus sign in the upper right corner of the interface, explicitly for creating new items.

Whether it is the web or mobile app, the plus icon in the interface content is usually used to indicate that the content can be expanded to view more information, and sometimes it is used together with the arrow icon. Using the plus sign to trigger other types of functions is likely to disrupt the expectations that users are accustomed to. For example, in the LinkedIn app, depending on the location, the plus icon nested in the circle represents the function of following or joining a group. In our usability testing, many users clicked the button with the expectation of viewing details, but found that they followed the other party's dynamics, and then felt puzzled.

Depending on the product type and target user behavior, the plus icon in your app may be most suitable for expressing a specific functional meaning. In any case, try to avoid using it everywhere in the app, because depending on the location, users can easily understand it as a different meaning, or operate with the cognition they have always been accustomed to, resulting in results that are inconsistent with expectations.

Given some usability issues with the plus icon, we recommend:

• The navigation bar is a relatively safe location, but using a plus button in other locations requires usability testing to ensure that users can correctly understand the functional meaning you want to express.
• To avoid the potential problems caused by the plus sign icon, it is better to avoid using it completely. Instead, use arrows to represent the expansion of details, and use simple and clear text buttons to clearly and accurately convey the meaning of other functions.

4. Drag icon

Like many other icons on mobile devices, the drag icon is not very intuitive to reflect the meaning behind it. We found that many users do not understand that this icon represents that the element can be dragged and moved, and the three horizontal lines arranged vertically can easily be mistaken for some kind of menu icon. In fact, this image metaphor is the anti-slip stripes on the draggable object, as if you can put your finger on it to drag the entire object without slipping. Usually, users need to long press this icon to activate the entire object, and then drag it to the appropriate position.

In usability testing, we found that users prefer to tap the object itself to drag it, rather than hold down a small icon with an ambiguous meaning. Compared to objects such as list cells, the icon is too small in size. If users are required to hold it down to drag the entire cell, the interaction cost will inevitably increase. In addition, users will also think that a cell as a whole will only trigger one behavior, that is, whether dragging the small icon or the cell itself, it can be dragged.

Yahoo! Finace uses the standard iOS drag icon, which users can long-press to make the cell draggable. Although the list cell itself is a larger, easier to operate, and more intuitive object, users cannot trigger the drag by long-pressing the cell itself.

Also, we have to point out that the drag icon is too similar to the familiar hamburger menu icon:

Objects that look the same or too similar trigger completely different events, which can be confusing. Although the debate about the hamburger icon is becoming more and more intense in the industry, more and more users have become accustomed to the mode of "clicking the three-line icon to expand the navigation menu". When they find that the results of the behavior are inconsistent with what they are used to and what they expect, they will feel frustrated and confused.

In view of some usability issues with drag icons, we recommend:

• At least allow users to long press the entire target unit to achieve the dragging goal, rather than limiting the interactive area to the drag icon.
• On the other hand, for the hamburger menu icon, you can try to make it clearer and more explicit, such as adding three dots in front of the three lines, or putting the “Menu” title next to the icon.

summary

Deviating from the "official" and "common" design patterns always makes people feel uneasy, and being consistent with everyone's patterns can also help users reduce the learning cost. However, no matter what design specifications you decide to follow, we recommend that you verify whether these patterns are really suitable for your own products and target users through necessary usability testing. At least, in our own research process, we have seen many users encounter usability problems in the 4 common patterns mentioned in this article that are enough to trigger our thinking.