Never Mind What You Like…
Maybe you don’t like having two copies of the each metric, but what is the impact on user performance? That matters more than your gut reaction. Or, to put it another way, what are users using this data for? That will tell you the optimal way of organizing it. You already know that users need to see On and Off values together, so you immediately recognize that toggling between the two is no good for you. However, for a different app and users, where users are almost always just interested in one or the other, toggling makes sense –especially if 80% of the time they only care about one specific light condition (e.g., Lights On), which you make the default, and avoid confusing the users with the other light condition.
Merging Row Headers
So what are users usually doing in your case? For example, I suppose that if users need to scan down a list of metrics to find the one they need to set, then repeating the metric might make it a little harder to find the right one because half of what users scan is a “false alarm” (the same thing they read before and already rejected). If that’s among the users’ tasks, then merging the common cells will take care of it:
But now the user can’t use the grid’s controls to sort or filter the list on anything other than metric (e.g., if they want to see and compare only the Light On’s or Lights Off’s, or find the Target with the highest value, if that makes any sense). If that’s an important part of your users’ tasks, you may be better off keeping your original design.
Side-by-side Columns
Often things are put in tables for the user to compare values (e.g., see if Temp Max is higher than Hum Max) or scan down a column for a particular value (e.g., find a metric with a Target of 85). That’s probably not the case for you since “metric” implies different units of measure, so such comparisons wouldn’t be meaningful. However, you mentioned that users need to see On and Off at the same time. Are they comparing corresponding On and Off values? If so, your original design is okay, but, since this is a web app, with likely a lot of available horizontal spaces, you may want On and Off side by side, rather than over/under:
This means less scrolling to find a metric (table is half as high), and the user can easily scan for or compare Metrics on either On or Off values without having to sort or filter first. The user can also sort on a specific On or Off value (e.g., find the metric with the highest Lights-On Target). Are these capabilities helpful to the user in your case?
But what if users are more often comparing within a light condition? For example, they want to check how each Target is relative to the Min and Max. Then maybe it should be:
What if they do both—compare within light condition, but also On vs. Off? Well, you’re back to your original design, especially if comparing between metrics is not meaningful
How do users enter the data? Do they copy it from a form, report, or control panel? Then your organization should match the source. Is it just out of the user’s head? Then how do they think of it naturally? If they think first “The Lights On values need to be…”, then organize as immediately above (or like your original design). If they think first, “The targets for on and off should be…”, then organize like #2 above.
Graphic Attributes
As for non-tabular displays of these data, the main alternative would be graphic display of some sort. For example, slider controls can be used to show visually how the values compare to each other. Multi-slider controls could be used to emphasize (and enforce) that the Target must be between Min and Max (if that's a requirement):
The above is laid out to emphasize differences between Lights On and Off, as well as the how Target compares to Min and Max. Redundantly color-coding the sliders (yellow versus dark grey) helps, to some degree, compare a single Light condition across metrics. If your users more often compare across metrics than across Light conditions, then consider putting the Off/On sliders side by side.
As input devices, sliders are best when users are shooting for a “looks about right” value, rather than a precise value. If users are entering (or copying) a precise value, make the text values on the sliders editable, so users can enter the exact value easily and see the results graphically.
Is graphic better than tabular? Well, it takes more space, making it harder to scroll to and check or change a metric. Is that trade-off worth a better visualization of the values? How much are users comparing them or scanning for relations among them?
…Mind What Helps the Users the Most
No one design is inherently superior. Work out your users’ tasks and pick the design with the best balance of trade-offs for what your users usually do. As you can see, the best design might be the one you started with.
