Recommended updates based on solution validation research for mass-integration
This issue contains update recommendations for UI design and copy for #208008 (closed). These set of recommendations have emerged from the solution validation that is now complete.
Recommendations
1. Microcopy
See details
The copy in the current design isn't clear and consistent when describing the possible states of a value. (i.e. when values are being inherited and overridden).
After walking through the flows many times myself and based on the feedback received from the user research, I have landed on the following terms to be used:
As an admin...
- I set default settings for all projects to inherit.
- I can see which projects are using custom settings.
As a project owner...
- I can see that my integration is inheriting default values from the instance level.
- I can set custom values and can restore the default values if needed.
To summarize:
- a default value can only be set at the Instance or Group level.
- a custom value can replace a default value from the Group or Project levels.
Also, when the terms “…settings are managed by the Administrator” were used on the project-level integration, participants had the impression that they were not able/allowed to override or change the settings, even when the input fields were intentionally left active and not visually disabled.
Instead, values should be specifically call out where they are being inherited from (e.g. Instance level values, Group level values) and avoid using the terms managed by and Administrator.
| Current (MVC-1) | Update (MVC-1) |
|---|---|
 |
 |
| Current (MVC-2) | Update (MVC-2) |
|---|---|
 |
 |
Copy top area and alert:
Default settings are being inherited from the instance level. Learn more.
Copy for help text for individual fields:
- Value inherited from instance level
- Using a custom value. Restore to default value.
NOTE: In the case where a default value is set at the Instance and Group level, the copy should read:
- Using a custom value. Restore to default value from: Instance level or Group level.
2. Layout
See details
The table showing the "Projects using custom settings" was preferred in a separate view. This also makes sense in terms of scalability.
| Current | Update |
|---|---|
 |
 |
3. Modal usage
See details
During the interviews it became apparent that the "Save" button on the configuration screen at the instance level was thought to be the final action that is taken in the task flow. Therefore adding a prompt for the user to make a potentially destructive decision after clicking "Save" was unexpected.
Because of this, I am proposing to remove that ability for an admin to override projects (or Restore them back to the default settings) that are using custom settings from this view. Instead, an admin should be able to perform this action in the new "Projects using custom settings" tab.
This way the primarily task of the "Settings" tab is for updating settings and the "Projects using custom settings" tab is for identifying the outlier projects and resetting them back to the default settings if needed.
In all cases the modal should be used as a confirmation, not as a place to make a potentially large, irreversible decision.
| Current | Update |
|---|---|
 |
 |
| Copy for modal confirmation: |
Saving will make these settings the default settings for 50 projects.
Any newly created projects will also inherit these settings.
Next steps:
-
1. Microcopy: All the latest copy updates have been added here. -
2. Layout: Update #218252 (closed) to reflect the new changes. -
3. Modal usage: Create an issue to adjust the modal (probably we can also remove some code related to the previous behavior). See Instance-level (Save confirmation) state Issue (#238628 (closed)). -
4. UI: Add control to restore all the values with one click back to the default on the project view. See Project-level (overriding) state.
