As part of sony music’s push to connect all of their products into one seamless app suite, I was asked to analyze, organize, & design how albums, campaigns, products, etc. are entered into our system and how they move around within it. The existing model had users creating & modifying these things, referred to collectively as objects, using a variety of ux patterns depending on the individual app.
To organize these requirements, I created user flows for each app using the information I gathered in interviews. Once I had all of the possible user flows, I set out to create one consolidated flow that merged and optimized all of these existing flows.
To organize these requirements, I created user flows for each app using the information I gathered in interviews. Once I had all of the possible user flows, I set out to create one consolidated flow that merged and optimized all of these existing flows.
My findings revealed to me that this process required the organization of objects in the context of 4 layers, each with their own flows that together map out the entire lifecycle of an object through our suite. I called these Stages, Statuses, States, & Actions.
describes the fundamental steps an object can move through in its lifecycle
describes or clarifies the place of the object in its lifecycle
describes the way the object and it’s functionality is presented to the user
describes the operation a user (or the system) can apply to an object
Once combined, these layers create a full picture of a objects lifecycle through our product suite. The map of the full lifecycle of an object is intended for use by designers to restructure their existing flows in a way that fits the larger system as well as help them determine the appropriate user flows as they introduce new features and functionality to their products.
Now it was time to answer the question of how objects are created, edited, & reviewed. First up - deciding on the overall pattern for each of these functions. Early on I identified two options:
After some consideration of the pros and cons, I chose to house these key functions in a full screen modal, which communicates clearly to the user that they are entering a functional session that will impact the content on the page and ensures users will not move inappropriately throughout the suite during these essential functions. Each of these functions now needed to be designed within this chosen context.
It may seem counterintuitive, but the first function we solved comes after the other two. However, because this function is only used in one app and is fairly straightforward, we were able to quickly identify the appropriate user flow and presentation for an object in the review mode.
Working backwards still, it was time to take a look at the edit function. This one was more complicated than review and required a closer look at the dependencies between information in an object, which revealed the need for not just one approach to editing. Based on the structure of information within an object, we created a map to determine which editing method should be used in which cases. In the end we had 3 different editing methods - inline editing, sidecar editing, and full screen modal editing.
From there it was just a matter of how these different editing modes would look and behave. Luckily inline editing and sidecar editing already existed in our systems and only required a bit of finessing to fit perfectly in the new system. The full screen modal editing however had to be newly designed. As in the case of object review, this was a matter of how and object is presented in full screen edit mode and how the user moves into and out of this session.
The create function is the most complex and diverse function in our object lifecycle and therefore took the longest to solution. It encompasses everything from how a new user is invited into the suite to how products like albums & music videos are entered into our system, how marketing campaigns are set into motion, and how finances are distributed among collaborators. This function is being used by every app and every user and is the entry point to the functionality of our suite.
With that in mind, it became clear that the answer wouldn’t be simple. I had to take a close look at the specific creation process for each and every object in our system, which led me to defining objects into two categories - simple & complex. A simple object requires certain information to be created, but it ends there. With a complex object however, once the required information to create the object is provided, there are still any number of optional steps and information that can be added to that object.
Under careful consideration of these complex flows as well as how best to accommodate confused, new users without creating extra work for experienced users, I separated the create process into two stages - basic create & advanced create. Basic create would happen in a wizard flow, taking a user through the steps required to create the object. If the object is simple, this is where the session would end. However, for complex objects we had to answer the question of what next, ultimately debating between continuing in a wizard format for a taken-by-the-hand experience or transitioning into the object edit format for a more customizable experience. The latter won out in the end, as it became clear that the frustration caused by users having to skip through steps they aren’t ready to complete to find the ones they are did not outweigh the slightly steeper learning curve it would create for new users.
Finally, the only thing left was to design the wizard mode of the full screen modal. This required defining templates and rules for things like layout and spacing as well as what defines something as a single step and how to best determine what order the steps should go in. In the end however, the information needed to create each object is so drastically different that designers for each product were given the flexibility within these rules to determine the patterns that should be used to complete each step.
I learned a lot about how to structure and maintain a design system that not only supports a rapidly growing suite of products, but also replaces & improves conflicting & outdated designs, allowing existing products to work in harmony.
I also learned how to take countless inputs from multiple sets of users - my design team, the engineering team, and the users of our products - as well as the larger product and business goals and tackle them all with simple yet comprehensive solutions.