" />
Factile · Customize case study
Problem statement

Customization was powerful. Using it was the hard part.

What Customize is

Factile lets teachers create and run Jeopardy-style review games. Customize is where they personalize those games — logos, colors, fonts, sounds, timers, scoring, teams, and more.

Every setting belongs to one of two scopes: Global, which applies across all games, or Game-specific, which overrides Global for an individual game. Users choose the scope before editing any setting.

Why revamp

Years of feature growth had left Customize without a cohesive design system. Visual hierarchy was weak, components behaved inconsistently, and important actions were harder to scan and predict.

Beneath that was a deeper product issue: the experience was scope-first, asking users to decide between Global and Game-specific before they even knew what they wanted to change. Reworking that model wasn't possible in this iteration, so the redesign focused on reducing the visual and interaction debt while working within the existing product structure.

What I did

Designed a cohesive design system for the Customize experience, introducing consistent components, spacing, typography, and visual hierarchy so settings became easier to scan and understand.

Standardized interaction patterns across the page to make controls behave predictably, improving learnability and reducing friction. The redesign also met WCAG AA/AAA accessibility standards.

Rather than changing the underlying product model, I preserved familiar workflows and used the redesign to establish a stronger foundation for a future task-first experience.

RoleProduct designer, end-to-end UX & UI
SurfaceFactile · the Customize experience
ContextMature product · older & long-term users
FocusDiagnosis · interaction · product model

The screens here are pre-release iterations from my design process. This case study is about the reasoning and first iteration behind the work.

The constraint

A cleaner interface couldn't cost users their familiarity.

Older & long-term users. Relocating familiar controls carries real relearning cost.
Four learned zones stay put: top nav, settings sidebar, scope controls, and the workspace.
So the brief wasn't “redesign it.” It was improve the experience inside a structure people already trust.
Factile's original Customize screen
Starting point The Customize screen I began from. Tap the image to enlarge
Diagnosis · the spine of this case study

The interface carried three different kinds of debt.

Not one broken thing: three layers, each demanding a different response. This framework organizes everything that follows.

01 · UI debt
Visual language
Consistency & readability, the surface layer.
  • Inconsistent icons & radii
  • Uneven type hierarchy
  • Flat elevation & contrast
02 · Interaction debt
Everyday friction
Small interruptions inside high-frequency tasks.
  • Overloaded navigation
  • Toast overload
  • Ambiguous fields
03 · Product-model debt
Mental model
How customization itself is structured.
  • Scope decided too early
  • Global vs. game confusion
  • Overrides before intent
01
UI debt

The product worked, but its visual language grew without a system.

Built successfully without a dedicated designer, components evolved independently. The result was accumulated inconsistency that quietly raised the effort of reading the page.

Original Customize screen with problem areas marked 1 2 3

The three marked areas below

1
Inconsistent icons
Sidebar glyphs vary in weight & corner radius, with no shared grid.
2
Uneven type hierarchy
Headings, helper text, labels, and button text each carry their own size and weight, with no shared scale tying them together as one system.
3
Flat elevation & contrast
Cards read as one plane, hard to tell surface from control.
02
Interaction debt

Routine actions demanded more attention than they deserved.

Each friction point was small. But customization is a high-frequency, settings-heavy workflow, so small interruptions compound.

Overloaded navigation. 11+ ungrouped sidebar items to scan every visit.
Weak active state. The current section relied mostly on colour alone.
Repeated toasts. Every save & reset fired its own interruption.
Ambiguous fields. Game selection & settings search looked nearly identical.
Unclear scope. Global / Game-Specific state was easy to miss.
Unrestricted colour. A raw picker placed contrast risk on the user.
03
Product-model debt

The hardest problem hit before a setting ever changed.

Before touching anything, the model forces one branching decision, scope, and hides three extra steps behind one of the answers.

User wants to change one setting
Global or Game-Specific?
If Global
Find the setting
Change it
2 steps
If Game-Specific
Choose a game
Enable override
Find the setting
Change it
4 steps
Asked too early. The scope question comes before the user has any intent.
The branch is invisible. Nothing warns that “Game-Specific” hides three extra steps.
The approach

Improve what could safely change. Preserve what users already knew.

Preserve

Overall layout · navigation location · the customization structure people had already learned.

Improve

Hierarchy · grouping · feedback · affordances · accessibility · consistency: everything that could change without moving the furniture.

What I changed · iterations

Six moves, each inside the familiar frame.

1 · Make a dense interface easier to scan.

Grouping cuts repeated scanning; the selected state no longer leans on colour alone. Drag to compare; the iteration is on the left.

Before: ungrouped sidebar
Iteration: grouped sidebar
Iteration Grouped into three sections: Appearance · Game Rules · Advanced
Before Flat, ungrouped list of 11+ items

2 · Make different actions look different.

Before: game selector and settings search shared one look
Before Select-game field & Search-settings bar, near-identical
Iteration: distinct selector and search
Iteration “Choose a game” + its own Search field & button
Ambiguous grammar

Game selection & settings search shared one look, so users couldn't tell which did what.

Distinct families

Selection reads as selection; search gets a dedicated field and an explicit Search button.

3 · Turn a hidden dependency into a visible sequence.

Why it confused
Three steps depended on each other, but nothing said so, or in what order.
The game field looked pre-filled, so users couldn't tell if they'd chosen anything.
What got clearer
The three steps became an explicit, numbered sequence.
Each control stays disabled until the previous step makes it relevant.
1 · Game Specific
2 · Choose a game
3 · Enable settings
Iteration: the redesigned Customize with grouped nav and guided scope controls
Iteration Redesigned Customize: scope now a guided, sequential toggle

4 · Make feedback ambient, not interruptive.

Before: a toast on every change
Before A toast fired on every single change
Iteration: one quiet status line
Iteration One quiet status line, built into the header
Interruptive
Every save or reset popped its own toast.
Each dismissed with an “unloading” bar — training people to swat them away.
Ambient & in place
A persistent status strip under the scope controls.
Its dot shifts Saving…All changes saved.

5 · Guide safer colour choices before unlimited choice.

The old flow put contrast responsibility on the user. The iteration makes curated, safer choices the default path; advanced customization still available. Drag to compare.

Before: one swatch, then a raw picker
Iteration: curated swatches
Iteration Curated swatch pairings → raw picker still available via “More”
Before One swatch → raw colour picker

6 · Make it a system that scales past one screen.

I standardized the visual & interaction language so the work could become reusable infrastructure, not a set of one-off mockups.

That system evolved into a mini demo built for a different product, since Factile's own system stays under NDA.

Check out the mini design system demo on the next case study
Type scale
AaGoogle Sans Flex
Colour
Radii
Buttons
SaveReset
Status
All changes saved
Segmented
GlobalGame
Field
Search settings…
Icons
Where the iterations landed

Still recognizable, but requiring less interpretation.

The work didn't replace the product's mental map. It reduced the effort to navigate it, understand it, and make repeated changes.

Easier scanningClearer stateQuieter feedbackSafer defaultsConsistent components
3
layers of debt named, separated, and each given its own kind of fix
6
targeted interventions, all inside the structure users already knew
1
reusable component language, so the work scales past one screen
Honest reflection

Improving the current model didn't make it the best model.

The constraint justified preserving the current model for this pass; it didn't put that model beyond criticism. Two UI gaps still stand:

UI
Both panels on white
Sidebar & workspace still share a white background, weak zoning for a first-time orientation.
UI · Accessibility
Unproven colour safety
Curated swatches aren't yet validated as contrast-safe pairs, only individually.
Future direction · hypothesis, not shipped

What if users customized first, and chose scope only when it mattered?

This addresses the product-model debt above, scope decided too early. Delay the decision until there's something to apply: validated with existing users before it replaces the familiar model. It couldn't be built this pass because of the constraint below, but it's the direction this should head.

Today · scope-first
Choose scope
Choose game
Enable override
Find setting
Change
Proposed Task-first
Find setting
Change & preview
Choose where it applies
Select game (only if needed)
Closing

Preserve familiarity. Remove friction.

UI debt → systematized
Interaction debt → reduced
Product-model debt → identified & exposed
© 2026 Kushagra SharanFactile · Customize case study