Improvements & Lessons Learned

Table of contents

Lessons learned (final presentation)

  1. Diversity is not a feature, it is a mindset. (German original: „Diversität ist kein Feature, sondern ein Mindset!”) Diversity cannot be “ticked off” as a single work package — it influenced the data model, scenario design, 3D modeling (e.g. vein visibility by skin type), and the UI alike.
  2. Diversity makes real challenges visible. („Diversität macht reale Herausforderungen sichtbar.”) Only through diverse patient profiles did the professionally most valuable scenarios emerge (interpreter decision, child bed, bariatric bed, dementia sensor mat).
  3. Existing code brings its own challenges. („Bestehender Code bringt besondere Herausforderungen mit sich.”) Entering an unfamiliar, sparsely documented codebase cost analysis time before features became possible — the analysis documents created at project start (now part of this documentation) were decisive for that.
  4. Early project organization creates clarity. („Frühzeitige Projektorganisation schafft Klarheit.”) The target agreement only arrived in week 9; unclear or changing requirements before that cost time (see critical evaluation).

Critical evaluation (from the final presentation)

What worked What did not work
Integration of different patient models into the existing VR application A clear separation between must-have and wish-list features was partly missing
Diversity aspects (age, gender, skin color, child models) implemented in alignment with stakeholders Requirements changed during the project or were interpreted differently
Migration from SQLite to PostgreSQL improved scalability and maintainability A project contract with clearly defined requirements came too late

Process improvements for future projects

  • Fix requirements in writing before development starts — target agreement in the first weeks instead of week 9.
  • Accessibility as a Definition-of-Done criterion from the start, not as a downstream work package.
  • Record architecture decisions as ADRs (see Design Decisions) instead of reconstructing them later.
  • Prepare backup demos: the backup video proved its worth as a safety net at the interim presentation.

Technical improvement ideas (backlog for future teams)

Idea Benefit Starting point
Switch Unity to WebSocket push No more 1 s polling, lower latency websocket/Events.ts already defines the vr client type
Error catalog as the single source No manual syncing of frontend/Unity/backend error_definitions table already exists
Automated tests + CI Regression protection during further development No tests exist so far
Docker Compose setup One-command onboarding Setup documentation as the basis
Hint system Didactic value Priority logic (TryGetHighestPriorityRemainingError) exists
AI patient conversations / multilingualism Scenario expansion Detailed feasibility study with three solution approaches and Unity roadmaps, in German: KI-Machbarkeitsstudie (PDF)
Further accessibility features Inclusive training for all trainees Written assessment with prioritized recommendations (wheelchair perspective, avatar, two-senses principle, …), in German: Assessment Barrierefreiheit (DOCX)

Information sources

Last build: 19 Aug 2026, 05:20+00:00


This site uses Just the Docs, a documentation theme for Jekyll.