2

Vorwort� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �5Quer denken – zielgerichtet handeln � � � � � � � � � � � � � � � 8Was ist eigentlich digitales Produktdesign? � � � � � � � � � 8Wie wir arbeiten � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �10Was uns inspiriert � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �12Unser Handwerkszeug � � � � � � � � � � � � � � � � � � � � � � � � � � �13

Designprozess � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �15Wie wird ein Produkt gut? � � � � � � � � � � � � � � � � � � � � � � � �16Wir denken, analysieren und probieren � � � � � � � � � � � �18Ideen werden konkret� � � � � � � � � � � � � � � � � � � � � � � � � � � �19Die Arbeit geht weiter � � � � � � � � � � � � � � � � � � � � � � � � � � � 20

Handwerkszeug � � � � � � � � � � � � � � � � � � � � � � � � � � � �23

Phase #1: Analyse � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �24Nutzeranalyse � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 26

Qualitative Interviews mit (potenziellen) Nutzern 29Emotionale Motivkarte � � � � � � � � � � � � � � � � � � � � � � � �31Rationale Motivkarte � � � � � � � � � � � � � � � � � � � � � � � � � �33

Marktanalyse � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �34Benchmarking � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �37Strategische Positionierung� � � � � � � � � � � � � � � � � � � � �39

Trendanalyse � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 40Trendmonitoring� � � � � � � � � � � � � � � � � � � � � � � � � � � � � �43Trendmap � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �45

Aufgabenanalyse � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 46Feldstudie � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 49Stakeholder-Interview � � � � � � � � � � � � � � � � � � � � � � � � 50UX-Zieltabelle � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �53

Technische Ist-Analyse� � � � � � � � � � � � � � � � � � � � � � � � � � �54Analyse der IT-Infrastruktur � � � � � � � � � � � � � � � � � � � �57Analyse von Bestandsystemen und Schnittstellen �59Analyse von Sicherheitsanforderungen � � � � � � � � � 60

Inhalt

3

Phase #2: Labor � � � � � � � � � � � � � � � � � � � � � � � � � � � 62Nutzerverständnis� � � � � � � � � � � � � � � � � � � � � � 64

Personas � � � � � � � � � � � � � � � � � � � � � � � � � � � � 67Mentale Modelle � � � � � � � � � � � � � � � � � � � � � 69Emphathy Map � � � � � � � � � � � � � � � � � � � � � � 70

Nutzungsszenarien � � � � � � � � � � � � � � � � � � � � � 72User Journey � � � � � � � � � � � � � � � � � � � � � � � � 75Experience Map � � � � � � � � � � � � � � � � � � � � � 77Storyboards� � � � � � � � � � � � � � � � � � � � � � � � � � 78

Ideation � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �80Die 7 goldenen Brainstorming-Regeln� � � 83Brainstation � � � � � � � � � � � � � � � � � � � � � � � � � 85Regelbruch � � � � � � � � � � � � � � � � � � � � � � � � � � 87Kaskadiertes Brainstorming � � � � � � � � � � �89Criteria Scan � � � � � � � � � � � � � � � � � � � � � � � � � 91Affinitäts-Diagramm � � � � � � � � � � � � � � � � � 93

Anforderungs-Definition � � � � � � � � � � � � � � � � 94Feature Map � � � � � � � � � � � � � � � � � � � � � � � � � 97Produkt Backlog� � � � � � � � � � � � � � � � � � � � � � 99User Story � � � � � � � � � � � � � � � � � � � � � � � � � � 101

Designstudien � � � � � � � � � � � � � � � � � � � � � � � � 102Moodboards � � � � � � � � � � � � � � � � � � � � � � � � 105Konzeptstudien � � � � � � � � � � � � � � � � � � � � � 107WallTalk � � � � � � � � � � � � � � � � � � � � � � � � � � � 109

Technische Evaluation � � � � � � � � � � � � � � � � � 110Auswahl Technologie � � � � � � � � � � � � � � � � 113Auswahl Systeme � � � � � � � � � � � � � � � � � � � 115

Phase #3: Design � � � � � � � � � � � � � � � � � � � � � � � � � 116Taxonomien � � � � � � � � � � � � � � � � � � � � � � � � � � 118

Card Sorting � � � � � � � � � � � � � � � � � � � � � � � � 121Mindmap � � � � � � � � � � � � � � � � � � � � � � � � � � 123

Konzeptdesign � � � � � � � � � � � � � � � � � � � � � � 124Flussdiagramme � � � � � � � � � � � � � � � � � � 127Wireframing� � � � � � � � � � � � � � � � � � � � � � 129Entwurfsmuster (Pattern) � � � � � � � � � � 131Konzept-Spezifikation� � � � � � � � � � � � � � 133

Oberflächendesign � � � � � � � � � � � � � � � � � � 134Layouting � � � � � � � � � � � � � � � � � � � � � � � � 137Styleguide � � � � � � � � � � � � � � � � � � � � � � � � 139Papier- & Funktions-Prototypen� � � � � 141Service-Prototypen � � � � � � � � � � � � � � � � 143Interaktions-Modelle � � � � � � � � � � � � � � 145

Evaluierung & Testing� � � � � � � � � � � � � � � � 146Usability-Testing � � � � � � � � � � � � � � � � � � 149Heuristische Evaluierung � � � � � � � � � � 151

Software-Architektur � � � � � � � � � � � � � � � � 152Datenmodell � � � � � � � � � � � � � � � � � � � � � � 155Komponentenmodell � � � � � � � � � � � � � � 157System-Architektur� � � � � � � � � � � � � � � � 159

Phase #4: Realisierung � � � � � � � � � � � � � � � � � � 160Implementierung � � � � � � � � � � � � � � � � � � � 162

Rapid Prototyping � � � � � � � � � � � � � � � � � 165Testgetriebene Entwicklung � � � � � � � � 167Kontinuierliche Integration � � � � � � � � 169

Testing � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 170Komponententest � � � � � � � � � � � � � � � � � 173Last- und Stresstest � � � � � � � � � � � � � � � � 175Sicherheitstest � � � � � � � � � � � � � � � � � � � � 177

Dokumentation � � � � � � � � � � � � � � � � � � � � � 178Technische Dokumentation � � � � � � � � 181Anwenderdokumentation � � � � � � � � � � 183Training� � � � � � � � � � � � � � � � � � � � � � � � � � 185

Kommunikationsplanung � � � � � � � � � � � � 186Integrierte Kommunikation � � � � � � � � 189Roadmap � � � � � � � � � � � � � � � � � � � � � � � � � 191

4

5

Vorwort#1

Quer denken – zielgerichtet handelnWas ist eigentlich digitales Produktdesign?

Wie wir arbeitenWas uns inspiriert

Unser Handwerkszeug

6

Bei denkwerk arbeiten wir mit 170 kreativen Köpfen im Team. Bei uns verfolgen alle das gleiche Ziel: Wir möchten digitale Nutzererlebnisse gestalten, die gleichzeitig überzeugen, faszinieren und weiterhelfen.

Bei unseren Projekten unterscheiden wir zwischen den beiden großen Themenfeldern Kommunikation und Design� Im Bereich Kommu-nikation liegt unser Schwerpunkt darauf, Marken einheitlich und einprägsam über alle Kanäle zu präsentieren� Unter dem Punkt Design verstehen wir die Entwicklung digitaler Platt-formen und Anwendungen� Darunter fällt auch die digitale Produktent-wicklung – und um die soll es im Folgenden gehen�

PROJECTMANAGEMEN

T

PROJECTMANAGEMEN

T

INSIGHTS  & 

PLANNING

 COMMUNICATION

 

 DESIG

N 

 TECHNOLOGY 

7

8

Quer denken – zielgerichtet handeln

Was ist eigentlich digitales Produktdesign?

Wir möchten Produkte entwickeln, die Sie und Ihre Kunden gerne nutzen� Aber die fallen eben nicht vom Himmel� Deshalb probieren wir gerne ungewöhnliche Dinge aus� Wir basteln auch schon mal eine iPhone-App aus Tonpappe und Knetgummi, weil wir wissen, dass man Dinge oft anfassen muss, um sie wirklich zu begreifen� Und wenn es nötig ist, kann man diese Dinge auch einfach in den nicht-digitalen Papierkorb befördern …

Can’t touch this …Digitale Inhalte und Dienstleistungen sind nicht mehr wegzudenken aus unserem bis ins letzte Eckchen durchdigitalisierten Leben� Dem Nutzer ist klar, dass man Produkte nicht mehr berühren können muss, um ihnen zu vertrauen und sie zu schätzen� Und weil digitale Güter inzwischen jeden Bereich unseres Alltags einnehmen, hat sich auch der Fokus unserer Arbeit verändert� Die Frage „Wie können wir dem Nutzer echte Mehrwerte bieten?“ steht mehr denn je im Zentrum� Wir helfen unseren Auftraggebern, neue Services und Geschäftsmodelle zu finden und zu entwickeln und begleiten sie dabei, ihre Wertschöp-fungskette zu digitalisieren�

9

Damit ein Produkt erfolgreich ist, müssen wir erst einmal die Bedürfnisse seines Nutzers kennen, da wir es schließlich für ihn gestalten und entwickeln.

Das fertige Produkt kann eine umfangreiche Software sein, die den Nutzer bei seiner täglichen Arbeit unterstützt - oft aber ist es auch nur eine kleine Applikation, die in bestimmten Situationen das Leben etwas angenehmer gestaltet und Freude bereitet�

Not just a pretty face …Design definiert, wie das Produkt aussieht und ob es dem Nutzer gefällt� Wir von denkwerk gestalten ein Nutzungserlebnis, das ganzheit-lich ist – zu dem also mehr gehört als nur die Farbe und Form eines Produkts� Wichtig sind eine einfache Struktur und Nutzerführung, logi-sche Interaktionen sowie verständliche Texte� Jedes einzelne dieser Elemente nimmt Einfluss auf den Nutzer�

Fühlt er sich gut bei der Bedienung des Produkts? Vertraut er dem Produkt? Nutzt er es gerne? – Dann haben wir einen guten Job gemacht�

10

Wie wir arbeiten

Ein gutes Produkt setzt voraus, dass jeder einzelne Bestandteil optimal gestaltet und umgesetzt ist� Dieses Ziel können wir nur im Team errei-chen und nur, wenn all unsere Abteilungen zusammenarbeiten� Denn nur so können wir jedes Detail eines Produkts – und damit jeden Arbeitsschritt – von Anfang an überblicken� Wir glauben, dass jeder unserer Mitarbeiter seinen Beitrag dazu leistet, weil sich Kreativität, Erfahrungen und Wahrnehmungen bei jedem anders auswirken�

Deshalb legen wir auf zwei Dinge ganz besonderen Wert: Zum einen müssen wir unsere Nutzer sehr gut verstehen – für sie gestalten wir schließlich unsere Produkte� Zum anderen beziehen wir jeden Mitar-beiter, der zur Entwicklung eines Produkts beiträgt, von Anfang an in unsere Prozesse mit ein� Nur so haben wir alle das gleiche Ziel vor Augen, können alle Arbeitsschritte von Anfang an überblicken und daraus eine gemeinschaftliche Vision entwickeln�

Auch Sie sind Teil des Teams!Natürlich kennen Sie als unsere Auftraggeber Ihre Kunden besser und länger als wir� Aber wir können Ihnen dabei helfen, neue Wege zu sehen und zu gehen� Deshalb arbeiten wir gerne für Sie – aber noch lieber mit Ihnen gemeinsam� Für Ihre Kunden�

Dabei sind uns interaktive Workshops, in denen wir mit unseren Auftraggebern gemeinsam Ergebnisse erarbeiten, lieber als PDFs, die von Mitarbeiter zu Mitarbeiter geschickt werden� Wir verfolgen unsere Vision – sozusagen als Sprecher des Nutzers – gemeinsam mit Ihnen, um ein nutzerzentriertes Produkt zu entwickeln und, wenn notwendig, auch die größtmögliche Akzeptanz innerhalb Ihres Unternehmens zu gewährleisten�

11

Nur wenn alle das gleiche Ziel vor Augen haben, lässt sich ein optimales Ergebnis erreichen.

12

Was uns inspiriert

Unser bunter Alltag, Reisen an interessante Orte,

das Leben miteinander, die Weite des Internets,

ein neuer Lieblingsfilm – all diese Dinge und der

Austausch untereinander (zum Beispiel beim

freitäglichen Kölsch auf unserer Dachterrasse)

inspirieren uns.

Inspiration ist nur der Anfang� Unsere internen Formate helfen uns dabei, aus unserer Inspiration Impulse und kreative Anstöße zu entwi-ckeln und den Austausch untereinander zu fördern� Denn oft löst ein Außenstehender mit einem Fingerschnippen einen Gedankenknoten, der am Schreibtisch nebenan stundenlang für Kopfschmerzen gesorgt hat�

Unsere Formate:

▶ kreatifrühstück: Regelmäßig hören wir beim gemeinsamen Früh- stück Vorträge von Externen oder Internen zu spannenden Themen�

▶ denkwerkstatt: Mehrmals im Jahr führen wir ganztägige Workshops durch, in denen wir interdisziplinär an neue Themen und Methoden, wie z� B� Design Thinking, herangehen�

▶ denkwerk thinx: Dabei handelt es sich um ein Labor, in dem wir "denkwerk Dinge" kreieren� Neue, nützliche und bewegende Dinge, die gerne auch etwas seltsam sein können� Große und kleine Ideen, die mal praktisch sind, mal mit Medien oder Kunst zu tun haben, manchmal aber auch einfach nur zu Nonsens verpuffen� Im Kern geht es immer darum, Digitales menschlicher zu gestalten und den Weg für neue digitale Produkte und Services zu ebnen�

13

Unser Handwerkszeug

Als denkwerker verstehen wir unser Handwerk und

benutzen unseren Kopf. Wir verkaufen Ihnen keinen

Zauberstaub, sondern unser Wissen und Können.

Mit unserem strukturierten Vorgehen, in dem wir alle Einflussfaktoren berücksichtigen, erzielen wir sehr gute und konkrete Ergebnisse� Um für Ihre Kunden das perfekte Produkt zu bauen, haben wir einen denk-werk-eigenen Prozess und einen Baukasten mit diversen Methoden entwickelt, der ständig erweitert wird�

Unser Prozess basiert auf unserer jahrelangen Erfahrung in der Entwicklung digitaler Produkte� Er berücksichtigt die vielen Besonder-heiten, die bei den unterschiedlichen Produkten auftreten, und wird implementiert durch unseren Methoden-Baukasten� An ein dogma-tisches Festhalten nur eines Vorgehensmodells glauben wir nicht, sondern sind überzeugt vom individuellen Einsatz unseres denkwerk-Prozesses� Passend zu den jeweiligen Anforderungen können wir damit die passenden Methoden aus unserem Baukasten auswählen und unseren Fokus auf das legen, was für das jeweilige Projekt am wich-tigsten ist�

Unseren Prozess möchten wir Ihnen in diesem Dokument vorstellen� Damit Sie verstehen, mit welcher Überzeugung und Leidenschaft wir unsere Vision von guten digitalen Produkten verfolgen� Denn auch wenn Kreativität manchmal nichts weiter als knochenharte Arbeit ist … wir lieben, was wir tun!

14

15

Designprozess#2

Wie wird ein Produkt gut?Wir denken, analysieren und probieren

Ideen werden konkretDie Arbeit geht weiter

16

Wie wird ein Produkt gut?

Ideen fallen nicht vom Himmel, sondern müssen hart erarbeitet werden.

Damit wir leichter auf noch bessere Ideen stoßen, haben wir uns diverse Methoden, Formate und Vorgehen angeeignet, die wir in unsere tägliche Arbeit integrieren�

Diesen „Design-Thinking“-Prozess bis hin zum fertigen Produkt durch-laufen wir gemeinsam mit Ihnen� Damit die Arbeit möglichst effizient ist und das Produkt wirklich gut wird�

Unser gemeinsamer Ablauf sieht so aus: Zu Anfang briefen Sie uns als Auftraggeber oder beschreiben kurz, wie Sie sich Ihr Produkt vorstellen� Wir stellen daraufhin gemeinsam mit Ihnen ein individuelles Set von Methoden aus unserem Baukasten zusammen� Dabei hilft ein Team von denkwerkern aus den unterschiedlichsten Fachbereichen� Ganz am Ende steht das fertige Produkt� Aber dazwischen liegen natürlich eine Menge Stationen: Analyse, Labor, Design und Realisierung – all diese Phasen müssen in der Produktentwicklung durchlaufen werden – bei Ihnen, bei uns oder gemeinsam�

17

18

Wir denken, analysieren und probieren

Für wen, warum und wie soll ein Produkt designt werden? Welche Bedürfnisse hat der Nutzer? Etliche Fragen sind ausschlaggebend dafür, dass ein Produkt gut und erfolgreich entwickelt werden kann� Um Antworten zu finden, beginnen wir unsere Projekte immer mit der Analysephase, die wichtig für alle weiteren Arbeiten ist� Hier betrachten wir produktrelevante Dinge wie Trends, Markt, Zielgruppe, Aufgabenstellung und Technik, überprüfen diese und bewerten sie�

Je nachdem, wie das Projekt ausgerichtet ist oder wie konkret oder offen die Vorgaben des Auftraggebers sind, wählen wir passende Methoden aus unterschiedlichen Disziplinen (wie Strategie, Technik, User Experience Design) aus und wenden diese an, um am Ende ein (Re-)Briefing zu erstellen, auf das dann die Laborphase aufsetzt�

Im Labor entstehen anhand der Erkenntnisse aus unserer Analyse erste Ideen und Entwürfe, die wir konzipieren, visualisieren und auspro-bieren� Die besten Ideenansätze entwickeln wir weiter, indem wir im Team wieder und wieder einen innovativen Mix aus Kreativität und Kollaborationen anwenden� Erst dann werden Ideen konkretisiert� Wir betrachten die ersten Ansätze aus den unterschiedlichsten Blickwin-keln, wir erstellen Szenarien und Studien und bewerten so die Qualität und Tragfähigkeit unserer Entwürfe� Anhand der Ideenskizze, die in der Laborphase entsteht, dokumentieren wir genauestens die Produktidee und bereiten sie für die weitere Konkretisierung und Ausdefinition auf�

19

Ideen werden konkret

In der Designphase wird die Idee dann „zum Leben erweckt“, damit unsere Auftraggeber und auch die Techniker sich an einer verbindli-chen und endgültigen Ausgestaltung orientieren können� Also schaffen wir Prototypen sowie klar verständliche Dokumentationen, Spezifika-tionen und Oberflächenvisualisierungen� Diese Dokumentation der Nutzeroberfläche, die aus einem oder mehreren Artefakten besteht, geben wir in die Realisierungsphase� Hier wird dann das „echte“ Produkt umgesetzt und schließlich an seinen Auftraggeber ausgeliefert�

20

Die Arbeit geht weiter

Sie haben Fragen, möchten noch etwas anmerken

oder haben vielleicht einen zündenden Einfall?

Während der gesamten hier beschriebenen Prozesse

stehen wir Ihnen Rede und Antwort und sind als

zuverlässiger Partner immer zur Stelle. Zusätzlich

bieten wir Ihnen, je nach Umfang und Ausrichtung

des Projekts, eine Auswahl möglicher Arbeitspakete

an.

Mit dem hier vorgestellten "Design-Thinking"-Ablauf ist unsere Arbeit noch längst nicht abgeschlossen, er zeigt nur den Weg von der ersten Anforderung bis zur Auslieferung des Produkts� Doch damit dieses reibungslos in den Markt integriert wird, gibt es auch danach noch einiges zu tun: Inhalte müssen bereitgestellt, Marketing- und Rollout-Pläne erstellt und umgesetzt werden� Und damit das Produkt auch zukünftig weiterentwickelt, angepasst und verbessert werden kann, ist eine ständige Optimierung nötig, die auf Tracking, Performance-Measurement und Usability-Studien basiert�

21

22

23

Handwerkszeug#3

AnalyseLabor

DesignRealisierung

2424

Phase #1

2525

An

alys

eA

nal

yse

2626

Nutzeranalyse

Das Netz erlaubt jedem Nutzer, aktiv zu werden und

mit seiner Umwelt zu interagieren. Wenn wir an

unsere Zielgruppen denken, denken wir an Nutzer,

weniger an Konsumenten. Also vor allem daran, wie

und warum Menschen mit Produkten interagieren.

Ob ein Nutzer mit einem Produkt interagiert

entscheidet allein er. Von der Relevanz eines

Produktes oder einer Dienstleistung können wir

den Nutzer dann überzeugen, wenn unser Produkt

seine Interessen, Bedürfnisse, Gewohnheiten,

Vorlieben und Wünsche trifft. Also beobachten wir

Gewohnheiten, spüren entsprechende Muster auf,

erarbeiten Typologien und führen uns immer wieder

vor Augen, was dies für die Gestaltung einzelner

Produkte heißt. Dafür wenden wir verschiedene

Methoden an.

2727

An

alys

eA

nal

yse

2828

2929

An

alys

e

QUALITATIVE INTERVIEWS MIT (POTENZIELLEN) NUTZERN

Die Bedürfnisse und Einstellungen der Nutzer interessieren uns� Um sie kennenzulernen eignet sich am besten das interaktive Interview, da es Rückfragen und die Vertiefung von Themen ermöglicht und wir so eventuell verborgene Erfahrungen und Wünsche erkennen können�

Wir nutzen keine einheitliche Vorlage, um einen Interview-Leitfaden zu erstellen� Für einen schnellen, unkomplizierten Einstieg in die Formulierung der Fragen, bietet sich die K�A�M�E�A�-Formel an:

▶ Kenntnisse Was weiß der Nutzer bereits über eine Produktkategorie oder ähnliche Produkte?▶ Anwendung In welchen Situationen würde er das Produkt gebrauchen?▶ Meinung Wie steht der Nutzer, ganz subjektiv, zu einem Produkt?▶ Erfahrungen Hat der Nutzer bereits Erfahrungen mit ähnlichen Produkten oder kennt er ähnliche Nutzungssituationen?▶ Anekdoten Kennt der Nutzer eine bemerkenswerte oder lustige Anekdote dazu?

Die Antworten der befragten Nutzer vergleichen wir miteinander� Wir suchen Gemeinsamkeiten, Unterschiede und Besonderheiten und bilden daraus 5 bis 15 aussagekräftige und mutige Thesen� Diese nutzen wir gegebenenfalls als Ausgangspunkt für die weitere Entwicklung des Produkts�

3030

»Indem wir die Eigenschaften und Features unseres Produktes in der Karte platzieren, können wir feststellen, welche Art von Motiven dadurch besonders stark angesprochen wird.«

3131

An

alys

e

EMOTIONALE MOTIVKARTE

Zusätzlich zu den Informationen die uns die Nutzer in Interviews geben, hilft uns eine emotionale Motivkarte dabei, unausgesprochene Bedürfnisse und Emotionen noch besser zu verstehen� Dabei arbeiten wir mit einer Karte, in der die wichtigsten Motivsysteme des Menschen und die dazugehörigen emotionalen Eigenschaften festgehalten sind�

Eines dieser Motivsysteme ist zum Beispiel das Dominanz-System, welches eng mit den Eigenschaften Mut, Macht, Kampf, Freiheit, Status usw� zusammenhängt� Indem wir die Eigenschaften und Features unseres Produktes in der Karte platzieren, können wir feststellen, welche Art von Motiven dadurch besonders stark angesprochen werden� Umgekehrt können wir sehr viel gezielter Produkteigenschaften entwi-ckeln, wenn wir wissen, welche Motivsysteme – und damit Nutzer-Typen – wir ansprechen wollen�

3232

»Die rationale Motivkarte stellt die Beziehung zur Marke oder zum Hersteller her und bildet die technische Affinität der Nutzer und mögliche Situationen der Nutzung ab.«

3333

An

alys

e

RATIONALE MOTIVKARTE

Die rationale Motivkarte wenden wir an, um bestimmte Faktoren einzuordnen und die Bedürfnisse der Nutzer zu erkennen� Bei dieser Methode grenzen wir die Nutzer, die wir ansprechen wollen, anhand einer Karte ein� Diese Karte stellt die Beziehung zur Marke oder zum Hersteller her (Bestandskunden, neue Kunden, Fans, Kritiker) und bildet die technische Affinität der Nutzer und mögliche Situationen der Nutzung ab� Die Beziehung des Nutzers zum Produkthersteller und weitere kontext-bestimmende Eigenschaften beeinflussen ihn in der späteren Nutzung� Damit wir diese Faktoren einordnen und die Bedürfnisse der Nutzer ableiten können, arbeiten wir mit der rationalen Motivkarte�Dadurch, dass mithilfe der Karte Persönlichkeitseigenschaften und Bedürfnisse zugeordnet werden, können wir Inspirationen für Personas und Brainstormings sammeln�

3434

Unsere Produkte und die dazugehörigen Firmen

haben fast immer direkte und indirekte Konkurrenz.

Vereinfacht gesagt heißt das: Wenn zwei das

Gleiche machen, halbiert sich der Ertrag. Deshalb

positionieren wir unsere Produkte dort, wo sie

sowohl zur anvisierten Zielgruppen, den Zielen

und weiteren Produkten der Firma passen, aber

gleichzeitig auch eine möglichst exklusive und

ausreichend große Nische erschließen.

Wir analysieren das gesamte Marktumfeld

und beziehen dabei sowohl aktuelle, als auch

zukünftige gesellschaftliche, wirtschaftliche

und technische Entwicklungen mit ein. Anhand

dieser Informationen wissen wir, an welcher

Stelle ein Kunde derzeit steht, welche Position er

mit der Entwicklung eines bestimmten Produkts

einnehmen möchte und wie wir dieses Ziel

erreichen.

Marktanalyse

3535

An

alys

e

Marktanalyse

Phas

e A

nal

yse

An

alys

e

3636

Mit Hilfe des Benchmarking können wir Stärken und Schwächen der Konkurrenz, aber auch Referenzen und Potentiale für unser eigenes Produkt herausfiltern.

3737

An

alys

e

BENCHMARKING

Mit Hilfe des Benchmarking können wir Stärken und Schwächen der Konkurrenz, aber auch Referenzen und Potentiale für unser eigenes Produkt herausfiltern�

Bevor wir unsere Recherche starten, müssen wir festlegen, anhand welcher Kriterien wir die Wettbewerber vergleichen möchten� Sinnvoll sind zwei bis fünf Vergleichskriterien, die wir mittels der eigenen Ziele, mithilfe unserer Erkenntnisse aus der Zielgruppenanalyse oder anhand von bestimmten Eigenschaften einer Branche auswählen� Beispiele für Kriterien können Emotionalität, Einfachheit, Sicherheit u� v� m� sein�

Nach intensiver Recherche bewerten wir mit diesen Kriterien nun das eigene Produkt und ausgewählte Konkurrenzprodukte� Die Ergebnisse visualisieren wir anschließend in einem Netzdiagramm, bei dem die ausgewählten Kriterien Eckpunkte bilden� Anhand dieser Eckpunkte können wir die Bereiche erkennen, in denen Wettbewerber besonders gut aufgestellt sind, aber auch, wo deren Schwachpunkte liegen�

Nun haben wir Potentiale und Gemeinsamkeiten mit Wettbewerbern sichtbar gemacht� Um unsere Bewertung mit Argumenten zu stützen, ist es sinnvoll, die gewonnenen Erkenntnisse über die Konkurrenz in Form von Texten und Bildern festzuhalten�

3838

3939

An

alys

e

STRATEGISCHE POSITIONIERUNG

Genau wie mit dem Benchmarking, können wir auch mit der strategi-schen Positionierung Alleinstellungsmerkmale, Stärken und Schwä-chen eines Produkts identifizieren� Der Unterschied besteht aller-dings darin, dass wir hierbei für die Bewertung immer gegensätzliche Eigenschaftspaare wählen, wie z� B� Emotionalität/Rationalität oder Sicherheit/Freiheit� Zur Visualisierung ist das klassische Positionierungskreuz beson-ders gut geeignet: Die Koordinatenachsen belegen wir mit jeweils zwei entgegengesetzten Dimensionen eines Kriteriums; innerhalb der entstandenen Flächen positionieren wir die Wettbewerber und das eigene Produkt, je nach Ergebnis der Wettbewerbsrecherche� Nun haben wir einen guten Überblick über die Ist-Position und können anhand der Bereiche, die nicht oder nur schwach von der Konkurrenz besetzt sind, das Ziel für unser eigenes Produkt festlegen�

Als Ergebnis haben wir die Zielpositionierung sichtbar gemacht, anhand derer wir nicht nur sehen können, wo unser Produkt am besten platziert werden sollte, sondern auch, in welchem Wettbewerbsumfeld es sich dann jeweils befindet.

4040

Ein Vorteil der Trendanalyse ist, dass wir

unseren Blick über den Tellerrand der aktuellen

technischen Entwicklungen richten und

auch soziale, wirtschaftliche und kulturelle

Aspekte miteinbeziehen. Da der Echtzeit- und

Interaktionsdruck immer stärker wird, nehmen

gerade diese Aspekte einen immer größer

werdenden Einfluss auf die mittel- und langfristige

Positionierung eines Produkts.

Mit der Trendanalyse können wir auch in einem

sich rasant verändernden Umfeld die Position

unseres Kunden besser verstehen, Marktchancen

und Risiken schneller erkennen und neue Projekte

zielgerichtet anstoßen.

Wir arbeiten auf diesem Gebiet mit spezialisierten

Trendagenturen wie Trendone zusammen, die uns

mit der Einteilung in Mega-, Macro- und Microtrends

bereits ein Werkzeug zur Verfügung stellen, mit dem

wir das Feld für unser Monitoring abstecken können.

Trendanalyse

4141

An

alys

ePh

ase

An

alys

eA

nal

yse

Trendanalyse

4242

4343

An

alys

e

TRENDMONITORING

Mit der übergreifenden Trendbeobachtung und mit der themen-basierten Identifizierung innovativer Technologien, Produkte und Konzepte können wir erkennen, in welche Richtung sich das Geschäft unserer Kunden entwickelt� Oder besser gesagt: in welche Richtung wir es zusammen aktiv entwickeln können�

Für unsere Kunden, egal ob Bestandskunden oder als Auftrag für Neukunden, beobachten wir dauerhaft Trends und einzelne, von der Konkurrenz entwickelte Lösungen� Anhand unserer Beobachtungen geben wir Empfehlungen ab, die im Idealfall auch schon zu neuen Produkten führen� Dabei sind wir auf die Recherche bestimmter Microtrends spezialisiert: Projekte und Lösungen, die sich aktuell am Markt beweisen� Anhand derer können wir verständlich machen, dass ein Trend nicht nur in der Theorie existiert, sondern echtes Business-Potential in sich trägt; so können wir bei unseren Kunden einen „sense of urgency“ erzielen�

Mithilfe des Trendmonitorings erstellen wir regelmäßig Trendreports zu vorher abgestimmten Themen oder Produktkategorien�

4444

4545

An

alys

eA

nal

yse

TRENDMAP

Die Trendmap ist nicht nur die Voraussetzung für ein kontinuierliches Monitoring, sondern trägt vor allem zur Konzeption und Positionierung eines Produkts bei�

Anhand kundenrelevanter Kriterien spüren wir zunächst die wich-tigsten Megatrends auf, die meist die gesamte Branche betreffen, und listen mit diesen Erkenntnissen die für unsere Kunden passenden Macrotrends auf� Dann wiederum suchen wir nach bestehenden, inte-ressanten Microtrends� Das sind bereits (oder oft auch nur zum Teil) umgesetzte Lösungen, anhand derer wir festmachen können, wie sich Produkte, Marketingmaßnahmen und ganze Märkte zukünftig entwi-ckeln� Mit all diesen neu gewonnenen Erkenntnissen erstellen wir eine Trendkarte, anhand derer wir – gemeinsam mit dem Kunden – beson-ders relevante Trendbereiche eingrenzen können� Diese Trendbereiche sind in vielerlei Hinsicht interessant: für das weitere Monitoring, als Ideen-Trigger für Produkte, die derzeit im Entwicklungsprozess sind, oder für das Feinkonzept bereits bestehender Services und Produkte�

Kurz zusammengefasst: Wir erstellen gemeinsam

mit dem Kunden eine Trendkarte, mit der wir den

kreativen Start in neue Projekte professionalisieren

und klare Koordinaten für eine produktbezogene

und kundenspezifische Trendbeobachtung liefern.

4646

Aufgabenanalyse

In der Aufgabenanalyse betrachten wir aus

unterschiedlichen Blickwinkeln, was das Produkt

alles leisten muss. Weil wir uns intensiv mit dem

Thema beschäftigen, verstehen wir Stakeholder,

Nutzer, Aufgaben und Schlüsselprobleme sehr viel

besser als zuvor.

4747

An

alys

ePh

ase

An

alys

ePh

ase

An

alys

eA

nal

yse

4848

Die Feldstudie bringt uns den Nutzer und seine Bedürfnisse näher.

4949

An

alys

e

FELDSTUDIE

Mit der ethnografischen Methode der Feldstudie können wir (poten-zielle) Nutzer eines Produkts oder Services in ihrer alltäglichen Umge-bung dabei beobachten, wie sie bestimmte Aufgaben lösen� Anschlie-ßend sammeln wir Artefakte und schreiben unsere Beobachtungen und Erkenntnisse auf� Mit der Feldstudie beleuchten wir nicht nur die Workarounds und Schwierigkeiten im Umgang mit Produkten, sondern finden bestenfalls schon im Vorfeld heraus, wie diese besser funktio-nieren könnten� Kombinieren wir die Feldstudie zusätzlich mit Nutzer-interviews, liefern diese uns Einblicke in die entsprechenden mentalen Modelle und Bedürfnisse der Nutzer�

Die Feldstudie bringt uns den Nutzer und seine Bedürfnisse näher� Dadurch, dass wir ihn im Umgang mit einem Produkt beobachten, können wir zuvor unbekannte Zusammenhänge und Abhängigkeiten, bzw� Kommunikations- und Denkmuster der Nutzer, bei unserer Aufga-benstellung und somit bei der Produktentwicklung berücksichtigen�

5050

STAKEHOLDER-INTERVIEW

In der Phase der Aufgabenanalyse sind Stakeholder-Interviews eine wichtige Quelle für uns, um eine Organisation oder ein Unternehmen besser verstehen zu können und Einblicke in die jeweilige Denkweise und Mentalität zu bekommen� Mit diesem Wissen können wir die Entwicklung eines Produktes mit der strategischen Ausrichtung und den Geschäftszielen eines Unternehmers in Einklang bringen� Stake-holder-Interviews helfen uns, Themen und Ansprechpartner zu finden, die für die weitere Projektplanung wichtig sind oder auf die wir beson-ders achten müssen�

▶ Die Fragestellung muss geklärt werden: Wer ist bei der Umsetzung des Projekts beteiligt? Welche Wege und Methoden sind im Unternehmen üblich? Außerdem muss ein Fragebogen mit offenen Fragen erstellt werden, damit man auf Unerwartetes reagieren kann�

▶ Stakeholder werden in Zusammenarbeit mit dem Kunden ausgewählt� Stakeholder können z� B� Mitglieder des Projekt- oder Research-Teams, ein Media Planer oder CRM-Manager sein�

▶ Dann werden die Interviews durchgeführt und alles genau dokumentiert�

Vorbereitung eines Stakeholder-Interviews:

5151

An

alys

e

Die Ergebnisse von Stakeholder-Interviews liefern einen generellen Überblick über die Organisation, die Verantwortlichen und ihr Verständnis für das Produkt. Nach der Auswertung der Interviews können wir die Business Anforderungen klar formulieren und so die strategische Ausrichtung der Produktentwicklung gemeinsam mit dem Kunden festlegen.

5252

Die UX-Zieltabelle ist ein gutes Abstimmungsdokument, mit dem wir Ziele eines Produkts definieren und spezifizieren können.

5353

An

alys

e

UX-ZIELTABELLE

Mit einer UX-Zieltabelle können wir übergeordnete UX-Ziele (UX goals) eines Produkts standardisieren (zum Beispiel, ob es gut bedienbar ist oder Kunden damit zufrieden sind) und die operativen UX-Zielset-zungen (UX targets) messbar machen� Usability-Eigenschaften, die wir zu Beginn des Designprozesses festlegen, können wir mit der UX-Zielta-belle über den gesamten Product-Life-Cycle messen�

So erstellen wir eine UX-Zieltabelle:

Definieren: Für jedes übergeordnete UX-Ziel formulieren wir operative UX-Zielsetzungen, Maßeinheiten und Messinstrumente� Um sie einem Nutzungs-Szenario zuzuordnen und das Ziel-Level zu bestimmen, spezifizieren wir jede UX-Zielsetzung durch Nutzerrollen�

Messen: Die UX-Zielsetzungen überprüfen wir an unterschiedlichen Stellen im Product-Life-Cycle�

Die UX-Zieltabelle ist ein gutes Abstimmungsdokument, mit dem wir Ziele eines Produkts definieren und spezifizieren können� Wir erkennen anhand der Tabelle aber auch, welche Ziele sich nicht umsetzen lassen� Je früher wir die Zielsetzungen definieren, desto früher können wir Eigenschaften und Features des Produkts nachjustieren� So sichern wir eine qualitativ hochwertige User-Experience�

5454

Technische Ist-Analyse

In der technischen Analysephase untersuchen

wir strukturiert alle relevanten technischen

Gegebenheiten. Dazu gehören, je nach Projektbezug,

die IT-Infrastruktur sowie mögliche Bestandsysteme

und Anwendungen, die wir in der technischen

Konzeption und Realisierung unbedingt beachten

müssen. Wir nehmen nicht nur die Systeme

in unsere Analyse auf, sondern auch sämtliche

relevanten Sicherheitsanforderungen, die wir für die

Realisierung eines Projekts nutzen.

5555

An

alys

ePh

ase

An

alys

ePh

ase

An

alys

eA

nal

yse

5656

5757

An

alys

e

ANALYSE DER IT-INFRASTRUKTUR

Damit wir ein neues Produkt möglichst gewinnbringend in eine beste-hende Infrastruktur integrieren können (z� B� in eine Systemlandschaft, die sich aus Servern, Datenbanken und deren Kommunikationsstruktur zusammensetzt), müssen wir diese bis ins kleinste Detail kennen und analysieren�

Eine IT-Infrastruktur besteht meist aus sehr heterogenen Systemen, die über technische Protokolle miteinander vernetzt sind� Alle diese Systeme, Server und Datenbanken erfüllen innerhalb der Systemland-schaft einen bestimmten Zweck und deshalb müssen wir sie mehr oder weniger bereits bei der Planung berücksichtigen� Wir beurteilen nicht nur die Anzahl und die Vernetzung der Systeme, sondern auch deren Leistungsfähigkeit – nur so können wir allen aktuellen und zukünf-tigen Anforderungen gerecht werden�

Als Ergebnis erhalten wir eine projektspezifische und detaillierte Über-sicht über die bestehende Systemlandschaft und über alle erforderli-chen Schnittstellen�

5858

5959

An

alys

e

ANALYSE VON BESTANDSYSTEMEN UND SCHNITT-STELLEN

Je nachdem, wie ein Projekt ausgerichtet ist, müssen wir oft ein beste-hendes System erweitern oder es komplett austauschen gegen neue Techniken und Systeme� In beiden Fällen müssen wir alle Anfor-derungen und Funktionsweisen des aktuellen Systems und seiner Schnittstellen überblicken und verstehen� Dafür müssen wir zum einen eine Business-Logik-Analyse durchführen (die bis hin zur Quellcodeanalyse führen kann) und zum anderen alle Interaktionen des Bestandsystems (bzw� der bestehenden Anwen-dungen) in unsere Untersuchungen einbeziehen, weil alle Interakti-onen, auch die Schnittstellen zu internen und externen Drittsystemen, relevant sind�

Wir erarbeiten uns einen möglichst vollständigen

Überblick über alle relevanten technischen

und nicht-technischen Workflows, die für eine

problemlose Erweiterung oder Ersetzung des

Systems notwendig sind, d.h. wir beziehen

beispielsweise auch redaktionelle Funktionsabläufe

mit ein.

An

alys

e

6060

ANALYSE VON SICHERHEITSANFORDERUNGEN

Jedes System muss gewissen Sicherheitsanforderungen entsprechen. Da diese Anforderungen aber häufig sehr stark variieren, müssen wir bei jedem Projekt sämtliche Sicherheitskriterien analysieren.

6161

An

alys

eA

nal

yse

Diese Sicherheitsanforderungen reichen von Standard-Sicherheits-mechanismen, wie beispielsweise Verhinderung von Cross-Site-Scrip-ting und SQL-Injections, bis hin zu speziell geschützten Bereichen oder Funktionen mit sensiblen Dateninhalten� Um ein Mindestmaß an Sicherheit zu garantieren, müssen für jede Anwendung und jedes Unternehmen also unterschiedliche Anforderungen erfüllt werden� Diese Anforderungen sind immer von Bedeutung, wir müssen sie also auf das Genaueste analysieren� Dafür müssen wir erst einmal die beste-henden Sicherheitsmechanismen untersuchen – und wenn nötig durch weitere Mechanismen ergänzen�

So schaffen wir einen Katalog von Sicherheitsanforderungen, der für die Konzeption und die Realisierung eines Projekts von höchster Bedeutung sein kann�

6262

Phase #2

6363

Labo

rLa

bor

6464

Nutzerverständnis

Damit wir Nutzer von Grund auf verstehen und für

sie relevante Produkte entwickeln können, müssen

wir ihre Bedürfnisse und Ziele kennen. Wie wir

ihnen den Alltag erleichtern, finden wir bereits in

dieser Phase heraus, weil wir schon hier ein tiefes

Verständnis für ihre Wünsche, Ideen und Probleme

entwickeln.

6565

Labo

rPh

ase

Labo

rLa

bor

6666

Personas helfen uns, unseren Blick für spezifische Nutzerziele zu schärfen.

6767

Labo

r

PERSONAS

Aus der Nutzer- und Marktanalyse haben wir bereits eine Menge unterschiedlicher Informationen zu potenziellen Produktanwendern gewonnen� Für die nutzerdefinierte Designentwicklung ist es wichtig, dass das gesamte Team die Ziele, Bedürfnisse, Erfahrungen und Motive der Nutzer kennt� Und zwar so gut kennt, dass sich jedes Teammit-glied in deren Lage hineinversetzen und deren Blickwinkel einnehmen kann� Um das zu erreichen, entwickeln wir Personas�

Personas sind anhand von Gemeinsamkeiten und zusammenhän-genden Verhaltensmustern konstruierte Archetypen� Sie stellen jeweils eine Gruppe potenzieller Nutzer dar, mit der wir uns identifizieren können� In erster Linie enthalten Personas Informationen zu Zielen, Motivationen und Verhalten des Nutzers, die mit demografischen Gege-benheiten und repräsentativen Szenarios angereichert werden� Zusätz-lich bekommen Personas durch persönliche Angaben wie Name, Foto und Interessen eine eigene Identität�

Personas helfen uns, unseren Blick für spezifische Nutzerziele zu schärfen� Bei wichtigen Designentscheidungen ziehen wir sie immer wieder zu Rate� So stellen wir sicher, dass das spätere Produkt die Nutzer dabei unterstützt, ihre Ziele zu erreichen�

6868

6969

Labo

r

MENTALE MODELLE

Mentale Modelle sind eine Form der subjektiven Abbildung von impli-ziertem Wissen� Um reale Sachverhalte zu begreifen, hat jeder Mensch ganz eigene modellhafte Vorstellungen von Abläufen, Funktionen und komplexen Strukturen� Also bildet jeder aus bekannten Sachverhalten seine eigenen Analogien (z� B� Warenkorb) oder reduziert von quanti-tativen Beziehungen zu qualitativen (z� B� eigene Erfahrungen)� Durch diese Verkleinerung, bzw� diese ausschnittsweise Betrachtung der Wirk-lichkeit, werden sehr komplexe technische, soziale oder physikalische Prozesse besser verständlich�

Die daraus gewonnenen Daten ordnen wir im weiteren Verlauf der Methodik hierarchisch, strukturieren sie innerhalb von Diagrammen und setzen sie in Beziehung zueinander�

Die finalisierten Diagramme beschreiben also den von den Nutzern durchlaufenen Prozess, sie zeigen Touchpoints, Analogien und Interak-tionen sowie Probleme, die bei der Nutzung eines Produktes für unsere konzeptionelle Arbeit auftreten können�

Um herauszufinden, wie Nutzer denken und

handeln und welche mentalen Modelle hinter

ihrem Verhalten stehen, befragen wir zunächst

repräsentative Personen, beispielsweise mit

qualitativen Telefoninterviews.

7070

EMPHATHY MAP

Die Empathy Map ist eine UX-Methode, mit der wir uns in den Nutzer und seine Situation einfühlen können� So sind wir in der Lage, unser Verständnis für den Nutzer in Bezug auf eine Aufgabe oder ein Produkt zu vertiefen� Wenn wir den Nutzer und seine sensorischen Erfah-rungen genau skizzieren, bekommen wir ein besseres Verständnis für ihn, sein Umfeld und sein Verhalten, aber auch für seine Bedenken und Ziele� Außerdem zeigt uns die Empathy Map Verständnislücken in der Betrachtung des Nutzerverhaltens auf�

So erstellen wir eine Empathy Map:

Ausgangslage definieren: Wir definieren den Kontext und eine Persona als Stellvertreter der Zielgruppe und formulieren die Ausgangs-frage wie z�B� „Warum sollte ich das Produkt nutzen?“

Einfühlen: Wir legen unseren Fokus auf die sensorischen Erfahrungen der Person im definierten Kontext: Was denkt sie? Was fühlt sie? Was sagt sie? Was hört sie? Womit hat sie Mühe? Was bringt ihr einen Nutzen?

Entwurf prüfen: Unseren Empathy Map-Entwurf lassen wir durch einen oder mehrere Kollegen prüfen� Dabei sollte sich jeder die Fragen stellen: Kann ich mich mit der Person identifizieren? Ist die Empathy Map vollständig oder fehlen bestimmte Aspekte oder Details?

In relativ kurzer Zeit (ca� 30 Minuten pro Empathy Map) können wir so eine umfassende Nutzerperspektive sichtbar machen, die uns hilft, unser Nutzerverständnis zu vertiefen� Auch wird uns ein Instrument zur Verfügung gestellt mit dem wir unser eigenes Produkt wieder und wieder – aus der Nutzerperspektive heraus – hinterfragen� So entwickeln wir nutzerrelevante Lösungen�

7171

Labo

r

Wenn wir den Nutzer und seine sensorischen Erfahrungen genau skizzieren, bekommen wir ein besseres Verständnis für ihn.

Labo

r

7272

Nutzungsszenarien

Um die Interaktion von Nutzer und System

bzw. Produkt alltagsnah zu veranschaulichen,

konstruieren wir Nutzungsszenarien.

7373

Labo

rPh

ase

Labo

rLa

bor

7474

7575

Labo

r

USER JOURNEY

Damit wir Lücken und Hürden, aber auch Cross-Channel Schnittstellen in typischen Benutzungsabläufen abbilden können, entwickeln wir User Journeys� Die zuvor von uns kreierten Personas sind die Hauptak-teure, die diese Geschichten durchlaufen�

User Journeys erzählen von typischen (Nutzungs-)Situationen, in denen das zu designende Produkt vorkommt oder – bei neuen Produkten – vorkommen könnte� Schritt für Schritt zeigen sie, wie ein Produkt im Kontext Raum, Zeit und Medium genutzt wird� Eine User Journey spiegelt ein Gesamtbild aller Berührungspunkte mit dem Produkt oder nur eine bestimmte Aufgabe und wie diese ausge-führt wird� User Journeys visualisieren wir über ein strukturiertes Diagramm, aus dem wir dann konkrete Anforderungen ableiten können�

7676

7777

Labo

r

EXPERIENCE MAP

Oft stehen Produkte und Services in einem komplexen Gebilde eines Nutzungskontexts� Damit wir die Schnittstellen und die Auswirkungen einer Cross-Channel-Experience im Bezug auf Ort, Zeit und Kanal verstehen, hilft es uns, sie in einer Experience Map zu darzustellen�

Eine Experience Map ist ein Modell, das den ganzheitlichen Nutzungs-ansatz und -kontext in einer Darstellung zusammenfasst und visuali-siert� In ihr wird eine User Journey mit qualitativen und quantitativen Informationen vereint und die unterschiedlichen Erfahrungs-Facetten des Nutzers (doing, thinking, feeling) zusammengestellt� Eine Experi-ence Map muss nicht erklärt werden, weil sie für sich steht, kann also auch zum allgemeinen Verständnis innerhalb großer Organisation eingesetzt werden� Um Unterschiede zu verdeutlichen, können Experi-ence Maps für alle Personas genutzt werden oder aber die Erfahrungen von nur einer Persona beleuchten�

Anhand einer Experience Map erkennen wir Innovations- und Interaktionslücken, aus denen wir dann passende Produkte oder Features ableiten können.

Das Artefakt schärft das Wissen unseres gesamten Projektteams über die Nutzerschaft eines Produkts� Wir können es immer wieder als Ausgangsbasis für die Entwicklung verschiedenster Produkte verwenden�

7878

STORYBOARDS

In der Produktentwicklung müssen wir herausstellen, welche Vorteile der Nutzer bei der Nutzung des Produkts hat� Mit einem Storyboarding können wir in einer kleinen Geschichte den Nutzungskontext erzählen�

In einer skizzenhaften Darstellung von einzelnen Schritten (pre-wire-framing Prozess) illustrieren wir ein Produkt vor, während und nach seiner Nutzung� Das Storyboard zeigt in der Einleitung Ziele und Prob-leme, im Hauptteil die Lösung des Problems und im Schluss den anschließenden Benefit für den Nutzer� Die Zeichnungen müssen hierbei nicht unbedingt detailgetreu sein�

Storyboards zeigen anhand einer groben Skizzierung, wie ein Produkt genutzt wird. Innerhalb einer Sequenz illustrieren wir hierbei plakativ ein Problem, seine Lösung und den Benefit für den Nutzer.

7979

Labo

r

8080

Ideation

Innovationen leben von Ideen. Ideen entwickeln

wir im Team, wobei wir immer unterschiedliche

Disziplinen einbeziehen. Weil es mühselig wäre, auf

den ultimativen Geistesblitz zu warten, haben wir

sieben Regeln verinnerlicht und nutzen zusätzlich

unterschiedlich strukturierte Methoden zur

Ideenentwicklung.

8181

Labo

rPh

ase

Labo

rLa

bor

8282

8383

Labo

r

DIE 7 GOLDENEN BRAINSTORMING-REGELN

Ein klares Briefing vorbereiten mit Ausgangslage, Zielen und Kriterien�

Themen splitten und Fragen in abwechslungsreiche Subthemen aufteilen�

Zuerst Masse, dann Klasse: In kurzer Zeit möglichst viele, wenn auch nur bruchstückhafte Ideen und Inspirationen sammeln, welche später selektiert werden�

Heterogene Teams bilden, um ein breites Spektrum an Ideen zu erhalten�

Immer wieder Perspektiven, Situationen und Orte wechseln, um eine freie Entfaltung anzuregen�

Probieren statt diskutieren und über schnelles Prototyping Ideen antesten.

Bei mehr als drei Teilnehmern einen Moderator einsetzen, der die Diskussion leitet�

▶

▶

▶

▶

▶

▶

▶

8484

8585

Labo

r

BRAINSTATION

Diese Methode eignet sich gut für den Beginn eines Brainstormings� In kurzer Zeit produzieren wir mit der Brainstation eine große Anzahl von Inspirationen, die wir später als Ausgangsmaterial für die Erarbei-tung konkreter Ideen verwenden können�

Für die Methode wählen wir drei bis sechs Stationen, beispielsweise Abschnitte einer Wand oder Flipcharts� An jeder Station wird eine Frage gestellt, die einen Teilbereich der Projektfrage abdeckt (Siehe Regel „Themen splitten“)� Die Teilnehmer des Brainstormings teilen wir entsprechend der Stationen in drei bis sechs Gruppen ein� Jeder Gruppe ordnen wir eine Station – also eine Fragestellung – zu� Hier schreibt jeder so viele Antworten wie möglich auf Post-its (ein Zettel pro Antwort) und klebt diese an die Station� Alle zwei Minuten wech-seln die Gruppen im Uhrzeigersinn zur nächsten Station� Um die Frage-stellungen aufzulockern können die Fragen mit Assoziationstriggern kombiniert werden� Das sind beispielsweise Tageszeiten, bekannte Marken, (fiktive) Persönlichkeiten etc� Eine Frage würde dann zum Beispiel lauten: „Welche Funktionen hat die persönliche App von Spider-Man?“

Die Ergebnisse der Brainstation-Methode sind Inspirationen und Ideen-Bruchstücke, aus denen wir in einer folgenden Phase durch verschiedene Kombinationen und Clustering Ideen „bauen“ können�

Labo

r

8686

8787

Labo

r

REGELBRUCH

Uns allen fällt es schwer, aus bekannten Denkweisen auszubrechen. Innovationen und Ideen entstehen aber nur, wenn wir den Mut haben, mit Gewohnheiten zu brechen.

Und das ist das Ziel dieser Aufgabe�

Zuerst müssen wir uns unseren eingeschliffenen Denkmustern bewusst werden, die uns hindern, ungewöhnliche Ideen zu entwi-ckeln� Hierzu schreiben wir alle Regeln, die uns im Zusammenhang mit einem Thema einfallen, auf ein Flipchart� Beim Thema „Auto“ wäre das beispielsweise „Ein Auto hat ein Lenkrad“� Anschließend unterstrei-chen wir mit einer anderen Farbe die bestimmenden, uns einschrän-kenden Wörter in den Regeln� Bei unserem Beispiel wären diese Wörter „ein“ und „Lenkrad“� Nun überlegen wir uns, wie wir diese Regeln brechen können� Wenn wir beim Beispiel „Auto“ bleiben, könnte eine Regelbrechung lauten: „Es gibt mehr als ein Steuerungsgerät und es ist kein fest verbautes Lenkrad�“ Daraus kann dann beispielsweise die Idee entstehen, dass ein Auto in Zukunft nicht mit einem Lenkrad, sondern mit einem Smartphone durch Neigung gesteuert wird (so wie heute schon in vielen Handy-Autorennspielen)� Man könnte das Steuer sogar ganz einfach an Mitfahrer übergeben, denn jedes Smartphone kann ja dann gleichzeitig auch ein Lenkrad sein�

Durch die Brechung bekannter Regeln entstehen also konkrete Ideen�

8888

Mit dem Kaskadierten Brainstorming fördern wir das Assoziationsdenken.

8989

Labo

r

KASKADIERTES BRAINSTORMING

„Vom Hölzchen kommt man zum Stöckchen“, heißt es� Und tatsächlich ist dies eine Methode, die wir zur Ideenfindung nutzen� Mit dem Kaska-dierten Brainstorming fördern wir das Assoziationsdenken�

Es gibt viele Varianten dieser Methode, allen gemein ist aber, dass immer mehrere Personen nacheinander an einer Idee beteiligt sind� Eine zweistufige Aufgabe kann z�B� lauten: „Welche unangenehmen Erfahrungen hast du mit Thema XYZ gemacht?“ Alle Teilnehmer schreiben ihre Erfahrung auf einen Zettel� Anschließend nimmt sich jeder einen Zettel (nicht den eigenen!) und schreibt darunter, welche Lösung diese spezielle Erfahrung verbessert oder verhindert hätte�

Bei dieser Methode geht es um Inspirationsbruchstücke, daraus können wir konkrete Ideen und Ideenansätze entwickeln�

9090

9191

Labo

r

CRITERIA SCAN

Jeder Teilnehmer eines Brainstormings hat eine ganz eigene Agenda, wenn er sich für oder gegen eine Idee entscheidet, oft ist es auch nur ein Bauchgefühl� Diesem Bauchgefühl stellen wir mit dem Criteria-Scan eine möglichst objektive Bewertung gegenüber, denn er hilft uns, die Ideen-Selektion stärker an das Briefing zu knüpfen�

Im Mittelpunkt stehen die Kriterien, die wir bereits im Briefing defi-niert haben (siehe Regel „Briefing vorbereiten“)� Die Ideen werden beim Criteria Scan strikt aus der Perspektive jeweils eines einzelnen Krite-riums bewertet� Erfüllt eine Idee beispielsweise besonders gut das Kriterium „kann kurzfristig umgesetzt werden“, bekommt sie zehn Punkte� Ist die Umsetzung dagegen eher zeitaufwendig, bekommt sie nur fünf Punkte – bis hin zu null Punkten für kaum umsetzbare Ideen� Diese Bewertung wenden wir für jede Idee und jedes Kriterium an� Idealerweise sucht sich jeder Teilnehmer nur ein Kriterium aus, anhand dessen er alle Ideen bewertet� So stellen wir sicher, dass die Teil-nehmer sich nur auf das Kriterium konzentrieren und weniger auf ihre eigene Meinung�

Neben den Ideen, die in allen Kriterien am besten bewertet wurden, lohnt sich auch ein Blick auf Ideen mit polarisierenden Bewertungen, die also bei einem Kriterium sehr gut, bei einem anderen aber sehr schlecht bewertet wurden� In vielen Fällen lohnt es sich, diese Ideen anzupassen, bzw� weiterzudenken�

Labo

r

9292

9393

Labo

r

AFFINITÄTS-DIAGRAMM

Das Affinitäts-Diagramm ist ein Hilfsmittel zur strukturierten Ideen-findung, mit dem wir große Mengen an Ideen für ein Problem sammeln und kategorisieren können� Der Prozess fördert unterschiedlichste Ideen zutage und identifiziert dahinterliegende Konzepte und Zusam-menhänge („Affinität“)� Mit dieser Methode können wir unterschwel-lige Denkgewohnheiten aufspüren, Potenzial für Innovationen aufde-cken und Denkmuster durchbrechen�

Wie entsteht ein Affinitäts-Diagramm?

Ideen generieren: Wir formulieren eine offene, neutrale Aufgaben-stellung (z� B� ein Statement, Problem oder Ziel)� Jeder Teilnehmer hat 10 Minuten lang Zeit, seine Ideen auf Karteikarten oder Post-its aufzuschreiben�

Ideen clustern: Die Ideenkarten legen wir für alle sichtbar aus und gruppieren sie nach ihren intuitiven Zusammenhängen (z� B� nach Ähnlichkeit, Abhängigkeit, Nähe etc�)�

Ideen kategorisieren und prüfen: Alle Teilnehmer benennen in einer Diskussion die Cluster und ggf� ihre Untergruppen� Die Qualität der Erkenntnisse richtet sich danach, wie viele unterschiedliche Daten gesammelt werden konnten – aber auch wie gut die Sortierungs- und Kategorisierungsprozesse durchgeführt wurden� Das Affinitäts-Diagramm sollte zum Schluss ein Kollege außerhalb des Projektteams prüfen (z� B� beim → WallTalk)�

Mit dem Affinitäts-Diagramm können wir verbal

und visuell Produkt-Lösungen dokumentieren und

ihre Entwicklung darstellen. Wir sichten damit

Themen, Ideen und ihre Zusammenhänge und

finden dabei wirklich neue Muster und Zugänge, die

uns als Grundlage für die weitere Ausarbeitung von

Produkten dienen.

Labo

r

9494

In der Anforderungs-Definition spezifizieren wir

nach der Ideenfindung, was ein Produkt können

sollte, welche Funktionalitäten und Eigenschaften

es haben muss und welche Beschränkungen

berücksichtigt werden müssen. Je nach Ausrichtung

des Projektes und vereinbarter Vorgehensweise

können wir die Anforderungen auf unterschiedliche

Weise konkretisieren und dokumentieren.

Anforderungs-Definition

9595

Labo

rPh

ase

Labo

rLa

bor

9696

9797

Labo

r

FEATURE MAP

Die Feature Map zeigt einzelne Features oder Featurefamilien in einer Karte oder einem Diagramm� Die Dimensionen müssen wir im Projekt festlegen, das können Dinge wie z�B� Priorität, inhaltliche Zusammen-gehörigkeit, Kosten etc� sein� Features basieren auf unseren Erkennt-nissen aus Nutzeranalysen und Marktforschungsdaten� Für die Defini-tion von Features setzen wir zudem unterschiedliche Kreativmethoden ein�

Feature Maps bilden den Funktionsumfang eines Produkts ab, wir können sie für die Ausarbeitung von Anforderungen (Requirements) nutzen�

Features sind spezifische Produkteigenschaften, die dazu beitragen, die Geschäfts- und Nutzerziele zu erreichen. Im Idealfall liefern sie dem Produkt einen entscheidenden Wettbewerbsvorteil.

9898

9999

Labo

r

PRODUKT BACKLOG

In agilen Projekten (z�B� nach dem SCRUM-Prozess organisiert) sammelt das Produktmanagement Anforderungen an das Produkt in einem Backlog� Hierbei gilt: wir sammeln alles, was zur Funktion des Produktes dazugehören soll�

Die im Backlog enthaltenen User Stories werden regelmäßig aktu-alisiert – die wichtigsten müssen immer an oberster Stelle stehen� Anhand der Abnahmekriterien bewerten wir die Komplexität der User-stories in einer abstrakten Einheit („Storypoints“), mit den Erfahrungs-werten aus dem bisherigen Projektverlauf können wir abschätzen, wie viele Storypoints wir in einem Entwicklungszyklus („Sprint“) erreichen können, so dass wir dementsprechend die ersten X User Stories für den nächsten Entwicklungszyklus planen können�

Vorteil des Backlogs ist, dass wir durch die sich immer wieder ändernde Priorisierung und durch ständige Reflektion der Userstories agil auf geänderte Anforderungen reagieren können�

100100

101101

Labo

r

USER STORY

In agilen Projekten halten wir anhand einer User Story die Anforde-rung fest, die das Produkt erfüllen muss, und sammeln diese in einem Product Backlog�

User Stories werden aus Sicht eines Stakeholders formuliert� Wichtig ist, dass wir dabei eine feste Struktur einhalten: „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“� In Kombination mit Abnahmekri-terien, die der Produktmanager definiert, ist diese User Story Umset-zungsgrundlage für das Produktentwicklungsteam�

Der Vorteil von User Stories ist, dass sie in natürlicher Sprache und kompakt die Anforderungen an ein Produkt beschreiben.

Der beschriebene Umfang sollte so klar zu verstehen sein, dass der Aufwand vom Team gut abgeschätzt werden kann� Wenn das nicht möglich ist, müssen wir die User Story aufteilen oder die Abnahmekri-terien weiter verfeinern, bevor wir sie umsetzen�

Labo

r

102102

Innerhalb dieses Arbeitspaketes erproben und

untersuchen wir das Look & Feel der zukünftigen

Produktoberfläche. Eine erfolgreiche Gestaltung

verlängert die konzeptionellen Entwürfe und gibt

dem Produkt sein Gesicht. Vor der ausdefinierten

Gestaltung der Oberfläche visualisieren wir in der

Laborphase bereits unter Anwendung verschiedener

Methoden erste Stimmungen und Richtlinien.

Designstudien

103103

Labo

rPh

ase

Labo

rPh

ase

Labo

rLa

bor

104104

105105

Labo

r

MOODBOARDS

Visuelles mit Worten zu erklären fällt oft schwer und kann vor allem missverständlich bzw� interpretierbar sein� Während ein Oberflächen-Design für die Einen reduziert und klar ist, finden Andere es vielleicht kalt und emotionslos�

Hier sind einfache Collagen am effektivsten� Mit ihnen können wir mögliche Design-Prinzipien beispielsweise für Farben, Typographie, Muster, Elemente oder den übergreifenden Look sichtbar machen und einander gegenüberstellen�

Damit wir ein Design-konzept entwickeln, das für alle Projektbeteiligten funktioniert, ist es wichtig, dass wir frühzeitig eine gemeinsame visuelle Sprache finden.

106106

107107

Labo

r

KONZEPTSTUDIEN

Interaktionselemente werden hauptsächlich anhand ihrer Form bestimmt� Damit wir den Nutzer bestmöglich führen und alle Elemente durch ihr Aussehen einer bestimmten Interaktion zuordnen, müssen wir detaillierte Studien erstellen� Beispielsweise können Buttons in ihrem Erscheinungsbild stark variieren� Mittels Konzeptstudien befassen wir uns mit solchen Einzelelementen und entwickeln unter-schiedliche Gestaltungsformen�

Wir konzentrieren uns auf einzelne Ausprägungen und überprüfen, bewerten und gestalten jedes Element bis ins kleinste Detail auf Form und Funktion.

108108

Mit der Methode des WallTalk können wir nicht nur über Formsprache, sondern auch über Informationsarchitektur und Usability diskutieren.

109109

Labo

r

WALLTALK

Während des WallTalks können wir neue kreative Lösungen entwi-ckeln und vorhandene Potenziale durch Diskussionen zu konkreten Designstudien und Fragestellungen außerhalb des Projekt-Teams ausschöpfen� Mit neuen Perspektiven auf die eigene Arbeit, auf Entwürfe und Layouts können wir Ideen validieren oder konstruktiv weiterentwickeln�

Was passiert beim WallTalk?

Fragerichtung definieren: Wir wählen Designstudien oder Layouts aus und formulieren konkrete, offene Fragen(zwischen 3 und 5)� Die Entwürfe und zugehörige Fragen machen wir für alle zugänglich�

Ideen sammeln: Innerhalb eines festgelegten Zeitraums (1 Woche) fordern wir möglichst viele Kollegen auf, Ideen zu bewerten und die formulierten Fragen zu beantworten�

Diskutieren: Alle Kommentare, Ideen und Vorschläge werten wir aus, diskutieren sie mit projektinternen und -externen Mitarbeitern inner-halb des moderierten „Wall Talks“�

Mit der so strukturierten Diskussion und Dokumentation verschie-dener Meinungen und Perspektiven haben wir mit relativ geringem Aufwand eine gute Grundlage für die Ausarbeitung von Designstudien geschaffen�

110110

In der technischen Evaluation geht es um die

Auswahl der richtigen Technologie und – wenn

notwendig – um entsprechende Systeme und

Drittsysteme. Nur wenn wir gleich zu Beginn die

richtige Auswahl getroffen haben, können wir alle

Anforderungen schnell und effizient erfüllen und

Erweiterungen und Änderungen

problemlos einbauen.

Technische Evaluation

111111

Labo

rLa

bor

112112

113113

AUSWAHL TECHNOLOGIE

Wenn wir uns für die richtige Technologie entschieden haben, können wir bestimmte Aufgaben leichter bewältigen� Wählen wir die falsche Technologie, kann es sogar passieren, dass wir später einige Problem-stellungen nicht oder nur teilweise bearbeiten können� Dabei geht es nicht nur um die richtige Programmiersprache, sondern im Spezi-ellen auch um Frameworks, die Funktionen und Eigenschaften mit sich bringen, um Aufgaben schneller und effizienter lösen zu können�

In dieser Auswahlphase kennen wir nur die groben Problemstellungen, wissen aber, welche Teilprobleme wir lösen müssen� Das macht es uns möglich, dass wir auch ohne detaillierte Beschreibung für die beste-henden Problemfelder einen Satz von Technologien auswählen können� Allerdings brauchen wir dazu Erfahrungswerte und müssen vereinzelt Funktionalitäten testen�

Wir müssen darauf achten, dass die Technologien untereinander kompatibel sind und sich nicht gegenseitig ausschließen.

Mit der Auswahl sollte ein Satz an technologischen Werkzeugen zur Verfügung stehen, auf die wir in darauffolgenden Phasen aufbauen können und die unsere folgenden Arbeiten erleichtern bzw� besser strukturieren�

Labo

r

114114

Mit der richtigen Auswahl des Systems und/oder Drittsystemen schaffen wir die Voraussetzung für eine stabile Plattform, auf der unser Produkt später ausgeführt wird.

115115

Labo

r

AUSWAHL SYSTEME

Wie auch die Technologieauswahl ist die Auswahl des richtigen Systems von großer Bedeutung – nur mit dem richtigen System können wir unser Produkt richtig umsetzen� Mit einem geeigneten System können wir die Realisierung erheblich beschleunigen und gegebenen-falls sogar die Nutzerbedienung verbessern� Bei speziellen Problemstel-lungen ist es oft sinnvoll oder sogar notwendig, dass wir neben dem eigentlichen System Drittsysteme integrieren, die eine einfache Lösung bieten�

Jedes System, beispielsweise ein Content Management System, hat unterschiedliche Eigenschaften und Gegebenheiten, die sich auf Prob-lemstellungen positiv oder auch negativ auswirken können� Generell gibt es nicht „das beste System“ sondern lediglich „das System, das für das Produkt am besten geeignet ist“� Damit wir dieses System finden, tragen wir alle Eigenschaften und Funktionen zusammen, die wir dafür brauchen und bewerten sie anhand von festgelegten Kriterien� Das gleiche gilt – in einem engeren Rahmen – für Drittsysteme (z�B� ein Payment-System, das Bezahlfunktionalitäten bereitstellt)�

Mit der richtigen Auswahl des Systems und/oder Drittsystemen schaffen wir die Voraussetzung für eine stabile Plattform, auf der unser Produkt später ausgeführt wird�

Labo

r

116116

Phase #3

117117

Des

ign

Des

ign

118118

Taxonomien

Damit wir unsere Produkte für die Nutzer auch

inhaltlich sinnvoll ausgestalten können, verwenden

wir unterschiedliche Methoden, die uns dabei

helfen, Inhaltsbereiche sinnvoll und nutzerzentriert

zu klassifizieren, zu kategorisieren und zu benennen.

119119

Des

ign

Des

ign

Des

ign

120120

121121

Des

ign

CARD SORTING

Beim Erstellen und Benennen von Strukturen und bei Interaktions- oder Navigationselementen kann es passieren, dass wir als involvierte Projektteilnehmer zu subjektiv denken und nicht mehr entscheiden können, ob die bisherige Struktur für die Zielgruppe leicht verständlich oder intuitiv bedienbar ist�

Also ist es ein Ziel des Card Sorting, die Nutzer-Sicht bei der Erstel-lung von Menüpunkten zu berücksichtigen und damit dafür zu sorgen, dass die Begrifflichkeiten und die Strukturierung für den Nutzer verständlich sind� Beim Card Sorting erhalten die Testpersonen, bzw� die Teilnehmer, Karten mit Kategorien oder Themen, die sie nach ihrem Verständnis in Gruppen einsortieren und in eine hierarchische Struktur bringen sollen� Je nach gewünschtem Freiheitsgrad können die Testperson die einzelnen Punkte auch frei benennen�

Des

ign

122122

Aus thematischen Clustern können inhaltliche Abhängigkeiten abgelesenwerden.

123123

Des

ign

MINDMAP

Bevor oder während wir Strukturen, Funktionalitäten oder Prozesse aufbauen, ist die inhaltliche Zusammengehörigkeit oder Abfolge noch nicht festgelegt� Eine Mindmap hilft in diesem Fall, weil dadurch Verbindungen sichtbar werden�

Das Mindmapping ist eine Technik, mit der wir visuell Themen darstellen, die wir durch freies assoziatives Denken aufbauen� In der Darstellung werden Zusammenhänge durch Verknüpfungen sichtbar, es entsteht eine vernetzte Struktur� Aus diesen thematischen Clustern können wir die inhaltlichen Abhängigkeiten ablesen�

Die gebildeten Cluster helfen uns, die Funktionen eines Produktes zu bündeln, bzw� inhaltlich „in der Nähe“ anzusiedeln� Wir können sie beispielsweise auch bei der Festlegung einer Facettensuche einsetzen� Auch beim Aufbau von Prozessen sind Cluster hilfreich; mit ihnen können wir inhaltliche Zusammenhänge beieinander oder nachein-ander abfragen�

124124

Im Arbeitspaket Konzeptdesign skizzieren

wir Produktideen, Funktionen und Prozesse

grundlegend. Mit unterschiedlichen

Konzeptionsmethoden machen wir dabei das

Produkt greifbar.

Konzeptdesign

125125

Des

ign

Des

ign

Des

ign

Des

ign

126126

Flussdiagramme helfen uns dabei, komplexe Prozesse im Team zu kommunizieren sowie Lücken und Hürden im Prozess zu finden.

127127

Des

ignFLUSSDIAGRAMME

Um komplexe Prozesse oder Interaktionen von Grund auf zu begreifen und wiedergeben zu können, muss man sie übersichtlich veranschaulichen�

Mit Hilfe von Flussdiagrammen können wir die aufeinanderfolgenden Schritte einer Aufgabe, eines Prozesses oder einer Interaktion schema-tisch beschreiben� Änderungen und Varianten im Ablauf lassen sich verhältnismäßig schnell abbilden� Komplexe Aufgaben zerlegen wir in Einzelschritte und bilden sie schematisch ab� Dadurch können wir Interaktionen zwischen verschiedenen Akteuren, Produktbereichen und -funktionalitäten visualisieren�

128128

129129

Des

ign

WIREFRAMING

Wireframes sind Funktionslayouts, mit denen wir ein Produkt verhältnismäßig realitätsnah und exakt in seinem Aufbau und seiner Funktionalität darstellen können.

Wir nutzen sie in der Konzeptionsphase, um ein Produkt genau zu spezifizieren�

Der Wireframe (dt�: „Gittermodell“) dient dazu, Elemente innerhalb einer Anwendung schematisch darzustellen� Er veranschaulicht den Produktaufbau, die Platzierung einzelner Module und Funktionen sowie Varianten und verschiedene Zustände� Eine Funktionsbeschrei-bung ergänzt die Darstellung eines Wireframes� Allerdings können wir mit ihm nicht das Look & Feel eines Produktes beschreiben�

Wireframes nutzen wir als Vorlage für die weitere Designentwick-lung und die technische Umsetzung� Außerdem setzen wir sie für die Entwicklung und Tests von Prototypen oder Mockups ein�

130130

Beispiel: unendliche Liste

131131

Des

ign

ENTWURFSMUSTER (PATTERN)

Als Entwurfsmuster bezeichnen wir katalogisierte Designansätze für häufig auftretende Gestaltungsprobleme.

Mithilfe von Entwurfsmustern können wir uns bei der Gestaltungsent-wicklung aus einer Bibliothek von bewährten Lösungen bedienen und so leicht auf Erfahrungswerte zurückgreifen� Wenn wir im Rahmen der Produktgestaltung ein Entwurfsmuster für einen bestimmten Einsatz-bereich gewählt haben, definieren wir dieses zugleich als Regel, damit bei der Weiterentwicklung des Produktes Kontinuität gesichert ist�In der Regel katalogisieren wir nach der folgenden Struktur:

▶ Beschreibung des Ausgangsproblems: Wann sollten wir den Ansatz (nicht) verwenden?

▶ Was müssen wir bei der Implementierung beachten? Beschreibung verschiedener Möglichkeiten der Implementierung�

▶ Konkrete Einsatzbeispiele sind Screenshots verschiedenster Gestaltungsausprägungen� Im Rahmen der Dokumentation müssen wir uns an konkrete Gestaltungsvorgaben halten�

132132

Die Konzept-Spezifikation zielt darauf ab, verschiedene Ergebnisse aus der Konzeptphase in einem Artefakt zusammenzuführen und zu dokumentieren.

133133

Des

ign

KONZEPT-SPEZIFIKATION

Die Konzept-Spezifikation zielt darauf ab, verschiedene Ergebnisse aus der Konzeptphase in einem Artefakt zusammenzuführen und zu doku-mentieren� Sie enthält Flussdiagramme, die Sitemap und Wireframes des entsprechenden Produkts� Je nach Größe des Projekts setzen wir für Teilabschnitte oder Produktbereiche ein eigenes Dokument auf�

In der Konzept-Spezifikation halten wir also den Gesamt-Lösungsan-satz aus dem Arbeitspaket des konzeptionellen Designs fest� Neben der visuellen Beschreibung des Projekts ist sie Teil der Ausgangsbasis für die Umsetzung�

134134

Nachdem wir das Oberflächendesign gestaltet

haben, wird zum ersten Mal das tatsächliche

Erscheinungsbild des Produkts sichtbar; die User

Experience wird zum Leben erweckt.

Oberflächendesign

135135

Des

ign

Oberflächendesign

Des

ign

Des

ign

Des

ign

136136

137137

Des

ign

LAYOUTING

Wie sieht das digitale Produkt letztendlich aus? Das grundsätzliche „Look & Feel“ der Oberfläche erarbeiten und bestimmen wir über Layouts� Diese basieren auf dem Konzept-Design und erwecken die User Experience zum Leben�

Die Ergebnisse aus Moodboards, Konzept und Designstudien fügen wir zu einem ganzheitlichen Bild zusammen und präsentieren sie mit einer Auswahl von Screens. Dabei berücksichtigen wir selbstverständlich die Designrichtlinien des Kunden.

138138

139139

Des

ign

STYLEGUIDE

Bevor wir das digitale Produkt realisieren, müssen wir gestalterische Richtlinien erstellen� Mit ihnen definieren wir, wie die Interaktions-Oberfläche aussehen soll�

Der Styleguide gewährleistet eine einheitliche und

marken- oder unternehmenskonforme Gestaltung.

Mit ihm legen wir Form- und Farbgebung,

Typographie, Struktur, Größen und Abstände fest,

er gibt aber auch Auskunft über die sprachliche

Ausrichtung oder über technische Aspekte, wie die

Erstellung von Quellcodes.

140140

141141

Des

ign

PAPIER- & FUNKTIONS-PROTOTYPEN

Digitale Produkte müssen funktional anwendbar sein� Damit wir mit unseren Produkten eine optimale Usability gewährleisten können und zeit- und kosteneffizient arbeiten, entwickeln wir Prototypen, die sowohl die finale Nutzeroberfläche als auch Bedienabläufe simulieren�

Mit Prototypen machen wir Designideen und Konzepte konkret, sichtbar und greifbar, sodass wir sie überprüfen und verfeinern können.

Darüberhinaus bieten sie uns die Möglichkeit, potenzielle Nutzer mitein-zubeziehen, so versetzen wir uns über prototypgestützte Interviews in die Sicht der Nutzer�

Je nachdem, wie sie ausgeprägt sind, spielen Prototypen in unterschied-lichen Stadien des Designprozesses eine wichtige Rolle� Angefangen bei sogenannten Low-Fidelity-Prototypen, die wir in Form von Papier-Proto-typen, d�h� Wireframes oder Scribbles, erstellen und die uns frühzeitig im Prozess Aufschluss geben über Idee und Konzept, bis hin zu Funktions-Prototypen (High-Fidelity-Prototypen), die schon sehr nah an der tatsäch-lichen Interaktionsoberfläche sind und demzufolge zu einem späteren Entwicklungszeitpunkt eingesetzt werden� Zudem vermitteln sie dem Designteam, den Stakeholdern und den Nutzern ein Gefühl für Bedienbar-keit, Verhalten und Look & Feel� Bei mobilen Anwendungen ist besonders wichtig, dass wir Designs so früh wie möglich testen, und zwar sowohl auf dem Endgerät als auch in verschiedenen Licht- und Bedienumgebungen� So bekommen wir früh einen Eindruck davon, wie die Applikation sich später für den Nutzer anfühlt�

142142

143143

Des

ign

SERVICE-PROTOTYPEN

Ähnlich wie Papier- und Funktions-Prototypen sorgen Service-Proto-typen dafür, dass wir ein tiefes Verständnis für die Nutzung eines Services oder eines Produktes entwickeln und daraus Designlösungen und User Experiences evaluieren und optimieren� Mit einem Service-Prototyp simulieren wir die digitale Anwendung nicht innerhalb einer Laborsituation, sondern verlagern die Simulation in die „reale Welt“� Je nach Fokus können die Ausprägungen des Service-Prototy-pings variieren: Von Rollenspielen, Konversationen oder detaillierten „Real-Szenarien“ mit Requisiten bis hin zu physischen „Touchpoints“, in denen sich die Akteure innerhalb einer konstruierten Situation bewegen�

Mit einem Service-Prototyp simulieren wir die digitale Anwendung nicht innerhalb einer Laborsituation, sondern verlagern die Simulation in die „reale Welt“.

144144

INTERAKTIONS-MODELLE

Anhand von Interaktions-Modellen beschreiben wir,

wie Mensch und Maschine voneinander abhängen

und wie sie miteinander in Verbindung treten. Wir

fokussieren Bedienabläufe und Interaktionen, bilden

sie detailliert ab, machen sie erlebbar.

Als Abbildungstechniken eignen sich, je nach Fragestellung, Evaluie-rung und Weiterentwicklung entweder Animationen, Mock-Ups oder einfache Fluss-Diagramme� Beispielsweise können wir Funktionen wie Drag'n'Drop bereits über eine einfache Animation überprüfen und konkretisieren, wohingegen wir Prozesslogiken wie ein Login-Szenario besser über ein komplexes Aktivitäten-Diagramm beschreiben können�

146146

Im iterativen Designprozess spielen Evaluierung

und Testing eine wichtige Rolle, um den

entwickelten Prototyp so lange zu verbessern und zu

verfeinern, bis wir ein wirklich nutzerorientiertes

Produkt entwickelt haben.

Evaluierung & Testing

147147

Des

ign

Des

ign

Des

ign

Des

ign

148148

149149

Des

ign

USABILITY-TESTING

Als Usability-Testing bezeichnen wir eine übergreifende Methodologie, die unterschiedliche Methoden und Instrumente beinhaltet, mit denen wir Produkte oder Services auf ihre Usability und Performance durch Nutzer (im Labor) testen� Mögliche Methoden sind u� a� A/B-Tests, Eye-Tracking, Thinking Aloud, Fragebögen oder Remote Usability-Tests� Unabhängig davon, welche Methode wir anwenden, halten wir einige Schritte fest, die bei jedem Test durchgeführt werden:

❶ Testleitfaden und -design erstellen (z� B� ein Test-Storyboard bestehend aus Fragen und Tasks zu den jeweiligen Test-Screens)

❷ Testpersonen auswählen (z�B� nach demographischen Faktoren oder nach Kenntnissen der Aufgabe; je nach Methode wählen wir eine unterschiedliche Anzahl von Testpersonen)

❸ Test durchführen (Testpersonen führen unter Beobachtung die beschriebenen Aufgaben durch, beantworten die Fragen und können je nach Testmethode die Screens zusätzlich kommentieren)

❹ Ergebnisse auswerten und debriefen (Besprechung der Testergebnisse mit dem beobachtenden Team und Schlussfolgerungen für die weitere Umsetzung)

Ziel des Usability-Testings ist es, dass wir beobachten

können, wie das Produkt in seinem Nutzungskontext

(oder im Labor) von Nutzern genutzt wird. So können

wir mögliche Interaktionsprobleme erkennen, bevor

wir das Produkt realisieren. In der Dokumentation

des Testings halten wir Handlungsempfehlungen für

die weitere Umsetzung fest.

150150

Die Experten-Bewertungen fassen wir zusammen, priorisieren Probleme und formulieren Lösungsvorschläge.

151151

Des

ign

Nachdem wir eine Heuristische Evaluierung durchgeführt haben, erhalten wir eine übergreifende Dokumentation der Usability-Probleme oder -Hürden, in der wir auf allgemeine Usability-Prinzipien hinweisen� Die einzelnen Experten-Bewertungen fassen wir zusammen, priori-sieren Probleme (der Schweregrad eines Problems ergibt sich aus seiner Quantität und Qualität) und formulieren Lösungsvorschläge�

HEURISTISCHE EVALUIERUNG

Die heuristische Evaluierung ist ein Instrument der Usability-Inspek-tion (für Interfacedesigns) innerhalb eines iterativen Designprozesses� Mehrere Experten aus unserem Team überprüfen unabhängig vonei-nander einen Website-Entwurf, der auf einem allgemein anerkannten Set von Usability-Prinzipien basiert („Heuristiken“)� So können wir Usability-Probleme oder -Hürden erkennen� Idealerweise prüfen zwischen drei und fünf unserer Usability-Experten die Nutzungsoberfläche in mehreren Durchläufen� Dabei halten sie sich bei ihrer Bewertung und Argumentation an die vorgegebenen Heuris-tiken� Molich und Nielsen entwickelten dazu eine Checkliste mit zehn Usability-Prinzipien, die durch weitere Heuristiken erweitert werden sollte, wenn sie für das spezifische Testobjekt relevant sind (z�B� bei Mobilen Produkten, touch gestures, Responsive Design etc�):

Usability-Prinzip

☐ Sichtbarkeit des Systemstatus

☐ Übereinstimmung zwischen dem System und der realen Welt

☐ Benutzerkontrolle und –freiheit

☐ Konsistenz und Standards

☐ Fehlervermeidung

☐ Wiedererkennen, anstatt sich erinnern zu müssen

☐ Flexibilität und Effizienz der Benutzung

☐ Ästhetik und minimalistisches Design

☐ Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern

☐ Hilfe und Dokumentation

Des

ign

152152

So wie beim Hausbau vor dem ersten Spatenstich

zumindest ein Bauplan des Gebäudes vorliegen

sollte, so machen wir uns vor der ersten Quellcode-

Zeile Gedanken über Aufbau und Struktur der

Software. Software-Architektur ist ein sehr

umfangreiches Gebiet, hierbei gibt es unzählige

Methoden und Werkzeuge, um ein System zu planen.

Exemplarisch stellen wir hier drei der verbreitetsten

vor:

Software-Architektur

153153

Des

ign

Des

ign

154154

Das Datenmodell bildet die Objekte der realen Welt in der künstlichen Umgebung der IT ab.

155155

Des

ign

DATENMODELL

Alle Services und Funktionen eines fertigen Produkts basieren auf den ihnen zugrunde liegenden Daten� Wenn wir den Aufbau und die Zuord-nung der Daten untereinander nicht korrekt definiert haben, werden die später darauf entwickelten Services und Funktionen schwerer zu implementieren und sind fehleranfälliger�

Das Datenmodell bildet die Objekte der realen Welt in der künstlichen Umgebung der IT ab� Es legt die Beziehung zwischen Daten fest (z�B� ordnet einer Bestellung einen Kunden zu oder ordnet die Systemein-stellung eines Nutzers einem Produktes zu) und sorgt für eine saubere Datenintegrität� Dazu sammeln wir sämtliche Daten, bestimmen ihren Typ (Zahlen, Buchstaben, Binärdaten etc�) und legen ihre Beziehung untereinander fest� So bestimmt das Datenmodell beispielsweise, ob ein Kunde eine oder mehrere Adressen hat und was Teil einer Adresse ist�

Das Ergebnis eines Datenmodells ist meist ein Schaubild, das die Verknüpfung der Daten untereinander zeigt� Häufig ergänzen wir es durch eine tabellarische Auflistung der Daten und der entsprechenden Typen und bei Bedarf durch einen zusätzlichen Erklärungstext�

156156

157157

Des

ign

KOMPONENTENMODELL

Mit dem Umfang der Funktionen und Anwendungen die ein Produkt leisten muss, steigt meist auch die Komplexität der Software� Wenn wir also mit der Implementierung beginnen, ohne uns weitere Gedanken über den allgemeinen Aufbau der noch zu entwickelnden Software machen, bekommen wir ein meist schlecht strukturiertes Ergebnis und das Produkt lässt sich schwer warten� Funktionen werden dann mehr-mals implementiert oder sind vielleicht sogar gar nicht realisierbar, ohne dass wir große Teile des bestehenden Systems neu entwickeln�

In einem Komponentenmodell definieren

wir Module und Komponenten sowie die

Berührungspunkte und Schnittstellen

dazwischen. Kontakte zu Drittsystemen können

wir auf möglichst wenige Punkte reduzieren und

vereinheitlichen.

Das Diagramm, welches das Komponentenmodell darstellt, ist ein Strukturdiagramm der Unified Modeling Language (UML)� Wie die anderen UML-Diagrammtypen dient es zur Systemmodellierung und zeigt die einzelnen Komponenten der Software und die Schnittstellen untereinander und nach außen hin auf�

158158

Jede Software braucht Hardware, auf der sie laufen kann. Da die Hardware die Software aber oft in ihrer Funktion einschränkt, müssen wir uns früh darüber klar werden, welche Hardware wir verwenden.

159159

Des

ign

SYSTEM-ARCHITEKTUR

Neben den naheliegenden funktionalen Anforderungen an die Hard-ware spielen auch die nicht-funktionalen Anforderungen wie Verfüg-barkeit, Performance und Wartbarkeit eine wichtige Rolle� Gemeinsam mit den funktionalen Anforderungen des Projektes ergeben sich aus ihnen die benötigte Qualität und Quantität der Hardware�

Die System-Architektur wird meist als Diagramm dargestellt� Wir skizzieren grob die benötigte Hardware und ergänzen das Diagramm durch eine möglichst genaue Beschreibung der einzelnen Hardwarekomponenten�

160160

Phase #4

161161

Rea

lisi

erun

gR

eali

sier

ung

162162

Implementierung

In der Implementierung wird der eigentliche

Quellcode erzeugt, wobei es unterschiedliche

Methoden gibt, die im Konzept beschriebenen

Funktionalitäten umzusetzen und die Qualität

des Produktes zu gewährleisten. Nachfolgend

beschreiben wir lediglich beispielhaft drei Methoden

für die Implementierungsphase.

163163

Rea

lisi

erun

gR

eali

sier

ung

Rea

lisi

erun

g

164164

Mit der Umsetzung des Rapid Prototypings können wir Lücken in der Software-Architektur rechtzeitig erkennen und diese schließen.

165165

Rea

lisi

erun

g

RAPID PROTOTYPING

Wie bei allen IT-Projekten spielt Zeit auch bei Softwareprojekten eine wichtige Rolle, dies gilt auch für die Implementierungsphase� Die Verwendung des Rapid Prototyping gibt uns die Möglichkeit, früh-zeitig eine Version des Produktes zu erzeugen, die wir mit dem Kunden zusammen durchgehen können� So erkennen wir Punkte, die geändert werden müssen� Denn nach der Fertigstellung des Gesamtproduktes sind einige Änderungen nicht mehr möglich�

Wir nutzen Rapid Prototyping, um frühzeitig eine festgelegte Basis-funktionalität bereitstellen zu können� Das ist wichtig, weil es in den meisten Fällen ungünstig auswirkt, zuerst alle Softwareanteile umzu-setzen und im Anschluss mit Arbeitsphasen wie Test und Abnahme zu beginnen� Mit der Umsetzung des Rapid Prototypings können wir Lücken in der Software-Architektur rechtzeitig erkennen und diese schließen� Hierfür fassen wir die Realisierungsaufgaben in Arbeitspa-keten zusammen� Wenn wir die ersten Arbeitspakete so zusammen-stellen, dass sie die wesentlichen Grundfunktionen beinhalten, können wir recht frühzeitig eine komplette Basisfunktionalität liefern� Damit starten wir dann in die erste Testphase� Ist das Basispaket fertiggege-stellt, können wir mit den nächsten Ausbaustufen beginnen�

Unser Ziel beim Rapid Prototyping ist es, einen ersten „Prototypen“ der Software fertigzustellen, der schon den wesentlichen Charakter des Produktes wiederspiegelt und zudem die Aspekte der Konzeption für die Umsetzung bestätigt�

166166

Bei der testgetriebenen Entwicklung erstellen wir vor der eigentlichen Implementierung Testfälle, die wir dann dazu nutzen, den entstehenden Programmcode und die darin enthaltenen Funktionen zu überprüfen.

167167

Rea

lisi

erun

g

TESTGETRIEBENE ENTWICKLUNG

Neben dem Zeitfaktor muss natürlich auch die Qualität der Software entsprechend stimmen� Aus diesem Grund verwenden wir häufig die Methode der testgetriebenen Entwicklung�

Bei der testgetriebenen Entwicklung erstellen wir vor der eigentli-chen Implementierung Testfälle, die wir dann dazu nutzen, den entste-henden Programmcode und die darin enthaltenen Funktionen zu über-prüfen� Wenn einzelne oder sogar alle Testfälle nicht erfolgreich durch-führbar sind, müssen wir den Programmcode so lange überarbeiten, bis alle Testbedingungen erfüllt sind� Neben den bereits beschriebenen Testverfahren über sogenannte Komponententests, die Funktionen und Module im Einzelnen testen, gibt es ebenfalls Systemtests, die das System in der Gesamtheit testen� Dabei gehen wir ebenso vor wie bei den Komponententests�

Wenn wir die Vorgehensweise strikt einhalten – was ein hohes Maß an Disziplin verlangt – können wir in den meisten Fällen die Testabde-ckung im Vergleich zu iterativen Vorgehensweisen steigern; dadurch verbessert sich die Qualität der Software� Außerdem können wir spätere Änderungen und Restrukturierungsmaßnahmen wesentlich schneller durchführen, da wir jederzeit auf die vorhandenen Testfälle zurück-greifen können�

168168

Durch eine stringente Anwendung der kontinuierlichen Integration verbessert sich das Zusammenspiel der einzelnen Programmfunktionalitäten, die wir meist unabhängig voneinander entwickeln.

169169

Rea

lisi

erun

g

KONTINUIERLICHE INTEGRATION

Sinn der kontinuierlichen Integration ist es, dass hierbei frühzeitig und fortlaufend die durchgeführten Entwicklungsschritte in das Gesamt-system integriert werden, um so die Qualität der Interaktionen der einzelnen Programmteile und damit die Qualität des Gesamtproduktes zu steigern�

Damit wir eine kontinuierliche Integration erreichen, müssen wir parallel oder vor der eigentlichen Implementierung Tests anfer-tigen, die automatisiert ausgeführt werden können� Die Implementie-rungsschritte erfolgen in kleinen Iterationen und werden frühzeitig in die Versionsverwaltung übernommen� Zu definierten Zeitpunkten, beispielsweise mit der Übernahme in die Versionsverwaltung oder – automatisiert – jede Nacht, wird das Gesamtsystem zusammengebaut und durch die bereitgestellten Tests automatisiert geprüft� War der Test erfolgreich, wird das System automatisiert auf eine Test- bzw� eine Stage-Umgebung aufgespielt� Wenn beim Zusammenbau oder bei den darauffolgenden Tests Probleme auftreten, kann sofort darauf reagiert werden�

Außerdem ist zu jedem Zeitpunkt ein lauffähiges System vorhanden, was jedoch noch nicht den gesamten Funktionsumfang abdeckt�

Rea

lisi

erun

g

170170

Testing

Das fertige Produkt kann nur dann unserem

Qualitätsanspruch genügen, wenn die Realisierung

der Software durch eine hohe Testabdeckung

begleitet wird. Dazu stehen uns eine Vielzahl von

Testmethoden zur Verfügung, die wir je nach

Anforderungen an das Produkt auswählen. Dabei

müssen wir stets beachten, dass Tests nur das testen

können, für das sie vorgesehen wurden.

171171

Rea

lisi

erun

gR

eali

sier

ung

172172

Unser Ziel bei den Komponententests ist es, eine Software zu entwickeln, die durch hohe Testabdeckung sicherstellt, dass nach der Entwicklung neuer Funktionen auch die bereits bestehenden lauffähig sind.

173173

Rea

lisi

erun

g

KOMPONENTENTEST

Je komplexer eine Software wird und je mehr Entwickler daran betei-ligt sind, desto größer ist die Gefahr von Nebeneffekten, die eine Komponente auf eine andere hat: Ein Entwickler einer Komponente kann ohne es zu wissen andere, bereits existierende Komponenten funktionsunfähig machen� Die Herausforderung ist hierbei, dass wir etwaige Programmfehler möglichst früh in der Entwicklung entdecken�

Jede Komponente oder Funktionalität wird für sich automati-siert auf Herz und Nieren überprüft� Wurde eine einzelne Kompo-nente erfolgreich getestet, und integriert, werden alle bereits fertigge-stellten Komponenten nochmals automatisiert auf die Bestandsfunk-tionen geprüft� Auf diese Weise stellen wir sicher, dass eine Neuent-wicklung keine negativen Einflüsse auf unser Produkt hat� Wenn die Tests jede bisherige Funktion abdecken – man spricht dabei von abso-luter Testabdeckung – werden Fehler in bestehenden Funktionen und Komponenten schnell sichtbar� Allerdings liegt auch genau darin ein gewisses Risiko: Eine absolute Testabdeckung ist in der Realität einer Produktentwicklung kaum umsetzbar; und eine unvollstän-dige Testabdeckung kann den Entwicklern eine Sicherheit geben, die unter Umständen nicht gewährleistet ist� Die Methode der testgetrie-benen Entwicklung (siehe „Implementierung“) kann dabei helfen, eine höhere Testabdeckung zu erreichen�

174174

175175

Rea

lisi

erun

g

LAST- UND STRESSTEST

Erfüllt ein Produkt oder ein Service seine grundlegenden Funkti-onen, ist das gut und genau so gewollt� Was aber passiert, wenn nicht mehr der eine Entwickler auf ein System zugreift, sondern 1000 Nutzer gleichzeitig? Ob unser Produkt auch unter diesen realistischer Bedin-gungen funktioniert oder das System vielleicht eine große Anzahl an gleichzeitigen Zugriffen nicht verkraftet, können wir nur anhand einer Reihe gut geplanter Tests herausfinden�

Ein Lasttest setzt ein Produkt oder einen Service

bewusst unter Druck, in dem er eine große Anzahl

zeitgleicher, aber unterschiedlicher Zugriffe auf das

System simuliert.

Dadurch, dass wir die Ergebnisse messen und visualisieren, bekommen wir einen Einblick in potenzielle Schwachstellen oder Engpässe, die das System im normalen Betrieb vielleicht ausbremsen würden� Der Stresstest ist ein Sonderfall des Lasttests� Er versucht ganz bewusst das System an seine die Grenzen der Leistungsfähigkeit und darüber hinaus zu bringen� Mit diesem Test machen wir uns ein Bild über die maximalen Kapazitäten des jeweiligen Produktes oder Services�

Ein Last- oder Stresstest stellen wir als Diagramm oder Tabelle dar, die Antwort- oder Reaktionszeiten von Services auflistet� Dadurch finden wir Hinweise auf kritische Stellen, die vor Produkteinführung noch behoben werden müssen�

176176

Ein Sicherheitstest ist ein sogenannter Negativtest. Mit ihm testen wir, ob bestimmte Merkmale, wie Sicherheitslücken oder unerwünschte Nebeneffekte, nicht vorhanden sind.

177177

Rea

lisi

erun

g

SICHERHEITSTEST

Ein Produkt muss nicht bloß einfach nur funktionieren, es muss auch sicher funktionieren� Das heißt, es muss gewährleistet sein, dass das Programm keine sicherheitskritischen Schwachstellen enthält, die ein potenzieller Angreifer ausnutzen könnte�

Da die Ausprägung dieser Merkmale zum großen Teil bekannt sind – typische Sicherheitsprobleme eines Programmes sind in der Regel die gleichen, z� B� Cross-Site-Scripting, SQL-Injection, Buffer Overflow – können grundlegende Sicherheitstest auch automatisiert durchge-führt werden� Hierfür gibt es teils kommerzielle, teils quelloffene Test-werkzeuge, die in oft ausführlichen Berichten die Ergebnisse doku-mentieren� Besondere Berücksichtigung sollten hier die Sicherheitsan-forderungen erfahren, die wir in der Analysephase als für das Produkt kritisch bewertet haben�

Unser Ziel bei den Sicherheitstests ist der Report eines ausgesuchten Sicherheitstest-Tools, das bestätigt, dass der Quellcode frei von bekannten Sicherheitslücken ist� Oder eben eine Liste von offenen Sicherheitslücken, die wir schließen müssen� Dabei ist es wichtig zu wissen, dass ein Werkzeug immer nur auf bekannte Schwachstellen testen kann� Eine 100%-ige Sicherheit kann niemals garantiert werden�

178178

In der Dokumentation verschriftlichen wir die

Ergebnissen der vorangegangenen Phasen. Neben

anwenderspezifischen Handbüchern müssen wir

oft Konfigurationen und spezielle Arbeitsschritte

dokumentieren, die es bei der Inbetriebnahme und

Pflege des Produktes zu beachten gilt.

Dokumentation

179179

Rea

lisi

erun

gR

eali

sier

ung

Rea

lisi

erun

g

180180

181181

Rea

lisi

erun

g

TECHNISCHE DOKUMENTATION

Jede Software braucht eine Plattform, auf der sie ausgeführt werden kann� Jedoch ist es da mit der reinen Technik nicht getan, oft dauert es sehr lange, diese Plattform zu konfigurieren� Aus diesem Grund ist ein Mindestmaß an technischer Dokumentation derartiger Funkti-onen und Gegebenheiten unerlässlich� Diese und andere technischen Aspekte – die von technischen Beschreibungen über den Aufbau eines Testsystems bis hin zur Umsetzung und Integration einzelner Funkti-onen in das Gesamtsystem reichen – können den Aufwand zukünftiger Implementierungen und Pflegearbeiten erheblich verkürzen�

Wie genau eine technische Dokumentation aufgebaut ist, hängt von der Komplexität des Produktes ab� In jedem Fall unterstützt eine gute technische Dokumentation die Pflege und Weiterentwicklung eines Produktes maßgeblich�

Das Ergebnis einer technischen Dokumentation sollten leicht verständ-liche und gut pflegbare Dokumente sein, die beispielsweise eine reibungslose Installation und Konfiguration des Produktes und der zugrundeliegenden Plattform gewährleisten�

182182

183183

Rea

lisi

erun

g

ANWENDERDOKUMENTATION

Die Qualität eines Softwareproduktes ist vor allem durch die Nutzbarkeit und die Verständlichkeit für den Nutzer bestimmt.

Daher müssen wir zu jedem Produkt eine entsprechende Dokumenta-tion verfassen, in der wir dem Anwender alle Funktionen des Produktes und den richtigen Umgang damit verständlich erklären�

Dabei ist es sinnvoll, dass wir Funktionsabläufe grafisch so aufbereiten, dass sie direkt auf das Produkt angewendet werden können und dass auch komplexe Sachverhalte leicht verständlich sind�

Anwenderdokumentationen stellen wir häufig in Form von Benutzer-handbüchern bereit�

Rea

lisi

erun

g

184184

185185

Rea

lisi

erun

g

TRAINING

Oft reicht eine reine Dokumentation nicht aus, Anwendern des Produktes die Komplexität und den kompletten Funktionsumfang im Detail zu erklären� In diesen Fällen ist es sinnvoll, wenn wir den Nutzern eine Einführung in das Produkt geben�

In einem Training erklärt ein Trainingsleiter strukturiert sämtliche Funktionen und Funktionsabläufe eines Produktes sowie gegebenen-falls dessen Konfigurationen und technische Zusammenhänge� Da es in komplexen Systemen häufig mehrere Wege gibt, bestimmte Aufgaben zu erfüllen, aber nicht jeder dieser Wege einen optimalen Nutzen bringt, kann in einem Training auch vermittelt werden, wie man als Nutzer mit bestimmten Problemstellungen umgeht�

Ein erfolgreiches Training erleichtert den Anwendern des Produktes oftmals den Einstieg und verbessert das Verständnis im Bezug auf detaillierte Fragestellung�

Nach einem Training sind Anwender in der Lage, mit Hilfe der Dokumentation auch komplexe Funktionsabläufe innerhalb des Produktes zu verstehen und auszuführen.

186186

Eine gute Produktentwicklung schließt die

Kommunikationsplanung von Beginn ein: Wie sonst

sollen die Nutzer, Stakeholder und Medien vom

neuen Produkt erfahren?

Kommunikationsplanung

187187

Rea

lisi

erun

gR

eali

sier

ung

188188

189189

Rea

lisi

erun

g

INTEGRIERTE KOMMUNIKATION

Integrierte Kommunikation bezeichnet ein Vorgehen, das eine konsis-tente und aufeinander abgestimmte Unternehmenskommunikation zum Ziel hat� Um ein einheitliches Erscheinungsbild des Unterneh-mens oder des Produkts zu vermitteln, müssen alle Kommunikations-kanäle miteinander vernetzt werden�

Integrierte Kommunikation umfasst also alle Kanäle, aber auch Kommunikations- und Vertriebswege:

▶ Digital (Unternehmenswebsite (SEO,SEM), Produkt-Landingpage, News und PR, Out-of-Home)

▶ Dialog (Social-Media-Kanäle: Facebook, YouTube, Twitter, …)

▶ Klassik (Marketing- und Printmedien: Kataloge, Broschüren, Berichterstattung & PR; TV, Out-of-Home)

▶ POS (Händler, Filialen und Ladengeschäfte, „Automaten“, Kiosk-Systeme)

Durch eine zielgerichtete Planung und Koordination von Kommu-nikationsinhalten und -instrumenten erreichen wir übergeordnete Kommunikationsziele wie z�B� die Akzeptanz bei Kunden und Stakehol-dern� Zudem heben wir unsere Produkte von Konkurrenzprodukten ab und bieten effiziente Kommunikationsmaßnahmen (Content Sharing & Content Strategy)�

190190

191191

Rea

lisi

erun

g

ROADMAP

Eine Kommunikations-Roadmap ist eine Methode, mit der wir Kommunikationsmaßnahmen zu einem Produkt-Launch grob – über den Produkt-Lebenszyklus hinweg – planen und strukturieren� Sie beinhaltet unterschiedliche Kommunikationsziele und -phasen, die wir wiederum in kleinere Schritte aufteilen� Die Roadmap enthält zusätz-lich verschiedene optionale Szenarien, die adäquate Lösungen für Prob-lemsituationen bieten – so können wir Fehlentscheidungen im Vorfeld vermeiden� Aber eine Roadmap leistet mehr als das: Neben den Kernelementen der Kommunikation werden hier auch die beteiligten Akteure und eine Priorisierung der Maßnahmen aufgelistet� Für uns ist sie also ein wich-tiges Dokument, um Kommunikationsziele abzustimmen, Rahmenbe-dingungen festzulegen und ausschlaggebende W-Fragen (Wer? Wann? Was?) zu beantworten�

192

Hier können Sie die Kopiervorlagen herunterladen�

www�press�denkwerk�com/dw/2012/Kopiervorlagen�pdf

193

194

PDF Download

Wenn Sie wissen möchten, wie Sie

Digitale Produktentwicklung für Ihr

Unternehmen einsetzen können, freuen

wir uns auf einen persönlichen Austausch�

Melinda Burmeister, melinda�burmeister@denkwerk�comdenkwerk GmbH Vogelsanger Str� 66 50823 Köln T +49 221 2942 100 www�denkwerk�comGeschäftsführer: Jochen Schlaier, Constantin Stammen, Marco Zingler