How to design and implement a feature to accommodate the organizational structures of distributor agencies?

While determining the most suitable customer profile for Ordr, we identified the distribution sector as the most compatible market by analyzing the usage of our users.

When we engaged with distributor agencies, a significant bottleneck emerged: they struggled to migrate their business to Ordr due to the platform's inability to replicate their organizational structure. Specifically, they required multiple access controls (MAC) - a management feature that would enable varying levels of autonomy and control for their workers. Ordr was initially designed for single-account users, making this a critical limitation.

Recognizing the necessity of this feature, the product team prioritized the design of MAC.
‍
I identified that before designing this feature, a thorough mapping of different user roles and the customizable permissions was needed. The product team was convinced, following which we focused on mapping permissions in the form of user stories for all the different modules of Ordr - including invoicing, inventory, order center, contacts, and ledger to name a few.

1. Replicate Organizational Structure: Enable distributor agencies to mirror their internal structure on Ordr, allowing for varying levels of autonomy and control among workers.
‍
2. Enhance User Management: Design a flexible and intuitive multiple access controls (MAC) feature to accommodate different user roles and customizable permissions across all modules.
‍
3. Facilitate Business Migration: Provide a solution that encourages distributor agencies to migrate their operations to Ordr, thereby expanding the customer base and market reach.

User management features are nothing new. So I kicked off the process by conducting a competitive analysis, examining how seven direct and indirect competitors offered multiple access controls on their systems. This analysis revealed several strong, recurring design patterns that I used as guide when designing this feature for Ordr.

With learnings from competitive analysis and a comprehensive map of user permissions, I turned my attention to designing the MAC module for Ordr. Over five iterations, I explored various ways to introduce this feature, while adhering to industry best practices and ensuring an intuitive user experience.

I started the design process by rapidly ideating on paper and visualizing how the patterns identified in competitive studies would translate onto Ordr.

In accordance with the industry practices, I designed this feature divided into two parts. User Management using which admin can invite and edit the organisation’s users, and Roles Management using which admin can create the role templates by specifying permissions.

When I tested the first iteration with users and presented it in our design critique, it quickly became apparent that we were executing user management in an unnecessarily complex manner. So in an effort to simplify the experience, we made a logical change to Settings and localized them to each business profile (in Ordr you can have multiple business profiles). This resulted in user management being simplified so much so that I didn’t need a dedicated page for user creation, a modal was sufficient.

The structure and flow of the feature started to settle by this time. The user management flow was almost complete. Only the role management section still needed further work, most importantly around how permissions were to be laid out - Create, Read, Update, Delete (CRUD) checkboxes, Descriptive stories, or a combination of both.

This iteration was largely focused on roles management. The main addition was the ability to send invites immediately after creating a role. This idea came about when users began expressing the desire for a shortcut to immediately send invites to users after making a role, instead of first creating a role and then inviting users one by one and assigning roles to each. They suggested connecting the two journeys.

Most of the effort was focused on addressing and designing for the edge cases. One significant update at this step was the decision to revert back to Descriptive permission stories from CRUD checkboxes, as developers identified a feasibility concern and for us to meet the deadlines, product decided to introduce the feature with that Descriptive permission stories first and then iterate if needed.

After handing off the designs to the engineering team, the developers revised their effort estimate and the new delivery date didn't align well with our customers' and product team’s expectations.
‍
After discussions, product decided to release a leaner version of the feature first, which consisted only of user management, and then release a comprehensive version later with customizable roles.
‍
With this iteration I also revised the general layout of the UI (a layout that was introduced through a design system project I was working on simultaneously) - this further refined the navigation and information hierarchy of the feature.

The lean version of MAC was largely well-received, with only a few customers requiring advanced permissions management. Nearly 80% of the distributors on our waitlist migrated to Ordr following its release.

Over the subsequent months, the demand for advanced permission management decreased, indicating that the lean version sufficed for the majority of distributors in Pakistan. Consequently, the release of the comprehensive version was put on hold.

This project highlighted the importance of understanding customer needs, conducting thorough competitive analysis, and being adaptable in product development.

1. The biggest learning from this project was to continuously involve end customers in the design process and dig deeper when the customers respond by "this looks good".

2. Prepare for the worst and break down big projects into smaller chunks. This would allow for faster testing and in case if something fails, it fails fast instead of at the end of a big project.

3. Push engineers to really understand the flows and features when running a feasibility. Feasibility concerns at the time of execution can really hurt timelines.