ARYIKA MEHROTRA
SYSTEM PREVIEWSELF-DIRECTED STUDY / 2026
DESIGN SYSTEMS / FRONT-END INDEPENDENT STUDY

One component.
Different voices.

An editorial card can carry very different brand expressions without changing its structure or interaction contract. I built a small interactive specimen to explore where that boundary should sit.

QUESTIONWhat varies by brand?
CONSTANTSemantics, content slots, interaction
VARIABLETypography, color, density, corners
FORMATWorking HTML/CSS/JS specimen
01 / MODEL

Separate meaning from expression.

The specimen has one article-card structure: category, title, summary, image area, and action. A publication voice changes presentation tokens, while the content order and destination remain stable.

CONTENTArticle data and editorial hierarchy
COMPONENTShared semantic structure and states
THEMEPublication-specific tokens

This is a portfolio exercise, not an audit of Condé Nast or an implementation of its Verso design system.

02 / TOKEN BOUNDARY

Small surface, explicit decisions.

DecisionShared contractTheme choice
ContentCategory, headline, summary, action orderDisplay typography
InteractionSemantic link, visible focus, readable labelAccent and button radius
LayoutResponsive card and stable reading orderSpacing density and surface color

On the homepage, the radio controls switch a CSS token set. The card is intentionally one component, rather than three separate brand-specific layouts.

Try the live specimen
03 / COMPONENT DOCUMENTATION

Editorial card / usage guide.

A useful system component needs more than a visual sample. This contract states the content it accepts, the behavior it owns, and the cases a team should verify.

COMPONENT CONTRACT / V0.1 STUDYEditorialCard
InputRequirementRule
categoryRequired textShort editorial label; does not replace the headline.
title + hrefRequiredOne descriptive link target for the card, with a semantic heading.
summaryOptional textMay be omitted without leaving an empty region.
imageOptional src + altUse meaningful alt text when informative; empty alt for decorative imagery.
headingLevel2 or 3Chosen by page context rather than visual size.
publicationInherited themeSet on an ancestor; it does not change content or markup.

Use it when

A story needs category, title, optional context, and one clear destination. Keep the reading order and link meaning intact at narrow widths.

Choose another pattern when

The card needs multiple independent actions, live data controls, or a complex media player. Adding flags for unrelated behaviors would make the shared contract harder to maintain.

Read the React/TypeScript reference component Read its token CSS

These are inspectable reference files for this study, not a compiled React package or shipped production library. The live specimen on the homepage uses HTML, CSS, and JavaScript.

04 / TOKEN STEWARDSHIP

A token is a decision with a name.

The live specimen uses component-facing variables such as accent, display type, spacing, and radius. A larger system should separate raw values from semantic intent so teams can change a publication's expression without changing every component.

FOUNDATIONpalette.oxide.600

Raw color, spacing, and type values. These describe what a value is.

SEMANTICcolor.action.primary

Usage meaning shared by components. These describe what a value does.

COMPONENTeditorialCard.action.background

Exceptions only when a component needs a documented, stable contract.

Proposed change path

  1. Request. State the use case and show where current tokens fail across at least two contexts.
  2. Review. Design and engineering check naming, contrast, theme coverage, and whether an existing semantic token fits.
  3. Implement. Update token source, component examples, migration notes, and visual snapshots together.
  4. Release. Version the change and record affected surfaces; deprecate old tokens with a migration path.

This is a proposed governance process for a mature system, not a claim that I owned such a process at a previous employer.

05 / QA & REVIEW

Protect the contract while moving quickly.

A review should catch a broken interaction or ambiguous token before it spreads to another brand. I use a compact checklist and make feedback actionable.

CONTENT

Long title, missing summary, absent image, and translated text retain a sensible reading order.

INTERACTION

One clear link destination, visible keyboard focus, touch-friendly target, and no duplicate tab stops.

THEMES

Every supported publication voice has legible text, meaningful contrast, and consistent states.

LAYOUT

Mobile widths, enlarged text, and reduced motion do not hide content or controls.

PEER REVIEW EXAMPLE / REFERENCE COMPONENT

Observation: A second “Read story” anchor would create two adjacent links to the same destination and add unnecessary keyboard stops.

Suggestion: Make the headline the semantic link and render the action label as visual text. Keep the link focus treatment visible. This reduces duplicated interaction while preserving the editorial cue.

The review example explains a choice in the reference component. It is not a claim of a formal team code review. Automated visual regression and accessibility suites remain on the production path below.

06 / HYPOTHESIS & TESTING

Turn preference into a testable question.

For this study, my hypothesis is that one shared content and interaction contract with theme-specific tokens can preserve distinct editorial voices while reducing duplicate implementation work. That has not been tested with real publication teams.

QUALITATIVE TEST

Ask designers and engineers to implement the same card in three brand contexts. Watch where they reach for overrides, and interview them about unclear tokens or props.

QUANTITATIVE SIGNALS

Track component adoption, one-off overrides, time to implement a new voice, and visual or accessibility defects per release. Compare against a baseline before claiming improvement.

DECISION RULE

If teams repeatedly override the same variable, revisit the semantic layer. If a variant changes meaning or interaction, separate it into a distinct component.

This is a proposed evaluation plan. No user study, A/B test, or adoption metric is claimed for the portfolio specimen.

07 / PRODUCTION PATH

What I would build next.

The current specimen demonstrates the separation visually. A real shared library would need typed component APIs, documented content and state rules, and an adoption process across teams. I would take the following steps before calling it a production system:

  1. Token contracts. Define semantic tokens separately from raw palette values, version them, and document intentional brand overrides.
  2. Component API. Build the card in React with typed props for content and permitted variants; avoid brand conditionals inside the markup.
  3. State coverage. Document long headlines, absent media, loading, hover, keyboard focus, and narrow viewports as first-class cases.
  4. Quality gates. Add accessibility checks and visual regression across themes and breakpoints, plus usage examples for designers and engineers.
  5. Governance. Set criteria for new variants, review changes with design and engineering, and track adoption and recurring exceptions.

These are proposed engineering steps. The present portfolio study is a small static specimen and does not claim a React package, Storybook library, automated test suite, or team adoption.

NEXT / PRODUCT DESIGNA publishing workflow shaped by constraints