The concerns are based on my own end-user experience with touch applications (both native and web SPA). Even slim and clean UIs may be prone to the same problem - the learning curve is gradual than desktop. It is always trial-and-error because there's no mouse to hover.

Despite the wishful thinking, graphic UI elements fail the expectations - no matter how good the icons are, it is not enough. And to be honest, fancy font-faced, lazy-bottomed flat icons aren't very good at explaining things.

The problem primarily affects smaller touch screens that don't have extra space for labels. But even big screens cannot afford explanatory i18zed labels on everything.

I'm considering two possibilities to improve UX of touch screens UIs.

Long press (all) / force touch (iOS)

Long press/force touch

This is the first thing I'm trying as a user to get a clarification on UI element because this is the only thing available to respectable hand-owner that has a chance to not perform undesirable actions.

In practice, this behaviour is very poorly supported (at least on devices that don't do 3D touch), to the point where it can be considered counter-intuitive.

Help-mode switch

Help mode

When 'help' mode is triggered with big red 'wth?!' button it can significantly lower the barrier to entry, especially in larger apps (much better than welcome tour in my experience).

The major problem with it is that there's no extra space on the bar. Moving the button to overflow menu (Android) would harm the accessibility, and moving 'help' mode switch to settings renders it practically useless.

Another problem is the layout. It may be painful to maintain a separate one for the mode.

I hope that the explanation is specific enough to ring a bell or two.

How do UX/UI guidelines cover this problem?

Are there acclaimed web or app implementations of the mentioned concepts? Do the other solutions exist?

Have 3D Touch affected UX trends and user habits in this context since its appearance?

A couple of illustrative examples may also help (in tech aspect I'm particularly interested in how this can be handled in common web UIs - Ionic & Material implementations, Bootstrap plugins).

  • In your mockups you seem to have enough room for the text in 'help mode'. Why not just show the labels? Commented May 29, 2016 at 21:22
  • @PixelSnader I didn't overload mockups with details to keep them clean, but let's assume that real toolbars are dense and we're struggling for horizontal and vertical space there (usually I do). Commented May 29, 2016 at 21:36
  • Then how would you show the labels in help mode? Either you have the space to show the text or not. =P Commented May 29, 2016 at 21:44
  • @PixelSnader That's pretty good question. The icons may become significantly smaller to stop vertical expansion, and the labels may be multiline (if possible) to not overflow horizontally. But in the end the layout is sort of a trade-off (one of the cons). Commented May 29, 2016 at 21:54

8 Answers 8


Assuming that you are targeting Android and iOS devices, you should try to use icons that are already known to users and popular among the Android/iOS ecosystem. For web, you could use Material Design Lite or Polymer to do the same.

You can see a list of icons following Material Design for Android here.

Now, if you have any icon that is not accurately represented in the above-listed icons, you should try to make one yourself. Be sure to follow the guidelines while creating System icons. This is to maintain consistency throughout the OS.

If the user needs an explanation for your design, it's mostly bad design.

As long as you can keep the icons grounded and close to the system icons which most of the other apps have, you should be fine.

Apart from that, only the Primary actions should land on the Toolbar itself. Limit that to 2-3 icons. These do not include any destructive action. First up, if the user has difficulty to comprehend on what the icon does, and then clicks on the bomb as shown in your mockup, it will lead to a negative action, which you wouldn't want for the user.

The secondary actions and the destructive actions should go into the Overflow menu.

Although your post suggests that you feel a Help button is a lot better than a Welcome tutorial, I beg to differ.

Navigation Drawer Reminders

It's better to feature a Welcome tutorial for a user for the first time since it creates a good onboarding experience and helps the user know crucial things about your app. The above example introduces a new icon: A finger with a knot. Is it easy to comprehend? No. But the tutorial makes it simple by referring it to as reminders and giving the user a hint as to what the icon means.

If you feel, however, that your icons are too complicated, you could have a Help section in the overflow menu and show a ListView of icons on another activity/page with a key-value pair of images and text.

I personally feel that you are overcomplicating the UI by stuffing a lot of icons when they aren't primary actions. Generally on mobile, the need for text is almost obsolete to showcase icons and it will simply make your UI less appealing for no reason at all.

As far as the icons in your mockups go, I'm sure you can find better ones to denote the actions. I like the Big Bang Theory references but I still do not understand what the icons might mean. Hence, try to keep it rather simple and consistent as per the OS' guidelines.

  • 2
    This is true in theory. In practice there's a little chance that the icon can be identified unambiguously by the majority of users at once. Especially if it is flat, and small, and unable carry much information. My favourite one is 'ball on the hill' icon. A single 'hill-ball' most likely means current user. That was easy. An icon with several hill-balls (group) means... what was the context? Can it be a... group of users? A contact list? In FB, this is 'friend requests'. We can blame FB for horrible UI, but at the end of the day we risk to find ourselves in the same boat. Commented Jun 5, 2016 at 14:13
  • Speaking from how I see Material Design do it, an icon should be designed well enough to resemble the shape of the object but not cluttered excessively to reduce its harmony. For example, keeping the icon too minimal may lead to several ideas about what it exactly is. Whereas detailing it to a great extent might make it visually not so appealing on smaller screen sizes. A compromise is what is needed. Commented Jun 5, 2016 at 18:30
  • What I feel is beneficial at these times when designing your own icons is that you could have user interviews/surveys and ask them what you feel the icon represents. If the answers are varied, improvise. These can be left open ended so that you get different aspects of what users might think and you could try to compare it with other users if they think alike or not. At the end of it all, the entire feedback can be used to remove the elements which might make the icon feel a little distant from what it is. Commented Jun 5, 2016 at 18:37
  • Another thing I would like to point out is the size of the icons in your mockup. It is essential to follow key-lines and metrics of the OS in order to appropriately fit in everything you need in the UI. In the mockup, the Toolbar is stretched out too far due to the large icons. You could easily fit those icons with a smaller size and it would still carry the same meaning. Look up for Metrics and Style in the choice of OS you are designing for. Commented Jun 6, 2016 at 14:20
  • 2
    Thanks for the detailed answer. Btw, 'not a pipe 'is a reference, too. Commented Jun 11, 2016 at 15:37

I've asked Your questions to our lead ux tester and she answered the next:

That is a very good idea - and also proved to be useful - to let the user turn on textual controls or function titles alongside icons on their wish and that is even better when this 'help' switch is available on every page consistently at the same place - but if You put it in the settings that'll work just fine, too.

Do not use 3D touch/long press to display local tool tip on buttons or other controls, since these might trigger real functions in other apps or even in Your app, and this would not feel natural/consistent to the user.

Divide Your user interface functions into fit portions ("pages") and do offer welcome tour on every page.

The worst thing You can do, if You do not provide any contextual help in any way.

I would add to her answer that we should always follow the appropriate guidelines of the publisher of the certain operating system.

  • 2
    "and this would not feel natural/consistent to the user." this simply is not correct, on Android long-pressing an ActionBar icon is the default gesture for getting the label of this icon, it works in every App that is using the default Android ActionBar/Toolbar. Commented Jun 6, 2016 at 8:51

There's a very good read from Aurora Bedford on icon usability: https://www.nngroup.com/articles/icon-usability/

and there's a section arguing that "icons need a text label":

To help overcome the ambiguity that almost all icons face, a text label must be present alongside an icon to clarify its meaning in that particular context. (And even if you’re using a standard icon, it’s often safer to include a label, especially if you slightly altered the icon to match your aesthetic preferences or constraints.)

It is true that some system icons and universally used icons can express themselves without a text label, for instance the hamburger menu icon, but such icons are rare - so it's reasonable to accompany them with text labels in order to avoid confusions, especially to first time users.

And I really think the text labels should be always on - sorry but IMHO both of your proposed approaches may not work well: users may not know they can long press the icon/button, nor would they naturally know there are two modes.

Finally I figure that it's not that terribly hard to accommodate text labels. Facebook and other apps demonstrate that it's okay to display text labels with icons, even in a relatively small area.

enter image description hereenter image description here


One solution would be to add undo buttons to every action. That way, users would become comfortable experimenting, with pushing buttons they don't fully understand. Once they tap something, the app would demonstrate the effects of that action, and give the user a better understanding than any tooltip would. At that point, if the button did what they want, they could continue on without skipping a beat, as if they knew what would happen. If it does something unexpected, they would tap the undo button, and have everything return to normal.

Such an undo button could take many forms. It could be a delete button, if the action created something, or a back button, if the action brought them somewhere. If the button was a back button, than the undo button would be a forward button. If the button was a delete button, than this presents a problem, as deleting can be hard to undo. In this case, you would need to present a dialogue before they're allowed to delete something.

The problem with force touch and other such solutions is that it turns one action, touching, into many similar actions. This can make it difficult to perform, as you might by mistake hold your finger too long or too hard and do the wrong action.

The problem with any tooltip based solution is that your tooltip will often provide too little information, or not the information a user was looking for. If the action might be irreversible, the user wants to make sure they understand it fully, which is difficult to do in only a few words.


If you need more space to show labels for the actions then I think it would be best to have less actions visible at one time and give them each enough space.

This would mean being very clever in two ways

  1. Knowing what actions the user is most likely going to use to have them visible (this might be different for different users, and might even change over time as the user displays their preferences for how to use the app).

  2. Let the user know that the extra actions are there and available without taking up too much space in giving that knowledge, and without making it too hard for the user to access them if they want. This is what the hamburger icon does. Another way that Google's material design has approached this is to bundle up a bunch of actions into the floating action button, so when that button is touched (or hovered over), the extra actions roll out of it.

Another thing I want to say is that your concerns are relevant for the first time someone uses an app, but after they've used it a few times I assume they would become familiar with the actions and not need any textual help for them - then for the majority of use-cases the text help is unnecessary clutter. That's why I think tutorial-style help is a great idea: When the user is presented with new controls, something pops up to explain what they do, then is never seen again and never gets in the way.


Try to stick with the mobile-os standards. On Android, long-pressing an ActionBar/Toolbar icon will show the label as a small pop-up in every app that uses the default ActionBar/Toolbar. I can't speak for iOS, but most apps on iOS i know use a permanently visible label below the icon. Please do not try to create a layout that fits different OS's if you want it to feel natural to a user oeprating his/her device.


I think you should go with help-mode switch because a lot of users are going to use it when they get lost and more advance users would understand the icons as longest is good iconography.

Don't rely in first screen tutorials because it is been prove people skip those all the time. no matter how many animations you add they don't work trust me

Force touch is a good idea but sadly only a few people knows how to use force touch. I did a small study and i found a lot of people never use it or they don't even know they have it.

That's my humble opinion


I'm sorry but icons simply aren't the primary content here. Icons are nice. Labels are good. Good labels are critical.

If there are so many buttons or controls that it's a struggle to include the accompanying text, then it's the structure of the layout that's at fault not the inclusion of the labels.

Take a step back. Lets say the labels are non negotiable - because that's your only way to communicate clearly and concisely to the user. The long press is now irrelevant and it doesn't make sense to have a toggle button to turn icons on/off.

So the only option is reduce or restructure the content visible at any one time.

As Susan Weinschenk says in 100 Things Every Designer Needs To Know About People,

If you have to make a trade-off on clicks versus thinking, use more clicks and less thinking

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.