---
name: Open Questions & Experiments
type: planning
status: living
depends_on: [aleris-tokens.css, aleris-design-governance.md, aleris-grids-tables-dataviz.md, aleris-baseline-animation.md, aleris-baseline-images.md]
propagates_to: [index.html, aleris-product-design-skill-workplan.md]
open_questions: [OQ-02, OQ-04, OQ-05, OQ-06, OQ-07, OQ-09, OQ-10, OQ-12, OQ-13, OQ-14, OQ-21, OQ-23, OQ-24]
last_verified: 2026-03-21
---

# Aleris Design System — Open Questions & Experiments

A living document. Questions move from Open → In Progress → Resolved as the design system develops. Each question has enough context to be actionable without reading the full document set.

---

## Open Questions — Actionable

These can move forward with design work, experiments, or the next product build.

### OQ-04: Operational real-time status palette

**Blocking:** Internal tools guidance, token system
**Experiment:** Inventory operational statuses across 2–3 Aleris products. Map to: (a) patient guide palette (emerald/violet/amber/rose), (b) chart palette subset, (c) consolidated palette. Evidence from patient guide project confirms operational status needs its own palette — softer than traffic light.

---

### OQ-06: Internal voice register — "den nära chefen"

**Blocking:** Internal tools micro-copy
**Experiment:** Write 5 common internal tool micro-copy strings in three registers (warm-colleague, competent-manager, neutral-system). Test with clinical staff. The voice guide gap is real — internal tools legitimately require actions, which conflicts with "erbjud, kräv inte."

---

### OQ-07: Keyboard navigation patterns

**Blocking:** Internal tools guidance, accessibility-as-practice
**Starting point:** Patient guide project's three-level model (global shortcuts / component-level / standard tab). Cmd+K Command Palette worth codifying for instrumental surfaces. Focus ring: `focus-visible` + petrol-500 ring + 2px offset confirmed. `aria-invalid` → red ring confirmed.
**Remaining:** Cross-product keyboard continuity mapping. Standardize global shortcuts across products.

---

### OQ-09: Responsive type scale compression

**Blocking:** Responsive design guidance
**Experiment:** Render full type scale on 375px viewport. Test perfect fourth (1.33) as mobile alternative. h1 at 60px is likely too large for mobile — does h2 (40px) become the ceiling? At what breakpoint?

---

### OQ-12: Component architecture patterns

**Blocking:** Framework-agnostic component specs
**Resolution path:** Document compound components, CVA variants, and slot pattern as abstract principles in governance doc. Patient guide project = reference implementation. Framework mappings in companion docs. The slot pattern (data-slot) is CSS-native and the strongest candidate for a cross-framework standard.

---

### OQ-13: Role-based UI filtering

**Blocking:** Internal tools guidance, privacy patterns
**Resolution path:** Document as Anchor pattern in governance. Connect to privacy JTBD (what data each role sees) and escalation model (what actions each role takes). Patient guide project provides reference implementation with 4-role RBAC.

---

### OQ-24: Icon library — Font Awesome Pro subset

**Blocking:** Component specs, any UI that needs icons
**Context:** The token system references `--font-family-icons: 'Font Awesome 6 Pro'` but no guidance exists on which icons to use, how to subset from 7,000+ icons, or naming conventions for icon usage in Aleris products. This is design exploration work — need to inventory icon needs across products, select a working subset, and document usage patterns (when to use solid vs regular vs light, size conventions, accessibility labeling).
**Resolution path:** Audit 2–3 products for icon usage, select a curated subset, document in a reference file. Consider whether a custom icon set is needed long-term or if Font Awesome Pro covers the domain.

---

## Parked — Waiting for External Input or Evidence

These won't move until products ship, infrastructure decisions are made, or specific experiments can be run. One line each — full context in version history if needed.

| ID | Question | Waiting for |
|----|----------|-------------|
| OQ-02 | Selectable density beyond tables | Evidence from products — monitor as they're built. Core model (scanning vs attending) resolved as Anchor. |
| OQ-05 | Multi-window / multi-system context | Screenshot of actual clinician desktop setup for mockup testing |
| OQ-10 | Museo Sans rendering at 27px | Render test on Windows/macOS/Android. Low priority. |
| OQ-14 | Small multiples responsive behavior | Viewport test at 375px with real chart data |
| OQ-21 | Shared image CDN | Infrastructure decision — outside design system scope |
| OQ-23 | CMS image pipeline (Optimizely) | Optimizely investigation — outside design system scope |

---

## Resolved Questions

| ID | Question | Resolution | Date | Evidence |
|---|---|---|---|---|
| RQ-01 | √φ vs perfect fifth for type scale | Perfect fifth (1.5) adopted. Better system coherence, shared ratio with spacing. | Mar 2026 | aleris-typography-spacing-scale.md |
| RQ-02 | 12px minimum or 14px floor | 14px floor. Fixed accessibility requirement. | Mar 2026 | Token system review |
| RQ-03 | Three or four heading levels | Four. h4 at 22px (geometric mean). Instrumental surfaces need nested structure. | Mar 2026 | Token system review |
| RQ-04 | Font weight 400 in Museo Sans | Doesn't exist. Regular = 500. Never use 400. | Mar 2026 | woff2 file inventory |
| RQ-05 | Token naming: 40/60/80 or 100/300/500 | 100/300/500 (Figma convention). | Mar 2026 | Figma export review |
| RQ-06 | Phantom tokens (cream, status-success, etc.) | Removed. Figma is source of truth. | Mar 2026 | Figma export review |
| RQ-07 | Warning vs error color confusion | error-500 = #c14444 (red), warning-500 = #d9b48f (sand/amber). | Mar 2026 | Figma + docs reconciliation |
| RQ-08 | "Procedural enhancement" as design principle | Replaced with "progressive enhancement" — established term, better system fit. | Mar 2026 | aleris-progressive-enhancement.md |
| RQ-09 | CSS custom properties vs framework as token source | CSS custom properties canonical. Frameworks consume, never define. | Mar 2026 | aleris-token-governance-frameworks.md |
| RQ-10 | Grid system (12-col, gutters, breakpoints, max-width) | 12-column grid, spacing-token gutters, surface temperature controls utilization. Breakpoints: 640/768/1024/1280px. Container queries preferred. | Mar 2026 | aleris-grids-tables-dataviz.md |
| RQ-11 | Table component tokens | Three density levels (36/48/64px), header quieter than data (xs/uppercase), cell padding from spacing tokens, zebra striping optional (sand-100). Read vs Work table distinction. | Mar 2026 | aleris-grids-tables-dataviz.md |
| RQ-12 | Progressive disclosure exception for risk communication | Progressive disclosure is for UI complexity; risk communication is always inline and immediate. Risks, costs, limitations are never progressively disclosed. Codified in governance document Section 6. | Mar 2026 | aleris-design-governance.md, aleris-anti-patterns.md pattern 5 |
| RQ-13 | Animation timing and motion system | Four-tier duration model: instant (100ms), fast (200ms), moderate (350ms), slow (500ms). Two easing curves: ease-out for arrivals, ease-in-out for movement. Only animate transform + opacity (GPU). Skeleton shimmer over spinners. `prefers-reduced-motion: reduce` disables all (Fixed, a11y). Supersedes earlier two-tier model. | Mar 2026 | aleris-tokens.css, aleris-baseline-animation.md |
| RQ-14 | Adaptive responsive strategy | Component swap at breakpoints, not just scaling. Tables→card stacks, popovers→sheet drawers, sidebars→toggle panels. Z-index hierarchy codified: base(0) → dropdown(10) → sticky(20) → sidebar(30) → search(40) → topbar(50) → modal(100) → toast(110). 4px grid alignment maintained through spacing token scale. Container queries preferred. | Mar 2026 | aleris-tokens.css, aleris-design-governance.md §4.4 |
| RQ-15 | Table density persistence | Density (compact/default/comfortable) persists as user preference via localStorage or profile setting. Reflects personal working style, not per-task choice. Key: `aleris-table-density`, default: `default` (48px). Anchor certainty — validate with user research. | Mar 2026 | aleris-tokens.css, aleris-grids-tables-dataviz.md |
| RQ-16 | Email animation | No animation in email. Email clients lack reliable CSS animation support. All Aleris email communications use static layouts. Constraint, not limitation — design for static rendering from the start. | Mar 2026 | aleris-baseline-animation.md |
| RQ-17 | Motion audit in design review | Yes. Every animation states its purpose and references a Baseline motion token. Line item in design review, not a separate process. If an animation can't be justified in one sentence, remove it. Anchor certainty. | Mar 2026 | aleris-baseline-animation.md |
| RQ-18 | Dataviz reference implementations | Written principles sufficient for AI-assisted development (primary consumer). Visual good/bad examples deferred until a real product dashboard exists. Anti-pattern examples belong in Phase 3. Anchor certainty. | Mar 2026 | aleris-grids-tables-dataviz.md |
| RQ-19 | Skeleton component approach | Baseline provides skeleton primitives (rectangle, circle, text-line) as token-driven building blocks. Shimmer animation standardized: single gradient sweep, --motion-duration-moderate (350ms), ease-in-out. Products compose primitives to match their layouts. No generic "loading page" skeleton. Anchor certainty. | Mar 2026 | aleris-tokens.css, aleris-baseline-animation.md |
| RQ-20 | Sequential color ramp for heatmaps | Parked. No current Aleris product requires heatmaps or map visualizations. If needed, derive a 5-step ramp from petrol scale. Reopen when a real use case appears. | Mar 2026 | aleris-grids-tables-dataviz.md |
| RQ-21 | Clinical vs marketing image quality | Different requirements. Clinical/medical images use higher quality or lossless PNG for diagnostic integrity. Marketing/editorial uses AVIF 75-80 with format cascade (AVIF → WebP → JPEG). Distinction is content-type driven, not surface-type driven. Anchor certainty. | Mar 2026 | aleris-baseline-images.md |
| RQ-22 | Scanning vs attending density model | Density for instrumental surfaces = scanning vs attending. Density comes from layout utilization and information hierarchy, not spacing compression. Table density user-selectable as power-user override. Sub-question remains: does selectable density extend beyond tables? Anchor certainty — core model resolved. | Mar 2026 | aleris-tokens.css, aleris-grids-tables-dataviz.md, aleris-design-governance.md |

---

*Living document. Updated as questions emerge and resolve.*
*Maintainer: Torfinn Almers, Head of Design, Aleris Group.*