Back to support

Reviewed guide

Design system audit

A maintained reference for teams reviewing the Scarlet Sync interface.

Checked-in snapshotSource: Maintained Scarlet Sync reference

Scarlet Sync Design System Audit

Date: 2026-06-27

Goal

Scarlet Sync should feel like a calm, information-rich Rutgers command center. The app should help students decide what to do next without burying them in random explanatory text, decorative cards, or noisy stats.

The ideal UI is:

  • dense enough to answer the student's immediate question
  • calm enough to scan repeatedly during the semester
  • explicit about source, freshness, and actionability
  • consistent across scheduling, courses, campus utilities, search, and AI

Audit Scope

Reviewed representative pages and source areas:

  • Dashboard and landing surfaces: /, app/Components/Dashboard/*, app/Components/landing/*
  • Academic tools: /explore, /classes-by-time, /sirs, /degree-search, /degree-planning
  • Campus utilities: /parking, /parking-map, /dining, /events
  • Search and AI: app/Components/UniversalSearch/*, /ai-assistant
  • Shared styling: app/globals.css, app/Components/Button.tsx, app/Components/Modal.tsx

Screenshots were sampled from the local app on localhost:3001; several authenticated routes redirected to login, so those were evaluated mainly through source.

What Exists Today

Strong Patterns

The app already has a recognizable product language:

  • Rutgers scarlet is the main brand accent.
  • Most product pages use a left sidebar plus a main work area.
  • Tool pages often start with a header panel containing an eyebrow, title, short description, and metric cards.
  • Data-heavy areas use compact rows/cards rather than only marketing-style sections.
  • Newer universal search previews have a good pattern: result-specific color, fast summary, enriched detail, and actions.
  • app/globals.css defines useful base tokens and utilities: --scarlet, grouped backgrounds, .card, .input, .btn-primary, .btn-secondary.

Inconsistent Patterns

The system is not yet unified:

  • Many pages bypass shared .card, .input, and button utilities with page-local Tailwind recipes.
  • Border radius varies widely: rounded-lg, rounded-xl, rounded-2xl, rounded-[1.75rem], rounded-[2rem], rounded-3xl.
  • Some pages use calm operational layouts; others use hero/marketing patterns even when the task is a repeated workflow.
  • Button color language is inconsistent. Button.tsx uses green for link/ghost/chip focus states while most product pages use scarlet, blue, emerald, amber, or purple.
  • Cards often look visually similar even when their jobs differ: metric, filter, result, empty state, explanation, and action cards all use comparable weight.
  • Some pages over-explain in prose while others dump raw lists without enough ranking or summary.
  • Loading and error states vary from refined skeletons to plain failed-feed blocks.

Product Surface Findings

Universal Search

This is currently the strongest design direction.

Strengths:

  • Search is fast-first, with richer preview information loading after dwell.
  • Search and Ask now share a single command surface.
  • Preview cards are colorful without becoming noisy.
  • Result-kind color coding gives students a way to understand the type of thing they are looking at.

Risks:

  • The color system is currently local to search and not yet available as reusable design tokens.
  • Preview cards are becoming a de facto pattern; if other pages do not adopt it, search will feel like a different app.

Recommendation:

Use search previews as the prototype for the broader product card system: hero summary, key stats, evidence cards, related actions.

Course Discovery

/explore and /classes-by-time are information-rich, but they need clearer hierarchy.

Strengths:

  • Students can see courses, departments, sections, instructors, campuses, credits, filters, and pagination.
  • /classes-by-time has useful top metrics and a clear workflow around allowed time slots.

Risks:

  • Explore exposes a lot of controls at once; the page can feel like a database table wrapped in cards.
  • Some helper text describes the tool rather than answering a student decision.
  • Result cards need a more consistent "why this matters" area: open sections, requirement fit, professor signal, schedule fit, and next action.

Recommendation:

Course cards should follow a consistent decision hierarchy:

  1. Course identity: code, title, credits.
  2. Availability: open sections, term, campus/time.
  3. Fit: core/degree requirements, prerequisite status, schedule compatibility.
  4. Trust: SIRS signal, data freshness.
  5. Actions: view sections, add to list, snipe, ask about it.

Campus Utilities

Parking and events are close to the right mental model: they are operational tools, not content pages.

Strengths:

  • /parking-map is highly actionable: permit, time, eligible lots, map.
  • /parking explains the purpose clearly and routes to the operational map.
  • /events has source-aware filtering and distinct lanes for clubs, sports, intramurals, and rooms.

Risks:

  • /parking-map is dense but visually heavy: many shadows and color classes compete with the map and lot list.
  • /events has some playful labels and status text that can feel loud when the data feed fails.
  • Error states currently reveal reliability problems but do not always give a useful next step.

Recommendation:

Campus utility pages should prioritize "Can I use this right now?" over broad descriptive framing. Keep source/freshness visible and make fallback actions explicit.

Dashboard

The dashboard has many useful widgets, but it needs a stricter information architecture.

Strengths:

  • It pulls together schedule, degree, research, map, room search, snipes, and assistant entry points.
  • Widgets are task-oriented and can become a strong "today" command center.

Risks:

  • Widget styles vary by component.
  • Too many equally weighted blocks can make it hard to tell what needs attention first.
  • Some cards are shortcuts rather than information-rich summaries.

Recommendation:

Dashboard sections should be ordered by urgency:

  1. Today / next class / transit risk.
  2. Active alerts: snipes, deadlines, blocked schedule issues.
  3. Academic progress: degree, prerequisites, course lists.
  4. Discovery: research, rooms, events.
  5. Utility shortcuts.

AI Assistant

The AI assistant should feel less like a separate chatbot and more like the expansion of the command layer.

Strengths:

  • Search now routes task-like input into Ask Scarlet.
  • Assistant artifacts already support schedule and degree outputs.

Risks:

  • The full assistant route and lightweight popup/search surfaces are not yet visually unified.
  • AI prompts can feel open-ended instead of grounded in the exact student context.

Recommendation:

Use the same "answer, evidence, actions" card grammar in AI responses. AI should create artifacts, comparisons, and next-step cards more often than prose-only replies.

Design System Problems To Solve

1. Card Overuse Without Card Roles

Many pages use cards for everything. That makes the page feel tidy at first but harder to scan because every block has similar visual importance.

Needed card roles:

  • Summary card: key answer and top action.
  • Metric tile: one number, label, and optional delta/source.
  • Result row/card: compact repeated item.
  • Filter panel: controls only, visually quiet.
  • Evidence card: source-backed details.
  • Empty/error state: explanation plus recovery action.

2. Too Much Explanatory Copy

Some text explains what the page is rather than what the student can decide.

Replace generic copy like:

  • "Browse live campus events..."
  • "Search by course name..."
  • "Use transit context..."

With decision-support copy like:

  • "Showing 30 events after 5 PM near College Ave."
  • "3 open sections fit your blocked times."
  • "This permit is valid in 113 lots right now."

3. No Shared Density Rules

Some pages are sparse and promotional; others are dense and raw.

Use a density ladder:

  • Level 1: headline answer and primary action.
  • Level 2: 2-4 key facts needed for a decision.
  • Level 3: supporting evidence, source, freshness, caveats.
  • Level 4: expanded rows/details only after click, hover, dwell, or filter.

4. Inconsistent Color Meaning

Color should communicate type or state, not decorate randomly.

Current colors often mean different things across pages. Proposed meanings:

  • Scarlet: primary Scarlet Sync action, selected state, urgent academic action.
  • Blue: schedule/time/navigation context.
  • Emerald: available, eligible, open, successful.
  • Amber: caution, SIRS/quality signal, time-sensitive warning.
  • Purple: AI, degree planning, synthesis.
  • Slate: neutral containers and inactive controls.

5. Weak Source/Freshness Language

Students need to know what is live, cached, scraped, or approximate.

Every data-heavy surface should show source/freshness in a compact way:

  • Course data: term and dataset.
  • SIRS: years/responses.
  • Parking: permit rules, not live occupancy.
  • Events: source and last attempted refresh.
  • Bus/rooms/dining: live endpoint status or fallback.

Recommended North Star

Scarlet Sync should feel like:

"A Rutgers student operations cockpit: calm, fast, source-aware, and action-first."

Avoid:

  • marketing sections inside operational tools
  • decorative stat cards that do not change a decision
  • filler copy that describes the page but not the student's situation
  • equal-weight grids where everything competes
  • one-off visual systems per route

Prefer:

  • compact summaries with proof
  • visible source and freshness
  • progressive disclosure for dense data
  • consistent card roles
  • command/search/AI as the cross-app interaction layer