How to show better hierarchy for inter dependent fields in a table?

Question

[Might be an existing question, couldn't find a better match]

User scenario

I have a list view that shows column headers ( fetched from a separate table )

User has the following ability to do.

1. Can add custom columns headers to the existing list. Hence ideally we have two sets of column headers

   1. Column headers fetched from the table (let's call it exiting column headers)
   2. Custom column headers added by the user to the list view

2. Can change the data type of each column header i.e data type 01 and data type 02. Once set, the user is asked to set the data value.

Problem

For existing column headers, these are the possibilities.

1. Set data type or leave as it is i.e Preserve its default state
2. If "data type 01 or data type 02" is selected, prompt the user to set the data value
3. If the column header is of "Date type", Allow the user to show different options to format date type.

However for custom column headers,

1. There is no default state involved
2. The user has to select one data type ie. data type 01 or data type 02, then prompt the user to set the data value
3. The date formatting option is still valid for custom columns headers.

To some extent, date formatting is possible through "data type 02" but its not intutive. Hence I want to keep it outside of it.

What have I done so far

1. For existing columns headers, I am showing 3 values for the data type i.e default, data type 01 and data type 02. If selected default, communicating the user the value will remain as it is.
2. For custom columns headers, however, we have only 2 options to show i.e data type 01 and data type 02 since default state is not available. Hence this can be inconsistent. Should I differentiate the custom column header vs existing column? It does not add any value though.
3. Most of the time, date formatting will remain empty hence white space problems would appear.

How can I improve this experience better?

Answer 1

Some factors that you may want to consider when designing your table:

1. What problem or need is your table trying to resolve for the user?
2. Is it meant to be be responsive? (e.g. mobile) If yes, how should it behave under each scenario? Will its current layout/structure be affected?
3. Is there a clear indication to the user of the actions they can take? (e.g. saving)
4. Is there a clear indication to the user of how to avoid or fix a mistake? (e.g. undo a mistake or cancel an action)

Based on the above factors, here are my observations on your design:

• As a user, how do I know if any change I made is saved? Having a sense of control over an outcome might relieve uneccessary concerns. Even if the edit is automatically saved and a notification appears to the user: what happens if they want to change multiple rows - does the back-end system queue individual edits/updates compared to a bulk save/update? Could this affect performance in any way? (might not, but it's good when you design to be aware of such aspects too).
• How do I know if I can delete a custom column?
• What other alternative table formats have you tested and what did they reveal?
• Is the ability (on your current design) to compare column types at a glance an intentional consideration? Because if not, have you tried an expanded-view approach?
  
  1. With an expanded-view you could potentially just display the name column in the list as an identifier and all fields in editable mode could take place inside the expanded view, with an expanded/open default-mode, on the right-side (e.g. like an email platform).
  2. The expanded section could provide you with more space to display your dropdowns as radio-buttons instead (preferrable, considering you only have 2-3 options in your dropdowns).
  3. Additionally, it allows you to include options that might not be applicable in other rows (e.g. date) without worrying about potential "mostly empty" columns. That might help if you the product team has planned to include more editable options available in the future.
  4. However, this approach might also prove to be an overkill - you can only find out by experimenting with alternatives and testing them (even internally with colleagues from other departments, if your team does not have the budget for user testing), which at the end of the day could inspire you for a better solution :)
  
  Here's a quick example of what I meant with the expanded side-view:
  
  

P.S. If you didn't comment that the table you fetched this information from (let's call it Table A) could include 40-50 columns, I would have suggested alternatively whether you could test editing column-specific information directly from Table A - e.g. by clicking on a column title on the header, which could slide in a dialog box on the side or something to edit column-specific fields (similarly to the content inside the expanded-view approach).

Relevant articles: https://www.nngroup.com/articles/top-10-application-design-mistakes/ https://www.patternfly.org/v4/design-guidelines/usage-and-behavior/lists-and-tables