Bulk Management of Permission Sets

Bulk Management of Permission Sets

Client

HotSchedules

Description

Uploading and adding Permission Sets to all Groups under a restaurant concept

Tags
UX designUser InterfaceDesktop

Background on Permission Sets - In our software, Permission Sets are created to assign different permissions to various employee levels. These levels can range from hourly employees to managers and GMs, each with different sets of permissions. The ask came from a client with many stores, so instead of having to recreate a Permission Set for each store, to be able to copy one to multiple stores.

image

About the Client

I led the development of a feature at the request of a prominent chain restaurant group. The project underwent initial ideation, took a hiatus lasting over a year as it was put on the backlog, and was subsequently revisited. The final outcome diverged significantly from the initial concept, reflecting the dynamic and evolving nature of the design process.

About the project

Much of my work at HotSchedules focused on essential, behind-the-scenes tasks crucial for enhancing client engagement. It’s not exciting, but it is fulfilling when a hard task gets solved. This particular feature showcases the iterative collaboration between Product Owners and the Design team, emphasizing my commitment to advocating for the end user and challenging assumptions to ensure optimal user-centric outcomes.

Should we let users have access to back end data? What could go wrong?

In the initial request, the Product Owner pitched a vision within the Rally ticket, proposing a functionality where customers could download, edit, and re-upload an Excel sheet containing properties for each permission set (of which there were many for each store). The rationale was that the person editing the sheet would be familiar with what could be modified or not - as in, only certain people that knew how this functionality worked would be the ones editing the spread sheet. However, I expressed reservations about this approach, questioning the extent of freedom granted in making changes that could potentially disrupt the software. Despite advocating for more stringent guardrails, this suggestion was not accepted. I went ahead with the work, only for the feature to be subsequently shelved and placed indefinitely in the backlog.

image

Second go-around

After a hiatus, the Feature was pulled back from the backlog. I was able to start and work out another vision without PO input or interference. “Don’t ask for permission, ask for forgiveness”? I had been thinking about this project while it was on the backlog and had some ideas I was excited to try. Mainly, we had room to add a new pattern to the existing page without adding too much clutter so I explored that idea several different ways.

image

Problem statement

icon
I need to create a new flow on an existing page in the current ecosystem, making it seem seamless and easy for users to understand.

Solution:

icon
Build it into the existing, and underutilized, side panel.

Final flow and getting my idea accepted

When presenting my design to the Product Owners, together we examined their proposed ideas highlighting potential challenges, particularly the inherent risks of granting customers access to behind-the-scenes settings which could pose unforeseen issues. I expressed my concerns about the possibility of unintended consequences if users were allowed to change settings without full understanding.

After proposing an alternative approach which involved allowing customers to duplicate and selectively apply Permission Sets to specific stores, the Product Owners were happy with the designs. This experience underscores the importance of diplomatically pushing back and engaging in constructive dialogue with higher-ups, always advocating for the user and best practices.

I was able to walk back a convoluted, complex problem and turn it into a simple, 3-step flow that was easier to understand, had a zero percent chance of failing, and fit it into the existing ecosystem.

image
image

Problem statement

icon
Users don’t like to feel like they’ve been taken for a ride when it comes to pricing. Apps are banking on customers experiencing sunken cost fallacy and completing their order, but the reality is when potential customers see the final price they will try another app to see if it’s cheaper.

Solution:

icon
Transparent pricing the entire way through the ordering flow will hopefully alleviate sticker shock and leaving the app to find a cheaper price with a competitor.

Summary

This proved to be a valuable learning experience, allowing me to advocate for our users and propose a flow that prioritized simplicity and minimized the risk of errors. While I always greatly appreciate insights from those with more experience, there are instances where it's beneficial to entrust the design process to the designers themselves.

What would I do differently?

I wish I we were able to discuss this problem with the users themselves - the GMs of the restaurant groups that would be enabling this feature. I would have liked to hear their opinion on solution A vs solution B, but that’s not always going to be able to happen. In instances like this, I think my experience in the restaurant world is invaluable as I’m able to put myself in the users’ shoes.