The roles and permissions section in the WM platform was five years old, broken, and provided incorrect descriptions. If an individual were assigned all roles, their permissions would conflict. The support team had figured out workarounds they implemented by hand. Internal stakeholders had been considering a long-term solution that would allow the creation of specific roles for clients as they requested them.
The support team had been asking product for updates to the roles and permissions section due to client complaints. Each role had the same view of the platform, which overwhelmed new users and irritated power users.
I interviewed long-tenured WorkMarket employees and QA folks to see whether features and actions within roles and permissions worked correctly, provided correct information, and were easy to use. The document started as an outline that evolved into an organized record containing features with actions within each and notes on the side regarding what was not correct or working. The document gave my scrum team insights into what approach to take.
My team, realizing the problem was much bigger than we had foreseen, decided along with internal stakeholders and DevOps to pivot and implement a new micro-services architecture that allowed breaking out features and their corresponding actions to create roles by turning permissions on or off. Product directors would be responsible for creating roles with their respective permissions through a switchboard I was to design. Next, I conducted need-finding by interviewing Product Directors to determine how they wanted the roles and permissions switchboard to behave, what it needed to look like, and whether clients would use it to create custom roles. Finally, we started outlining requirements.
We decided to design a prod-quality interface so clients could eventually create custom roles. Using components from the design system, I laid out workflows with my PO to create pre-canned roles. Next, I tested the prototype with the product directors and the support team. The tests included creating and editing a role by turning on a feature and turning off actions within that feature. The prototype passed all tests; we had to tweak labels because it was difficult to understand that features had actions within them.
We also designed an employee management dashboard prototype to add or remove client employees to the WM platform and assign them roles. Finally, we usability tested the workflows with clients. Again, the prototype passed all tests since we used components and UI patterns already in production.
Our final solution became three distinct projects:
1. Development took about a year to break out the entire platform into an API driven micro-services platform following CRUD (Create, Read, Update, Delete — the four database functions for persistent storage) to be able to hide and therefore restrict actions in specified areas;
2. a new roles and permissions dashboard for internal WorkMarket users to bundle permissions into roles and later use for external clients to create their custom roles; and
3. a client-facing employee management section to handle all employee-related actions.
Support got fewer calls regarding the roles and permissions area of the platform. And internal stakeholders could now configure and deploy a new role to a single client or WorkMarket's entire client base. In addition, the clients could manage employees and enter new ones without assigning conflicting roles. Client employees had a much better experience since they could now have a distinct view of the platform and take action only on items concerning their function, significantly improving UX. Finally, turning roles and permissions for potential new clients was now possible, which was of great value to the sales team and became a new project I later worked on: Packages.