I designed iAffiliate's corporate website for its rebrand and worked on iDB, an internal tool for managing content across Noxwin and Casino.online. My focus spanned website structure, editor workflows and reusable UI components.

View live site
The shipped corporate website introduced the new iAffiliate brand.
Project Overview

From corporate website to content operations

Two connected design challenges

The website needed to explain the business to partners and candidates. Internally, editors needed a way to maintain operator information across multiple brands and markets. The work covered both the public-facing site and the tools behind the affiliate products.

ROLE
Product Designer
SCOPE
Corporate website + iDB back office
COLLABORATION
Engineering, SEO and Content
FOCUS
Information architecture, UI system, publishing workflows

One company website for partners and candidates

I structured the page around three questions: what does iAffiliate do, why work with it, and why join the team? Business information, partner logos and work examples address potential partners; employee stories, benefits and open roles address candidates.

Keeping both audiences on one page meant a longer scroll. The trade-off was a single company introduction, with dedicated sections for each audience.

The shipped homepage brings the company story, partner proof and careers into one journey.
Brand experience

Company values as interactive cards

Each value pairs a distinct symbol with a short statement and an interactive detail state. A shared card pattern keeps the six values visually connected.

Six company principles became one responsive interaction system.
Behind the website

Managing content across Noxwin and Casino.online

iDB is designed for content editors managing operator information across Noxwin and Casino.online. It brings offers, assets and market-specific details into shared records, so related content can be maintained in one place.

The iDB dashboard brings integration reporting and recent operator additions into one view.
Editor workflow

From content gap to published operator

The proposed workflow starts with a gap in website coverage, then moves through an operator update, validation and publishing. The operator record connects these steps.

iDB editor workflow showing how a content gap moves through operator updates, validation and publishing across affiliate websites.

Three decisions behind the editor workflow

Dense operational data had to be easy to find, update and reuse.

01 / Content model

Organise everything around the operator

The design keeps each operator's information in one record, with tabs for deals, bonuses, software, payments and licences. Related content stays accessible without leaving the operator being edited.

iDB operator record general tab with identity, publishing availability and logo management fields.
Core operator information and publishing availability stay in one record.
iDB operator record with tabs for general information, deals, bonuses, software, payments, licences, key facts and details.
Related content stays connected to its operator and market.
02 / Operational visibility

Show coverage before opening a record

The operator list shows whether content is available to Noxwin or Casino.online. Editors can spot coverage gaps without opening records one by one.

iDB operator list showing connected bonus, software and deal records alongside publishing status for Noxwin and Casino.online.
Website availability is shown in the list, before an editor opens the record.
03 / Information architecture

Organise the detail, don't hide it

Editors need detailed information, so removing fields was not the answer. I grouped them into sections such as Casino, Restrictions, Sport, App and Support, with consistent controls throughout.

Long iDB operator details form grouped into casino, restrictions, sport, app, design, technical and customer support sections.
Section headings divide the long form by topic while retaining its detailed fields.
Built as a system

Shared controls across screens and themes

Buttons, inputs and navigation share defined states and spacing across dashboards, tables and forms. Light and dark variants retain the same component structure and interaction patterns.

iDB button component set covering primary, secondary, ghost and outlined states in light and dark themes.
iDB input components for text, search, languages, country restrictions and colour selection across themes and states.
Expanded and collapsed iDB navigation components in light and dark themes.
Core controls, complex inputs and navigation share the same states, spacing and theme logic.
Light theme iDB dashboard showing integration reporting and recently added operators.
Dark theme iDB dashboard using the same navigation, cards and reporting structure.
The dashboard retains its layout and controls across light and dark themes.
Outcome & reflection

A launched website and an editor-focused product design

The corporate website launched with the new brand, company information and careers content. The iDB design covered operator records, publishing workflows and reusable components for the internal product.

Post-launch performance data was not available. The screens demonstrate the proposed structure and interactions, but do not establish whether editors completed tasks faster or made fewer errors.

The key design distinction was between explaining the business and supporting the people maintaining its content. The website needed a clear narrative; iDB needed detailed records and predictable controls.

What I would measure next
  • Time to identify missing website coverage
  • Time to update an operator record
  • Errors when updating an operator record
  • Content discrepancies across brands and markets