[bl] spotlight - Der Funktionsumfang einer DiGA

Wenn man sich zuvor Gedanken zu den Haupt-Usecases und der User Journey gemacht hat, dann ist das Definieren von sinnvollen Funktionalitäten in der Regel in einer kreativen Runde an Personen schnell getan. Zumindest das Sammeln der ersten Ideen. 

Hierfür nimmt man sich jeden Usecase und stellt sich Fragen wie: „Mit was für Funktionen kann ich den Usecase erfüllen?“ Natürlich macht es Sinn, sich durch ähnliche Produkte inspirieren zu lassen, die schon auf dem Markt sind und ähnliche Usecases verfolgen. Es ist aber immer wichtig zu prüfen, ob die Umsetzung bei den anderen Produkten auch für die eigene Zielgruppe sinnvoll ist und wirklich auf die eigenen Usecases passt oder angepasst werden muss! Ebenso ist es immer wichtig zu prüfen, wie man ein Alleinstellungsmerkmal hinbekommt. Kann man die Inspiration einer Funktion noch erweitern oder so abwandeln, dass sie sogar besser für die eigene Zielgruppe funktioniert? 

Ergänzend zu den Funktionalitäten, die zur Erfüllung der Usecases gedacht sind, sollte man prüfen, was an Funktionen zusätzlich benötigt wird, um Anforderungen von Stakeholdern oder regulatorische Vorgaben zu erfüllen. Ebenso sollte im Kontext der späteren Markteinführungsstrategien geprüft werden, um Funktionalitäten benötigt werden, die die Markteinführung, das Marketing oder den Vertrieb unterstützen. 

Zusätzlich ist es wichtig, die Weiterentwicklung und den Betrieb zu betrachten. Wird ein Service- oder Administrationsportal benötigt, damit nicht technisch affine Service-Mitarbeiter*innen Supportanfragen von Nutzer*innen beantworten können? Werden eventuell Analysemöglichkeiten benötigt, um bewerten zu können, ob und in welchen Bereichen des Produktes eine Weiterentwicklung notwendig ist, um das Produkt stetig zu verbessern? 

Am Ende kommen noch sogenannte nicht-funktionale Anforderungen dazu, wie z.B. der Wunsch nach Barrierefreiheit – btw. Pflicht für Medizinprodukte – Definition einer Kompatibilität zu technischen Geräten und Betriebssystemen, wie iOS und Android und auf welchen Smartphones soll das Produkt mindestens funktionieren, …. 

Die Liste an Funktionen wird schnell sehr lang. Da Zeit und Geld in der Regel immer eine Rolle spielen, ist es daher immens wichtig, die Liste zu priorisieren. Welche Funktionen sind zwingend notwendig zum Marktstart, welche sind weniger relevant für einen Erfolg und könnten zu einem späteren Zeitpunkt, in einer neuen Version des Produktes nach deinem Update, erst umgesetzt werden. 

Viele laufen nach dem MVP Prinzip. MVP bedeutet Minimum Viable Product – was ist das Notwendigste, damit ein Produkt verwendet werden kann. Das Problem dabei: MVP bedeutet im Zweifel auch, dass es nicht „schön“ ist und deshalb auch nicht von der Zielgruppe verwendet wird. Wir bei Bornholdt Lee laufen deshalb lieber nach dem MLP Prinzip. MLP bedeutet Minimum Lovable Product. Was ist das minimal Notwendigste, was im Produkt umgesetzt sein sollte, damit das Produkt auch gerne verwendet wird. 

Das Priorisieren und mögliche Streichen von Funktionalitäten sollte in einer Diskussion im Team oder mit Expert*innen erfolgen, um möglichst alle Aspekte und Interessen auch von Stakeholdern vielseitig zu betrachten. Ein Tipp: Es lohnt sich immer, die definierte Liste an Funktionalitäten durch Nutzerinterviews mit Personen in der Zielgruppe zu prüfen und Informationen darüber zu erhalten, ob die Liste an Funktionalitäten und die gesetzten Prioritäten auch aus deren Sicht passt.