Designing a platform for digital-goods sales and operationsDesigning a platform for digital-goods sales and operations

SoloProduct designer

~12moProject duration

2Engineers

LiveProduction status

As the sole product designer, I worked from briefs that often named features without defining how they should work. I identified missing requirements, worked through the flows and interface states, and clarified decisions with the client before reviewing implementation.

My scope covered merchant operations, customer-facing sales channels and a separate workspace for platform payments—from catalogue and inventory management to fulfilment, support and access permissions.

Operational overview

The dashboard had to show what changed, not just what happened

I designed a configurable dashboard for comparing sales and inventory trends. Operators can inspect exact values, reorder or hide widgets, and trace an Item’s contribution through linked charts and lists.

The overview combines trends and configurable widgets. Hover reveals exact values for a selected date.

Hovering over the chart or list highlights the same Item and reveals its contribution to the total.

Catalogue model

One catalogue had to connect content with individual keys

Optional hierarchyCategory and Section are optional and organise products .

ItemThe customer-facing offer with a name, image, description and price.

ProductAn individual key or other unit of stock linked to its Item.

My task was to make the relationship between customer-facing offers and individual stock units clear in the interface. I designed separate creation flows for Items and Products, with stock entry linking keys to their Item and responsible operator.

The interface also supports a flat catalogue: Category and Section remain optional, so merchants can add structure when needed.

One customer-facing Item connects to the individual Products held in stock and delivered to buyers.

An Item holds the image, description and price of the customer-facing offer.

Bulk loading connects key validation and operator assignment to the same stock workflow.

Sales channels

One catalogue had to work wherever customers buys

Each merchant can configure one website and unlimited Telegram bots around the same catalogue, orders and support. I split website settings into focused tabs, keeping save and reset actions in context without adding a separate publishing workflow.

The storefront turns the shared catalogue into a customer-facing sales channel with search, filtering, availability and purchase states.

Responsive tables

When tables lose space, the hierarchy still has to work

Essential columns stay visibleFocused overview

Complete record in DetailsFull access

Desktop and narrow layoutsOne responsive pattern

Dense tables needed to remain usable as space narrowed. On smaller screens, I kept a compact set of columns for scanning records and moved the complete record into Details, alongside shared rules for copying values, opening linked records and accessing row actions.

Usernames open linked records, copyable values stay actionable, and row controls remain consistent.

The narrow layout prioritises scanning and row actions. All information remains available through Details.

Details exposes the complete record and copyable values without expanding the table horizontally.

Exception handling

When automation stopped, operators still needed context

Paid order cannot completeManual fallback

Website, order and TelegramOne shared queue

Named target and visible severityConfirm consequences

I designed the manual paths operators need when automatic fulfilment cannot complete. Manual fulfilment and refunds stay in Orders, while replacements stay in Support alongside the customer conversation.

For high-impact actions, I added confirmations that identify the affected record or selection. This keeps the action connected to its context and gives operators a chance to check the target before proceeding.

Conversation and ticket details stay together. Surrounding panels can collapse when more space is needed.

The operator can issue another Product from the same Item or select a different one for the replacement.

The confirmation identifies the affected subject before a dangerous action is executed.

Platform operations

Payment exceptions in a separate owner workspace

The platform team manages providers, balances and payment exceptions in a separate workspace. I kept the user’s message, transaction details, attachments and current status together so operators could investigate each case without switching context.

Operators can contact the user directly from the payment record before deciding whether to approve or reject the request.

The payment record brings together user’s information and current review status.

Operators can ask for additional information without leaving the payment context.

Access and accountability

Granular access and logs built for investigation

Permissions across all areasConfigure access

Different events need different dataSplit by domain

Links to affected recordsInvestigate in context

Operators have individual permissions across 16 product areas, with different controls for Support and Warehouse. This gives precise access control, but creates more settings to configure.

For logs, I split activity by domain so each view exposes relevant fields and links to affected records. Investigations gain specific context, while activity across domains remains in separate views.

Identity, security and permissions are edited within one operator record.

Different product areas expose their own access flags instead of relying on a small set of fixed roles.

Each domain table keeps only the fields and record links required to investigate that activity.

Design system

Shared components across products and themes

Primitive tokensStore raw foundations such as colour, spacing, radius and stroke.

Semantic tokensExpress meaning for backgrounds, text, icons, feedback and themes.

Alias tokensBind decisions to a specific component, element or state.

I published a shared Figma library for the Kratos ecosystem. Basic tokens store raw values, semantic tokens express their purpose, and alias tokens connect those decisions to specific component properties and states.

This structure supports shared components across Light and Dark themes and desktop, tablet and mobile layouts.

Component properties resolve through alias, semantic and basic tokens, keeping states and themes connected to the same foundations.

The published library separates reusable foundations from semantic decisions for Light and Dark themes.

Kratos light theme — Light and Dark modes are available across the Kratos ecosystem, from operational panels to customer-facing surfaces.

Kratos dark theme — Light and Dark modes are available across the Kratos ecosystem, from operational panels to customer-facing surfaces.

What I Delivered

My role went beyond designing screens. When briefs left behaviour undefined, I worked out what each feature needed to function, identified gaps, and clarified decisions with the client. I carried that work through detailed flows, a shared Figma design library, and implementation reviews with two engineers.

UnitBank

See Next