In our application we have a customer/user tree structure. Depending on the role signed in a level of the tree will be displayed, where a Super User (SYSTEM) sees all and a Customer (eg. Ford) sees himself and all branching/nodes beneath him.

A customer node has two branches, one for its customers and one for its users. The image below describes it more thoroughly:

enter image description here

As you see, all customer nodes have the same structure, it has a Customers node and Users node. There is also a search/filter feature that will expand the branches to the node and select the node that is searched for. As a node is selected, a sheet to the right of the tree view will display a table of the node content and provide user actions such as "Create new customer" or "Create new user".


The problem though is that there is now no good representation of which nodes in the tree are customers and which are users, and also which nodes are merely branching/category nodes, such as the Users and Customers nodes. The only good feedback existing now is the communication of hierarchical relations, shifting nodes in and out depending on its hierarchical abode, which of course already is in the nature of tree structures.


I would appreciate some input in this matter.

  • How can I clearly communicate the structure of the tree and of what type a node is?
  • Maybe you've seen a similar tree structure that had a good solution to the problem?
  • If I'm to use icons, then what would intuitively differentiate a Customer-icon from a User-icon?

If you feel that you could provide any informative feedback or nice UX suggestions on either of these queries I have, I would greatly appreciate it.

  • It sounds like you might actually have multiple questions within this one. You may consider breaking them out on their own to simplify this one.
    – cdeszaq
    Mar 19, 2012 at 14:38
  • @cdeszaq hmmm... you may be right about that, especially considering I haven't gotten any feedback/suggestions previous to this one. Maybe it's hard to phrase an answer from this question in its current form. I'll look over it to see if I can breaking it up some. Thanks! Mar 19, 2012 at 14:45
  • Is there is a risk of circularity?
    – JOG
    Mar 20, 2012 at 10:43
  • @JOG you mean for example if Volvo could have Ford as a customer at the same time as Ford has Volvo as a customer? To my knowledge no, I don't see that scenario. Mar 20, 2012 at 10:55
  • Yes. Ok you might still want to test that nothing breaks if there is one, in the end. I just checked because if circular references were common, I would rethink using a tree structure at all.
    – JOG
    Mar 20, 2012 at 13:40

2 Answers 2


Looking at the image, a few things come to mind:

  • Flatten the hierarchy. Your hierarchy is deep, and (deep) trees are difficult to use
  • Your tree is unclear, because it repeats the same nodes at different levels. Get rid of the repetition. For me, it is not clear what this actually means. Are you trying to represent a network in a tree widget?
  • If you must use a tree, use one that uses visual hints to connect nodes of certain level. Can you really judge what the parent of your GM node is?


If I understand you correctly, you need to display a data structure of Customer nodes, where each Customer can have both Users and other Customers. Right?

One way to simplify the tree a lot is to get rid of the intermediary level you now have in your tree: the Users and Customers items. Because these repeat throughout the tree, they confuse more than that they help. If you put customers directly under other customers, the tree gets much simpler already. However, you will need a distinction between customers and users, of course. Use of a different icon and sorting the customers above the users in the tree would help. Compare how folders and files are distinguished in a file manager.


download bmml source – Wireframes created with Balsamiq Mockups

One step further could be to just separate the display of customers and their users, where you have the customers in a tree, and the users in a list next to it:


download bmml source

All this assumes of course that there are no circular customer relations, otherwise you end up with an infinite tree depth. If that is the case, you don't have a real tree hierarchy but a network, and perhaps you should display it as such then.

  • I like the pointers. I will look into flattening the hierarchy. You're right about it being hard to read, especially after a more levels are added. On you second point, this is one of the real problems. Each customer must display its user accounts and its customers (which will have to be able to display the same thing). And here's the problem, I can't really see how that structure can be withheld without repeating one self. The tree is not my construction, I've merely been assigned to iterate it's design to try and make it more usable. If we're not to use a tree, then what would you suggest? Mar 20, 2012 at 8:16
  • You have some neat ideas, I like it. Breaking up the Users and Customers category and displaying their content one level directly under the parent is not something we've really considered. That would simulate a conventional file browsing tree as you pointed out. But then there is that with the icons.. I suppose one could use Folder and File icons, at least that structure/relation of a tree would be recognized by most users. But would there a problem that there's no semantic relation between folder/customer and file/user? And no, the are no circular customer relations. Mar 20, 2012 at 11:05
  • I don't know enough about icon design to suggest good icons for your use case. I just used the default file/folder ones in Balsamic to illustrate a the point, but I think you do need something else. However, I think I would keep something that suggests that you can open it (like a folder does) in the Customer icon that you come up with in this tree, perhaps by overlaying a customer icon over a folder icon. Note that if you go for the second solution, it is not all that important anymore. Also, in many tree views, the [+] signs already indicate that a node can be opened.
    – André
    Mar 20, 2012 at 11:48

Maybe you don’t want a tree control. Tree controls are best for users editing the hierarchy to an arbitrary depth (e.g., like when creating and moving file folders). I don’t know what the user task is here, but here’re some possibilities:

UI #1. Known Entity Selection

If the purpose of the UI is to select a known entity (e.g., a customer) for further work, then trees can be an awkward way to make a selection, requiring the user “drill down” through a lot of irrelevant information. Consider a search dialog where users enter any subset of:

  • The entity identifier (or substring)

  • Whether it’s a user or customer

  • Who it’s a user or customer of

This yields a list of matches for your users to select. This is best when your users know what they’re looking for, e.g., an entity name ADMVO. They can type “ADMVO” into the Search identifier blank and get the desired result. No need to think, “who is ADMVO a customer of again?” Nonetheless, it can also be used when your users can’t recall the identifier but know the entity is customer or user of someone else and they will recognize it when they see it. I’m assuming your users don’t think in terms of multiple levels of relationship such as “I know the entity I want is a customer of a user of Ford,” or “I need to retrieve all customers of customers of users of customers of GM.” That just seems human-infeasible.

UI #2. Network Exploration

If the purpose of the UI is to explore and edit the relations among entities, the UI depends on the structure of the relations. Your example suggests you don’t have a hierarchy at all, but a network structure of relations. This is the case if a given entity (e.g., Volvo) appears on more than one branch (e.g. it’s customer of Ford but also a user of GM, and also maybe a user at the System level). I suspect you users will be confused by trees where the same “leaf” appears on difference branches –it breaks the tree metaphor.

UI #2a If your network is relatively sparse (not a whole lot of connections between entities), then consider a node-link diagram that users can zoom, pan, and filter. Arrowheads on the links can show who is a customer/user of whom, and the shapes of the arrowhead (e.g., hollowed versus filled) or lines (e.g., solid versus dashed) can code the relationship type (user or customer). A tool palette provides pointer-tools to add new links, and any link can be selected for moving or deleting.

UI #2b If the network is too dense for node-link (many interconnections), then consider a square grid with entities listed across both the top of the columns and down the rows. Entities in the rows are potential users/customers of entities across the top. Cells of the grid code type of the relationship between each pair of entities. Users can pan and filter the grid. Your users can select any cell(s) and change the relations through menu commands.

For both #2a and #2b, your users can select an entity and open a window for it showing its details (attributes).

UI #3. Child Comparison and Edit

If the purpose of the UI is to study and edit the attributes of the children (users and/or customers) of a given entity, then consider a master-detail UI with three panes. The top pane provides attributes for a single entity (which may have been selected using UI #1). The next pane lists the users and their attributes in a tabular layout, and the last pane lists the customers and their attributes in a tabular layout.

Your users can view, compare, and edit the attributes of the users or customers directly in the tables. Put the tables in expanders and your users can show or hide customers or users as needed, much like a tree allows. Your users can edit relations by cut/copy/paste of selected entities from one child pane to another (including another in a different window for a different parent entity).

As in UI #2, users can select any entity in either child pane, and open a window for details on that entity (e.g., who are its customers and users).

  • I really respect your effort. You give many good pointers. The solution we have is a a mix of UI#1 and UI#3. UI#2 doesn't really apply because the customers are unique and there won't be any editing of the node relations. I would say the UI you describe in UI#3 is along the lines of what we have. In addition to the tree there is a sheet to the right of it being populated with the data of the node that is selected in the tree. If a customer is selected then the details of that customer is displayed, if it's a "Customers" node then a table with the customers of the parent node is displayed. Mar 20, 2012 at 12:43

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.