I have this hierarchical structure. For simplicity & understanding's sake, let's call it a postal address:




------address #

--------apartment #

I need to provide settings to each apartment, but the data design allows a setting to be defined at the country level and will then "propagate" down to lower levels unless overridden at a lower level. So, a setting x could be defined at any level, but the one effective at the apartment will be the one defined closest in hierarchy to it.

So currently, I'm solving this by presenting settings together with an origin field: When a user selects an item in the hierarchy, any setting defined at that level or above it will also contain a field specifying where the setting is defined (example for one apartment being selected):

setting            origin                value
deliver mail       country (U.S.)        xxx
take out trash     street (Elm street)   yyy
wash the dishes    apartment # (3a)      zzz

This solution however confuses the heck out of my customer (the manager that ordered the app).

They simply cannot comprehend the design. To put it simply: they would rather enter the same settings for each apartment than deal with this design. They would rather copy settings among apartments than just fix the one responsible for the entire street.

Now, as the ultimate solution, they demanded an Excel export / import that would flatten the entire structure into one spreadsheet because apparently this (flattened) structure is what they can understand.

What better ways do I have to present this data such that my customers will understand it?

  • It would be much easier to help if you listed the use cases. The fact that data model allows something to do should have 0-implication on the UI. UI satisfies only use cases and the implementation should follow the UI design as much as possible. That said, I guess, the best answer is posted by octern below. Knowing the use cases might help to provide more responses.
    – mikryz
    Mar 10, 2016 at 0:17
  • Well, basically the use case is listed in the second paragraph just below the postal address "drawing". Perhaps the wording is wrong specifying that "data design allows..." instead of "some settings need to be declared at..."
    – velis
    Mar 11, 2016 at 14:58

4 Answers 4


It sounds like you're offering an affordance that the users would benefit from, but you're explaining it in the terms that make sense to you. Rather than using the concepts of propagation and hierarchy, I'd set it up to use the more familiar "apply to everything like this" pattern, which commonly shows up in applications and OS functions.

OS X "open with" option shows an example of "apply to all" functionality

Your presentation of the feature would sound something like this:

  1. Here's the interface for entering an apartment.
  2. Here's how you can set a setting for the apartment.
  3. Look, there's a neat feature where you can select the city, enter a setting, and press the button marked "apply to all apartments in this city."
  4. Don't worry about losing settings you already put in. The program will ask whether you want to change the settings for every apartment, or only the ones where this setting is currently empty.

This is less elegant from the backend. Rather than a CSS-style solution where multiple settings exist and are ranked by specificity, you would walk through the hierarchy at that moment and apply the setting to each individual apartment. It means more work for your users because the new setting won't become a default for new apartments added within that hierarchy.

However, it sounds like this would be much less cognitive work for them, because it's more in line with their expectations and doesn't require them to learn how to think in terms of inheritance. If they're pushing back this hard against your current proposal, then this might be a good compromise.

Another point is that your "settings" look like things I would call "tasks" or items." To me, "setting" refers to a configuration option. You might want to see if this is causing additional confusion.

  • Actually, I like this idea very much. I'd probably do the "aply to all children" operation such that I would delete any existing settings defined in them. This way the actual data structure would remain same as it is right now, but the customer would work the way they want to.
    – velis
    Mar 10, 2016 at 8:07

My first thought would be stealing a page from Google Dev Tools view of CSS style hierarchies. It was designed to show the exact same thing, all the applied settings of an elements ancestors in order of scoping precedence. To do this they simple list this they simply list the settings starting with the applied setting (highest specificity) followed by the inherited settings from all higher levels crossed out.

enter image description here

Now obviously this exact design is very technical and bare, it would have to be adapted and cleaned up. But you can quickly and easily see that the blue setting at the apartment level is overriding the state level green setting and the country level red.

  • This is indeed a good solution, but I'm afraid it caters specifically to developers. We understand data hierarchy and I believe my current solution is not very far from this one.
    – velis
    Mar 9, 2016 at 19:34
  • @DasBeasto do you have a suggestion for cleaning and adapting it? I have similar concern with an application but I can say my users are rather technical so they can understand hierarchy and inheritance. Yet, I cannot use this design as-is.
    – Assimiz
    Apr 18, 2016 at 7:20

Either hardcode default values for each or add a "setup" page to allow the user to do so (i.e. deliver mail=xxx, take out trash=yyy, and wash the dishes=zzz).

When viewing an apartment, list each with its value and some indication of the level the value was override. While I use text below, consider using an icon, and consider leaving blank if using original default value.

  • deliver mail: xxx
  • take out trash: abc (overridden at address level)
  • wash the dishes: zzz

If the value of "take out trash" is clicked, a dialog is displayed. If the value or the "empty" indicator (I am using --) on the dialog is clicked, allow the user to inline edit it.


  • country: yyy
  • city: xyz
  • street: --
  • address #: abc
  • apartment #: --

It depends on the amount of customization required by the USER.

  1. If the customer requires high level of customization even for the lowest level, then a tabular approach which is already presented serves the purpose.

  2. If there is low level of customization i.e. few exception at the lower levels then a grouping approach for hierarchy has a benefit. An example for implementation is as attached. An excel based tabular approach might not be that convinient. Sample XML file

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.