I would like to use this case study to share my experience and thoughts on how designers contribute to the complex domains of enterprise 0-to-1 products.
The campaign management domain is a part of the TikTok E-commerce Operation Management Platform. It consists of multiple systems that support operators' work throughout an entire campaign. The ultimate goal is to help operators efficiently recruit and manage sellers/creators/products to get a high sales number for a campaign. In this case study, I'll be touching on 3 systems that are the core of the domain.
The product was still in a cold-start phase when I got involved. The business logic of the domain was quite complex, and there were many ambiguities. If I simply rely on the PRD, it's easy to fall into the frustrating situation of "am I just transferring PM's prototype into a prettier wireframe?".
I've learned along the way that what's written in the PRD is only the PM's interpretation of the need. We as designers should always step back to understand where's the interpretation coming from, evaluate the given solution from a UX perspective, and see if there is a better way of solving the problem. Below are examples of how I turned the original product solution into a better user experience. 🎉
Once a product has been registered by sellers for a campaign, it will circulate to the campaign product management system and then to the scheduling system. The product will be reviewed, the subsidy will be set (optional), and scheduled into sessions. During circulation, a product can have different statuses, and operators need to have a clear overview of any changes.
There were statuses from 3 different dimensions mixed up in the given solution. Due to the lack of an overarching logic, there was no consistency in how statuses circulate throughout the whole journey. For example, an expired product would be in “expired” status in one system and “ended” status in another.
One of the purposes of laying out all the status is to give operators a clear overview of registered products in a campaign. A consistent status change flow is needed regardless of what system the products are in. I mapped out all possible scenarios we may have and reorganized the status structure.
Based on the analysis, product status and session status should be separated, and subsidy status should be considered as a part of product status. Below is the final design of the page with the status structure issue resolved.
Once a session has been registered by creators for a campaign, it will circulate to the livestream management system. From there, operators will bind sessions together to get more push from TikTok to achieve higher GMV. We need to enable operators to bind sessions and manage bound sessions as one entity.
I agreed with utilizing bulk action to bind selected sessions together, however, the way bound sessions were presented on the page contained one key issue. The original solution used labeling as a strategy to signify the bound result. however, changes in the relationship between entities can't be reflected by a change in labels.
In the target scenario, when sessions are bound together, the sessions stop being the main subject on the list, instead, they become sub-entities of a new bound entity. All actions such as edit/delete will be performed directly on the new bound entity.
I started by getting to know how operators bind and manage sessions with their own tools. In Excel, operators highlight sessions to bind with the same color so they can differentiate between grouped and ungrouped sessions while still being able to see the sub-session data. Noted there are actually two user types (account manager & promotion operator) and promotion operators rely more on sub-session data to review and make a decision.
My first proposal is to create a similar offline experience online. Grouped sessions will remain in the table as the nested content of the bound session.
However, if a bound session contains a lot of sub-sessions, expanding and collapsing the list will become problematic. Therefore I came up with the second proposal of only showing the bound session on the table and putting the sub-sessions into a drawer. This solves the issue of vertical space but inevitably creates an issue in the horizontal space since the scrollable area gets narrower.
To figure out which proposal is better, I did a quick round of usability testing. 100% of the participants favored proposal 1 since it's closer to their existing flow of binding sessions and makes it more intuitive to use. They also provided valuable feedback regarding proposal 1 that helped me land the final solution.
👩🏻: Being able to efficiently scroll for data is key in the reviewing process.
🧑🏻: Normally, in a bound session, we have a key account that is expected to generate the highest GMV.
👨🏻: Theoretically, the number of sub-sessions in a bound group should be less than 15.
In the scheduling system where products and sessions are associated together, operators need to be able to assign and manage products in the designated sessions. We've been using the regular table format to display the scheduling results.
The table view can definitely achieve users' need of locating a session or looking up detailed information. However, if I put myself in the shoe of someone who's hosting an event, not only do I care about the individual session, but I would also be interested in seeing how everything is organized for each day. This is especially important for events requiring non-stop session arrangement.
To validate my assumption, I observed how operators manage sessions offline. Turns out that after the sessions are scheduled, they will start a very comprehensive Excel sheet for the event, containing detailed info about each session, a calendar to keep track of the arrangement, sales data, and overall retrospective data.
My initial idea was to add an instant filter and display the table data chronologically. However, during research I realized for this specific scenario, users only cared about which time slots are filled and what order the sessions are in for each day. I ended up with a proposal giving users the ability to toggle between the table view and the calendar view. In the table view, users can get detailed data about each session, while the calendar view only serves the purpose of displaying session names and statuses chronologically for each day.
In order to push this design-driven feature forward, I consulted developers about the feasibility and workload. Afterward, I showed PMs the proposal and explained my thought process. In the end, we decided to include the "calendar view" feature in the project scope.
In the first half year of 2022, the campaign management system supported 350+ events across 7 countries, and managed 1.2M+ registered campaign products, increasing operators’ work efficiency by 360%+. For the next phase, the plan is to fully cover the main business scenarios, aiming to bring the entire campaign management process online.
