You should ask yourself what are they going to do with this data. In general a table is not a very convenient way to store data - a form with a custom-made layout is usually a better option. Data tables are useful for working with this data - comparing it across rows, sorting, filtering, bulk-editing etc. When a cell holds a lot of information usually it's a good indication that none of these use-cases apply, since you can't really do any of them on large chunks of text. This in turn would mean that you don't really have to place all of this directly in the table cell itself, and you can consider aggregating this data. For example, you could say "10 agencies" with a hyperlink formatting, and then display the list on hover. Or you can show the first 3 or so items, and then say "7 more". Or you could have a sidebar showing this info on the selected item. I would examine whether this data really needs to be at the user's immediate field of view.

Since you mention that this is a grid/ table experience you are designing for, sorting a column by filled/ unfilled cells would rearrange the rows in the table as well. If multiple columns have empty cells your problem might not be solved by either of these 2 approaches. I would suggest that if identifying the empty cells is so important, then highlight them by default, or have a checkbox to highlight them.

Consistency can be found in many aspects of a design. When one table needs a click to sort it correctly, it breaks consistency with the other tables that are automatically sorted correctly. Unless the table contains the same data as the others there is no need to keep it sorted the same as the others as long as you can assure users know what they are looking at. So make the sorted column the prominent one by either making it the first column and/or add arrow icons, a background shade or borders, whatever suits the design. With useful sorting and clear visual cues you're doing your users a favor. If you have no control over the design, it is a matter of testing. See how users react on both situations for the table and decide what is best based on that data.

What do the users assume? I would be quite confused if I select "vegetables" (if that is a category" and still see the different meats. But I am only one and a designer, to boot. Please test this with new potential users. Design a prototype where the second column adapts to the selcetion of the first and again test this with new potential users. Think about animations or other design "tricks" that clarify the dependency. Of course, you have to consider the existing users who are already used to the established way. In my experience, if the new way is more logical and easy to perceive, users will adapt quickly (there will be some resistance, though) Established users are used to how the table works, but usually you always have to consider new users as well. If the established design does not work well, the onboarding of new users is more difficult, it may even cause resistance. You have to weigh the costs of keeping the design and changing it. Having test data will facilitate a good decision.

I would recommend only showing the scrollbar on hover and having sticky columns that allow the user to still see which rows are relevant. Adding a shadow to the sticky column will give the impression that the columns are scrolling beneath. I think having the scrollbar at the bottom is fine as long as the table is not taller than the window. If it is taller then maybe also consider making the table scrollable vertically. example:

It's also not clear to me. There are two mixed concepts: setting and editing. If you don't clarify these two options, either together or separately, the concept of editing will never be clear. There is the edit/settings icon but I don't think it's entirely clear. On the other hand, in your app I think the option to edit is not mandatory, the user can only access it to view. Icon from https://stock.adobe.com/ee/search?k=edit%20icon&asset_id=234382730 I know that it may not be the intention, but the most accessible and understandable option for any type of user, even though the modal window is editable by default, is still to include the edit, save and discard changes buttons.

Without reading your options this is what I went with in my head: 1st flow (image below): Adding icon "open in new" Quick View opens by clicking the item Subpage opens by clicking the icon The fact that you have the "quick view" should mean that it will be used more often than the subpage thus should be accessible via the simplest action - click. Otherwise there is no point for it and just use the subpage only. You can just implement this way and add some anchors to count the actual uses of both actions. See how many users actually open the quick view and how long they stay there (measure time between that click and the next one on some other action) versus opening of the full page. You can also use A/B testing if you have the capabilities in your feature flag system and see which way is better for the users.

Leverage common patterns whenever possible; users come to your application with lots of shared patterns from other sources. The form above (current) approach: Is there a specific reason to use a vertical pattern? Going from detail to list vertically tends to confuse which elements are grouped together. We often approach a list first for what's already present, then make decisions as to Add a new item to the collection, or edit / delete what's there already. Since most desktop viewports are wider than tall, making a vertical add pattern tends to be confusing for several reasons: The value of the list is to show all elements already created, and to quickly search for a particular item or value. Putting the list below the list will push down some of the elements. The action buttons such a Take It and Clear Fields look like they belong to the table (which is a common pattern) There's also not an obvious way to abandon an edit. 'Clear fields' is different than Cancel. There needs to be an exit that reverts any edits to the pre-edit state. 'Cancel' is a common label for this. A list detail pattern on desktop using a panel Try honoring the list and provide a quick way to edit in place by using either a dialog or sliding panel. It's a common way to add or edit items in a collection. The panel comes in from the side when editing or adding a new item: Now if there's a sub object (the conditions), focus their attention by drilling into a condition detail:

I think the Labels Column is the bigger culprit. If you can shorten it and then show beneficiaries as different colored round avatars with the first letter of their names in them. Hovering over them will show the full name in a tooltip.

If the symbols used in a graph provide perceptual meanings that can be misleading, there is no possible solution except to eliminate them or find graphical alternatives. Two solutions: 1 - Reduce the level of relevance in visual perception of the symbol by contrasting size and / or color so that it loses its meaning in reference to the number and becomes its own entity: If the design of the symbols is systematized, perceptually they can be interpreted as part of the same graphic group, separating them even more from their meaning in direct relation to the number ( https://www.interaction-design.org/literature/article/the-law-of-similarity-gestalt-principles-1 ). 2 - Redefine the graph's metric symbology using other types of symbols to represent worst / best. Example with alternative font: Example with https://www.toptal.com/designers/htmlarrows/ : ←1 –––––––– 0 –––––––– 1→ Example with https://www.w3schools.com/charsets/ref_utf_geometric.asp : ◄ 1 –––––––– 0 –––––––– 1 ►

It looks like you need to change the controls. Name doesn't really indicate what the button does or should do. Give a button for each column with meaningful names like column headers. Replying to JonW's comment: The buttons would function like column headers in a data table. They both label the columns and control how they're sorted. If you're sorting columns in a list, it's like a data table. Here it is with the Item button hit so Items are listed in descending order:

Whats in the data table? phrase, sentences, loading bars, integers, user defined names, etc.? Each of those require a different amount of minimal space to discern. I'm assuming it's names or phrases. If this is the case, then the column width should not collapse further than the width of the column header, or even the expected string length. In most cases, you will come across data in a table that requires disclosure, like a long name or a description. In this situation it's more important to design around how the user can read the full value if the string when the data is truncated (EG: tool-tips).

Try baking the constraint into the table header, and have an interaction when a user changes the 'X' per type. I don't know how frequent a user will be configuring this, so you could use the table header to explain the constraints (the what); if more explanation is needed, use the info tooltip to tell them the why. You can pair that with some feedback. When they select the dropdown to YES, a label appears, telling them what type this is the X for. This way the column sort can show them the YES's in a row, plus labels for each type represented, which is helpful if you have a decent amount of types. Scenario: each type must have an x before proceeding If selecting an X for every type is mandatory, you can pop a warning message above the table that tells them they must select an X for Type C. Testing: try a version with proximity for Type and X If you have many columns, one thing you can try is to place the related columns next to each other, to cut down on the scanning.

The reason the Size column is shown in your examples is because in some cases, there will be items with sizes. A user might drop a file into the folder, which would have a size. If the Size column were hidden sometimes, the user might wonder, "Is this because there are no items with sizes, or because the system has a bug?" If there will never, ever be a value in the Size column (for example: a user preference to not show size) then hiding it would make sense.

Why don't you provide both? You might want to shorten "View details" into just "view", "more" or "details": "EDIT" shows the modal in edit mode, "DETAILS" shows the modal in view mode with the edit button present, just like in your examples. Having two links and a same modal with a view and edit mode is not redundant, it adds affordance. A user has to know what each record has to offer: More details and an option to edit. Adapt to the path the user takes Is a user curious what more information there is, then show a readable view of the information. Does that user want to edit from there, provide a button to edit. Is a user directly interested in editing the information in the table, then allow to open that view in an editable mode. So your ideas A and B are good, you just have to combine them.

Based on the screenshot, the hidden content is only information about the item column, it's not selectable nor does it modify any of the subsequent columns. Consequently, if the expand button only expands info below a single column of the table item and is just information, it doesn't make sense and creates confusion to place it at the beginning of each row. The expand icon should be only where there are elements to display:

It looks like you're designing to help the user compare classes of life insurance and make a decision on which one to select. In that case, the user is likely going to want to compare specific criteria side-by-side. You might try a comparison grid, like this: Bear in mind that it's tough for anyone to compare 20 items - we humans usually can only handle about 7 or so before we start to struggle. In the cases where there are more options than that, you might want to look at grouping items together based on criteria that is most important (such as Plans for People Over 55, or Payout Amount Over $1 Million). Those can have their own tables. Filters are really good, too. You can display everything in one view, and then let the user decide ranges and other criteria that will narrow down their options.

If verifications in your system are expected to produce as many false positives as true positives, a three-state selector would be appropriate (like the Holly's Coffee example in another answer): Unknown (Default state) | Correct | Incorrect If false positives are an exception and are usually rare, a better pattern would be a flag. Since verifying items is optional, perhaps there is simply a "Mark as invalid" option somewhere in the row actions. Invalid/false positive rows can then be treated differently - red text, moved to another table, different status, etc.

Did you check the https://demos.shieldui.com/web/grid-grouping/grouping and https://demos.shieldui.com/web/grid-multiple-groups/groups-aggregates functionalities of other products?

I would build something like a partitioning UI. If that is not in scope, you can always switch the percentage inputs in your table with dual range sliders. Then I would add validations that highlight the row if two sliders overlap.