The user is trying to select an element which will be used in a form. So it could be like selecting interests in an app where you can pick the more general case (e.g. sports) or the more specific (e.g. baseball).

I have hierarchical data where:
* Exactly one node may be selected.
* Users can select nodes anywhere in the tree
* Leaf nodes must be selectable
* Parent nodes may be selectable. Selecting a parent node represents a selection of all of its leaf node descendants.
* Selectable parent nodes are uncommon.
* The depth of the data is deeper than can be readily shown on the screen all at once.

I am developing an interface for browsing this data. This data needs to be usable on both desktop and mobile interfaces on the web.

I am thinking of modeling an interface after what Apple does with hierarchical menus, like the one below. The differences in my case are primarily that:
* The items can have three states: selectable node, refinable node, and nodes with both capabilities. How do I make this look uncluttered?
* My design must operate reasonably on both desktop and mobile. How do I design the refinement signifier in an unobtrusive way that is clear even on desktop views.
* My lists have a lot of heterogenous content. This happens only rarely in Apple menus, like the shut down button in the second screenshot. How do I show heterogenous content without looking disjoint?
iOS settings menu

Notice the blue row at the bottom representing differing content.
iOS shut down screen

What I've been thinking of so far is similar to the Apple design. These next two screenshots show the top level of the hierarchy here, and...
Top level of hierarchy

...the screen after food is selected.
Refinement of hierarchy

I like the multi-screen approach to this design for my use case, so I am primarily looking for feedback on exactly what icons/buttons to put in, and how to separate out content. I'm particularly interested in examples on the web and high fidelity mock examples, but I'm open to lower fidelity feedback as well.

The one structural thing that I think could be changed is in the combination case where a parent node can also be selected. Conceptually I've illustrated it here:
Alternate design to combination case

I'd like to draw attention to the fact that this makes the rows less crowded, and seem more homogenous. But I'm not sure exactly how to design the current level selection mechanism. How could I clearly indicate that the current level can be selected? Relatedly, how do I indicate the situation where the current level can't be selected?

  • Probably be more useful to under stand the use case for this design, what is the user trying to do? Commented Jul 17, 2019 at 8:38
  • The user is trying to select an element which will be used in a form. So it could be like selecting interests in an app where you can pick the more general case (e.g. sports) or the more specific (e.g. baseball). The hierarchy can get as deep as ~8 levels though. Commented Jul 17, 2019 at 8:43
  • And how many total, potential options? Can they select more than one? Commented Jul 17, 2019 at 8:50
  • They can only select one option. Selecting an option returns them to the form with the item selected. Commented Jul 17, 2019 at 9:37
  • 1
    8 levels deep to select a singular item could be quite a frustrating experience for your users, do they know what they are searching for? Commented Jul 17, 2019 at 9:47

1 Answer 1


Thanks for your comments, given what you have said, I would not use a tree hierarchy. As your users know what they are looking for and there is the potential for so many items, I would use a type-ahead search, that returns results as the user type and they can select the right one when it appears.

I suggested this for a similar query posted about a medical app, the idea is principally the same.

enter image description here

  • I realize now that I omitted this in my description, but the difficulty with doing a typeahead search in my case is that the hierarchy defines the items in my structure. I suppose that my example wasn't quite representative enough because it's actually more like traits. So maybe it's [music] -> [rap] -> [east coast]. People might not search "east coast" or think of it, and I don't have an advanced enough search to be able to parse something like "east coast rap" into the above. Commented Jul 17, 2019 at 10:23
  • I had explored showing the hierarchy of items, like saying "music -> rap -> east coast" and "music -> rap -> west coast" as the items in a flat list, but then it gets difficult to find the differences visually. And it could get crowded on small screens. Commented Jul 17, 2019 at 10:24
  • It's also probably important to mention that this is a best fit type search. They can find the most similar item to what they're looking for, not necessarily an exact match. Commented Jul 17, 2019 at 10:27
  • It'd be advantageous to work with the real data and understand what the challenge is. Commented Jul 17, 2019 at 10:32
  • Sure. I'm working with the USDA nutrient database, and generally would recommend the best fit data when people are selecting things. That is, if you have honeycrisp apples and the closest thing is gala, you'll want to just select gala because it's quite similar. Commented Jul 17, 2019 at 10:37

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.