hierarchy - How best to present origin in a hierarchical settings structure

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

country

--city

----street

------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?

Answer

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.

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.