Overview
The company sells the service in two ways: first, it has its customers and sells the service by itself, and second, the company has partners (providers) that sell our service, like as owners. Most customers (tenants) belong to the partners, who prefer to manage tenants similarly; therefore, providers asked to create multitenant management in the Settings area of the platform, which could give the same setting parameters to many tenants with one click.
The Problem
Inability to quickly manage settings of companies. Limited and closed settings structure focused on changing settings within units only.
The Solution
After deep research, I chose a convenient decision to separate navigation between “Company settings” and “Group settings”. I would use allegory from architecture, I created a kitchen (“Group settings”) that is naturally separated from a dining room (“Company settings”).
The decision allows the user to go to the separate area of the “Group settings” to create presets and assign them to different companies simply and quickly.
Also, the decision allowed us to save the current settings area, which is huge and complex. As a result, that preserved a lot of development hours.
My role
I took charge of the MSP Settings design, starting from the early stages. This involved gaining a comprehensive understanding of the intricacies of our current system, researching existing solutions, and creating prototypes. The result was a design prioritizing user experience and logical simplicity.
During the process, I worked alongside a Product Manager and R&D Frontend and Backend teams.
Personas and Interviews
During the last few years, the Customer Success team heard from providers that the platform has become huge, and they would like us to provide the ability to work fast and by click to spread the same settings to many tenants.
We defined our personas and started holding rounds of interviews. Sometimes, we returned to the same users to ask continued questions that became deeper. The last rounds of interviews were simple, with specific questions “yes” or “no”.
Research
Gaining access to the settings areas of large and complex systems is challenging. During my research, I discovered that the examples available were the same but tailored to the specific complexities of each system. While some examples were logically clear, others were not. This perspective allowed me to fully understand the importance of providing users with the ability to comprehend the hierarchical structure of settings.
The emergence of new requirements necessitated the creation of a new area that precedes the existing one by hierarchy. Now, users can create group settings in this new area, and then the settings group can be assigned to companies. The existing settings area will not influence group settings but will represent them. However, adjusting individual settings that do not belong to the group will still be possible.
The Salesforce settings work in the same way. The first level of navigation invites users to choose to create group settings or to go to work on specific company settings.
Design
We conducted several meetings with the Backend team to understand the system restrictions. Then we ran with the design. Each design step was shared with the R&D team.