1. Einleitung

Hochschulbibliotheken stehen vor der Herausforderung, digitale Services aufzubauen. Dies ist eine Aufgabe, die mit wachsenden Anforderungen und technischen Neuerungen immer komplexer wird und selbst größere Einrichtungen vor Herausforderungen stellt. Immer mehr Ressourcen für die Entwicklung einzusetzen, ist aber nicht die Lösung, die zu innovativen und nachhaltigen Services führen kann. Vielmehr braucht es einen Ordnungsrahmen und entsprechende methodische Ansätze, um die vorhandenen Ressourcen besser einzusetzen. Dieser Beitrag zeigt, wie der gezielte Einsatz von Designmethoden1 im Ordnungsrahmen Service Engineering2 bei der Entwicklung von digitalen Services zur Professionalisierung des Vorgehens zielführend sein kann.

Neu an diesem Vorgehen ist, dass Designmethoden und -prinzipien von Beginn an fest in den Prozess integriert werden und nicht nur einer grafischen Anpassung dienen. Die These des Beitrags lautet daher, dass Designmethoden maßgeblich sind für eine strukturierte Entwicklung von Services, die nutzerzentriert und innovativ sind, Interessen der Stakeholder berücksichtigen, Fehlentwicklungen früh identifizieren und zu einer besseren und wertschätzenden Kommunikation im Team beitragen. Das Verbinden der beiden Ansätze Service Engineering und Designmethoden ermöglicht auch bei knappen Ressourcen bessere Services.

In den folgenden Kapiteln wird dargelegt, wie Service Engineering den Entwicklungsprozess ausgehend von einer tragenden Serviceidee begleiten und systematisieren kann (2). Darauf aufbauend wird die Herausforderung umrissen, ein Serviceportfolio für eine Hochschulbibliothek aufzubauen (3). Im Anschluss werden Möglichkeiten aufgezeigt, durch den Einsatz von Designmethoden die Perspektive zu wechseln und der Komplexität mit konkreten Handlungsansätzen zu begegnen (4). Zuletzt wird dargelegt, wie der gezielte Einsatz von Designmethoden innerhalb eines bestehenden Ordnungsrahmens das Service Engineering, die Praxis der Serviceentwicklung wesentlich vereinfachen kann (5).

2. Von der Idee zum Service

Am Anfang jedes Service3 steht eine Idee. Dieser Idee kommt im Verlauf der Serviceentwicklung eine zentrale Rolle zu. Je ausgereifter eine Serviceidee herausgearbeitet und gefasst werden kann, umso klarer können Dienstleistung und digitales Produkt entworfen und umgesetzt werden.

Ideen können unterschiedlichen Quellen entstammen. Sie können sich beispielsweise aus einer Kundenanfrage4 ergeben, das Ergebnis eines Co-Creation-Workshops5 sein oder aus den strategischen Zielen der Bibliothek abgeleitet werden. Hochschulbibliotheken oder die Hochschulen selbst geben sich in vielen Fällen eine auf mehrere Jahre angelegte Digitalstrategie bzw. einen Entwicklungsplan, in dem auch die Rolle digitaler Produkte oder ganzer Technologien als Grundlage des strategischen Handelns dargelegt wird. Solche strategischen Ziele haben daher maßgeblichen Einfluss auf die Ausgestaltung jedes einzelnen Service.

Um diesen Anforderungen besser begegnen zu können, wurde das Service Engineering an der Universitäts- und Landesbibliothek Münster (ULB) eingeführt. Es schafft einen klaren Ordnungsrahmen, um aus den Zielen der Gesamtstrategie und konkreten Bedarfen forschungsunterstützende Services abzuleiten und umzusetzen. Services bestehen meist aus einer Dienstleistung und einem digitalen Produkt, das entwickelt oder an den technologischen Wandel angepasst werden muss. Dieser Prozess schließt die kontinuierliche Adaption bestehender Services an die sich wandelnde Informationsinfrastruktur eines Hochschulstandortes ein, beispielsweise hinsichtlich der Entwicklung von Software mit dem Merkmal der Cloud Readiness im Umfeld von Kubernetes6.

Die Auseinandersetzung mit einer Serviceidee, ihre Revision und Verfeinerung wird im Service Engineering als Service Creation beschrieben. Dieser Prozess wird dadurch komplex, dass Bedarfe auf unterschiedlichen Ebenen erhoben und miteinander in Einklang gebracht werden müssen: Im Verlauf des Service Engineering gilt es auszuhandeln, ob es sich um einen Service oder mehrere distinkte Services bzw. Varianten handelt. Im Anforderungsmanagement tauchen in Konflikt stehende Stakeholderinteressen auf (z. B. IT-Sicherheit vs. Bedienkomfort) und Features des digitalen Produkts müssen gewichtet sowie priorisiert werden. Des Weiteren ist der Umgang mit Ressourcenknappheit (Zeit, Finanzmittel, Kompetenzen) entscheidend. Im Moment der Entwicklung stehen dann den konkreten Bedürfnissen der Nutzer*innen abstrakte strategische Ziele gegenüber. Dies erschwert das Zusammenführen der verschiedenen Ebenen in der konkreten Serviceentwicklung, insbesondere die Anforderungsanalyse und die daran anschließende Konsensfindung.

Konkret spielen hierbei drei Ebenen zusammen:

Ebene 1: Ableiten neuer Serviceideen aus den abstrakten Vorgaben einer allgemeineren Strategie, z. B. die Idee eines Beratungsservices, abgeleitet aus der Vorgabe der Forschungsunterstützung.

Ebene 2: Ableiten neuer Serviceideen aus der konkreten Anforderungsanalyse diverser Stakeholderinteressen. Diese können ihrerseits in strategischen Zielen bereits erfasst sein, z. B. das Sichtbarwerden des Bedarfs für ein digitales Produkt zur Repräsentation von Texteditionen im Umfeld der Beratungen eines Digital-Humanities-Centers.

Ebene 3: Direkter Vorschlag einer Serviceidee von Nutzer*innen existierender Services oder Kooperationspartner*innen der Einrichtung, z. B. der Vorschlag eines neuen Produkts zur Erkennung von Text in Bildern (Optical Character Recognition, OCR), nachdem Forschende Vergleichbares auf einer Fachtagung kennengelernt haben.

In diesem Beitrag wird dafür plädiert, dieser Komplexität mit Designmethoden zu begegnen. Hierbei kommt der Nutzerperspektive eine besondere Bedeutung zu, da der nutzerzentrierte Designprozess zwischen den genannten Ebenen vermittelt. Designmethoden können dabei unterstützen, das durch den Service zu lösende „Problem“ präziser zu formulieren, abseits erster Ideen Lösungen systematischer zu explorieren und verschiedene Perspektiven der Stakeholder*innen einzunehmen. Auf diese Weise werden Ideen systematisch weiterentwickelt, konkretisiert und wichtige Perspektiven integriert. So lässt sich verhindern, dass vorschnell naheliegende Lösungen akzeptiert werden, die das Problem nur unzureichend adressieren. Designmethoden berücksichtigen in der Regel von sich aus schon die limitierenden Faktoren (Ressourcen) und streben unter diesen Bedingungen eine optimale Lösung an.

3. Problemstellung: digitales Serviceportfolio

Bibliotheken bieten Dienstleistungen an. Eine der grundlegendsten Dienstleistungen für eine Bibliothek als Serviceeinrichtung ist es, einen Zugang zu physischen Büchern zu schaffen. An der digitalen Transformation dieses Basisdienstes lassen sich die Notwendigkeit und die Problematik eines Serviceportfolios verdeutlichen. Schon physische Medien setzen bekanntermaßen Logistik und Arbeitsprozesse voraus, um Anschaffung, Ausleihe, Pflege, Transport und Vieles mehr zu organisieren. Unabhängig vom Medium lassen sich auch diese Organisationsprozesse selbst digital repräsentieren und durch den Einsatz digitaler Technologien verbessern, etwa durch Katalogsysteme und Planungswerkzeuge. Das Medium „Buch“ selbst unterliegt offensichtlich ebenfalls dem Wandel hin zur digitalen Repräsentation.7 Allgemeiner betrachtet sind durch veränderte Anforderungen auch in der Vergangenheit bereits Varianten dieser grundlegenden Dienstleistung entstanden: Den Zugang zu den digitalen Repräsentationen anzubieten, fügt dem bestehenden Service neue Aspekte hinzu, wie z. B. Softwareanwendungen zur Erstellung, Anzeige und Verarbeitung des digitalen Mediums. Der Service fächert ggf. zu einer Servicefamilie auf, hat Hierarchien und zunehmende Abhängigkeiten. Um ein Produkt wie das Buch können so verschiedene Dienstleistungen entstehen, wie beispielsweise Repositories oder digitale Publikationsservices. Sollen darüber hinaus Anteile der involvierten digitalen Produkte von der Bibliothek selbst entwickelt oder konfiguriert werden, müssen IT-Infrastruktur und Personal für Software Engineering sowie Betrieb eingesetzt werden. Hochschulbibliotheken sind heute aufgrund neuer Handlungsfelder vielfach auch „Softwareschmieden“, selbst ohne eigene Entwicklungsabteilungen, die digitale Produkte entwickeln.

Nimmt man nun für die Hochschulbibliotheken die Veränderung der Forschungspraxis hinzu, so zeigt sich, dass der Erkenntnisgewinn der Forschenden nicht nur von Zugriffsmöglichkeiten auf Medien abhängt, sondern auch und vor allem durch die verfügbaren digitalen Instrumente und Technologien des Standorts beeinflusst wird. Da die Forschenden in vielen Situationen um exzellente Ergebnisse wetteifern, entsteht ein kraftvoller Antrieb für die fortlaufende, wenn auch heterogene Digitalisierung der Wissenschaft. Dies betrifft insbesondere die zunehmende Verschmelzung von Informationsinfrastruktur und Forschungspraxis.8

Ein digitales, forschungsunterstützendes Serviceportfolio ist dynamisch, heterogen und muss Auswirkungen der rasch fortschreitenden Transformation reflektieren und integrieren. Für die Hochschulbibliotheken ist die Transformation der Wissenschaft eine so gravierende Veränderung, dass sie dem eigenen Anspruch auf Forschungsunterstützung nur dann nachkommen können, wenn sie ihr Serviceportfolio fortwährend aktualisieren. Doch damit nicht genug: Hochschulbibliotheken müssen mit der gesamten Vielfalt der digitalen Fachdomänen des Hochschulstandortes umgehen und adaptiv handeln, um rechtzeitig geeignete Services anbieten zu können. Zusätzlich zu den dauerhaften Herausforderungen der Portfoliogestaltung wie dem Optimieren der eingesetzten Ressourcen oder der Bewahrung von Qualität und Interoperabilität der digitalen Produkte kommen auf servicegebende Institutionen noch andere Anforderungen zu, etwa dass IT-Stellen im öffentlichen Dienst schwer zu besetzen sind.

Wie ist unter solchen Rahmenbedingungen ein systematisches Service Portfolio aufzubauen?

In Ermangelung einer generischen und erprobten Blaupause9 wurde an der ULB Münster der Entschluss gefasst, das Service Engineering als strukturierten Ansatz unter Zuhilfenahme von Designmethoden neu zu denken und in der Praxis am Standort Münster umzusetzen.

4. Services entwickeln, aber wie?

4.1 Theoretische Anknüpfungspunkte

Services sind komplex, da sie in voraussetzungsreiche Prozessketten integriert sind, etwa hinsichtlich ihrer Anforderungen, Stakeholder*innen oder des Betriebs digitaler Produkte. Oft bedingt allein die Vielzahl der involvierten Stakeholder*innen mit unterschiedlichen, teils gegensätzlichen Interessen an dem zu entwickelnden Service zusätzliche Komplexität. Zu den Stakeholder*innen gehören beispielsweise Product Owner*innen, Entwickler*innen, Designer*innen, Manager*innen, Marketingexpert*innen, betreibende Einrichtungen usw. In der Anforderungsanalyse müssen diese Stakeholder*innen mit ihren Bedarfen und Perspektiven erfasst und in Einklang mit Nutzerperspektiven gebracht werden. Das Service Engineering kann daher als sozio-technischer Prozess aufgefasst werden, bei dem es gilt, die unterschiedlichen Perspektiven, Interessen und Anforderungen miteinander in Einklang zu bringen.

In der Designforschung sind solche Situationen wohlbekannt. Mit Verweis auf den Designtheoretiker Horst Rittel und den Stadtplaner Melvin Webber spricht man hier von „Wicked Problems“.10 Geprägt wurde dieser Terminus in den Bereichen der Stadtplanung und der politischen Planung: Aufgrund der hohen Komplexität eines sozialen Geflechts unterschiedlicher, teils widersprüchlicher, teils nicht klar ersichtlicher Interessen bereitet schon die Beschreibung des Problems in diesem Kontext Schwierigkeiten und es gibt keinen offensichtlichen, klar definierten Lösungsweg, der sich etwa aus der Anwendung eines bestimmten Methodensets ergibt. Conklin lieferte später eine generalisierte Definition, die auch auf andere Kontexte übertragbar ist:

1. The problem is not understood until after the formulation of a solution.

2. Wicked problems have no stopping rule.

3. Solutions to wicked problems are not right or wrong.

4. Every wicked problem is essentially novel and unique.

5. Every solution to a wicked problem is a „one shot operation“.

6. Wicked problems have no given alternative solutions.11

Im Design haben Wicked Problems durch den Designtheoretiker Richard Buchanan eine größere Aufmerksamkeit erfahren. Dieser wies darauf hin, dass Wicked Problems nicht nur in politischen Planungsprozessen, sondern in den meisten Designprozessen zu finden sind.12 In der Designpraxis reagiert man auf solche unbestimmten Probleme und das damit verbundene Wissensdefizit mit der Exploration einer Vielzahl von möglichst diversen Lösungsansätzen, die das Problem jeweils auf unterschiedliche Weise konzeptualisieren bzw. „framen“13. Sie tragen damit einerseits zu einem besseren Verständnis basierend auf einer besseren Durchdringung des Problems bei, andererseits schaffen sie auch die Grundlage dafür, bessere Lösungsansätze von schlechteren zu unterscheiden. Ein Lösungsansatz und die dazugehörende Problembeschreibung entwickeln sich bei diesem Vorgehen in enger Abhängigkeit voneinander.

In den Aufgaben rund um das Serviceportfolio, in denen es gilt, Stakeholderinteressen, Nutzerinteressen und strategische Vorgaben auszubalancieren, treten die Merkmale eines solchen „Wicked Problems“ wieder auf und es drängt sich daher die These auf, dass der Aufbau eines digitalen Serviceportfolios ein Wicked Problem in diesem Sinn ist. Insbesondere beim Vergleich von Stadtplanung vs. Portfolioplanung, wird die Ähnlichkeit aufgrund der Prozessorientierung augenfällig. Ein auf Designmethoden basierender Ansatz erscheint daher in besonderer Weise geeignet zu sein, um mit der Unbestimmtheit umzugehen, die für derartige Probleme typisch ist.

Daher wird in diesem Beitrag eine designbasierte Herangehensweise für die Planung und Konzeption von Services vorgeschlagen, die geeignet ist, dieser Problemstellung zu begegnen.14 Viele der Designmethoden wurden dem Bereich des Service Designs entlehnt. Dieser Ansatz wird als verwandt, aber nicht deckungsgleich verstanden, insofern, als mit dem Service Engineering ein stärker ordnender Rahmen eingeführt wird, der die Besonderheiten einer Hochschulbibliothek berücksichtigt. Für die Designmethoden, die im Rahmen des Service Engineering eingesetzt werden sollen, sind drei Eigenschaften charakteristisch:

1. Ein agiles Vorgehen, bei dem in Iterationen gearbeitet wird, Lösungen stetig evaluiert sowie verfeinert werden (z. B. mithilfe von Prototypen im Rahmen von Nutzertests),

2. die Einbindung aller Stakeholder*innen in den Prozess, um sicherzustellen, dass Lösungsansätze deren unterschiedliche Interessen berücksichtigen und

3. der Einsatz visueller Repräsentationsformen als Kommunikations- und Kreativwerkzeug.

Der Designprozess lässt sich als kreisförmig beschreiben. Auf die Analyse und Erhebung von Anforderungen folgt eine Phase der Gestaltung von Lösungsansätzen, die in einer weiteren Phase überprüft werden. Halten die Lösungsansätze einer Überprüfung stand, werden sie weiterverfolgt. Ist dies nicht der Fall, geht man häufig wieder zurück in die erste Phase und vertieft die Anforderungsanalyse, um den Prozess von neuem zu durchlaufen. Das Vorgehen hat daher einen stark experimentierenden Charakter: Erst durch eine Überprüfung kann die Tauglichkeit von Lösungsansätzen gezeigt werden. Als konkretes Beispiel lässt sich die Überprüfung von Bedienkonzepten in Usability-Tests anführen. Dieser Umstand verlangt vom Team eine Bereitschaft, sich nicht zu früh auf Konzepte festzulegen, sondern offen für Änderungen zu bleiben. Diese Änderungsfreudigkeit im Rahmen eines iterativen Vorgehens findet man auch im agilen Softwareentwicklungsprozess. Beide Prozesse scheinen daher in hohem Maße kompatibel zu sein.

4.2 Beispielszenario für eine Serviceentwicklung

Zur weiteren Illustration soll nun in einem fiktiven Szenario das Service Engineering eines eng umrissenen Beispielservice vorgestellt werden, hier provisorisch „KI-Visualisierer“ genannt – ein Instrument, das Visualisierungsformen für Datensamples vorschlägt. Am Anfang steht die Ideenfindung: Als emergente Technologie mit großem Potenzial erscheinen KI-unterstützte Services für die Wissenschaft naheliegend und folgerichtig in Bezug auf die digitale Transformation. Auch aktuelle und zukünftige Drittmittelförderlinien müssen als strategischer Faktor bedacht werden. Hier ist ein starker Aufwuchs von KI-Förderprogrammen bei den Drittmittelgebern zu verzeichnen. Auf diese Weise findet der Themenkomplex seinen Weg in die Gesamtstrategie der Einrichtung. Durch Gespräche mit Nutzenden lässt sich der konkrete Bedarf nach adäquaten Datenvisualisierungen in Beratungsgesprächen ermitteln, etwa im Kontext von Digital-Humanities-Projekten.

In einem ersten Schritt veranstaltete das Design- und Entwicklungsteam für die Entwicklung des digitalen Produkts einen Design Studio Workshop, eine erprobte Designmethode, mit der in den frühen Phasen des Service Engineerings der Lösungsraum exploriert wird.

Zu diesem Workshop werden neben dem Design- und Entwicklungsteam Forschende aus unterschiedlichen Bereichen und weitere Stakeholder*innen eingeladen. Ziel des Workshops ist es, in kurzer Zeit eine Vielzahl von Lösungsansätzen zu generieren und die vielversprechendsten zu ermitteln. Alle Teilnehmenden skizzieren in Gruppen mit wenigen Strichen viele Lösungsansätze und bringen so jeweils ihre eigene Perspektive ein. Diese einfachen Skizzen von Anwendungen spielen eine wichtige Rolle: Sie vermitteln Lösungsansätze in simpler, leicht verständlicher Form; sie sind schnell zu erstellen; sie vermitteln einen Überblick, wenn man sie nebeneinander legt; in ihrer Unfertigkeit laden sie zum Weiterdenken ein, fördern somit Kreativität. Die entwickelten Lösungsansätze werden in den Gruppen vorgestellt und diskutiert. In einer zweiten Iteration verfeinern die Gruppenmitglieder ihre Lösungsansätze basierend auf dem Feedback der anderen und stellen diese erneut vor. Gemeinsam wählt jede Gruppe dann vielversprechende Ideen aus, kombiniert sie ggf. und arbeitet einen Lösungsansatz im Detail aus. Diese werden im Plenum den anderen Gruppen vorgestellt. Jeder der im Workshop entwickelten Lösungsansätze konzeptualisiert die ursprünglich eingebrachte Idee auf eine einzigartige Weise und hilft auch zu verdeutlichen, welche Annahmen man hinsichtlich des zu lösenden Problems getroffen hat. Es entstehen Problem-Lösungspaare (siehe Abb. 1).

Um diese Annahmen zu überprüfen, das mit dem Lösungsansatz verbundene Problem also besser zu verstehen, werden in der nächsten Phase Contextual Inquiries15 durchgeführt, eine Art vereinfachte, teilnehmende Beobachtung. Hierbei beobachtet man Nutzer*innen, wie sie bisher Datenvisualisierungen in ihrem Forschungsalltag nutzen und welche Bedürfnisse und Ziele sie dabei verfolgen. Domänenspezifische Workflows, auch solche, die implizit sind, werden dadurch sichtbarer. Zu den Ergebnissen dieser Studien gehört die Erkenntnis, dass viele Nutzer*innen gerne Schritt für Schritt durch den Prozess der Erstellung geführt werden wollen und Schwierigkeiten haben, Vor- und Nachteile einzelner Visualisierungstechniken zu verstehen. Eine weitere Erkenntnis ist, dass es je nach Disziplin bevorzugte Visualisierungstypen gibt. Diese und andere Erkenntnisse sprechen dafür, aus den verschiedenen, im Rahmen des Workshops entstandenen Lösungsansätzen, die Variante „KI-Chatbot (Large Language Model, LLM)“ weiterzuverfolgen. Sie verspricht einen niedrigschwelligen, zielgruppengerechten Zugang zu den komplexen Themenfeldern Data Science, Datenvisualisierung und Artificial Intelligence.

Wie im Designprozess üblich, folgt auf eine Entscheidung für eine Lösung und damit eine Begrenzung des Lösungsraumes wieder eine Öffnung und in der nun folgenden Konzeptionsphase werden möglichst diverse Varianten des KI-Chatbots exploriert. Zu diesem Zeitpunkt werden Lösungsansätze sehr viel detaillierter ausgearbeitet. Hierfür eignen sich Wireframes16 als Methode. Dabei handelt es sich um eine Art von Drahtgittermodellen, die die wichtigsten Interaktionen mit der Anwendung als Abläufe darstellen, um auf diese Weise die Lösung und das Problem weiter zu spezifizieren. Als Kommunikationsmittel dienen sie einerseits dazu, innerhalb des Designteams und mit Stakeholder*innen Vor- und Nachteile zu diskutieren sowie Probleme und Chancen aufzudecken. Andererseits können sie zu einfachen Klickprototypen weiterentwickelt werden, die im Rahmen von Nutzertests erprobt werden können, sodass auch hier wieder Erkenntnisse gesammelt werden, die zu einer Verfeinerung in der nächsten Iteration führen, usw.

Nach eingehender Prüfung verschiedener Varianten auch mithilfe eines einfachen Nutzertests wird eine Entscheidung gefällt: Das digitale Produkt soll eine leicht zugängliche Webapp sein, die es ermöglicht, tabellarische Datensätze hochzuladen und geeignete Visualisierungsvorschläge für diese Datensamples zu erhalten. Im einfachen Fall kann das Sample aus einer Tabelle mit zwei Spalten bestehen, deren numerische Werte auf zwei Achsen geplottet werden. In komplexeren Fällen müssen Datentypen für Kategorien angegeben und die Parameter der Visualisierung genauer festgelegt werden. Um dies zu verdeutlichen, wird im Folgenden ein möglicher Use Case für einen solchen Service angeführt:

Ein großer Nutzen des Beispielservices scheint in der Verbindung des gerade skizzierten digitalen Produkts mit der Dienstleistung des Beratungsgesprächs im Kontext der Digital Humanities und des Forschungsdatenmanagements zu liegen. Das Visualisierungswerkzeug dient nicht dazu, publikationsreife Plots und Diagramme zu erzeugen, sondern unterstützt den Beratungskontext. Hierbei kommt es immer wieder vor, dass Daten und Datentypen dargestellt und referenziert werden müssen, um Aufwände für das weitere Vorgehen abzuschätzen. Mittels des Beispielservice können die Forschenden mit wenig Vorbereitung eine Vorschau auf mögliche adäquate Darstellungsformen ihrer quantitativen Daten erhalten, z. B. für die Darstellung von Statistiken rund um ein Textkorpus oder eine Sammlung. In der Forschungsunterstützung kommt es darauf an, dass Forschende und Forschungsunterstützende eine gemeinsame Sprache finden, um Verständnis für die domänenspezifischen Gegenstände herzustellen. Das zu entwickelnde digitale Produkt abstrahiert für diesen Zweck das notwendige Expertenwissen zur Erstellung einer komplexen Datenvisualisierung, um schnell zu einer beispielhaften Lösung zu gelangen. Methodisch kann dies mit einem LLM mit Chatinterface umgesetzt werden, das den Code für die Visualisierungsvorschläge erzeugt. Die Webapp bindet dann das hochgeladene Datensample ein und rendert die Demo-Visualisierung.17

Die Einbindung von Designmethoden ergänzt hierbei den durch das Service Engineering vorgegebenen Ordnungsrahmen um die zuvor genannten Charakteristika von Designmethoden (vgl. Kap. 4.1): In strukturierter Weise schaffen Designmethoden Situationen, die es ermöglichen, die unterschiedlichen, am Gestaltungsprozess beteiligten Stakeholder*innen engmaschig einzubinden und ihre Perspektive zu integrieren. Eine Kultur des offenen Experimentierens ermöglicht es den am Designprozess Beteiligten, ihre Ideen einzubringen, mithilfe visueller Repräsentationen anschaulich zu vermitteln und iterativ weiterzuentwickeln.

Designmethoden stellen auf diese Weise sicher, dass Problem- und Lösungsraum ausgiebig exploriert werden, mit einer größeren Wahrscheinlichkeit, auch innovative Lösungen zu finden. Sie verringern damit die Gefahr eines Rückgriffs auf naheliegende Lösungen, die das Problem nur unzureichend adressieren. Entscheidend ist hierbei die Abhängigkeit der beiden Räume. In obigem Beispiel hat man sich auf den Lösungsansatz "KI-Chatbot" festgelegt. Damit wurde das Problem auf eine bestimmte Art konzeptualisiert (Framing): Durch sein einfaches Prompt-Interface und wenige Anpassungsmöglichkeiten ist ein KI-Chatbot bestens geeignet, um schnell verschiedene Visualisierungsformen vorzustellen und zu diskutieren. Dies kann z. B. im Rahmen von Beratungsgesprächen geschehen oder unerfahrene Forschende können eigenständig Visualisierungen generieren. Hierfür ist zunächst kein besonderes Expertenwissen erforderlich. Implizit fasst man damit das Problem folgendermaßen:

Unerfahrene Nutzer*innen müssen großen Aufwand betreiben, um sich die technische Kompetenz zu erarbeiten, die für eine erste Analyse ihrer Daten mithilfe von Datenvisualisierungen notwendig wäre.

Hätte man einen anderen Lösungsansatz weiterverfolgt, bei dem KI-generierte Visualisierungen nicht nur über die verhältnismäßig ungenaue Eingabeschnittstelle Prompt, sondern präzise einstellbare User-Interface-Elemente generiert und angepasst werden können, hätte man bei Nutzer*innen ein hohes Maß an Kompetenz vorausgesetzt, so dass die Zielgruppe hier eher Expert*innen gewesen wären. Für diese läge der Vorteil eines solchen Tools in der Schnelligkeit und der Vereinfachung, mit der unterschiedliche Datenvisualisierungen ausprobiert und verglichen werden können. Ein Framing des Problems könnte dann etwa lauten:

Erfahrene Nutzer*innen benötigen viel Zeit, um Datenvisualisierungen mithilfe von Code zu generieren. Sie fahren dabei gewissermaßen „blind“, insofern, als sie erst nach dem aufwändigen Erstellen von Datenvisualisierungen bewerten können, ob eine Visualisierung geeignet ist.

4.3 Zusammenfassung

Damit der Designprozess gelingen kann, ist es wichtig, die folgenden Voraussetzungen zu erfüllen: Für die Anwendung von Designmethoden muss ein Rahmen geschaffen werden, in dem eine offene, transparente und wertschätzende Kommunikationskultur etabliert wird. Am Designprozess Beteiligte sollten keine Angst davor haben, ihre Ideen einzubringen, zu experimentieren, Fehler zu machen und aus ihnen zu lernen. Sie sollten Offenheit für die Ideen zeigen und bereit sein, auf diesen aufzubauen. Die Formen der Zusammenarbeit sollten daher nicht nur festgehalten, sondern auch immer wieder im Rahmen von Designmethoden in Erinnerung gerufen werden.18

5. Ergebnis

Die Entwicklung eines Serviceportfolios für Hochschulbibliotheken ist ein Wicked Problem. Es können daher die erprobten Lösungsansätze für solche unbestimmten Probleme angewendet werden. Diese Ansätze stellen die Prinzipien der visuellen Repräsentation, des Einbeziehens aller Stakeholder*innen von Beginn an und die Änderungs- sowie Experimentierfreudigkeit in den Mittelpunkt. Der Beitrag zeigt, dass es möglich ist, das Methodenset der Designpraxis auf die Serviceentwicklung zu übertragen. Es gibt bei dieser Vorgehensweise keine vordefinierte Musterlösung, da diese den Eigenschaften eines Wicked Problem nicht gerecht werden könnte. Die genannten Methoden entsprechen auch nicht dem Schema „ein Problem – eine Lösung“. Stattdessen ist es notwendig, explorativ den Problem- und Lösungsraum für jede Serviceerstellung zu erkunden. Erarbeitet werden daher sowohl Problembeschreibungen, die im weiteren Verlauf immer adäquater werden, als auch dazu passende mögliche Lösungsbeschreibungen. Problem- und Lösungsraum werden auf diese Weise abgesteckt und Schritt für Schritt genauer erfasst. Somit gelingt die iterative Annäherung an die Serviceidee im Sinne einer Ausdifferenzierung aus der Vielzahl der vorgefundenen Möglichkeiten und existierenden Einschränkungen. Es wird durch den experimentierfreudigen Einsatz von Visualisierungen für die Akteure leichter, Fortschritte zu erzielen, den nächsten Schritt zu erkennen und neue Ergebnisse zu erarbeiten.

Integriert ist diese Herangehensweise in den Ordnungsrahmen des Service Engineering. Dieser dient dazu, die einzelnen Phasen der Serviceerstellung von der Idee bis zur Inbetriebnahme digitaler Produkte sehr grob vorzustrukturieren und mittels beigeordneter Methodenvorschläge zu operationalisieren. Die involvierten Akteure sollen in die Lage versetzt werden, einen Serviceentwurf kontinuierlich weiterzuentwickeln und dabei die Qualitätsvorgaben der servicegebenden Einrichtung einzuhalten. Erscheint diese Aufgabe zunächst kaum lösbar, weil das am Ende stehende digitale Produkt noch nicht absehbar ist, bietet sich den Akteuren durch das Methodenset der Designpraxis die Chance, die Bedingungen und Eigenschaften eines Service herauszuarbeiten und Konsens über das nächste Zwischenziel herzustellen. Der Ordnungsrahmen verbindet dabei einzelne Methoden und Prozessschritte zu einem nachvollziehbaren Ganzen, in dem die Expertise der Akteure vorgehalten und verfügbar gemacht wird. Standortspezifische Vorgaben und Standards können an Kontrollpunkten zwischen den Phasen des Service Engineering abgeglichen werden, während der Serviceentwurf an Reife gewinnt.

Ordnungsrahmen und Designpraxis stehen orthogonal zueinander: Die eher formalisierte Kommunikation des linear ausgerichteten Service Engineering mit dem Ziel, Projektphasen abzubilden und am Ende ein digitales Produkt in Betrieb zu nehmen, trifft auf die weniger formalisierte Kommunikation der Designmethoden, etwa in einem Workshop. In der Verbindung von Ordnungsrahmen und Designmethoden liegt das Potential, Kreativität und Agilität in der Entwicklung von Services innerhalb institutioneller Strukturen zu fördern. Service Engineering ist hierbei aber auch ein Werkzeug, das durch seinen formalen Charakter strukturbildend wirkt, etwa in Form von Rollen wie der eines bzw. einer Product Owner, und es erleichtert, die Serviceentwicklung in ein Projektmanagement zu integrieren.

Der Anspruch exzellenter Forschung erfordert für die Forschungsunterstützung ein aktuelles Serviceportfolio, das je nach Anforderungslage eines Standorts, potenziell alle Schritte im Forschungszyklus durch Dienstleistungen und digitale Produkte sinnvoll begleitet. Diese Herkulesaufgabe lässt sich besser und adaptiver bewältigen, wenn Services von gleichbleibend hoher Qualität rasch entwickelt werden können. Die in diesem Beitrag vorgestellte Herangehensweise kann ein Ausgangspunkt für den effizienten Aufbau eines solchen adaptiven Serviceportfolios sein.

6. Literaturverzeichnis

Buchanan, Richard: Wicked problems in design thinking, in: Design Issues 8 (2), 1992, S. 5–21. https://doi.org/10.2307/1511637.

Conklin, Jeffrey: Dialogue Mapping. Building Shared Understanding of Wicked Problems, Chichester 2005.

Dinger, Patrick; Schutzeichel, Marc: Agiles Service Engineering für digitale forschungsunterstützende Dienste in Hochschulbibliotheken, in: Bibliothek Forschung und Praxis 49 (1), 2025, S. 71–184. https://doi.org/10.1515/bfp-2024-0028.

Deutsche Forschungsgemeinschaft (DFG). Ausschuss für Wissenschaftliche Bibliotheken und Informationssysteme Hg.): Digitale Forschungspraxis und kooperative Informationsinfrastrukturen. Ein Diskussionspapier der Deutschen Forschungsgemeinschaft zur Förderung und Finanzierung wissenschaftlicher Informationsinfrastrukturen, Version 1, Bonn 2025. https://doi.org/10.5281/zenodo.14621979.

Dorst, Kees: The core of ‘design thinking’ and its application, in: Design studies, 32 (6), 2011, S. 521–532. https://doi.org/10.1016/j.destud.2011.07.006.

Karsten-Welker, Adienne; Dinger, Patrick; Schutzeichel, Marc: Vom Bedarf zum nachhaltigen Service. Einführung eines elektronischen Laborbuchs an der Universität Münster, in: o-bib. Das Offene Bibliotheksjournal 12 (4), 2025. https://doi.org/10.5282/o-bib/6178.

Paulick-Thiel, Caroline; Arlt, Henrike; Köbler, Bettina: Öffentliches Gestalten. Handbuch. https://www.oeffentliches-gestalten.de/, Stand: 06.02.2026.

Rapp, Andrea: Digital Humanities und Bibliotheken. Traditionen und Transformationen, 027.7, 8 (1), 2021. https://doi.org/10.21428/1bfadeb6.486c17e5.

Rittel, Horst W. J.; Webber, Melvin M.: Dilemmas in a general theory of planning, in: Policy sciences 4 (2), 1973, S. 155–169. https://doi.org/10.1007/BF01405730.

Sanders, Elizabeth B. N.; Stappers, Pieter Jan: Co-creation and the new landscapes of design, in: Co-design, 4 (1), 2008, S. 5–18. https://doi.org/10.1080/15710880701875068.

Terras, Melissa M.: The rise of digitization. Digitisation perspectives, in: Rikowski, Ruth (Hg.): Digitisation Perspectives. Educational Futures Rethinking Theory and Practice, vol 46, SensePublishers 2011, S. 3–20. https://doi.org/10.1007/978-94-6091-299-3_1.

Wixon, Dennis; Karen Holtzblatt; Stephen Knox: Contextual design. An emergent view of system design, in: Proceedings of the SIGCHI Conference on Human Factors in computing systems, 1990, S. 329–336. https://doi.org/10.1145/97243.97304.