suite invitation & permissioning

A complete re-imagination of the Sony Music Product Suite’s invite & permissioning process that provides the user with a comprehensive & streamlined flow while accommodating a growing & evolving backend system.

UX, UI, IA, UXR
2023 - 2024
Sony Music Entertainment

brief

context

The sony music product suite encompasses a set of apps that allow music industry professionals to conduct all areas of their business, from accounting to marketing to publishing and even performance analysis. Over the recent years, the app suite has grown from a group of functions that could be encompassed in just two products, to a massive array of functions requiring much more separation. As a result of this increase in size and complexity, it became necessary to re-image the permissioning system on the back end and, alongside that, to redesign the frontend experience.

ask

As the lead designer on the platforms team, I was asked to spearhead the project. Our task - transform the current permissioning flow, which commonly tripped user’s up and no longer accommodated the full extent of the product suite, into a comprehensive, clear, & streamlined flow for the user.

Hurdles

designing while developing

Because the system was being completely redone both on the back and front end, it required a consistent and in-depth interchange of information between product, design, and engineering. To succeed, I had to learn how to collaborate closely with backend developers, to understand their terminology & processes and translate design work in a way that spoke to this new audience.

dichotomous user base

Sony Music Entertainment is composed not only of major music labels with people designated to conduct each area of business in our suite, but also of small labels and independent artists who are managing all parts of the process. We call these power users and self-service users, respectively. While this is certainly a challenge suite-wide, it rears its head most strongly in foundational processes like the one at hand.

conflicting views among stakeholders

a question of the overall approach to permissioning was yet unanswered and required context & exploration from all parties - business, product, design, & engineering - to solve. As could be imagined, such differing perspectives lead to differing answers, which lead to long debates. Ultimately, this meant keeping the question open for the entire timeline of the project, which in turn meant designing for multiple approaches at each iteration and, on behalf of the user, constantly exploring new ways to bring all parties together under one solution.

lack of access to users

as a function of the way Sony Music is organized as well as the music industry itself, it is near impossible to get access to members of most user groups. This means we are often designing without input from the user, relying instead on feedback from support tickets submitted by users as well as access to a select few internal team members who use the invite & permissioning flow often.

approach

getting project buy-in

We started unconventionally with basic wireframes demonstrating what an improved user flow would look like in comparison to the existing user flow in order to get buy-in from stakeholders who were originally unconvinced that the process required such a dramatic overhaul.

research & information synthesis

Once we had that buy-in, we went back to the drawing board and started moving through the appropriate steps for the design process, starting with interviews. 

Realizing we needed much more information to answer the questions at hand, we decided to dive deep into interviews with product managers from each app in the suite to find out exactly what jobs were to be done, by which users, to which objects. 

Once we had gathered & synthesized this data, we created a comprehensive map of the entire suite, identifying overlapping functionality and consolidating all avenues into what we called “jobs to be done.” These became the set of things for which permission could be assigned. 

With these in hand, we returned to our steering committee to validate our findings and open the conversation about how permissions would be grouped. Two approaches resulted from this meeting - a “by app” approach and a “by role” approach - each of which were backed by strong arguments from one or more of the areas involved.

user experience

We then moved on to the user flow & wireframing stage, where we aimed to explore & demonstrate the similarities & differences between the two approaches from the user experience perspective and, in turn, make an argument for the by role approach as the more user-centric option. 

After presentation & discussion with product & engineering, we decided to move into the hi-fidelity stage, continuing with both approaches.

user interface

Now completely in my hands, I set out on an exploration of many interface & interaction patterns, working iteratively with weekly feedback from product & engineering, until we decided on a final design

final sign off

With final designs in hand, it was time to bring everyone back together to make the ultimate decision between the by app and by role approaches as well as get final sign off to move forward into development. In a supergroup steering meeting including department executives, engineering leads, & product managers, I presented my designs and made one final argument on behalf of the user for the by role approach before standing down and allowing the executives to make the final decision.

Ultimately, the business leaders chose to organize the permissions on a by app basis. While not the ideal solution for the user, we had created a design solution to mitigate any additional complexity brought on by the alternate organization.

user feedback & handoff

Finally, we had the opportunity to bring the signed-off prototype in front of a few key internal users for feedback & validation, which resulted in one last iteration before passing the project off to development.

results

In the end, we created a digestible, yet fully comprehensive experience to accommodate the new complex permissioning system as well as the diverse user base. 

The invite flow is housed in a full screen wizard, following our system wide approach to creating objects, and presents the assignment of permissions using a stepped accordion to group permission options which are themselves presented by a series of toggles & checkboxes to accommodate both default & optional permissions. 

After final review, all parties agree we have ultimately succeeded in creating a new permissioning process that accommodates a rapidly scaling suite and strikes a perfect balance between simplicity & customizability that will serve all users well.

takeaways

building a relationship with backend engineering

I walked away with a new ability to communicate & collaborate with backend developers, which I’ve added to my toolbelt alongside my relationships with frontend development, ultimately making me a more well-rounded designer.

confidence in standing up for design

having to argue on behalf of the user experience against the leanings of business leaders & product managers challenged me to stand firmly in my confidence & responsibility as a designer while finding ways to compromise & accommodate such opposing viewpoints and ultimately to know when to stand aside and do what I can to make a decision I don’t support as user-friendly as possible.