KOL Payment
Center

KOL was a small branch of one company app’s business. Its existing creator-facing frontend followed that app’s visual style: creators entered information through the company’s own forms, while internal marketing managers managed and read submissions in Jiandaoyun. The management work covered three modules: Invoice, KOL Management and Marketing Manager Management. Marketing managers managed creators, supervisors managed marketing managers, and finance handled transfers.

In that implementation, relationships between modules, navigation, information hierarchy and task steps were confusing. Exporting accounts and personnel information from Jiandaoyun alone did not support the workflow and led to repeated work. The company already had a finance system with its own frontend and backend. This project needed to connect this business branch to that existing system, clarify roles and cross-department steps, and bring its management workspace into the company’s unified backend entry point and visual and interaction standards. The specific historical API wiring has not been verified.

One creator may work with several marketing managers. The person who sends an invitation, updates information or creates an invoice is not necessarily the same as every manager responsible for that creator. Creators need to understand their own information and documents, while internal staff also need responsibility and activity history. A single name field cannot answer all of those questions.

The workspace is organised around KOL management, marketing manager management and Invoice. Marketing managers are responsible for creators; supervisors oversee managers; finance processes transfers through the existing finance system. Creator identity, assigned managers and the person performing an action remain distinct, supporting navigation, handover and traceability.

Staff may arrive with an email address, a creator’s name, a manager’s name or a group of incomplete records to work through. The filter group therefore includes onboarding email, creator name, marketing manager, payment-information status and signature-authorisation status. These are different ways into the same task. Payment-information status describes the information on file; it does not mean that money has arrived.

Within the table, I prioritised information that needs quick comparison and made supporting detail available on demand. Multiple managers appear as one name and an additional count, with the full list available on hover. Authorisation is expressed as a text status first, with dates available in more detail. The aim is to balance completeness with scanability, rather than simply remove information.

A bulk manager change contains two separate decisions: which creators are affected, and how their manager relationships should change. All filtered records are not necessarily the same as the checked records. Adding, removing and replacing a manager also have different meanings. Selecting a target manager alone would not make the consequences of the change clear.

I separated the scope from the action and made the form respond to the selected operation. Replacement asks for the original and new managers; adding a manager needs the target manager. Affected creator and manager counts appear before confirmation. The dialog is therefore not just a place to collect inputs: it helps the user understand the reach of a bulk change before submitting it.

Payment information needs frequent checking and also supports the next invoice task. If every account click opened an editable form, it would be harder to distinguish reviewing information from changing it. Clicking PayPal or Bank transfer therefore opens a viewing state, while the edit icon opens an editing state.

The viewing panel presents completed, read-only information with actions to create an invoice or edit. The editing state exposes inputs, selectors and a submit action. Keeping this in a side panel lets staff review information without losing the creator-list context. A compact panel suits a local information check; a larger panel gives a detailed invoice more room. The container follows the complexity of the task.

An invoice count should do more than report a number. When someone sees four invoices for a creator, the next question is usually which four they are and what state they are in. I made the count an entry point to the separate Invoice list, carrying the creator’s name and email into that context rather than asking the user to search again.

From the filtered list, the user can open an individual invoice and inspect its detail and process information. The journey has three levels: creator overview, related invoice list and individual invoice detail. Each level answers a different question without forcing every document detail into the original creator table.

Invitations and emails are not separate from the product experience: they are entry points into it. With no invoice and no authorisation, the message needs to explain why authorisation is requested. With an invoice but no authorisation, the creator needs to review the document and complete the missing signature. With authorisation already in place, a new invoice should lead to viewing the completed document. A generic request to take action would leave the creator to work out what is missing.

I aligned each email’s purpose with the state of its landing page. For a new invoice after authorisation, the page explains that the invoice is ready to download and shows the existing signature and information, rather than asking for authorisation again. A blue text link keeps PDF preview discoverable without giving it the weight of a primary action. Where authorisation is missing, the page must not suggest that signing has already been completed.

A marketing manager has an internal organisational identity and may use a different external-facing name. Separating those identities helps colleagues identify the right person and understand how that person appears to creators. Employment status, group and added date support ongoing management and handover, rather than simply filling table columns.

For a single display-name change, I used inline editing to keep the adjustment close to the record. Adding a manager involves selecting an organisation member and providing an external name, so it uses a fuller dialog. Consistency does not mean every action opens the same container. It means familiar patterns for comparable tasks, with enough context for more involved ones.

The Invoice list needs to support quick checking. I paired status text with colour for rejected, under approval, confirmation complete and awaiting confirmation, and right-aligned amounts with explicit currency codes. This helps staff compare information without reading an uneven sequence of numbers or relying on colour alone. Currency matters when records use different monetary units.

Invoice status and payment-action availability are not the same information. In the current design, invoices labelled confirmation complete can still show different availability for the Pay action. I therefore treat document progress separately from action eligibility. A useful next review is whether the user can understand why an action is unavailable, rather than merely notice a grey button.

An invoice detail needs more than an amount. Who submitted it, when it was created, its process state and what changed can all affect the next decision. I brought business content together with process information and data logs so that the user can trace the context of a document rather than reconstruct it across unrelated screens.

The file itself also communicates its state. A light-grey translucent watermark marks a preview, while a red translucent VOID mark distinguishes a voided document without making its contents unreadable. Download remains an action, not proof that a document is valid, has been emailed or has been paid. A familiar button should not hide differences in the document lifecycle.

The shared design language supports internal systems including accounts, talent, contracts, finance, payroll and procurement. Across modules, useful consistency means knowing where to search and reset, how primary actions appear, what is interactive, what is a state and how viewing differs from editing. Colour, typography and components provide the foundation; behavioural rules make familiarity transferable.

The KOL Payment Center makes those principles concrete. Lists share a search pattern, blue primary actions remain recognisable, text links lead to detail, inline edits handle local changes, drawers retain context and dialogs support fuller creation tasks. Different containers are not an inconsistency when they apply the same principles to different task sizes.

The complexity of this project lies in intersecting relationships and states, not simply its number of screens. A creator can have several managers; an email can serve different authorisation stages; an invoice has current content, a process and a history. My design decisions centre on these distinctions: what belongs together, what needs progressive detail, which actions need an explicit scope and which states must stay separate.

The outcome I can show here is the management-side design and its interaction reasoning, rather than an unverified efficiency percentage. Further evaluation should focus on concrete tasks: understanding bulk scope, finding a creator’s invoices, distinguishing authorisation from payment and understanding unavailable actions. That would move the assessment from the plausibility of the screens to evidence of how people use them.