Re-check with the include and exclude energy use history

[baipai]

Although the design below didn't showcase it, the original design/plans from a while ago included a visual where, upon entering this page, the system would automatically select the 'include' data based on calculations from the uploaded CSV file in the previous step. Users could then review the included data and manually exclude any if they desired, or if the system was unable to identify it.

During the discussion on 12/26, @plocket raised the question of whether it makes sense to indicate whether the data is automatically selected or manually adjusted by users.

The original flow is designed with the goal of aiding users in reviewing automatically included or excluded data. It does not emphasize marking the differences between automatic and manual data inputs, as the primary focus is on achieving 'the end result,' aligning more with human behavior. But, if it's essential for users to tell apart auto and manual data for decision-making, we might need a different approach.

Here are some areas/questions that we might need to clarify, and there could be additional points to consider. I sense there might be a difference in perspective between the engineering and design sides in this case. The functionality can occur in the background without necessarily being displayed in the design/front.

• How do automatic or manual data inputs affect users' decision-making?
• Would marking them differently produce different results?
• What's the goal for the users here?

[plocket]

I think that's a good point. Is it actually useful to the user to be aware of which settings are theirs vs which changes were automatic. After all, if the app needs to reset to automatic settings, it can just re-run the calculation. Maybe I was off-base on this.

[baipai]

Quick note:

On 1/2, here were several data conversations with the entire team (design, JavaScript, and rules engine), leading to the need to display distinct heating usage and non-heating usage (other usage) in the visual with override sections.

During the design meetings on 1/2 and 1/9, various options were explored, including color coding, icons, dropdown menus, and implementing a default button.....etc.

Aspects to consider include:

• What are the users' goals with this setting?
• What objectives are we helping users achieve through this feature?
• What's the default setting means?
• How will the default setting appear in the absence of any adjustments?

[baipai]

I think that's a good point. Is it actually useful to the user to be aware of which settings are theirs vs which changes were automatic. After all, if the app needs to reset to automatic settings, it can just re-run the calculation. Maybe I was off-base on this.

No, you are bringing out the right point. It's good to see the conversation happening among the entire team rather than on an individual level.

[baipai]

Copy from slack:

During 1/9 week’s design conversation, Steve mentioned that even though some UA numbers are similar to others (automatically included/excluded by the system), they are still excluded due to other reasons. This implies the necessity to showcase and differentiate them. Along with non-heating usage (other usage) and heating usage information from last week conversation, here are some questions to consider and clarify:

• What is the user’s goal with this setting?
• What are we helping users achieve with this?
• What does the default setting mean?
• How will the default setting appear if there is nothing on top of it?
• Regarding “non-heating usage” in the original Excel sheet:
• What happens if a user changes it to “heating usage”?
• Does this mean it is no longer considered “non-heating usage”?
• Are there any use cases for this change?
• Does it make sense to allow users to make this change?
• What occurs if there are errors or mistakes in the Excel sheet’s calculations?
• When I experiment with a real-use case and try to change ‘non-heating usage (-1)’ to ‘including heating usage (1),’ the number changes significantly. All other data is also affected by this modification. However, when I change ‘include heating usage’ to ‘exclude heating usage’ or vice versa, the number remains the same and is unaffected by the change; the only difference is whether it is included or excluded. So, I wonder, are we still allowing users to switch from ‘non-heating usage’ to ‘heating usage’ and vice versa? What is the goal behind this? or am I understanding it in the right way?

I’ve adjusted some possible designs based on the conversations below and figma, using the shadcn community components, and added notes about considerations for different approaches.

No matter how the final look turns out, just keep in mind the points I mentioned for the UI designs. And something extra for the UI, it should have almost the same design as the oil propane fuel type data history. They don't have a 'no-heating' usage type and a 'heating' usage type.