I created iAffiliate's brand and corporate website from the ground up. The work then expanded into iDB, an internal back office where editors manage operator data, offers and assets shared across Noxwin and Casino.online.

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

What began as a company website became an internal content back office.

How the scope evolved

The website gave the new brand a clear face for partners and candidates. Behind it, the same operator facts, offers and assets also had to stay consistent across brands and markets. That need became iDB.

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

First, make the company easy to understand

The site had three jobs: explain the business, build trust with partners and show people why they should join. I shaped one continuous page around proof: the business model, partner logos, work, employee voices, benefits and open roles.

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

Values designed to feel alive

A shared set of principles became an interactive system for the company website, giving every value its own symbol, voice and responsive state.

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

The same content was needed in more than one place

iDB is an internal back-office product, not a customer-facing website. Content editors use it to create and maintain operator records, deals, bonuses, payment methods, licences, assets and market rules, then publish consistent information across Noxwin and Casino.online.

Instead of maintaining the same information separately in each affiliate product, iDB acts as the shared source of truth. It connects operators and offers with providers, affiliate websites, rankings and assets while keeping market and publishing context attached to the content.

Editor workflow

From content gap to published operator

Editors can spot missing website coverage, update the operator once, and publish consistent content across markets and affiliate products.

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

Three decisions made iDB easier to use

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

01 / Content model

Keep everything around the operator

Each operator became one record. Related deals, bonuses, software, payments, licences and details sit in predictable tabs, so editors can work from a single context.

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.
Cross-site availability becomes visible at a glance.
03 / Information architecture

Organise the detail, don't hide it

The domain needs many fields. Instead of removing useful detail, we grouped it into clear sections such as Casino, Restrictions, Sport, App and Support, using the same control patterns throughout.

Long iDB operator details form grouped into casino, restrictions, sport, app, design, technical and customer support sections.
Clear sections make a dense record easier to scan and update.
Built as a system

Reusable patterns kept the product consistent

The system worked at three levels: foundations set the visual rules, reusable components handled interaction states, and product screens assembled them into workflows. The same patterns had to support dashboards, tables, forms and navigation in both light and dark themes.

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.
One component language supports both light and dark operational contexts.
Outcome & reflection

A shared foundation for the brand and its content operations

The corporate website launched with one clear story for partners, candidates and employees. For iDB, the outcome was a shared content structure that brought operator details, offers, assets and publishing context into one system.

Editors could see coverage gaps from the operator list and manage related information from a single record instead of navigating disconnected content areas. The reusable UI patterns also gave future workflows a consistent foundation across tables, forms and dashboards.

Formal post-launch metrics were not available, so I evaluate the work through the shipped scope and the workflow improvements built into the product.

What I would measure next
  • Time needed to create or update an operator
  • Time needed to identify missing website coverage
  • Content discrepancies between brands and markets
  • Completion rate of required operator information
  • Editor confidence and usability feedback