Wer sich im Winter abseits der präparierten Pisten oder auch nur in einem grösseren Skigebiet bewegt, ist auf eine Vielzahl von Informationen angewiesen. Die aktuelle Lawinenwarnstufe wird vom Institut für Schnee- und Lawinenforschung (SLF) publiziert, das Wetter kommt von MeteoSchweiz oder privaten Diensten, der Status der einzelnen Pisten und Bahnen wird von den Bergbahnbetreibern selbst kommuniziert, und kurzfristige Warnungen erreichen die Wintersportler oft nur über regionale Radiosender oder Aushänge an der Talstation. Diese Informationen sind zwar grundsätzlich öffentlich zugänglich, liegen aber auf unterschiedlichen Websites, in unterschiedlichen Apps und in unterschiedlicher Aufbereitung vor.
Aus eigener Erfahrung und aus Gesprächen in unserem Umfeld wissen wir, dass genau dieser Umstand im Alltag am Berg zu Problemen führt. Wer früh am Morgen in der Gondel steht, hat weder die Zeit noch die Datenverbindung, um drei oder vier verschiedene Dienste abzufragen. Oft werden einzelne Quellen dann schlicht weggelassen, was im schlechtesten Fall bedeutet, dass eine akute Warnung nicht wahrgenommen wird. Dieses strukturelle Problem der verteilten Informationen bildete den Ausgangspunkt für unsere Vertiefungsarbeit.
Hinzu kommt, dass viele der etablierten Dienste primär für den Desktop-Browser optimiert sind und sich auf dem Smartphone mit Handschuhen schlecht bedienen lassen. Das Lawinenbulletin ist in seiner offiziellen Form textlastig und erfordert Vorwissen, um es richtig einzuordnen. Pistenkarten grosser Skigebiete sind oft als statische PDF-Dokumente hinterlegt, die bei schlechter Datenverbindung kaum zu öffnen sind. Wetterwarnungen kommen über Push-Benachrichtigungen generischer Wetter-Apps und sind selten auf das konkrete Gebiet zugeschnitten, in dem sich der Nutzer gerade befindet. In Summe entsteht eine Situation, in der zwar viele gute Einzelinformationen existieren, die Zusammenführung aber dem Nutzer selbst überlassen bleibt.
Wir haben uns deshalb die Frage gestellt, ob sich die für Wintersportler relevanten Daten nicht sinnvoll an einem Ort bündeln lassen, und zwar so, dass sie gebietsspezifisch abrufbar sind. Nicht jede Information ist überall gleich relevant: Eine Sturmwarnung für das Oberengadin ist für jemanden in Arosa nicht direkt nützlich, eine Lawinenwarnung für die Region Glarus betrifft nur bestimmte Touren. Die Idee einer App, die automatisch oder nach manueller Gebietswahl die jeweils relevanten Daten anzeigt, lag daher nahe.
SlopeSafe ist aus diesem Gedanken heraus als sogenannte One-Stop-App konzipiert, also als Anwendung, in der sämtliche sicherheitsrelevanten Informationen für einen Skitag oder eine Skitour an einer Stelle zusammengeführt werden. Der Anspruch war von Anfang an, dass ein Nutzer die App öffnet, sein Gebiet sieht oder auswählt und innerhalb weniger Sekunden einen vollständigen Überblick über Lawinenlage, Wetter, Pistenstatus und aktive Warnungen erhält. Zusätzlich sollte ein klar sichtbarer Notfall-Bereich zur Verfügung stehen, der im Ernstfall die wichtigsten Nummern, die eigene Position und gegebenenfalls die nächste Rettungsstation anzeigt, damit die Bedienschritte bis zum Absetzen eines Notrufs minimal bleiben.
Die Zielgruppe haben wir bewusst breit definiert. SlopeSafe richtet sich nicht nur an erfahrene Tourengängerinnen und Tourengänger, sondern ebenso an Gelegenheits-Skifahrer, Snowboarder und Familien, die sich auf den markierten Pisten bewegen. Das bedeutet, dass die App sowohl die vertiefte Information bieten muss, die erfahrene Nutzer erwarten, als auch eine Benutzeroberfläche, die ohne Vorwissen verständlich ist. Diese doppelte Anforderung hat die Entwicklung während des gesamten Projekts stark geprägt.
Als Leitbild haben wir die drei Begriffe "gebündelt", "gebietsspezifisch" und "verständlich" festgelegt. Gebündelt bedeutet, dass die Kernfunktionen ohne App-Wechsel erreichbar sein müssen. Gebietsspezifisch heisst, dass die Informationen automatisch oder nach manueller Auswahl auf das aktuelle Skigebiet zugeschnitten sind. Verständlich meint, dass auch ein Nutzer ohne einschlägige Vorbildung die wichtigste Kernaussage auf den ersten Blick erfassen kann. An diesen drei Leitbegriffen haben wir im Zweifelsfall Designentscheidungen gemessen.
Als inhaltliche Referenz diente uns die bestehende Anwendung White Risk des SLF. White Risk ist ein ausgezeichnetes Werkzeug für die Lawinenbeurteilung, richtet sich in seiner Tiefe aber vor allem an eine fachlich vorgebildete Zielgruppe. Die App stellt Bulletin, Gefahrenkarte und Planungswerkzeuge zur Verfügung, bündelt aber weder das aktuelle Wetter im engeren Sinn noch den Pistenstatus einzelner Skigebiete. Wer sich auf der Piste bewegt, findet dort nur einen Teil der für ihn relevanten Informationen.
SlopeSafe grenzt sich von White Risk bewusst dadurch ab, dass es die Lawinenwarnung als eine von mehreren gleichwertigen Informationsebenen behandelt. Das Lawinenbulletin des SLF wird über die offizielle Schnittstelle eingebunden, aber vereinfacht dargestellt und mit Wetter-, Pisten- und Notfallfunktionen kombiniert. Unser Ziel war nicht, White Risk zu ersetzen, sondern eine niederschwellige Alltagsanwendung für Wintersportler zu schaffen, die im Bedarfsfall auf die Fachanwendung verweist. Für die anspruchsvolle Tourenplanung bleibt White Risk die erste Adresse; SlopeSafe soll dagegen auch dann noch sinnvoll sein, wenn der Nutzer keine Tour plant, sondern einfach nur einen Skitag auf der Piste verbringen will.
Gleichzeitig war uns von Beginn an klar, dass wir kein fachliches Beurteilungsniveau erreichen können, das mit dem SLF vergleichbar wäre. Die Lawinenstufe zeigen wir deshalb immer mit einem kurzen Erklärtext und einem Verweis auf das Originalbulletin, damit Nutzer bei Bedarf weiterrecherchieren können. Die redaktionelle Verantwortung für die Warnung selbst bleibt vollständig beim SLF; SlopeSafe agiert an dieser Stelle ausschliesslich als aufbereitende Anzeige.
Bevor wir mit der Entwicklung der App begonnen haben, wollten wir unsere Annahmen über die Bedürfnisse der Zielgruppe quantitativ absichern. Dazu haben wir eine Online-Umfrage über Microsoft Forms erstellt und diese zwischen dem 25. Februar und dem 1. März 2026 verteilt. Die Umfrage wurde über unsere persönlichen Netzwerke, über zwei Skiclubs in der Region, über den internen Verteiler einer regionalen Skischule sowie über einen Aushang an einer Bergbahnkasse geteilt. Die Teilnahme war freiwillig und anonym, die durchschnittliche Bearbeitungszeit lag bei rund vier Minuten.
Insgesamt haben 133 Personen den Fragebogen vollständig ausgefüllt. Der Fragebogen war in drei Blöcke gegliedert: demografische Angaben und Wintersportverhalten, inhaltliche Bedürfnisse zu Sicherheit, Notfall und Navigation sowie eine abschliessende offene Frage zu Bedenken und zur "einen unverzichtbaren Funktion". Für die quantitativen Teilfragen zur Wichtigkeit einzelner Themen haben wir eine fünfstufige Likert-Skala von "1 = unwichtig" bis "5 = sehr wichtig" verwendet, für die Funktionsauswahlen Mehrfachauswahl-Listen mit der Möglichkeit einer Ergänzung im Freitext. Die Auswertung haben wir in einer Tabellenkalkulation sowie mit einem kleinen Python-Skript durchgeführt, mit dem wir Mehrfachnennungen sauber trennen konnten.
Bei der Interpretation muss berücksichtigt werden, dass unsere Stichprobe nicht repräsentativ für die Schweizer Wintersportbevölkerung ist. Einerseits ist sie durch die Rekrutierung über unsere Netzwerke tendenziell jünger als der Durchschnitt, andererseits sind Fachgruppen wie Bergführerinnen, Skilehrer und Mitarbeitende von Bergbahnen deutlich stärker vertreten, als sie es in einer zufälligen Stichprobe wären. Das war für unsere Fragestellung nicht hinderlich, im Gegenteil: Diese Gruppen lieferten besonders wertvolle Rückmeldungen zu den Anforderungen im professionellen Alltag. Die Ergebnisse sollten aber als qualitatives Stimmungsbild und nicht als repräsentative Statistik gelesen werden.
Die Zusammensetzung der 133 Teilnehmenden war bewusst breit angelegt. Rund 79 Prozent gaben an, sich primär als Skifahrerin oder Snowboarder im Freizeitbereich zu verstehen. 12 Prozent ordneten sich als Bergführerinnen oder Skilehrer ein, rund 5 Prozent als Mitarbeitende der Pisten- oder Bergrettung und jeweils 2 Prozent als Liftpersonal beziehungsweise als Wettkampfsportler. Diese Verteilung ist für die Interpretation wichtig, weil die fachlich geprägten Gruppen andere Anforderungen an die App haben als Gelegenheitsnutzer. Insbesondere bei den Fragen zum Notfall-Bereich und zum Bedarf an Rettungsstationen zeigte sich, dass Fachpersonen tendenziell höhere Ansprüche an die Genauigkeit und Dokumentationspflicht stellen als Freizeitnutzer.
[BILD-PLATZHALTER: Kreisdiagramm Verteilung der Rollen]
Bei der Frage nach der Anzahl Pistentage pro Saison zeigte sich eine bemerkenswert aktive Gruppe: 24 Prozent gaben mehr als 30 Pistentage pro Saison an, weitere 28 Prozent zwischen 16 und 30 Tagen und 32 Prozent zwischen 6 und 15 Tagen. Nur etwa 17 Prozent waren höchstens fünf Tage pro Saison auf der Piste unterwegs. Im Gelände ist das Bild erwartungsgemäss anders: 38 Prozent sind nur ein bis fünf Tage pro Saison abseits markierter Pisten unterwegs, 14 Prozent gar nicht, während 11 Prozent angaben, zwischen 16 und 30 Geländetage zu sammeln, und 9 Prozent mehr als 30. Diese Mischung aus Vielfahrern, Gelegenheitsnutzern und einer substantiellen Gruppe mit Geländeerfahrung bildete die Basis für die Auswertung der Funktionswünsche.
[BILD-PLATZHALTER: Balkendiagramm Pistentage und Geländetage im Vergleich]
Auf die Frage, ob die Teilnehmenden bereits Apps im Wintersport-Kontext nutzen, antworteten rund 23 Prozent ausdrücklich mit "nein", während der grösste Teil der positiven Antworten auf White Risk und Swisstopo entfiel. Vereinzelt wurden auch Bergfex, Slopes, Skiline, Infosnow und die Wetter-App von MeteoSchweiz genannt. Auffällig war, dass kein einziger Teilnehmer eine App nannte, die alle unsere Kernthemen gleichzeitig abdeckt. Damit war unsere Ausgangshypothese empirisch gestützt: Eine integrierte Lösung gibt es in der wahrgenommenen App-Landschaft nicht.
Das zentrale Ergebnis der Umfrage waren die Funktionen, mit denen sich die grösste Deckung zwischen Nutzerbedürfnissen und unserem Projektumfang ergab. Bei den Sicherheitsinformationen gab es ein klares Ranking. 87 Prozent der Teilnehmenden nannten die aktuelle Lawinenwarnstufe für das eigene Gebiet als eine der nützlichsten Informationen, 58 Prozent konkrete Wetterwarnungen zu Sturm, Sichtbehinderung und Kälte, 55 Prozent Informationen zu Schneebeschaffenheit und Pistenzustand, 48 Prozent gesperrte Pisten und Lifte in Echtzeit, und 35 Prozent Gefahrenstellen-Meldungen von anderen Nutzenden. Auf der Likert-Skala zur reinen Lawinengefahr vergaben rund 61 Prozent die höchste Wichtigkeit (Stufe 5) und weitere 18 Prozent Stufe 4; insgesamt stuften damit rund 79 Prozent die Lawinenwarnung als "wichtig" oder "sehr wichtig" ein.
[BILD-PLATZHALTER: Balkendiagramm Top-Sicherheitsinformationen]
Beim Notfall-Bereich stand der klassische SOS-Button mit GPS-Standortübermittlung mit 82 Prozent an erster Stelle, gefolgt von der Möglichkeit, Notfallkontakte zu hinterlegen und zu benachrichtigen (55 Prozent), sowie der Anzeige der nächsten Rettungsstation beziehungsweise Pistenrettung (55 Prozent). Eine automatische Unfallerkennung durch Sensoren wünschten sich immerhin 12 Prozent, allerdings oft in Kombination mit Bedenken zu Fehlalarmen. Auf der Skala zur Wichtigkeit eines Notfall-Buttons mit automatischer Standortübermittlung vergaben 57 Prozent Stufe 5 und 18 Prozent Stufe 4, insgesamt also 75 Prozent "wichtig" oder "sehr wichtig".
Die Bereitschaft, die eigene GPS-Position zu teilen, fiel überraschend hoch aus: 57 Prozent gaben an, dies "dauerhaft" zu akzeptieren, weitere 38 Prozent "nur im Notfall aktivierbar", nur 5 Prozent lehnten eine Positionsteilung ab. Bei der Frage, ob Nutzer Gefahrenstellen wie Eisplatten, Steine oder schlechte Sicht selbst in der App melden würden, antworteten jeweils 42 Prozent mit "ja, auf jeden Fall" und "vielleicht", und 16 Prozent mit "nein". Diese Antworten haben wir als klares Signal gewertet, dass ein Meldesystem mit community-basiertem Beitrag grundsätzlich Akzeptanz findet, aber sorgfältig gestaltet werden muss, damit die unentschlossene Hälfte tatsächlich teilnimmt.
Bei den Navigationsfunktionen führte die interaktive Pistenkarte mit Echtzeit-Status mit 66 Prozent die Liste an, gefolgt von der Markierung von Hütten, Toiletten und Erste-Hilfe-Stationen (61 Prozent), Live-Wartezeiten an Liften (56 Prozent), Offpiste- und Freeride-Routenvorschlägen (44 Prozent) sowie Routenplanungsfunktionen wie "einfachste Abfahrt" oder "schnellste Route" (30 Prozent). Eine reine Pistenfilterung nach Schwierigkeitsgrad und Zustand stuften nur 28 Prozent auf Stufe 4 oder 5 ein; die Mehrheit sah diese Funktion als "mittel wichtig" oder weniger.
[BILD-PLATZHALTER: Balkendiagramm Navigationsfunktionen]
Bei den Community-Funktionen war das Bild heterogener. 50 Prozent würden ein Gruppen-Tracking nutzen, um Freunde auf der Piste zu sehen, 41 Prozent würden Gefahrenmeldungen mit anderen Nutzenden teilen, 32 Prozent fänden Bewertungen und Kommentare zu Pisten attraktiv, 23 Prozent wollten ausdrücklich keine Community-Funktionen. Diese hohe "Opt-out"-Quote war für uns ein wichtiger Hinweis darauf, dass Community-Funktionen klar optional und gut abgegrenzt implementiert sein müssen.
Die Auswertung bestätigte unsere ursprüngliche Annahme, dass der Bedarf an gebündelten Sicherheitsinformationen real ist und über die Tourengeher-Szene hinausreicht. Besonders aufschlussreich war die Freitextfrage nach der "einen Funktion, die SlopeSafe unverzichtbar machen würde": Die Antworten kreisten überwiegend um die Verknüpfung verschiedener Informationen an einem Ort, um die unmittelbare Verfügbarkeit der Lawineninformation sowie um einen zuverlässigen Notruf. Mehrere Teilnehmende schrieben wörtlich sinngemäss, dass sie heute mehrere Apps nebeneinander nutzen und sich eine zentrale Lösung wünschen; einige räumten offen ein, dass sie an einzelnen Tagen ganz auf die Informationsbeschaffung verzichten, weil sie ihnen zu aufwändig sei.
Ebenfalls aussagekräftig war die Frage nach Bedenken gegenüber einer solchen App. Rund 27 Prozent der Teilnehmenden antworteten explizit "nein" oder "keine". Unter den geäusserten Bedenken dominierte die Akkulaufzeit; Datenschutz wurde deutlich seltener genannt, als wir es erwartet hatten. Vereinzelt wurden Sorgen vor Ablenkung beim Fahren oder vor einer falschen Sicherheit durch Technik angesprochen. Diese Rückmeldung hat die spätere Arbeit an der App in mehrfacher Hinsicht beeinflusst. Sie hat uns erstens bestätigt, dass eine datenschutzfreundliche Grundhaltung zwar Pflicht, aber kein Alleinstellungsmerkmal ist. Zweitens hat sie uns gezwungen, das Akkuverhalten der App früh ernst zu nehmen, insbesondere im Hinblick auf GPS-Nutzung und Hintergrundaktivität. Drittens hat sie uns darin bestärkt, die Oberfläche so zu gestalten, dass sie minimal Aufmerksamkeit bindet, solange keine akute Warnung vorliegt.
Aus der Gesamtauswertung haben wir fünf Kernfunktionen definiert, an denen sich die weitere Entwicklung orientieren sollte: erstens die aktuelle Lawinenwarnstufe für das eigene Gebiet, zweitens Wetterwarnungen zu Sturm, Sichtbehinderung und Kälte, drittens der Echtzeit-Pistenstatus mit gesperrten Pisten und Liften, viertens eine gebietsspezifische Karte, die diese Informationen in einer Ansicht zusammenführt, und fünftens ein Notfall-Bereich mit prominent platziertem SOS-Auslöser, Anzeige der nächsten Rettungsstation und der Möglichkeit, Notfallkontakte zu hinterlegen. Diese Priorisierung hat auch die Platzierung auf dem Startscreen geprägt: Die Lawinenstufe steht an oberster Stelle, weil sie als wichtigste Einzelinformation eingestuft wurde, während weniger nachgefragte Funktionen wie eine reine Pistenfilterung nach Schwierigkeitsgrad bewusst in Unterseiten verschoben wurden.
Aus den Erkenntnissen der Umfrage und aus den besonderen Rahmenbedingungen des Wintersports haben wir drei Designprinzipien abgeleitet, an denen sich alle späteren Entscheidungen orientieren mussten. Das erste Prinzip ist Klarheit: Eine Information muss auf den ersten Blick lesbar sein, auch für Nutzer, die die App zum ersten Mal öffnen. Das zweite Prinzip ist schnelle Erreichbarkeit, insbesondere im Notfall. Der Notfall-Bereich muss ohne Suchen zu finden und bedienbar sein, auch mit Handschuhen. Das dritte Prinzip ist Lesbarkeit unter schwierigen Bedingungen, also bei direkter Sonneneinstrahlung auf Schnee sowie bei schlechtem Licht im Nebel oder in der Dämmerung.
Diese Prinzipien haben konkrete Konsequenzen für das Design. Wir haben uns für grosse Schaltflächen, klare Schrifttypen ohne dekorative Elemente und einen hohen Farbkontrast entschieden. Die Standardschriftgrösse wurde gegenüber gängigen Web-Anwendungen deutlich erhöht, und alle interaktiven Elemente erreichen mindestens die empfohlene Mindestfläche von 48 mal 48 Pixeln, viele sogar mehr. Der Hintergrund ist in allen Ansichten dunkel gehalten, weil dunkle Flächen bei Sonneneinstrahlung weniger blenden und den Akku mobiler Geräte mit OLED-Displays messbar schonen. Die Schrift selbst ist in einem hellen, leicht wärmer abgestimmten Weiss gehalten, das bei langen Betrachtungen weniger ermüdet als reines Weiss auf Schwarz.
Ein viertes, später ergänztes Prinzip war Robustheit gegenüber ungünstiger Verbindung. Auf dem Berg ist die Datenverbindung nicht verlässlich, und eine App, die dann zur leeren Seite wird, verliert ihren Nutzen. Sämtliche Ansichten müssen daher auch mit unvollständigen oder veralteten Daten arbeiten können und dies dem Nutzer klar kenntlich machen. Diese Anforderung wirkte sich nicht nur auf die Technik aus, sondern auch auf die Gestaltung: Jeder Informationsblock musste einen Platzhalter für den Fall "Daten nicht verfügbar" und eine Anzeige für das Alter der Daten vorsehen.
Das Farbkonzept musste zwei Anforderungen erfüllen. Einerseits wollten wir eine eigenständige visuelle Identität, andererseits mussten die etablierten Farben der Lawinenwarnstufen übernommen werden, da diese in der Schweiz und im gesamten Alpenraum standardisiert sind und Nutzer sie bereits kennen. Die fünfstufige Skala reicht von einem hellen Grün für die Stufe 1 (gering) über Gelb (2, mässig), Orange (3, erheblich) und Rot (4, gross) bis zu einem dunklen Rot für die Stufe 5 (sehr gross). Diese Farben haben wir unverändert übernommen und auch in der Legende entsprechend beschriftet.
Für die übrige Oberfläche haben wir eine zurückhaltende Palette gewählt, damit die Warnfarben nicht mit dem Interface konkurrieren. Als Primärfarbe dient ein gedecktes Navy-Blau, das an klare Winterhimmel erinnert, als Akzentfarbe ein helleres Sky-Blue sowie ein warmes Orange, das wir gezielt für Handlungsaufforderungen einsetzen. Die Trennung zwischen Warn- und Interface-Farben hat sich als wichtig erwiesen, weil die Nutzer in unseren ersten Tests ansonsten Schwierigkeiten hatten, zwischen "Bedienelement" und "Warnhinweis" zu unterscheiden. In der finalen Version wird die Warnfarbe Rot ausschliesslich in Verbindung mit einer inhaltlichen Warnung verwendet, niemals für neutrale Schaltflächen.
Neben den reinen Farbwerten haben wir uns auch Gedanken zur Zugänglichkeit für Menschen mit Farbsinnstörungen gemacht. Die Lawinenskala allein auf Farbbasis lesen zu müssen, wäre für Rotgrün-Schwache ein Problem. Wir haben deshalb die Stufennummer in grosser Schrift direkt auf der Farbfläche angebracht und zusätzlich eine kurze Textbezeichnung ("gering", "mässig", "erheblich" etc.) eingeblendet. Diese redundante Codierung stellt sicher, dass die Warnstufe unabhängig vom Farbsinn verständlich bleibt.
Vor der eigentlichen Gestaltung haben wir das Grundgerüst der App mit Wireframes in Figma entworfen. Wireframes sind stark vereinfachte Bildschirmskizzen, die nur Position, Hierarchie und Interaktionslogik der Elemente zeigen, aber bewusst auf Farbe und fertige Typografie verzichten. Diese Abstraktion war uns wichtig, um die Struktur vor der Gestaltung abzuschliessen und nicht durch visuelle Entscheidungen abgelenkt zu werden.
Insgesamt haben wir drei Wireframe-Iterationen durchlaufen. In der ersten Version war der Notfall-Bereich nur über das Menü erreichbar, was wir nach interner Diskussion verworfen haben. In der zweiten Version lag er als fester Balken am unteren Bildschirmrand, was aber die Pistenkarte überlagerte. Die dritte Version, die wir schliesslich umgesetzt haben, platziert die Notfallfunktionen als eigene, prominent beschriftete Kachel auf dem Startscreen und zusätzlich als kreisförmigen, halbtransparenten Knopf in der rechten unteren Ecke der Kartenansicht. Er ist jederzeit sichtbar, verdeckt aber nur einen kleinen Teil der Karte. Diese Lösung hat sich in den späteren Nutzertests bewährt.
[BILD-PLATZHALTER: Wireframe Startscreen]
Parallel zu den Wireframes haben wir uns früh mit der Informationsarchitektur auseinandergesetzt, also mit der Frage, wie viele Ebenen die App haben darf und welche Information auf welcher Ebene liegt. Unsere Vorgabe war, dass jede der fünf Kernfunktionen aus der Umfrage höchstens zwei Klicks vom Start entfernt sein darf. Diese Vorgabe hat mehrere Design-Entwürfe verworfen, die zwar visuell ansprechender waren, aber mehr Klicktiefe erforderten.
Parallel zu den Wireframes haben wir die zwei wichtigsten User Flows dokumentiert, also die typischen Abfolgen von Bildschirmen, die ein Nutzer für eine bestimmte Aufgabe durchläuft. Der erste Flow beschreibt den Normalfall: Nutzer öffnet die App, das System erkennt über die Geolocation-API (eine Browserschnittstelle zur Abfrage der aktuellen Position) das aktuelle Gebiet automatisch, und der Startscreen zeigt die Lawinenstufe, die aktuelle Wetterlage und allfällige Warnungen. Mit einem einzigen Tippen gelangt der Nutzer auf die Pistenkarte mit den Detailinformationen.
Der zweite Flow beschreibt den Notfall. Nach einem Tippen auf den Notfall-Button erscheint ein Bestätigungsdialog mit einem Drei-Sekunden-Countdown, damit versehentliche Auslösungen vermieden werden. Bestätigt der Nutzer, zeigt die App die aktuellen Koordinaten in lesbarem Format, die Rega-Notrufnummer mit direktem Wähllink, die nächste eingetragene Pistenrettung des aktuellen Gebiets sowie eine Übersicht der hinterlegten Notfallkontakte. Eine direkte automatisierte Alarmierung der Rega oder ein automatischer SOS-Versand an Drittpersonen war in der aktuellen Version bewusst nicht implementiert; die Gründe dafür werden in Kapitel 5 ausführlich besprochen.
Zusätzlich zu diesen zwei Hauptabläufen haben wir drei weitere Flows skizziert, die wir für relevante Sonderfälle hielten: das Wechseln des Gebiets, das Hinterlegen eines Notfallkontakts und das Meldeformular für Gefahrenstellen. Der dritte Flow war uns wichtig, weil die Umfrage gezeigt hatte, dass die Hälfte der Teilnehmenden eine solche Meldefunktion "vielleicht" nutzen würde; die Hürde bis zur Abgabe muss also niedrig gehalten werden. Wir haben deshalb das Meldeformular auf zwei Pflichtfelder reduziert (Art der Gefahr und Position, wobei letztere automatisch vorbelegt ist) und alle weiteren Angaben optional gemacht.
Auf Basis der Wireframes haben wir fünf Mockups in voller Gestaltung erstellt, die als Vorlage für die spätere Implementierung dienten. Die wichtigsten Screens sind der Startscreen mit den zusammengefassten Informationen, die interaktive Pistenkarte mit farbig eingefärbten Pisten und Warnsymbolen, der Notfall-Screen mit SOS-Bestätigung und Kontakten, der Wetterwarnungs-Screen mit zeitlicher Prognose sowie der Einstellungsbereich, in dem Nutzer ihr bevorzugtes Gebiet und Benachrichtigungsoptionen verwalten können.
[BILD-PLATZHALTER: Mockup Pistenkarte]
[BILD-PLATZHALTER: Mockup Notfall-Screen]
[BILD-PLATZHALTER: Mockup Wetterwarnungen]
Besonders bei der Pistenkarte haben wir mehrere Varianten getestet. Die erste Variante zeigte die Pisten in ihren realen Schwierigkeitsfarben (blau, rot, schwarz), was aber mit den Lawinenwarnfarben kollidierte. Die finale Variante zeigt die Pistenschwierigkeit als kleinen Punkt am Anfang der Piste, während die Pistenlinie selbst den aktuellen Status durch ihre Farbintensität anzeigt: volle Sättigung für "offen", halbe Transparenz für "teilweise offen" und ausgegraut für "geschlossen". Warnungen werden durch separate Symbole überlagert, die mit dem Lawinenfarbsystem konsistent sind. Gefahrenstellen-Meldungen aus der Community erscheinen als dritte Symbolklasse und sind dadurch auf einen Blick von offiziellen Warnungen unterscheidbar.
SlopeSafe folgt einer klassischen Client-Server-Architektur mit zusätzlicher Echtzeit-Kommunikationsschicht. Der Client ist eine im Browser laufende Web-App, die wir mit React implementiert haben. Der Server ist eine Node.js-Anwendung auf Basis von Express, die einerseits eine REST-API (eine standardisierte Schnittstelle für die Kommunikation zwischen Client und Server über HTTP-Aufrufe) für die meisten Anfragen bereitstellt und andererseits eine WebSocket-Verbindung für Echtzeit-Updates unterhält. Die persistente Datenhaltung erfolgt in einer PostgreSQL-Datenbank, die sich für die relationalen Beziehungen zwischen Gebieten, Pisten und Warnungen besser eignete als eine dokumentenbasierte Alternative.
Zwischen Client und Server liegt eine Authentifizierungsschicht auf Basis von JSON Web Tokens (JWT). Diese Technik übermittelt nach dem Login einen signierten Token, den der Client bei jeder weiteren Anfrage mitsendet. Der Server kann den Token prüfen, ohne für jede Anfrage die Datenbank konsultieren zu müssen, was die Antwortzeiten reduziert. Externe Datenquellen wie das SLF-Lawinenbulletin oder der Wetterdienst werden ausschliesslich vom Backend abgefragt, nicht vom Client direkt. Das hat zwei Vorteile: Erstens können wir die externen Antworten zwischenspeichern, zweitens bleiben allfällige API-Schlüssel auf dem Server und tauchen nicht im Browser auf.
[BILD-PLATZHALTER: Architektur-Diagramm]
Eine bewusste Entscheidung war, die App nicht als native iOS- oder Android-Anwendung umzusetzen, sondern als Progressive Web App (PWA) — also eine Webanwendung, die sich wie eine native App installieren und nutzen lässt, aber über den Browser ausgeliefert wird. Die Gründe waren pragmatisch: Wir konnten mit einem einzigen Codebestand beide grossen Plattformen bedienen, benötigten keinen App-Store-Review für jede Änderung, und die in der Umfrage von 72 Prozent geäusserte Zurückhaltung gegenüber zusätzlichen Installationen spielte in unsere Richtung. Der Preis dieser Entscheidung war, dass wir auf einige native Sensoren verzichten mussten, insbesondere auf Hintergrund-Tracking und automatische Unfallserkennung, was in Kapitel 5 näher erläutert wird.
Das Frontend ist in React als Single-Page-Application (eine Webanwendung, die ohne klassische Seitenwechsel auskommt) aufgebaut. Wir haben die Anwendung in wiederverwendbare Komponenten zerlegt, die sich grob in drei Ebenen gliedern. Die oberste Ebene bilden die Seitenkomponenten, also beispielsweise die Startseite, die Pistenkarte oder die Einstellungen. Darunter liegen bereichsspezifische Komponenten wie das Warnungspanel oder die Wetterkachel. Die unterste Ebene besteht aus generischen Basiskomponenten wie Buttons, Dialogen und Eingabefeldern.
Die Komponenten kommunizieren über definierte Schnittstellen, sogenannte Props, und verwenden für bereichsübergreifenden Zustand eine zentrale State-Management-Lösung. Nach einer Abwägung zwischen Redux, Zustand und der in React eingebauten Context API haben wir uns für die Kombination aus Context API und gezielt eingesetzten Zustand-Stores entschieden. Die Context API reichte für die Authentifizierung und Gebietsauswahl aus, während für die häufig aktualisierten Pistenstatus-Daten ein Zustand-Store mit feinerer Kontrolle über Re-Renderings sinnvoller war. Eine vollständige Redux-Lösung hätten wir für den Projektumfang als Überdimensionierung betrachtet.
Das Routing, also die Navigation zwischen den verschiedenen Ansichten, übernimmt React Router. Wir haben fünf Haupt-Routen definiert: die Startseite, die Pistenkarte, die Warnungsübersicht, die Einstellungen und einen geschützten Bereich für angemeldete Nutzer, in dem persönliche Favoriten und Notfallkontakte verwaltet werden. Alle Routen sind so gestaltet, dass sie auch ohne Anmeldung die Kernfunktionen anzeigen; nur die personalisierten Funktionen erfordern einen JWT-Token. Diese Entscheidung war bewusst, weil eine Zwangsanmeldung die Einstiegshürde erhöht hätte — gerade der Gelegenheitsnutzer, der die App zum ersten Mal öffnet, soll unmittelbar Nutzen sehen, ohne ein Konto anlegen zu müssen.
Das Backend ist als Node.js-Anwendung mit dem Framework Express implementiert. Alle öffentlichen Endpoints liegen unter dem Pfadpräfix /api/v1/, was uns erlaubt, in einer späteren Version eine /api/v2/ parallel zu betreiben, ohne bestehende Clients zu brechen. Die Routen sind nach Ressourcen gruppiert: Unter /api/v1/resorts liegen die Gebietsdaten, unter /api/v1/pistes die Pistenstatus, unter /api/v1/alerts die Warnungen, unter /api/v1/reports die Gefahrenmeldungen aus der Community und unter /api/v1/auth die Authentifizierung. Jede Ressource ist in einer eigenen Datei implementiert, was die Wartbarkeit erhöht.
Express erlaubt es, Anfragen durch eine Kette von sogenannten Middleware-Funktionen zu leiten, bevor sie die eigentliche Route erreichen. Wir haben drei zentrale Middlewares implementiert. Die Auth-Middleware prüft bei geschützten Routen den JWT-Token und hängt die Nutzerinformationen an das Request-Objekt. Die Logging-Middleware schreibt strukturierte Log-Einträge in eine Datei, damit wir im Betrieb nachvollziehen können, welche Anfragen wann eintrafen und wie lange sie dauerten. Die Error-Handling-Middleware fängt alle in den Routen geworfenen Fehler ab und übersetzt sie in einheitliche JSON-Antworten mit passendem HTTP-Statuscode. Zusätzlich haben wir eine einfache Rate-Limiting-Middleware eingebaut, die pro IP-Adresse eine bestimmte Anzahl Anfragen pro Minute erlaubt, um das Backend gegen Überlastung oder simple Missbrauchsversuche zu schützen.
Das Datenbankschema ist so ausgelegt, dass es die Beziehungen zwischen den zentralen Entitäten klar abbildet. Die Tabelle users enthält die Nutzerkonten mit E-Mail-Adresse, gehashtem Passwort, bevorzugtem Gebiet und Benachrichtigungseinstellungen. Die Tabelle resorts bildet die Skigebiete ab, inklusive Name, Kanton, geografischer Bounding Box und Verweis auf das zugehörige SLF-Warngebiet. Die Tabelle pistes enthält die einzelnen Pisten eines Gebiets mit Schwierigkeitsgrad, Länge und aktuellem Status; sie ist über eine Fremdschlüsselbeziehung mit resorts verknüpft.
Für die Warnungen haben wir zwei Tabellen unterschieden. avalanche_warnings speichert die vom SLF abgerufenen Bulletins mit Gültigkeitszeitraum, Warnstufe und betroffenen Höhenlagen. weather_warnings speichert die Wetterwarnungen des externen Dienstes. Beide Tabellen sind zeitlich versioniert, das heisst ältere Bulletins werden nicht überschrieben, sondern mit einem valid_until-Feld archiviert. Damit können wir im Nachhinein nachvollziehen, welche Warnung zu einem bestimmten Zeitpunkt in der App sichtbar war. Die Tabelle hazard_reports speichert die von Nutzern gemeldeten Gefahrenstellen mit Ortsangabe, Art der Gefahr, optionaler Fotoreferenz und Verfallsdatum, sowie die Tabelle emergency_contacts die pro Nutzer hinterlegten Notfallkontakte.
[BILD-PLATZHALTER: ER-Diagramm der Datenbank]
Bei der Modellierung haben wir uns bewusst gegen eine weitgehende Normalisierung entschieden, wenn sie die Lesbarkeit der Abfragen spürbar verschlechtert hätte. Die Standortkoordinaten etwa liegen direkt in den jeweiligen Tabellen statt in einer separaten Geodatentabelle. Dafür nutzen wir die PostGIS-Erweiterung von PostgreSQL, die räumliche Abfragen wie "alle aktiven Gefahrenmeldungen innerhalb einer Bounding Box" effizient ermöglicht.
Ein zentraler Teil der Entwicklung war die Integration externer Datenquellen. Das Lawinenbulletin des SLF wird über die offizielle Schnittstelle abgerufen und alle zwanzig Minuten aktualisiert. Da das SLF-Bulletin zweimal täglich veröffentlicht wird, ist diese Aktualisierungsfrequenz grosszügig bemessen, vermeidet aber, dass ein kurz nach dem Update gestarteter Client veraltete Daten erhält. Für Wetterdaten haben wir uns für OpenWeatherMap entschieden, da MeteoSchweiz zwar hochwertige Daten liefert, aber keine niederschwellig zugängliche API für den nicht-kommerziellen Gebrauch bereitstellt. Für die Kartendarstellung nutzen wir die Leaflet-Bibliothek in Kombination mit OpenStreetMap-Kacheln; Mapbox hatten wir in einer frühen Phase evaluiert, aber zugunsten der lizenzfreien Lösung verworfen.
Alle externen Aufrufe laufen über einen zentralen Service im Backend, der Antworten für eine konfigurierbare Dauer im Arbeitsspeicher zwischenspeichert. Das reduziert sowohl die Latenz für die Clients als auch die Last auf den externen Diensten. Fällt eine externe API aus, liefert der Service die zuletzt bekannte Antwort mit einem Hinweis auf das Alter der Daten. Diese Strategie hat sich im Testbetrieb bewährt, als OpenWeatherMap während einer Stunde nicht erreichbar war und die App dennoch die letzte gültige Prognose anzeigen konnte.
Für den Pistenstatus haben wir keine universelle externe Quelle gefunden, die über alle Schweizer Skigebiete hinweg strukturierte Echtzeit-Daten liefert. Bergbahnen publizieren ihre Betriebslage in sehr unterschiedlichen Formaten, von strukturierten JSON-Feeds bis zu unstrukturierten HTML-Tabellen. In der aktuellen Version beschränkt sich SlopeSafe deshalb auf eine überschaubare Liste von Skigebieten, für die wir einen Parser implementiert haben oder bei denen ein maschinenlesbarer Feed verfügbar ist. Die Auswirkungen dieser Beschränkung besprechen wir in Kapitel 5.
Für die Aktualisierung des Pistenstatus setzen wir Socket.io ein, eine Bibliothek für bidirektionale Kommunikation zwischen Browser und Server über WebSockets. Sobald ein Pistenstatus im System geändert wird — sei es durch einen automatischen Feed-Parser oder durch ein internes Eingabewerkzeug — wird die Änderung in der Datenbank gespeichert und über Socket.io an alle verbundenen Clients verteilt, die das betroffene Gebiet aktuell angezeigt haben. Diese zielgerichtete Auslieferung erreichen wir dadurch, dass sich Clients beim Öffnen der Pistenkarte in einen Socket.io-Raum für ihr Gebiet einschreiben und beim Verlassen wieder austragen.
Die gleiche Infrastruktur nutzen wir für akute Warnungen und für neue Gefahrenmeldungen aus der Community. Wird eine neue Sturm- oder Lawinenwarnung im System erfasst oder reicht ein Nutzer eine Gefahrenmeldung ein, erhalten alle betroffenen Clients die Information innerhalb weniger Sekunden, ohne die App neu laden zu müssen. Damit ist SlopeSafe in der Lage, auf Lageänderungen deutlich schneller zu reagieren, als dies mit klassischem Polling (regelmässige Abfrage in festen Intervallen) möglich wäre.
Die Authentifizierung basiert wie erwähnt auf JSON Web Tokens. Bei der Registrierung wird das Passwort mit dem Verfahren bcrypt gehasht, bevor es in der Datenbank abgelegt wird. Beim Login prüft das Backend das Passwort gegen den gespeicherten Hash und gibt bei Erfolg einen signierten Token mit einer Gültigkeit von zwei Stunden zurück. Zusätzlich wird ein längerlebiger Refresh-Token als HTTP-Only-Cookie gesetzt, mit dem der Client ohne erneute Passworteingabe einen neuen Zugriffstoken anfordern kann. Diese Trennung reduziert das Risiko, dass ein gestohlener Zugriffstoken dauerhaft missbraucht werden kann.
Exemplarisch zeigen wir drei kurze Ausschnitte aus dem Projekt. Der erste stammt aus dem Backend und implementiert die Route zum Abruf des aktuellen Lawinenbulletins für ein Gebiet:
router.get('/api/v1/resorts/:id/avalanche', async (req, res, next) => {
try {
const warning = await avalancheService.getCurrent(req.params.id);
res.json(warning);
} catch (err) {
next(err);
}
});Der zweite Ausschnitt zeigt eine React-Komponente, die die Lawinenstufe visuell anzeigt und bei Änderungen automatisch neu rendert:
function AvalancheBadge({ level }) {
const colors = ['#CCFF66', '#FFFF00', '#FF9900', '#FF0000', '#9D0000'];
return (
<div className="badge" style={{ backgroundColor: colors[level - 1] }}>
Stufe {level}
</div>
);
}Der dritte Ausschnitt stammt aus dem Frontend und zeigt den Socket.io-Listener, der neue Pistenstatus-Meldungen entgegennimmt und den zentralen Zustand aktualisiert:
socket.on('piste:update', (payload) => {
pisteStore.setStatus(payload.pisteId, payload.status);
});Für den Betrieb der App haben wir uns für eine geteilte Hosting-Lösung entschieden. Das Frontend wird als statische Auslieferung über Vercel ausgeliefert, da diese Plattform automatische Deployments aus unserem Git-Repository unterstützt und die Auslieferung über ein weltweites Content-Delivery-Netzwerk erfolgt. Das Backend läuft auf einem kleinen Server bei Hetzner, der Node.js, PostgreSQL und einen Reverse-Proxy auf Basis von Caddy zusammen betreibt. Die Entscheidung gegen Railway fiel aus Kostengründen, da wir mit Hetzner für rund fünf Euro pro Monat eine ausreichende Umgebung erhielten. Der Reverse-Proxy übernimmt die TLS-Terminierung und leitet Anfragen an das Node.js-Backend weiter.
Die Kostenfrage war für uns nicht nebensächlich. Da wir SlopeSafe als kostenlose Anwendung konzipiert haben und als Schulprojekt auch in Zukunft keine Einnahmen erzielen, mussten die laufenden Betriebskosten so niedrig wie möglich gehalten werden. Sämtliche gewählten Dienste sind entweder kostenlos in einer ausreichenden Stufe verfügbar (Vercel, OpenStreetMap) oder so günstig, dass sie sich aus Eigenmitteln tragen lassen (Hetzner, Domain). Diese Überlegung hat auch einen direkten Einfluss auf das Kapitel zu den nicht umgesetzten Funktionen (Kapitel 5), weil mehrere technisch mögliche Features aus Kostengründen verworfen werden mussten.
Für die Entwicklung haben wir uns an agilen Prinzipien orientiert, ohne eine formale Methodik wie Scrum vollständig umzusetzen, da das in einem Zweier-Team unverhältnismässig gewesen wäre. Stattdessen haben wir in zweiwöchigen Iterationen gearbeitet, an deren Beginn jeweils eine kurze Planungsbesprechung und an deren Ende ein Review stand. Innerhalb einer Iteration arbeiteten wir an klar abgegrenzten Aufgaben, die wir vorab in einem gemeinsamen Kanban-Board festgehalten hatten. Dieses Board diente gleichzeitig als Protokoll und ermöglichte es, jederzeit den Fortschritt zu überblicken.
Dieses Vorgehen hat sich als tragfähig erwiesen, weil es Struktur gab, ohne uns durch formale Abläufe auszubremsen. Gleichzeitig mussten wir lernen, Aufgaben realistisch zu schätzen. In den ersten beiden Iterationen haben wir systematisch zu viel geplant und mussten am Ende jeder Iteration Aufgaben verschieben. Ab der dritten Iteration haben wir die Planung reduziert und die Aufwände am Anfang einer Iteration bewusst konservativer angesetzt, was die Einhaltung der Planung deutlich verbesserte.
Für die Versionskontrolle haben wir Git mit einem gemeinsamen Repository auf GitHub verwendet. Jede grössere Funktion wurde in einem eigenen Branch entwickelt und erst nach einem gegenseitigen Review zusammengeführt. Dieses Vier-Augen-Prinzip hat mehrere Fehler früh abgefangen und uns gezwungen, unseren Code so zu schreiben, dass er auch für den anderen verständlich war — ein Effekt, den wir rückblickend als mindestens so wertvoll wie die Fehlerfindung selbst einschätzen.
Der Gesamtzeitrahmen erstreckte sich von Mitte Oktober 2025 bis Ende April 2026. Die ersten vier Wochen waren für die Konzeptphase reserviert, in der Ziel, Zielgruppe und Funktionsumfang grob abgesteckt wurden. Daran schloss sich eine fünfwöchige Designphase an, in der die ersten Wireframes, User Flows und Mockups entstanden. Die eigentliche Implementierung begann Anfang Dezember und lief in mehreren Iterationen weiter. Die Umfrage wurde bewusst etwas später platziert und zwischen dem 25. Februar und dem 1. März 2026 durchgeführt, nachdem das grobe Konzept stand und wir die Umfrage mit konkreten Funktionsvorschlägen bestücken konnten. Die letzten sechs Wochen waren für Testing, Feedback-Integration und Dokumentation vorgesehen.
[BILD-PLATZHALTER: Gantt-Diagramm des Projektzeitplans]
In der Realität haben sich einige Phasen überschnitten. Die Auswertung der Umfrage zog sich länger hin als geplant, weil wir kurzfristig die Freitext-Antworten stärker gewichtet haben. Gleichzeitig konnten wir mit der Frontend-Entwicklung schon während der Designphase beginnen, weil die Komponentenstruktur früh stabil war. Diese Überlappungen haben zwar kurzfristig zu höherem Koordinationsaufwand geführt, am Ende aber Zeit gespart. Rückblickend würden wir die Umfrage früher durchführen, weil einzelne Erkenntnisse daraus — etwa die nur mittlere Priorität der Pistenfilter-Funktion — zu diesem Zeitpunkt bereits in Design-Entscheidungen eingeflossen waren und nachträgliche Korrekturen aufwändiger wurden.
Die Aufgaben haben wir nach Stärken und Interessen aufgeteilt, mit bewussten Überschneidungen, damit beide Autoren das gesamte Projekt verstehen und beide Teilbereiche jeweils kompetent beurteilen können. Nevio hat den Schwerpunkt auf das Frontend und die Gesamtarchitektur gelegt. Dazu gehörten die Auswahl der Frameworks, der Aufbau der Komponentenstruktur, die Implementierung der Pistenkarte mit Leaflet sowie die Integration der Echtzeit-Updates im Client. Tobias hat sich vorwiegend um das Backend, das Datenbankdesign, die Anbindung der externen APIs sowie um das Projektmanagement, die Umfrage und den grössten Teil der schriftlichen Dokumentation gekümmert.
Bestimmte Aufgaben haben wir gemeinsam bearbeitet. Dazu zählten die Definition der REST-API, da diese Schnittstelle von beiden Seiten eingehalten werden musste, die Erstellung der Mockups in Figma sowie die Durchführung der Nutzertests. Für die Kommunikation im Alltag haben wir einen gemeinsamen Chat-Kanal genutzt und uns mindestens einmal pro Woche persönlich oder über eine Videoverbindung ausgetauscht. Diese Rituale haben dazu beigetragen, dass wir uns nie in Parallelarbeit verloren haben.
Während der Entwicklung haben sich drei technische Herausforderungen als besonders zeitaufwändig erwiesen, deren Lösungen wir stellvertretend darstellen.
In einem grösseren Skigebiet sind mehrere Dutzend Pisten mit jeweils mehreren Punkten und Kanten darzustellen. Zusätzlich kommen Warnsymbole, Liftstationen und Hütten hinzu. In der ersten Implementierung hat Leaflet bei geöffneter Karte für jedes einzelne Element einen separaten DOM-Knoten erzeugt, was auf älteren Mobilgeräten zu merklichen Verzögerungen beim Zoomen und Verschieben führte. Wir haben dieses Problem in zwei Schritten gelöst. Zum einen setzen wir die Erweiterung Leaflet.markercluster ein, die eng benachbarte Marker automatisch zu Clustern zusammenfasst und erst beim Hineinzoomen einzeln darstellt. Zum anderen haben wir die Pisten als einzelne Polylinie pro Piste modelliert und nicht als Kette aus einzelnen Segmenten, was die Anzahl der gerenderten Elemente ungefähr halbierte. Die kombinierte Lösung reduzierte die Zeit für das initiale Rendern einer typischen Pistenkarte von rund 1,4 Sekunden auf etwa 0,4 Sekunden auf einem Referenzgerät.
Die Geolocation-API des Browsers liefert in der Theorie eine Position mit einer Genauigkeit von wenigen Metern. In der Praxis ist die Genauigkeit im alpinen Gelände stark eingeschränkt, weil Satellitenempfang durch Bergflanken reduziert wird und moderne Mobilgeräte zusätzlich auf Mobilfunk- und WLAN-Ortung zurückgreifen, die im Gebirge kaum verfügbar ist. In den ersten Tests haben wir Positionen gesehen, die mehrere hundert Meter neben dem tatsächlichen Standort lagen. Für die automatische Gebietserkennung ist das kein grosses Problem, weil wir Bounding Boxes verwenden, die eine gewisse Ungenauigkeit vertragen. Für den Notfall-Bereich ist die Genauigkeit aber kritisch.
Wir haben das Problem dadurch entschärft, dass der Client nach dem Auslösen des Notfall-Vorgangs während des dreisekündigen Bestätigungs-Countdowns mehrere Positionsmessungen durchführt und jene mit der besten gemeldeten Genauigkeit auswählt. Zusätzlich wird die Genauigkeitsangabe prominent angezeigt, damit der Nutzer einschätzen kann, wie verlässlich die Koordinate ist. Für Gebiete mit bekanntermassen schlechtem Empfang bieten wir ausserdem einen manuellen Fallback an, bei dem der Nutzer seine Position auf der Karte durch Tippen bestätigen kann.
Gerade im alpinen Gelände ist die Datenverbindung nicht immer zuverlässig. Eine App, die im Funkloch gar nichts anzeigt, verliert genau dann ihren Nutzen, wenn sie am meisten gebraucht wird. Wir haben deshalb frühzeitig einen Service Worker implementiert, also ein vom Browser im Hintergrund ausgeführtes Skript, das Anfragen abfangen und aus einem lokalen Zwischenspeicher beantworten kann. Der Service Worker hinterlegt beim ersten Aufruf die Grundgerüst-Dateien der App sowie die zuletzt abgerufenen Daten zu Lawinenwarnung, Wetter und Pistenstatus für das gewählte Gebiet. Bei fehlender Verbindung lädt die App aus diesem Zwischenspeicher und kennzeichnet die Daten mit einem Zeitstempel, damit der Nutzer deren Alter erkennen kann.
Die Offline-Fähigkeit bedeutete auch, dass wir den Client so gestalten mussten, dass er robust mit unvollständigen Daten umgeht. Statt eines Fehlers wird in solchen Fällen eine reduzierte Ansicht gezeigt, die auf fehlende Werte explizit hinweist, aber die sonstigen Funktionen weiterhin zugänglich macht. Kartenkacheln werden für das gewählte Gebiet in einer definierten Zoomstufe vorgehalten, damit zumindest eine grobe Orientierung auch im Funkloch möglich ist.
[BILD-PLATZHALTER: Screenshot der fertigen App (Hauptscreen)]
[BILD-PLATZHALTER: Screenshot Pistenkarte im Betrieb]
Während der Entwicklung mussten wir mehrere Funktionen, die in der Umfrage durchaus Zuspruch fanden, aus dem Umfang nehmen oder in reduzierter Form umsetzen. Wir halten diese Entscheidungen hier transparent fest, weil sie die App in ihrer finalen Form mitprägen und bei der Reflexion wieder aufgegriffen werden sollen.
Die Umfrage hat gezeigt, dass sich 55 Prozent der Teilnehmenden wünschen, im Notfall hinterlegte Kontakte automatisch benachrichtigen zu können. Technisch liesse sich das über einen E-Mail- oder SMS-Versanddienst umsetzen. In der Praxis scheitert es aber an den Betriebskosten. SMS-Gateways berechnen pro Nachricht je nach Anbieter zwischen rund 7 und 15 Rappen. Bei auch nur einer Handvoll realer oder versehentlicher Auslösungen pro Tag würden Kosten entstehen, die sich ohne Einnahmen nicht tragen lassen. Auch der E-Mail-Versand über Dienste wie Mailgun oder SendGrid ist ab einem bestimmten Volumen kostenpflichtig, und bei einer Notfallanwendung müssen wir mit Spitzenlasten rechnen, die über die kostenlosen Kontingente hinausgehen können.
Hinzu kommt eine rechtliche Komponente: Eine Anwendung, die im Notfall Dritte alarmiert, muss verlässlich funktionieren. Kommt die Nachricht nicht an, weil ein Gateway ausfällt oder ein Spamfilter zuschlägt, kann das zu einer falschen Sicherheit beim Absender führen. Wir haben uns deshalb entschieden, in der aktuellen Version keine automatisierte Benachrichtigung anzubieten, sondern die hinterlegten Kontakte nur im Notfall-Screen anzuzeigen, damit der Nutzer sie direkt anrufen kann. Ein späterer Ausbau ist möglich, setzt aber eine finanzielle Trägerschaft voraus — sei es durch Sponsoring, Mitgliederbeiträge oder eine optionale Premium-Stufe.
Eine direkte, automatisierte Alarmierung der Rega oder eines kantonalen Notrufs wäre in der Theorie die eleganteste Lösung. In der Praxis ist sie aus mehreren Gründen nicht umsetzbar. Erstens existiert keine öffentliche Programmierschnittstelle, über die Drittanwendungen Notrufe bei der Rega absetzen könnten; für die offizielle Rega-App besteht eine explizite Partnerschaft mit der Rega. Zweitens wäre jede Form von automatisierter Alarmierung ohne vorherige Freigabe durch die betreffenden Rettungsorganisationen rechtlich problematisch, weil Fehlalarme nachweislich Ressourcen binden, die an anderer Stelle fehlen. Drittens hätten wir für eine solche Integration einen Zertifizierungs- und Vertragsprozess durchlaufen müssen, der den Rahmen einer Vertiefungsarbeit sprengt. SlopeSafe zeigt deshalb im Notfall-Screen die offizielle Rega-Notfallnummer (1414) mit einem direkten Wähllink an und stellt die Koordinaten in lesbarer Form dar, damit sie am Telefon verlesen werden können.
12 Prozent der Teilnehmenden würden eine automatische Unfallerkennung, etwa durch Auswertung von Sensordaten bei einem Sturz oder längerem Stillstand, sinnvoll finden. Eine solche Funktion ist technisch anspruchsvoll und setzt permanenten Zugriff auf Beschleunigungs- und Gyroskopsensoren voraus, idealerweise auch im Hintergrund. Genau diesen Hintergrundzugriff erlauben Browser für Web-Apps nur sehr eingeschränkt, was eine native App-Entwicklung erfordern würde, die wir aus Kapazitätsgründen nicht leisten konnten. Zusätzlich ist die Abgrenzung zwischen einem Sturz und einer harten Kurvenfahrt so heikel, dass selbst kommerzielle Anwendungen eine substantielle Fehlalarmquote haben. Für eine verlässliche Umsetzung wäre ein aufwändiger Trainings- und Kalibrierungsprozess nötig, der deutlich über den Umfang einer Vertiefungsarbeit hinausgeht.
50 Prozent der Teilnehmenden würden eine Funktion nutzen, mit der sie die Positionen ihrer Freunde auf der Piste sehen können. Auch hier lag die Hürde primär bei den Betriebskosten und bei der Akku-Belastung. Ein dauerhaftes Tracking mehrerer Nutzer bedeutet einen konstanten Datenfluss zum Backend, der sowohl Serverressourcen als auch Bandbreite in Anspruch nimmt. In Kombination mit den Datenschutzanforderungen an eine dauerhafte Standortverarbeitung mehrerer Personen wäre der Aufwand für eine saubere Umsetzung unverhältnismässig gross geworden. Als Kompromiss bieten wir in der aktuellen Version eine zeitlich begrenzte Positionsteilung innerhalb einer zuvor erstellten Gruppe an, die manuell aktiviert und automatisch nach wenigen Stunden beendet wird.
Die Umfrage zeigte mit 66 Prozent ein starkes Interesse an einer Pistenkarte mit Echtzeit-Status. Wie in Abschnitt 4.5 beschrieben, ist die Datenlage aber heterogen: Nicht jedes Skigebiet stellt einen maschinenlesbaren Feed bereit. In der aktuellen Version sind rund ein Dutzend Gebiete aus der Zentralschweiz und dem Bündnerland eingepflegt, weitere Gebiete werden auf manuelle Anfrage ergänzt. Eine flächendeckende Abdeckung wäre möglich, wenn wir Parser für unstrukturierte Webseiten schreiben und diese bei jeder Saison neu pflegen. Der laufende Wartungsaufwand dafür ist für ein Zweier-Team nicht tragbar, weshalb wir uns für die konservative Variante entschieden haben.
Parallel zur Entwicklung haben wir eine zweigleisige Teststrategie verfolgt. Einerseits haben wir während der Implementierung einzelne Funktionen des Backends mit automatisierten Unit-Tests abgesichert, insbesondere die Authentifizierung, die Berechnung der Zwischenspeicher-Gültigkeit sowie die Transformationsfunktionen zwischen externem Bulletinformat und internem Datenmodell. Diese Tests laufen bei jedem Commit über einen automatisierten Workflow auf GitHub Actions. Andererseits haben wir die Gesamtanwendung systematisch manuell getestet, zunächst durch uns selbst, anschliessend durch externe Testpersonen.
Für die manuellen Tests haben wir ein Testprotokoll mit klar definierten Szenarien entwickelt. Jedes Szenario beschreibt die Ausgangslage, die auszuführenden Schritte und das erwartete Ergebnis. Die Testperson notiert, ob das Ergebnis eingetreten ist, wie lange der Weg dahin dauerte und welche Unklarheiten oder Probleme auftraten. Dieses Vorgehen hat zu vergleichbaren Daten geführt, obwohl die drei Testpersonen sehr unterschiedliche Hintergründe hatten. Ergänzend haben wir während der gesamten Testphase die Browser-Konsole und das Server-Log mitlaufen lassen, um technische Fehler mit konkreten Interaktionen korrelieren zu können.
Für die externe Testphase haben wir drei Testpersonen ausgewählt, die gemeinsam ein möglichst breites Spektrum unserer Zielgruppe abdecken. Die erste Testperson, Andreas (52), ist ein erfahrener Skitourengeher, der sich seit über zwanzig Jahren regelmässig im winterlichen Gelände bewegt und White Risk aktiv einsetzt. Die zweite Testperson, Lara (24), ist eine Gelegenheits-Skifahrerin, die etwa fünf bis sieben Tage pro Saison im Skigebiet verbringt, aber bisher keine spezialisierte App nutzt. Die dritte Testperson, Marco (17), ist ein Snowboarder, der vor allem in grossen Skigebieten unterwegs ist und überdurchschnittlich technikaffin ist.
Die Tests fanden zwischen dem 25. März und dem 10. April 2026 statt, jeweils in einer rund 45-minütigen Sitzung. Die Testpersonen erhielten das Testprotokoll und führten die Szenarien unter unserer Beobachtung aus. Wir haben uns dabei bewusst zurückgehalten und nur bei ausdrücklicher Nachfrage unterstützt, damit die Ergebnisse nicht durch Hinweise verfälscht wurden. Im Anschluss an die Szenarien führten wir jeweils ein offenes Gespräch, in dem die Testperson ihre Eindrücke schildern konnte. Zusätzlich baten wir sie, einen kurzen standardisierten Fragebogen (angelehnt an den System Usability Scale) auszufüllen, damit wir die Eindrücke später auch quantitativ vergleichen konnten.
Das Testprotokoll umfasste sechs Kernszenarien. Im ersten Szenario sollte die Testperson die App öffnen und die aktuelle Lawinenwarnstufe für ihr aktuelles Gebiet ablesen. Im zweiten Szenario sollte ein anderes Gebiet manuell ausgewählt werden. Im dritten Szenario war die Pistenkarte zu öffnen und der Status einer bestimmten Piste zu ermitteln. Im vierten Szenario sollte die Testperson die Wetterwarnungen für die nächsten 24 Stunden abrufen. Im fünften Szenario war ein Notfall-Vorgang bis zur Bestätigungsseite auszuführen, ohne ihn tatsächlich auszulösen. Im sechsten Szenario wurde die Datenverbindung deaktiviert, und die Testperson sollte die App im Offline-Modus nutzen.
[BILD-PLATZHALTER: Tabelle mit Testfällen und Ergebnissen]
Die Ergebnisse fielen über alle drei Testpersonen hinweg erfreulich aus. Die Szenarien eins, drei und sechs wurden von allen ohne Rückfragen bestanden. Beim zweiten Szenario (Gebietswechsel) brauchten Lara und Marco im Durchschnitt 18 Sekunden, bis sie die Funktion gefunden hatten, was uns auf eine zu versteckte Navigation hinwies. Beim vierten Szenario beschrieb Andreas die Darstellung der Wetterwarnungen als klar, bemängelte aber, dass die zeitliche Abfolge auf den ersten Blick nicht eindeutig war. Das fünfte Szenario wurde von allen drei Testpersonen bestanden, wobei Marco die Dreisekunden-Bestätigung als eher zu lang empfand, während Andreas sie als angemessen bezeichnete. Der Fragebogen am Ende der Session ergab für alle drei Testpersonen einen Wert im oberen Drittel der Skala, wobei Andreas mit Abstand das höchste Vertrauen in die inhaltliche Korrektheit der Warnungen äusserte und Lara die höchste Bewertung für die Verständlichkeit der Oberfläche vergab.
Neben den protokollierten Beobachtungen lieferten die Abschlussgespräche wertvolle qualitative Rückmeldungen. Durchgängig positiv wahrgenommen wurde die Klarheit der Farbcodierung sowie die Tatsache, dass die wichtigsten Informationen ohne Login erreichbar sind. Andreas hob besonders die Offline-Fähigkeit hervor, die er aus anderen Apps in dieser Form nicht kenne. Lara lobte die Lesbarkeit bei hellem Umgebungslicht, die sie an ihrem Smartphone auf dem Balkon in der Mittagssonne ausprobierte. Marco schätzte die kompakte Pistenkarte und die Möglichkeit, Gefahrenmeldungen mit zwei Taps abzusetzen.
Auf der kritischen Seite wurde mehrfach die Auffindbarkeit der Gebietswahl angesprochen. Der entsprechende Knopf lag in der ursprünglichen Version oben links und war nach Angaben der Testpersonen zu klein. Marco kritisierte ausserdem, dass die Wetterwarnungen keine Angabe darüber enthielten, wann sie zuletzt aktualisiert wurden. Andreas wies darauf hin, dass die Legende für die Lawinenwarnstufen zwar vorhanden, aber erst nach einem zusätzlichen Klick sichtbar sei; er würde sich eine dauerhaft eingeblendete Kurzlegende wünschen. Lara fragte ausdrücklich nach einer Benachrichtigungsfunktion für Notfallkontakte und war sichtbar enttäuscht, als wir erläuterten, warum wir diese Funktion in der aktuellen Version nicht anbieten können — was wir später bei der Reflexion wieder aufnehmen.
Aus dem Feedback haben wir mehrere konkrete Verbesserungen abgeleitet und vor Abschluss des Projekts umgesetzt. Erstens haben wir die Gebietswahl prominenter platziert: Sie ist nun als breite, beschriftete Schaltfläche direkt unter dem Hauptstatus angeordnet und nicht mehr als kleines Icon in der Kopfleiste. Die Testpersonen haben die Funktion in einem Nachtest innerhalb weniger Sekunden gefunden. Zweitens zeigen alle Informationsblöcke nun einen klar sichtbaren Zeitstempel mit dem letzten Aktualisierungszeitpunkt, eingefärbt nach Alter, damit veraltete Daten auf einen Blick erkennbar sind. Drittens haben wir eine permanente Kurzlegende am unteren Rand der Startansicht ergänzt, die die fünf Lawinenwarnstufen mit einem Stichwort und ihrer Farbe erklärt, ohne Platz zu beanspruchen, der für andere Informationen benötigt wird.
Zusätzlich haben wir die zeitliche Darstellung der Wetterwarnungen überarbeitet. Anstelle einer reinen Aufzählung zeigt die App nun eine Zeitleiste, auf der die Warnungen als farbige Balken in ihrem Gültigkeitszeitraum dargestellt sind. Diese Änderung war mit relativ wenig Aufwand verbunden, hat aber die Verständlichkeit nach Einschätzung unserer Testpersonen spürbar erhöht. Die Dreisekunden-Bestätigung des Notfall-Vorgangs haben wir nach einer internen Diskussion unverändert gelassen, obwohl Marco sie als zu lang empfunden hatte; die Gefahr einer versehentlichen Auslösung wiegt in diesem speziellen Fall aus unserer Sicht schwerer als ein etwas längerer Bestätigungsweg, und Andreas' professionelle Einschätzung hatte uns darin bestärkt.
Als fünfte Verbesserung haben wir den Notfall-Screen um eine unmittelbare Anzeige der genauen Koordinaten inklusive Genauigkeit in Metern ergänzt, damit diese Angabe am Telefon direkt durchgegeben werden kann. Der bisherige Verweis auf eine separate Unterseite war mehrfach übersehen worden. Diese kleine Änderung verkürzt den Weg vom Drücken des Notfall-Buttons bis zum einsatzbereiten Informationsstand spürbar und war einer der am eindeutigsten positiv aufgenommenen Änderungen in einem Nachtest, den wir mit Andreas durchführen konnten.
Am Ende der Entwicklungs- und Testphase lässt sich festhalten, dass sich die ursprüngliche Projektidee tragfähig umsetzen liess. Die Umfrage unter 133 Teilnehmenden hat den Bedarf an einer gebündelten Sicherheitsanwendung quantitativ bestätigt und uns erlaubt, den Funktionsumfang gezielt auf jene Themen auszurichten, die für eine Mehrheit der Zielgruppe unmittelbar relevant sind. Die gewählte technische Architektur aus React-Frontend, Node.js-Backend mit Express, PostgreSQL und Socket.io hat sich im Betrieb bewährt und die gesteckten Anforderungen an Geschwindigkeit, Echtzeit-Fähigkeit und Offline-Robustheit erfüllt.
Die technischen Herausforderungen rund um Kartenperformance, GPS-Genauigkeit und Offline-Nutzung haben uns in der Entwicklung am meisten gefordert, gleichzeitig aber auch die grössten Lerneffekte gebracht. Ebenso lehrreich waren die bewusst gezogenen Grenzen: Die Entscheidung gegen automatische SOS-Benachrichtigungen, gegen eine direkte Rega-Anbindung, gegen automatische Unfallerkennung und gegen eine native App-Version folgt in jedem Einzelfall einer Abwägung zwischen Nutzerwunsch einerseits und Kosten, Recht sowie Projektumfang andererseits. Diese Grenzen sind keine Schwächen der Lösung, sondern ehrliche Konsequenzen eines Schulprojekts ohne kommerzielle Trägerschaft. Das Feedback der drei Testpersonen hat darüber hinaus mehrere punktuelle Schwächen aufgedeckt, deren Behebung die Benutzerfreundlichkeit der App sichtbar verbessert hat.
In welchem Umfang die Arbeit darüber hinaus unsere eigenen Erwartungen erfüllt hat, wo sie hinter ihnen zurückblieb und welche Überlegungen sich daraus für eine mögliche Weiterentwicklung ergeben — insbesondere die Frage, unter welchen Voraussetzungen die in Abschnitt 5.5 diskutierten nicht umgesetzten Funktionen in einer nächsten Ausbaustufe realisiert werden könnten — werden wir im folgenden Reflexionsteil ausführen.