Case studies/Citi Spotlight

Citi Spotlight: who owns what, at a glance

Citi teams tracked module status and project ownership across separate tools, spreadsheets and email threads. Spotlight is an internal dashboard that brings modules, status and owners into one view. I designed it inside the Citi Design System (CDS), in light and dark themes.

Fintech · internal toolAdaptive themingVariants
Client
Citi via Synechron
Role
UI/UX designer
Timeline
Nov 2021 – Jul 2022
Tools
Figma, HTML/CSS
The problem

Teams tracked module status and owners across tools, spreadsheets and email.

What I did

One dashboard built inside the Citi Design System (CDS). Components with Theme, Status and State properties, in light and dark.

Result

Full Figma designs and specs for every state in both themes, and support for developers during the build.

Research

Start with the questions people actually ask

With the product owners, I collected the questions employees were asking in email and chat: “What's the status of X?” “Who owns this?” “Which modules need attention?” I mapped each question to the data that answers it and to the role that needs it. That map became the information architecture.

Requirement workshopsModule and data inventoryRole mappingDesign system audit
Information architecture
  • Overview · one KPI card per module: status, progress, owner
  • Projects · table with owner, status and due date
  • Role views · employees see their modules, managers see across units
  • Search · one box for modules, projects and people
Strategic trade-offs

Working inside someone else's system

Custom components or Citi's design system?

OptionCustom cards and tables tuned to this dashboard
ChosenOnly Citi design-system components, extended through tokens

Custom components would have looked fresher but added build and maintenance work. Staying inside the system made handoff faster and kept Spotlight familiar to Citi employees.

One theme or two?

OptionLight only, dark later
ChosenLight and dark from the start, using approved token pairs

Dark mode was in scope. Designing both themes together exposed contrast problems early, especially status colors on dark surfaces.

Show numbers or show ownership?

OptionLead with the metric
ChosenMetric, owner and status on every card

The real problem was accountability. A number with no owner just restarts the “who's on this?” thread.

Spec only, or test in code?

OptionHand over Figma specs only
ChosenAlso build key layouts in HTML/CSS

Coding the grids myself showed how cards reflowed at real breakpoints before engineering started, so fewer layout questions came back during build.

Figma file · KPI card

One component, two themes, every state

The KPI card is a single component set with Theme, Status and State properties. I designed empty, loading and error states next to the populated one, so developers never had to guess. Module names and figures below are sample data.

Citi · Spotlight / Components
100%
❖ KPI card
Theme=Light
Module A
12 / 14
Owner · J. Matthews
● On track
Module B
6 / 10
Owner · P. Rao
● Review
Module C
3 / 9
Owner · Unassigned
● At risk
Theme=Dark
Module A
12 / 14
Owner · J. Matthews
● On track
Module B
6 / 10
Owner · P. Rao
● Review
Module C
3 / 9
Owner · Unassigned
● At risk
Interactive fileClick a layer or anything on the canvas to inspect it
Outcome & reflection

What I took from it

I delivered full Figma designs for every dashboard state in both themes, plus specs for spacing, tokens and interactions, and supported the developers through implementation.

Constraints speed you up

Working inside a mature design system meant fewer decisions about visuals and more time on structure and states.

Theme early, not late

Dark mode added afterwards becomes a list of contrast bugs. Designed alongside light mode, it's part of the system.