---
name: Work Plan
type: planning
status: living
depends_on: [aleris-design-system-open-questions.md]
propagates_to: []
open_questions: []
last_verified: 2026-03-21
---

# Aleris Product Design Skill — Work Plan

A plan for building a shareable, tool-agnostic design reference that gives anyone building digital products at Aleris the best possible starting point — without needing to carry the full reasoning behind every decision in their head.

---

## What we're building

Three layers that work together but can be consumed independently:

1. **Token Reference** — immutable design variables. Colors, spacing, radii, typography, shadows, states. Sourced from Figma, published as CSS custom properties. No opinions here, just facts.

2. **Design Governance** — the principles and reasoning behind Aleris product decisions. Structured by certainty level (Fixed / Anchor / Hypothesis) with two reading paths: beginner (give me the answer) and expert (explain the reasoning and tensions). Covers both patient-facing and internal tool contexts.

3. **Anti-Pattern Guide** — what Aleris is not. Concrete examples of framework defaults vs. Aleris choices. What to override when starting a project with any component library.

These three layers get packaged as a skill (for Claude/Cowork) and as a standalone document set (for ChatGPT, Cursor, Codex, or any other AI coding tool). Single source of truth, multiple consumption formats.

---

## Why this matters

People across the organisation are building digital products with AI assistance. They think they're asking for visual design direction, but what they actually need is a way to make product decisions that are consistent with Aleris values — without having sat through years of conversations about why things are the way they are.

Without this, every new project starts from framework defaults and gets Aleris colors painted on top. The result looks templated, not intentional. And the reasoning about privacy, accessibility, progressive enhancement, and emotional design gets lost because it lives in one person's head.

---

## Inventory: what exists and what's missing

### Exists (strong, reusable)

| Material | Location | Covers | Reuse plan |
|---|---|---|---|
| Figma token exports | Uploaded CSS files | Global primitives + component-level semantic aliases | Becomes the canonical token reference (Phase 1) |
| ALERIS-DESIGN-WORKING.md | /aleris/ | Fixed/Anchor/Hypothesis structure, non-negotiables, color system, typography, voice, emotional modes, trust architecture | Core scaffold for governance document (Phase 2) |
| aleris-patient-product-design-guidelines.md | /aleris/ | Full visual system, component specs, animation, forms, AI chat, patient vs. staff patterns | Detailed implementation reference — extract and restructure (Phase 2) |
| Product Build Checklist | /frameworks/ | Tech-agnostic 8-stage shipping framework, inclusive design checklist, error resilience, i18n-from-day-one | Integrate as the "how to ship" layer (Phase 2) |
| Aleris Brand Core 2025.md | /aleris/chatgpt-agents/ | Vision, mission, values, positioning, brand personality, audience definitions | Brand foundation — reference for voice and positioning sections |
| healthcare-ux skill | Skills folder | Scandinavian healthcare UX patterns, calm design, pattern library by category | Reference patterns for both patient and internal contexts |
| design-thinking-frameworks skill | Skills folder | DDO, Relational Change, Liminal Thinking, Products People Actually Want, emotional design | Conceptual toolkit — connect to Aleris-specific applications |
| Impact Mapping Framework | /frameworks/ | Goal → Actor → Impact → Deliverable | Product scoping method — integrate into governance |
| research-methodology skill | Skills folder | JTBD, Value Proposition Canvas, Kano Model, Cynefin, evidence hierarchy | Framework references — codify Aleris-specific usage |
| aleris-progressive-enhancement.md | /3-resources/ | Progressive enhancement as foundational design principle — four application levels (technical capability, surface temperature, patient contexts, token architecture), distinction from graceful degradation | Core philosophy for governance document section 1 (Phase 2). Fixed certainty level. |
| aleris-token-governance-frameworks.md | /3-resources/ | CSS custom properties as canonical token format, Tailwind as optional consumption layer, governance rules for token changes, multi-context distribution (full stack / WordPress / AI / vibecoding / future unknown), Tailwind v4 @theme integration | Governance rules feed directly into Phase 2 section 2 (non-negotiables) and Phase 3 (anti-patterns). Open questions inform Phase 4 distribution strategy. |
| aleris-privacy-jtbd-analysis.md | /3-resources/ | JTBD analysis of privacy across patient (self-data) and clinician (work-data) domains. Concrete component patterns: masked input, patient ID, tiered export, purpose-request, access log, tap-to-reveal, notification templates. Proportional confirmation mapped to escalation framework. Tensions between domains documented. Hypothesis certainty level — desk research, not user-validated. | Covers Phase 2 section 1 (privacy-first as design principle) and section 4 (privacy component patterns). Demonstrates JTBD applied to a specific Aleris domain. Work-data patterns feed Phase 2b (internal tools). |
| **Den nära experten — röstguide (4 delar)** | /3-resources/ | | |
| 1-den-nara-experten-karnguid.md | /3-resources/ | Core voice definition: "den nära experten" as communication stance. Five principles: patient as subject, structure follows patient journey, directness without distance, clinical info explained not dumped, legal/clinical protection separate. AI system guidance. Swedish. | **Referenced, not embedded.** Market-specific voice layer. Design system points to this for Swedish tone guidance. Covers Phase 2 section 3 (voice principles). |
| 2-den-nara-experten-dokumenttyper.md | /3-resources/ | Voice applied per document genre: kallelse, patientguide, hälsodeklaration, brev, presentation. Anti-patterns per genre. Swedish. | **Referenced, not embedded.** Content writing guidance — stays separate from product design system. Hälsodeklaration section has form design implications. |
| 3-den-nara-experten-digital-rost-v2.md | /3-resources/ | Digital voice and micro-copy: button labels (verb phrases), error messages (what happened + what to do), confirmations (no thank-you phrases), empty states (explain + next), placeholder text rules, chat voice, "no Scandinavian AI-smicker" anti-pattern. Swedish. | **Partially embedded.** Micro-copy patterns are component specifications regardless of language. Design system references these patterns in component guidance. "AI-smicker" anti-pattern feeds Phase 3. |
| 4-den-nara-experten-digital-behavior-v1.md | /3-resources/ | Digital product behavior: medical boundary, phase awareness, referral logic, AI chat guardrails, consent handling, progression locks, inline feedback (not modals), status handling. English. Draft status. | **Integrated.** Language-independent behavior principles feed directly into Phase 2: AI guardrails → section 2 (non-negotiables), phase awareness and referral logic → section 4 (design patterns), inline feedback → connects to escalation framework. |
| aleris-anti-patterns.md | /3-resources/ | 10 behavioral/ethical anti-patterns for healthcare digital products: consent asymmetry, cost burial, urgency fabrication, obstacle withdrawal, informational hiding, data maximalism, default escalation, emotional exploitation, exit penalty, notification coercion. Machine-readable Never/Because/Instead structure. Smell test (4 questions). Anti-pattern log template. Fixed certainty level. English. | **Phase 3 core document** — covers ethical/behavioral anti-patterns. Still needed: visual/framework anti-patterns (shadcn defaults vs. Aleris identity, white backgrounds vs. sand, rectangular buttons vs. pills). These two dimensions (behavioral + visual) likely combine into one Phase 3 deliverable. Note: pattern 5 (Informational Hiding) creates a progressive disclosure exception that Phase 2 governance must reference. |
| **Patient guide project — technical review** | Conversation context (Mar 2026) | Reference implementation: Next.js 16 + React 19 + Tailwind 4 + Base UI + CVA. Three-layer tokens, adaptive responsive strategy (component swap not just scaling), three-level keyboard model (global/component/tab), operational status palette (emerald/violet/amber/rose), 150ms ease-out animations, RBAC navigation, print/reduced-motion support, 27 UI components. | **Validation evidence** for multiple design system decisions. Informs OQ-01 (responsive), OQ-04 (status palette), OQ-07 (keyboard), OQ-11 (animation), OQ-12 (component architecture), OQ-13 (role-based UI). First real product measured against the token system. |
| aleris-design-system-open-questions.md | /3-resources/ | Living document tracking open questions and experiments. 17 open questions, 11 resolved. Questions move Open → In Progress → Resolved with evidence. | **Cross-cutting.** Not a phase deliverable — a persistent tracking document that feeds all phases. |
| aleris-grids-tables-dataviz.md | /3-resources/ | 12-column grid spec (surface temperature controls utilization not structure), breakpoints (640/768/1024/1280px), container queries preferred. Read vs Work table distinction with complete token set (3 density levels, header quieter than data, privacy-aware identifier placement). Five dataviz principles (Tufte-inspired, Aleris-translated): show data then stop, natural comparison, intentional color, annotate the important, respect reader's time. Chart typography and spacing using token system. DDR for all major decisions. | **Resolves OQ-01 (grid) and OQ-03 (tables).** Grid tokens and table component tokens added to aleris-tokens.css. Dataviz principles feed Phase 2 section 4 (design patterns) and Phase 3 (anti-patterns — pie charts, dual axes, 3D, dashboard overload as visual anti-patterns). Raises 4 new questions: OQ-14 (small multiples responsive), OQ-15 (density persistence), OQ-16 (sequential color ramp), OQ-17 (reference implementations). |

### Exists (needs reconciliation)

| Issue | Details |
|---|---|
| Token naming mismatch | Figma uses 100/300/500 scale. Existing docs use 40/60/80. **Decision: adopt Figma naming.** |
| Color values in multiple places | At least 4 documents define the color palette with minor variations. **Action: Figma becomes single source, docs updated.** |
| Tailwind-coupled specifications | Existing docs describe everything in Tailwind utility classes (rounded-xl, bg-sand). **Action: describe in framework-agnostic terms with Tailwind as one mapping example.** |
| Phantom tokens | cream (#FBF7F4), status-success (#4F866E), status-warning (#D9B48F), status-info (#004851) appear in docs but not in Figma export. **Decision: remove. If needed later, add to Figma first.** |

### Missing (needs to be created)

| Gap | Why it matters | Phase |
|---|---|---|
| Progressive enhancement as a foundational design principle | Building from the simplest functional layer upward. Each layer of complexity enriches the experience but is never required for the base to work. Applies across technical capability (43 units, varying digital maturity), surface temperature (instrumental as complete base, communicative as expressive addition), patient contexts (complete service on any device/connection), and the token architecture itself (primitives always work, semantic adds meaning, surface mode adds context). Not graceful degradation — the direction matters. See `aleris-progressive-enhancement.md`. | 2 |
| Privacy-first as a UX design principle | Goes beyond PII handling rules to shape what we collect, what we show, consent UX, data minimization in interfaces. **Partially covered:** `aleris-privacy-jtbd-analysis.md` provides JTBD-structured hypothesis with concrete component patterns and design principles. Needs validation through user research and codification into governance document. | 2 |
| Jobs to Be Done as an Aleris product lens | Not as a generic framework but as "this is how Aleris decides what to build and for whom." Connected to emotional modes. **Partially covered:** privacy analysis demonstrates JTBD applied to a specific domain. Still needed: JTBD as a general product evaluation method for Aleris, connected to emotional modes and surface temperature. | 2 |
| Product-market fit thinking | How Aleris evaluates whether a digital product should exist. What questions to ask before building. | 2 |
| Internal tools design guidance | Clinician and admin interfaces have different needs: density, efficiency, keyboard navigation, domain terminology, speed over calm. Currently no documented principles. | 2b |
| Anti-pattern library | Concrete examples: "this is what a booking flow looks like with shadcn defaults" vs. "this is Aleris." What to override, what to keep, what to build custom. **Partially covered:** `aleris-anti-patterns.md` provides 10 behavioral/ethical anti-patterns (dark patterns in healthcare). Still needed: visual/framework anti-patterns — side-by-side comparisons of framework defaults vs. Aleris for buttons, cards, forms, navigation, colors, shadows, backgrounds. | 3 |
| Accessibility-as-practice guide | WCAG 2.1 AA is stated as a requirement, but there's no practical guidance for beginners who've never built accessible interfaces. | 2 |
| Framework-agnostic component specifications | Current specs are Tailwind-native. Need descriptions that translate to any CSS approach. | 1 |
| Tone and voice as a separate, market-specific layer | English codebases, but patient-facing communication adapts to SE/NO/DK cultural specifics. The governance doc needs to reference this without embedding it. **Covered:** Den nära experten guide (4 parts) provides the complete Swedish voice layer. Design system references it for tone guidance; micro-copy patterns from part 3 are embedded as component specs; behavior principles from part 4 integrated into governance. NO/DK adaptations still needed. | 2 |

---

## Phase plan

### Phase 1: Canonical Token Reference

**Input:** Figma CSS exports (global-tokens-default.css, component-tokens-default.css)
**Output:** Single authoritative token file + human-readable mapping document

Work:
- Restructure Figma export into a clean two-layer CSS custom properties file (primitives + semantic aliases)
- Add missing semantic tokens that the component layer implies but doesn't fully cover (e.g., text hierarchy, shadow levels)
- Create a mapping table: token name → hex value → usage description → Tailwind equivalent (as one example, not the source of truth)
- Document the naming convention and scale system (100 = light/tint, 300 = mid, 500 = full)
- Flag any tokens that need to be added back to Figma (if the surface temperature system needs status colors, that's a Figma-first addition)

Deliverable: `aleris-tokens.css` + `aleris-token-reference.md`

### Phase 2: Design Governance Document

**Input:** ALERIS-DESIGN-WORKING.md, aleris-patient-product-design-guidelines.md, Product Build Checklist, Brand Core 2025, aleris-progressive-enhancement.md, aleris-token-governance-frameworks.md, aleris-privacy-jtbd-analysis.md, 3-den-nara-experten-digital-rost-v2.md (micro-copy patterns), 4-den-nara-experten-digital-behavior-v1.md (product behavior), design-thinking-frameworks skill, research-methodology skill
**Output:** Single governance document with beginner/expert paths

Structure (draft):

```
1. What Aleris builds and why
   - Progressive enhancement (build from the simplest functional layer upward — the base is complete, not minimal; complexity is earned, not assumed; capability differences are normal, not exceptional)
   - Jobs to Be Done as product lens (what job is the patient/clinician hiring this for?)
   - Product-market fit (when should a digital product exist at all?)
   - Privacy-first (data minimization, consent-as-design, collect only what serves the user)

2. Non-negotiables (Fixed)
   - Clinical data and PII separation
   - Accessibility baseline (with practical beginner guidance)
   - Multi-language architecture
   - AI guardrails

3. Brand anchors (Anchor)
   - Visual identity → references token file, not inline values
   - Voice principles (English codebase, market-specific tone layer)
   - Emotional mode framework (anxiety-driven, aspiration-driven, latent anxiety)
   - Trust architecture sequences

4. Design patterns (Anchor → Hypothesis)
   - Progressive disclosure
   - Inline feedback
   - Component shapes and their reasoning
   - Animation principles
   - Form and input patterns

5. Building and shipping
   - Integrated from Product Build Checklist
   - Error resilience
   - Testing infrastructure
   - i18n from day one

6. Open questions and things we're still learning
   - Voice AI interaction design
   - Cross-country visual variation
   - Physical-to-digital transitions
```

Each section has:
- **Beginner block:** The decision, stated plainly. "Do this. Here's an example."
- **Expert block:** The reasoning, the tensions, what's validated vs. hypothesised, what needs testing.

### Phase 2b: Internal Tools Design Guidance

**Input:** Conversations, existing staff-facing patterns in patient product guidelines, healthcare-ux skill
**Output:** Section within governance document or companion document

This is structured as a delta from the patient-facing principles:

| Principle | Patient-facing | Internal tools |
|---|---|---|
| Information density | Progressive disclosure, one thing at a time | Higher density acceptable, overview-first |
| Animation | Calm, 300-500ms, breathing | Minimal, 150-200ms, functional only |
| Language | Plain language, no jargon | Domain terminology acceptable, brevity valued |
| Navigation | Linear guided flows | Keyboard-navigable, shortcut-friendly |
| CTAs | One primary per screen | Multiple actions acceptable, clear hierarchy |
| Feedback | Inline, never modals | Brief confirmation, non-blocking |
| Emotional register | Calm, reassuring, anxiety-reducing | Efficient, confident, low-friction |
| Touch targets | 48px preferred | Standard (minimum 44px for hybrid touch/mouse) |

### Phase 3: Anti-Pattern Guide

**Input:** All of the above + real examples of framework defaults
**Output:** Standalone reference document

Structure:
- What "templated" looks like and how to spot it
- Per-framework override guide (what to change when starting with Tailwind, shadcn, Material, vanilla CSS)
- Side-by-side comparisons: default vs. Aleris for common patterns (buttons, cards, forms, navigation, tables, dashboards)
- The Aleris visual signature: what makes something look like Aleris vs. "healthcare startup template"
- Common mistakes: raw Tailwind colors, default shadows, rectangular buttons, white backgrounds, generic icons, stock photography

### Phase 4: Skill Packaging and Distribution

**Input:** All Phase 1-3 outputs
**Output:** Claude skill + portable document set

- Claude/Cowork skill that reads the canonical files and applies them in context
- Document set formatted for ChatGPT custom instructions (single-file version with token reference inline)
- Cursor rules file (.cursorrules) with the same principles
- README explaining which file to use where
- Versioning strategy: how updates propagate from source of truth to all consumption formats

---

## Decisions made

1. **Token naming:** Follow Figma's 100/300/500 scale. Update all documentation to match.
2. **Phantom tokens:** Remove cream, status-success, status-warning, status-info from docs. Figma is the source of truth. Add back to Figma first if needed.
3. **Language:** All English for codebases, variables, and documentation. Tone and voice guidance references market-specific layers (SE/NO/DK) without embedding them.
4. **Framework coupling:** Describe everything in framework-agnostic terms. Tailwind mappings provided as examples, not as the specification.
5. **Scope:** Both patient-facing and internal tools from the start. Internal tools as a delta from patient-facing principles.

## Decisions still needed

1. **Surface temperature system** — the Figma component tokens have surface-100-neutral/warm/cold and surface-500-neutral/warm/cold. Is this actively used in current designs? Should it be part of the canonical system or is it exploratory?
2. **Gray scale** — Figma has gray-100 (#d7d2cb), gray-300 (#9e9281), gray-500 (#585044). The docs only reference the lightest as "slate." Do we use the full gray scale?
3. **Warning vs. error** — Figma has a single warning-100 (#c14444). The docs distinguished between error (#C25450) and warning (#D9B48F). Which is correct?
4. **Typography tokens** — the Figma exports don't include typography. Are there typography tokens in Figma, or does that need to be defined here?
5. **Internal tools** — who are the primary users right now? What tools are being built? This shapes the guidance we write.

---

## Existing material that stays separate

These materials are valuable but serve different purposes and shouldn't be folded into this skill:

- **Patientinformation modules** (01_core through 04_exempelreferens) — content writing guidance, not product design
- **Tonalitetsguide** — Swedish-language communication guide, referenced from the tone layer but not embedded
- **ORSC/coaching frameworks** — organisational development, not product design
- **PDF frameworks** (Service Blueprinting, Design Thinking Methods, etc.) — reference library, not Aleris-specific guidance

---

*Work plan created March 2026. Torfinn Almers, Head of Design, Aleris Group.*