eparo – Digital Service Design

Das Blog von eparo.de

22. Dezember, 2015

Axure 8 – Alle Events erklärt

Axure zeichnet sich seit Jahren gegenüber anderen Prototyping Tools dadurch aus, dass jede Idee bis zum High-Fidelity Prototyp erstellt werden kann. Grund dafür ist eine riesige Anzahl an Events, die zahlreiche Aktionen auslösen können. In der neuen Version 8 sind nun noch mehr Events hinzugekommen und die Möglichkeit, diese an den meisten Widgets aufzurufen. Um den Überblick zu behalten, haben wir eine Liste mit allen Widget-Typen und deren Events erstellt.

151222_Axure 8 - Events Overview

Und hier noch eine kurze Erklärung zu jedem Event:

OnClick: Wenn das Widget geklickt wird.
OnMouseEnter: Wenn der Mauszeiger über das Widget bewegt wird.
OnMouseOut: Wenn der Mauszeiger den Bereich des Widgets wieder verlässt.
OnDoubleClick: Wenn das Widget mit einem Doppelklick geklickt wird.
OnContextMenu: Wenn das Widget mit der rechten Maustaste geklickt wird.
OnMouseDown: Wenn das Widget geklickt wurde, die Maustaste aber nicht losgelassen wird.
OnMouseUp: Wenn das Widget geklickt wurde und die Maustaste losgelassen wird.
OnMouseMove: Löst solange aus, wie der Mauszeiger über dem Widget ist.
OnMouseHover: Wenn der Mauszeiger eine Sekunde über dem Widget stillsteht.
OnLongClick: Wenn das Widget geklickt wurde und die Maustaste gehalten wird.
OnKeyDown: Wenn eine Taste auf der Tastatur gedrückt wird, während Text auf dem Widget eingegeben wird.
OnKeyUp: Wenn eine Taste auf der Tastatur losgelassen wird, während Text auf dem Widget eingegeben wird.
OnMove: Wenn das Widget sich bewegt.
OnRotate: Wenn das Widget rotiert wird.
OnResize: Wenn das Widget seine Größe verändert.
OnShow: Wenn das Widget angezeigt wird.
OnHide: Wenn das Widget versteckt wird.
OnFocus: Wenn das Widget fokussiert wird.
OnLostFocus: Wenn das Widget den Fokus verliert.
OnSelectionChange: Wenn in der Droplist eine andere Option ausgewählt wird.
OnSelection: Wenn das Widget selektiert wird.
OnUnselection: Wenn die Selektion des Widgets abgewählt wird.
OnLoad: Wenn das Widget initial beim Start der Seite geladen wird.
OnPanelStateChange: Wenn sich der State des Dynamic Panels ändert.
OnDragStart: Wenn der Drag auf dem Dynamic Panel anfängt.
OnDrag: Wenn das Dynamic Panel gedragged wird.
OnDragDrop: Wenn der Drag auf dem Dynamic Panel endet.
OnSwipeLeft: Wenn das Dynamic Panel von rechts nach links geswiped wird.
OnSwipeRight: Wenn das Dynamic Panel von links nach rechts geswiped wird.
OnSwipeUp: Wenn das Dynamic Panel von unten nach oben geswiped wird.
OnSwipeDown: Wenn das Dynamic Panel von oben nach unten geswiped wird.
OnScroll: Wenn der Inhalt des Dynamic Panels gescrollt wird.
OnScrollUp: Wenn der Inhalt des Dynamic Panels hoch gescrollt wird.
OnScrollDown: Wenn der Inhalt des Dynamic Panels runter gescrollt wird.
OnTextChange: Wenn der Text sich in einem Eingabefeld ändert.
OnItemLoad: Wenn die Elemente des Repeaters geladen werden.
OnItemResize: Wenn die Elemente des Repeaters die Größe verändern.
OnPageLoad: Wenn die Seite geladen wird.
OnWindowResize: Wenn sich die Größe des Browser Fensters ändert.
OnWindowScroll: Wenn das Browser Fenster gescrollt wird.
OnWindowScrollUp: Wenn das Browser Fenster hoch gescrollt wird.
OnWindowScrollDown: Wenn das Browser Fenster runter gescrollt wird.
OnPageClick: Wenn auf der Seite geklickt wird.
OnPageDoubleClick: Wenn auf der Seite mit einem Doppelklick geklickt wird.
OnPageContextMenu: Wenn auf der Seite mit der rechten Maustaste geklickt wird.
OnPageMouseMove: Wenn die Maus auf der Seite bewegt wird.
OnPageKeyDown: Wenn eine Taste auf der Tastatur gedrückt wird.
OnPageKeyUp: Wenn eine Taste auf der Tastatur losgelassen wird.
OnAdaptiveViewChange:   Wenn sich der Adaptive View ändert.
 
14. Dezember, 2015

Neues in Axure 8

Bild 0

Noch ist Axure 8 seit einigen Monaten in der Betaphase, aber sie bringt bereits einige Neuheiten mit sich. In diesem Beitrag haben wir die aus unserer Sicht wichtigsten Veränderungen zusammengefasst.

1 Das Pen Tool und eigene Shapes

Jedem, der einmal Probleme hatte, seine eigenen Icons oder Flächen zu definieren und dafür nicht extra Photoshop öffnen wollte, ist jetzt geholfen. Mit dem Pen Tool lassen sich ähnlich wie in Illustrator eigene Flächen über Ankerpunkte definieren.

Bild 1 - Pen Tool
 
 
 
 
 

Zu dem ist es möglich, die eigenen Shapes abzuspeichern.

Bild 2  

2 Gruppen haben einen neuen Sinn

Eine der wahrscheinlich größten, strukturellen Veränderungen ist die neue Verwendung von Gruppen. Endlich können gruppierte Elemente auch über Events und Aktionen gemeinsam beeinflusst werden. Eine Gruppe wird in der neuen Version mit einem Ordnersymbol im Widget Manager dargestellt und kann wie ein eigenständiges Widget manipuliert werden.

Bild 3  

3 Weitere Events und Actions

Was ihr vielleicht in den CSS3 Animationen kennt, ist nun auch in Axure 8 möglich. Es lassen sich mit Axure 8 nicht nur alle Widgets über die Action Set Size in ihrer Größe verändern lassen, es ist auch die Action Rotate hinzugekommen. Außerdem lassen sich Elemente bei der Nutzung der Action Show/Hide und Set Panel State über eine neue Animation flippen.
Außerdem ist es von nun an möglich über die Action Set Adaptive View von Widgets aus den View zu ändern. Mit der neuen Action Fire Event lässt isch jedes Event auf einem anderen Widget auszulösen. Das klingt erst mal nerdish, aber hilft, um übersichtlicher zu arbeiten. Wir freuen uns drüber :-)
In Bezug auf Events von Widgets lässt sich feststellen, dass sich die Bandbreite an potenziellen Events auf allen Widgets vergrößert hat. Während in der Version 7 das Dynamic Panel eine Art Vormachtstellung hatte, können nun sehr viele Events auch an anderen Widgets aufgerufen werden.

4 Styling und Dokumentation

Wenn ihr Axure 8 öffnet, fallen zunächst die neu gestylten Default Widgets auf. Diese erinnern nun eher an Flat Design. Zu dem gibt es eine neue Rubrik Markup. In dieser befinden sich designte Shapes, die an Post Its erinnern. Außerdem gibt es das interessante Widget Snapshot. Mit diesem lassen sich andere Seiten oder nur einen Bereich aus diesen als referenziertes Bild anzeigen. Mit dieser Palette an Widgets lassen sich so übersichtlichere Dokumentation anfertigen.

Bild 5 - Markups
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Auch der Widget Style Editor hat sich stark verändert. Dieser hat von nun an keine Unterscheidung zwischen Widget Defaults und Custom Styles mehr, sonder lediglich einen Default Style ,auf dem alle anderen Styles aufbauen und einen Bereich mit den definierten Styles für die einzelnen Elemente. Außerdem können in dieser Version mehrere Styles gleichzeitig bearbeitet werden und man erkennt die grundlegenden Veränderungen in einer Direktvorschau.

Bild 6 - Widget Style Editor

Hat man Widgets einen eigenen Style zugewiesen und verändert diese nachträglich am Objekt, gibt es jetzt die Möglichkeit unter den Properties and Style den globalen Style zu updaten. Dies macht es deutlich einfacher, auf einer Dokumentationsseite alle Style-Ausprägungen übersichtlich darzustellen und über diese gegebenenfalls Anpassungen vorzunehmen.

Bild 7 - Update Styles
 
 
 
 
 
 

Um Abfolgen in der Dokumentation darzustellen, hat bestimmt der ein oder andere von euch schon mal auf die Axure Flow Library zurückgegriffen, da diese Elemente den Vorteil hatten sich über Ankerpunkte miteinander verbinden zu lassen. In der neuen Version kann jedes Widget Element bzw. eine Widget-Gruppe über Ankerpunkte verknüpft werden.

Bild 8 - Ankerpunkte
 

5 Weiteres

Die Entwickler in Kalifornien haben in der Version 8 noch an vielen weiteren Stellen kleinere Veränderungen vorgenommen. So ist das Page Properties Panel nicht mehr am unteren Programmrand zu finden, sondern lässt sich über einen Klick in die Seite erreichen. Die Manipulation erfolgt nun in dem Inspector Bereich, der somit nicht nur die Page Properties, sondern auch die Panels Widget Interactions and Notes und Widget Properties and Style vereinigt.
Des Weiteren können Ecken und Umrandungslinien an Shapes einzelnd angesprochen und in ihrem Style beeinflusst werden.
Auch das Repeater Widget hat zwei entscheidende Neuerung erhalten. Zum einen wirken sich Elemente, die im Repeater versteckt sind, nicht auf die Größe bei der Duplizierung aus und zum anderen können über Dynamic Panels gekachelte Elemente auch unterschiedlich Groß sein.
In dieser Version ist auch außerdem möglich Team Project über den AxShare Server zu hosten und Vektorgrafiken zu verwenden.

6 Fazit

In diesem Beitrag haben wir uns auf die wesentlichen Veränderungen fokussiert. Eine tabellarische Sicht findet ihr im Axure Blog.
Insgesamt wurden sehr viele kleinere Anpassungen an allen möglichen Stellen vorgenommen, die die Funktionalität steigern und das zukünftige Arbeiten mit Axure erleichtern werden. Auch wenn diese Veränderungen sich nicht wie ein Quantensprung anfühlen, werden sie vermutlich einen starken Einfluss auf das effektive Bauen von Prototypen haben.
Prototypen können noch einfacher in High-Fidelity gebaut werden. Und auch die Dokumentation von Interaktionen und Elementen wird einfacher.

 
21. Juli, 2014

Rückblick: Erster „GovJam“ Hamburg – Wie Service Designer unsere Städte verbessern können

GovJam Sketch von Britta Ullrich

Trust – unter diesem Motto stand der erste GovJam in Hamburg Anfang Juni 2014. Die Aufgabe: In nur 48 Stunden sollten rund 20 Teilnehmer mit den Methoden des Design Thinking (DT) die öffentlichen Dienstleistungen der Großstadt Hamburg verbessern. eparo als Service Design Manufaktur durfte natürlich nicht fehlen. Gleich zwei Leute aus dem eparo-Team waren dabei. Unser Werkstudent Malte Lücken war begeistert und wollte unbedingt diesen Blogbeitrag schreiben. Malte erzählt, warum Hamburger einen flexiblen Reparatur-Service brauchen und wie Rentner Helmut mit seinem Repair-Mobil auf öffentlichen Plätzen zum Einsatz kommen könnte.

Global GovJam – offene Behördentüren für Service-Designer

Der GovJam Hamburg ist Teil eines weltweiten Projektes unter dem Namen Global GovJam.

Zusammen mit verschiedenen Städten erarbeiten die Teilnehmer eine neue Service-Idee, die von der Stadt weiterentwickelt werden kann. Daher steht das Gov in GovJam für Government. In diesem Jahr waren es 24 verschiedene Länder, die vom 03.06.14 – 05.06.14 gleichzeitig an Ideen zur Verbesserung des öffentlichen Raums arbeiteten.

Da wir das Projekt extrem spannend finden, nahmen Magi und ich am GovJam teil. In einer interdisziplinären Gruppe von rund 20 Teilnehmern versuchten wir die Probleme von Bürgern zu erkennen und lösende Serviceleistungen mit den Methoden des DT zu kreieren.

Ablauf eines GovJams

Illustrationen: Adrian Paulsen

Probleme der Stadt erkennen. Lösungen entwickeln

Dienstag: Abends trafen sich die Teilnehmer in den Räumlichkeiten der Xing AG, um gemeinsam Probleme des öffentlichen Raums zu finden und Teams zu bilden, die sich in den folgenden Tagen über mögliche Lösungskonzepte den Kopf zerbrechen würden. Wie kann man den Austausch von Wissen zwischen jungen und alten Menschen verbessern? Wie können wir die Entwicklung von Kreativität bei Schulkindern fördern? Meine Gruppe hatte die Aufgabe handwerkliche Arbeit wieder „sexy“ zu machen.

Mit Straßenumfragen Zielgruppen kennenlernen

Mittwoch: Morgens stand die Konkretisierung der Thematik auf dem Plan. Wir leiteten drei Fragen für eine  Benutzerbefragung unserer möglichen Zielgruppe ab und gingen dann für eine Stunde raus auf die Straße. „Was fällt Ihnen spontan zu dem Begriff Handwerk ein?“ oder „Haben Sie schon einmal selbst etwas repariert?“ – durch kurze offene Fragen versuchte meine Gruppe im Getümmel eines Radioballetts von 1000 Schülern aus 20 Hamburger Schulen (abendblatt.de/128715355) herauszufinden, ob handwerkliche Arbeit „sexy“ ist und wie die Hamburger mit Gegenständen umgehen, die kaputt gegangen sind.

Personas definieren: Der typische Hamburger hat keine Zeit – auch nicht für Reparaturen

Nach der Mittagspause analysierten wir unsere Umfragen. Schließlich hatten wir ein genaueres Bild unserer Zielgruppe, unsere so genannten Personas. Ergebnis: Hamburger würden durchaus selbst Geräte reparieren. Wenn die Bedingungen stimmen: Sie müssen wissen wie es geht, das richtige Equipment besitzen und am besten auch noch Zeit haben. Da dies selten vorkommt, werden gerade kleinere Geräte oft schnell weggeworfen. Besonders bei einer jüngeren Zielgruppe vom um die 20 Jahre kam noch der Punkt der Bequemlichkeit hinzu. „Bloß nicht zu weit weg gehen!“.

Die Idee: Der fahrende Handwerker Helmut und sein Repair-Mobil

Unter Berücksichtigung dieser Probleme folgte die Ideenfindung für einen möglichen Service. Nach mehreren Iterationen durch Diskussionen in unserer Gruppe und dem Feedback anderer Gruppenmitglieder war am Abend eine erste Idee greifbar. Zusätzlich zu den bekannten Repair Cafés (repaircafe.org/de/) überlegten wir uns einen mobilen Service. Unseren fahrenden Handwerker nannten wir Helmut, ein Rentner, der Spaß und das Know-how hat, mit anderen zusammen kaputte Geräte zu reparieren. Er fährt mit seinem Repair-Mobil zu verschiedenen belebten Punkten in der Stadt, um direkt vor Ort mit Anwohnern Geräte zu reparieren. Wem das immer noch zu weit weg ist, der kann ihn sogar zu einer Repair-Party bei sich zu Hause einladen. Einzige Voraussetzungen – es müssen mindestens 6 Leute mit kaputten Geräten kommen.

Der Prototyp aus Lego

Diese Idee wurde in den Morgenstunden des dritten Tages zu einem komprimierten Satz zusammengefasst.

Anschließend wurden Prototypen erstellt. Meine Gruppe entschied sich zum Testen einen Prototyp mit Lego zu bauen.

Mit diesem Prototyp erzählten wir mehreren Menschengruppen vor dem Gebäude der Kulturbehörde Hamburg von unserer Idee und herhielten viel positives Feedback.

Prototyp auf offener Straße testen

Fazit: Spaß trotz Zeitdruck

Am Nachmittag stellten alle Gruppen ihre Services vor und verließen den GovJam in der Hoffnung, dass die Ideen von der Stadt Hamburg gehört und umgesetzt werden.

Die drei Tage waren anstrengend, aber auch sehr inspirierend. Man konnte eine Menge neue Kontakte knüpfen und viele Methoden praktisch anwenden. Trotz des ständigen Zeitdrucks wurde viel gelacht und es hat insgesamt großen Spaß gemacht.

Aus diesem Grund wird eparo sicherlich auch das nächste Mal Hauptsponsor des GovJam Hamburg sein.

Wer mehr über den GovJam und die anderen Projekte erfahren möchte, findet unter folgender Adresse mehr Informationen: govjam.org.

 

 
20. November, 2013

Axure 7.0 | Teil 3: Variablen und Repeater

Dieser Blogbeitrag ist einer der dreiteiligen Beitragsserie zu Axure 7.0:

Nach der überarbeiteten Arbeitsoberfläche, den Adaptive Views und neuen Interaktionen schauen wir uns die etwas komplexeren Variablen und das neue Repeater-Widget an, mit denen es nun möglich ist, realistischere und komplexere Interaktionspatterns zu erstellen.

Variablen

Die Aufgabe von Variablen war bisher sehr einfach, aber auch sehr begrenzt: sie speicherten Zahlen, Buchstaben oder irgendwelche Wörter, die weiter benutzt werden sollten. Da viele komplexe Interaktionen und Ideen (beispielsweise das Berücksichtigen von Portrait- und Landscape-Modus bei Mobile Prototypen) noch nicht möglich waren, musste vieles mit Hilfe von Variablen gelöst werden.

Meistens haben wir Text-Widgets benutzt, um die Eigenschaften von einzelnen Widgets oder von Dynamic Panels wie die Größe oder die Position direkt zugreifbar und auch veränderbar zu machen. Diese Technik haben wir unter anderen auch für selbst-erstellte Widgets (Custom Widgets) genutzt. Allerdings war es immer mühselig, erst alle Eigenschaften manuell anpassen zu müssen, um schließlich ein Custom Widget benutzen zu können. Viel einfacher wäre es, wenn die Widgets selbst schlau genug wären, um z.B. ihre Größe zu kennen und Move-Befehle automatisch an diese Größe anzupassen.

Ab Axure Version 7.0 ist genau das jetzt möglich: nun können viele notwendige Eigenschaften eines Widgets automatisch ausgelesen werden. Dafür speichert man das Widget selbst als lokale Variable ab. Ähnlich wie bei [[LVAR.length]] ist nun mit [[LVAR.width]] die Breite eines Widgets und mit [[LVAR.X]] die horizontale Position eines Widgets ermittelbar. Ändert sich dann die Position oder die Größe des Widgets, muss nichts mehr angepasst werden, da die Eigenschaften automatisch bestimmbar sind. So können endlich vollständig-anpassbare Widgets mit einer vordefinierten Interaktion erstellt werden.

Bildschirmfoto 2013-10-08 um 13.19.05

Variablen-Editor

axure7-variables-browser

Bislang war der Variablen-Editor ein Mysterium für sich. Man konnte Variablen auswählen und wusste jedoch nicht, wozu man sie einsetzen konnte – oder auch wozu sie gehören. So wurden sowohl mathematische Operationen wie Addieren oder Subtrahieren mit Operationen wie [[LVAR.toFixed(decimalPoints)]] und die speziellen Variablen wie Day mit TotalDragX gnadenlos zusammen angezeigt.

Durch die Fülle an neuen Funktionen musste der Editor natürlich gründlich aufgeräumt werden. Sämtliche speziellen Variablen und Operationen werden nun durch einzelne Baum-Menüs in den verschiedenen Typen kategorisiert. So kann man sehr schnell die passende spezielle Variable oder die Operation finden, die man sucht. Zusätzlich wurde das Auswahl-Fenster mit dem aus anderen Bereichen bekannte Instant-Suche ausgestattet.

Ein Wermutstropfen: Es sind jetzt so viele Möglichkeiten geworden, dass sich der „Coder“ freut, aber der Normalsterbliche sich schnell überfordert fühlt:-(

repeatericoRepeater

Es kommt noch besser: das kalifornische Axure-Team hat der neuen Version auch noch ein neues und mächtiges Widget spendiert: den Repeater.

repeater-sketchDas Prinzip des Repeaters ist durch ein Beispiel gut zu erklären: Wenn man neue Visitenkarten für die Mitarbeiter drucken möchte, hat man meistens eine Tabelle von Informationen und ein Muster. Für jeden Mitarbeiter wird dann anhand des Musters seine persönliche Visitenkarte erstellt.

Genauso ist auch der Repeater aufgebaut: man hat für jedes Element (die Visitenkarte pro Mitarbeiter) eine Tabelle mit Informationen und ein Muster, das mit den Informationen bespeist wird.

Der Repeater ist dadurch ideal für sämtliche listenartige Inhalte. Ob eine Produktübersicht, Kontaktliste oder auch ein Dateibrowser: der Repeater beseitigt sinnloses kopieren der gleichen Inhaltsbox (die meistens als eigenes Widget angelegt wurde) und erleichtert erheblich das nachträgliche Bearbeiten durch die Maske. Außerdem unterstützt der Repeater natürlich auch die Adaptive Views: für jeden eigenen View kann man eine eigene Konfiguration und eine eigene Maske erstellen. So muss man nicht den Repeater pro View duplizieren.

repeater-interactions

Das Repeater-Widget kann aber noch deutlich mehr: natürlich konnte man auch bereits vor Axure 7.0 Listen durch kopieren der Inhalte erstellen. Der Mehrwert des Repeaters besteht aber darin, Interaktionen wie Filtern, Umsortieren oder Erweitern der Listen deutlich zu vereinfachen. Dadurch sind realitätsnahe und flexible Usability-Tests möglich.
Nicht zu vergessen: wenn ein Widget nicht kopiert, sondern – wie beim Adaptive View – einfach nur verändert wird, sind kurzfristige und sonst zeitraubende Design- und Strukturänderungen im Nu umgesetzt.

 

Weiteres

Seit unserem ersten Teil hat sich die Axure-Schmiede natürlich nicht ausgeruht und eine neue Version (ab 7.0.0.3118) veröffentlicht, die eine ziemlich lange Liste an Verbesserungen beinhaltet. Unter anderen ist der bereits vorgestellte Widget-Manager mit einer Filterfunktion ausgestattet worden, der unbenannte Widgets nicht anzeigt. Dadurch müssen nur noch wichtige und änderbare Widgets benannt werden.

Außerdem wurde die Aktion „Set Text to Widget“ erweitert, sodass nun auch Textänderungen in einem Widget durchgeführt werden können, ohne den Style zu ändern. Vor allen für den Repeater ist das wichtig, da bereits vieles im Muster über Styles vordefiniert wird.

sitemapEin weiteres zusätzliches Feature versteckt sich im Punkt „Generate Prototype“: nun können die Prototypen ohne die linke Navigationsleiste generiert werden. Des Weiteren wurde die neue Style-Eigenschaft „Line Spacing“ sowie die neue Aktion „Scroll to Widget“ hinzugefügt.

Fazit

Wir arbeiten seit zwei Monaten intensiv mit der Axure 7.0 Beta und haben natürlich noch viele Verbesserungsvorschläge. Allerdings sind wir im engen Kontakt zu den Entwicklern, sodass wir seit der Version 7.0.0.3118 bereits viele Vorschläge umgesetzt wiederfinden konnten. Das ist ein großer Pluspunkt, der wieder einmal beweist, dass das Axure-Team für die Nutzer der Software entwickeln und nicht blind oder taub gegenüber Kritik sind. Vielen Dank an dieser Stelle an die Entwickler für die gute Zusammenarbeit.

Deutlich zugenommen hat allerdings auch die Komplexität von Axure: Durch die vielen Funktionen und Möglichkeiten muss man sich erst einmal einen umfassenden Überblick über alle neuen Funktionen verschaffen. Dies erhöht natürlich die Hürde für Neueinsteiger, was allerdings durch gezielte Schulungen bewältigt werden kann.

Axure 7.0 erfüllt genau das, was zu erwarten war: das bisher bekannte Tool wurde deutlich weiterentwickelt. Und um ehrlich zu sein: wir wollen nicht wieder zurück zu Axure 6.5.

Mit Axure 7.0 ist es nun möglich bekannte, aber komplexe Interaktionspatterns einfach und modular zu erstellen. Das steigert nicht nur die Produktivität, sondern auch die Möglichkeiten in einem Usability-Test. Vor allen in Sachen Mobile Prototyping hat sich in Axure 7.0 viel getan: durch die Adaptive Views und den vielen Interaktionen und speziellen Variablen können nun deutlich besser High-Res App-Prototypen erstellt und getestet werden.

Stay tuned!

 
8. Oktober, 2013

Axure 7.0 | Teil 2: Ready for Mobile!

Dieser Blogbeitrag ist einer der dreiteiligen Beitragsserie zu Axure 7.0:

Axure 7 kann jetzt auch Apps und Responsive Websites! Wichtigste Neuerung sind die Adaptive Views, mit denen die Darstellung der Prototypeninhalte für verschiedene Displaygrößen angepasst werden kann. Vor allen für App-Prototypen sind die Adaptive Views wirklich nützlich: sie ermöglichen das Erstellen und testen einer auf das System zugeschnittenen App. Zudem ermöglicht Axure 7 mit 16 neuen Interaktionen vollkommen neue Möglichkeiten und Ideen.

Neue Apps braucht das Land: Adaptive Websites mit Axure 7.0

Adaptive Views HeaderMit dem alten Axure war bisher alles eher kompliziert und zeitintensiv. So musste man einzelne Prototypen-Seiten oder Dynamic Panels bauen und mächtig tricksen, um beispielsweise verschiedene Darstellungen für Landscape- und Portrait-Modus zu ermöglichen. Den Inhalt von Webseiten vollständig auf mobilen Endgeräten wie Smartphones anzuzeigen, war sehr schwierig. Das Resultat wäre eine unübersichtliche, ellenlange „Tapete“ an Informationen mit wenig Informationsngehalt. In der Webentwicklung wird daher auf eine angepasste Darstellung der Inhalte abhängig von der Bildschirmgröße gesetzt: je nach Breite des Bildschirmes passt sich also der Inhalt auf die Fläche an.

Seit es Axure 7 gibt, ist Schluss mit der Trickserei: durch die Funktion „Adaptive Views“ kann man auf einer einzigen Seite die Größe, den Style und die Position einzelner Widgets abhängig von der Bildschirmgröße darstellen. Dabei wird das jeweilige Widget nicht kopiert, sondern einfach nur anders dargestellt. Aber nicht nur die Darstellung der Widgets kann man verändern: man kann in einzelnen „Views“ die Widgets ausblenden, ohne das Widget selber zu löschen. So kann man den dargestellten Inhalt auf das Nötigste reduzieren.

Adaptive Views SettingsDie Adaptive Views folgen dabei einem einfachen Prinzip: man hat eine „Base“-Ansicht, die als Grundlage für die Views dient. Dann erstellt man einzelne Views, die von der Base-Ansicht die Widgets, deren Style, Position und Größe erben. Diese Views können dann wiederum so organisiert werden, dass sie untereinander ebenfalls die jeweiligen Informationen voneinander erben.

Auch wenn die Adaptive Views nicht unbedingt wie für responsive Webseiten gemacht sind, so eignen sie sich umso mehr für App-Prototypen. Durch die fest-definierbaren Breakpoints können so maßgeschneiderte Apps für iPhone und iPad konzipiert und getestet werden – ganz ohne Tricks und Kniffe.

Erweiterte Interaktionen für realitätsnahes Prototypen-Testing

Axure 7 bringt eine Menge neuer Interaktionen mit. Allein beim Dynamic Panel kann man nun bis zu 28 verschiedenen Interaktionen auswählen. So gibt es nun auch die Möglichkeit, Interaktionen wie Mausbewegungen oder Tasteneingaben zu nutzen, um Aktionen auszuführen. Damit können beispielsweise Shortcuts für Webseiten entwickelt und getestet werden.

Um eine grobe Übersicht über die Fülle der Interaktionen zu bekommen, haben wir eine tabellarische Auflistung aller möglichen Interaktionen für jedes Widget erstellt. Das wichtigste ist allerdings – wie in jedem Falle – die Übung: am besten nimmt man sich die Zeit, um jede einzelne Interaktion auszutesten. Erst dann bekommt man ein Gefühl dafür, wann eine Interaktion eingesetzt werden kann und bei welchen Stellen man sie besser vermeidet. Wir empfehlen auch, das offizielle Forum für Axure 7 zu besuchen. Dort findet man Tipps, Tricks, tolle Beispiele und viele weitere Informationen zu Axure 7.

Zwischenfazit:

Wir vermissen kein Stück die noch aktuelle Version 6.5. Im Gegenteil: die Adaptive Views und Interaktionen von Axure 7.0 sind schon Grund genug, auf die zukünftige Version der Prototypen-Software zu setzen. Dank diesen neuen Funktionen spart man zukünftig viel Zeit und kann sich auf andere Interaktionsprobleme und Lösungen konzentrieren. Letztendlich verbessert es aber auch die Ergebnisse in Usability-Tests: Dadurch, dass bisherige Tricks nun Kernfunktionen von Axure 7.0 sind, sind auch die Prototypen deutlich stabiler und sorgen somit für weniger Frust und Risiken während der Tests.
Tipp: Wir haben unsere Axure-Kurse bereits auf die Version 7.0 maßgeschneidert!

 
8. September, 2013

Axure 7.0 – Einführung | Teil 1: Grundsätzliches, Widgets und Styles

Die Freunde von Axure in Kaliformien haben wieder einen großen Schritt nach vorne gemacht: Axure RP 7.0 ist als Beta-Version verfügbar! Wir haben das neue Release unter die Lupe genommen und haben uns sehr über die Fülle von neuen Funktionen und Verbesserungen gefreut. Es gibt so viele Neuerungen, dass es zu viel für einen Blog-Beitrag ist. Daher gibt es unseren Beitrag „Neues in Axure RP 7.0“ in drei Teilen:

Teil 1: Grundsätzliches, Widgets und Styles

Vergleich zwischen Axure 6.5 RP und Axure 7 Beta

Vergleich zwischen Axure 6.5 RP und Axure 7 Beta

Ein wenig iOS7, ein wenig Windows 8: die Axure 7 Beta überrascht mit einer eigenen „flachen“ Design-Note und schafft doch die Kurve für versierte Nutzer. Die meisten bekannten Elemente finden sich auf ihren üblichen Platz wieder, was den Einstieg in die neue Version deutlich vereinfacht.

Widget Properties and Style FensterEiniges wurde jedoch umstrukturiert und umsortiert: Das Fenster „Widget-Properties and Style“ beinhaltet nun sämtliche Einstellungsmöglichkeiten, die man bislang über einen Rechtsklick auf einem Widget angeboten bekam. (Der Rechts-Klick hat damit an Bedeutung verloren, was mir persönlich nicht so gut gefällt. Kann sein, dass sich da noch was tut. Victor von Axure will noch drüber nachdenken, ob er nicht doch auch wieder mehr Funktionen über den Rechts-Klick verfügbar macht. Mal sehen…)

Außerdem ist der „Dynamic Panel Manager“ den Umstrukturierungen zum Opfer gefallen und wurde vom neuen, deutlich besseren Widget-Manager ersetzt. Hier finden sich jetzt ALLE verwendeten Widgets wieder!

Der Widget-Manager

Bisher war es ziemlich mühsam bei vielen Widgets ein Widget wiederzufinden oder zu markieren, wenn es unter anderen Elementen versteckt im Hintergrund lag. Der Widget-Manager schafft nun Abhilfe: genauso wie der Ebenenmanager in Photoshop sind nun alle Widgets in der Reihenfolge aufgelistet, wie sie auch im Wireframe angezeigt werden. So kann schnell die Reihenfolge von mehreren Elementen verändert werden. Ein wichtiges Feature!
Doch Vorsicht: anders als bei Photoshop ist das unterste Element als erstes Element in der Liste angeordnet.

Preview

Preview-funktionWie oft musste ich in der Vergangenheit einen Prototypen neu generieren, um mir Veränderungen anzusehen? Das hat immens viel Zeit gekostet und ich habe mir immer gewünscht, eine Art Live-Preview zu haben.  Die Preview-Funktion macht (fast) genau das: man vollzieht eine Änderung in Axure 7 und aktualisiert einfach den Browser statt den Prototypen (oder auch nur einzelne Seiten) ständig neu generieren zu lassen. Ein Feature, dass die Arbeitsgeschwindigkeit deutlich steigert!

Widgets können mehr!

Widget ActionsEin weiteres Thema, das mir nicht ganz klar war: warum muss man für jede Aktion, die man auf ein Widget ausführen wollte, dieses zu einem Dynamic Panel konvertieren lassen. Das hat sich scheinbar das Team aus Kalifornien ebenfalls gefragt und kurzerhand etliche Aktionen, die bislang nur mit Dynamic Panels möglich waren, für alle Widgets implementiert. Alle Aktionen wie Move, Hide und Show, Bring to Front der Dynamic Panels sind nun auch im „Case-Editor“ unter „Widgets“ einsortiert.

Widgets können aber nun noch mehr: in Windeseile können vordefinierte „Shapes“ wie einzelne Überschriften-Formatierungen oder Formen mit wenigen Klicks auf das Widget übernommen werden.

Aber das ist immer noch nicht alles: Nun können Widgets auch automatisch in der Höhe oder in ihrer Breite angepasst werden. Mit einem Rechtsklick auf das Widget der Wahl und einen Haken bei „Auto Fit Height“ und/oder „Auto Fit Width“ macht lästiges nachjustieren bei einem etwas längeren Text überflüssig.

Es hat sich außerdem etwas bei den einzelnen Widgets getan: die Höhe des Droplist-Widgets lässt sich nun endlich einstellen, Dynamic Panels können sich selbstständig ihrem Inhalt anpassen und die „Image Map Region“ heißt nun „Hot Spot“.

Neue Styles

Neue StylesOft muss ein Prototyp erstellt werden, der nicht nur das Nutzererlebnis, sondern auch das Aussehen einer Webseite oder einer App darstellen soll. Hier ist es umso wichtiger, möglichst genau das Design abzubilden. Das ging bislang auch schon ziemlich gut, mit ein paar Ausnahmen.

Es gab keine Schatten. Mit Axure 7 hat sich das erledigt. Jetzt ist ein Schatten nur wenige Klicks entfernt: in den Styles können nun innere und äußere Schatten festgelegt werden.

Abgerundete Ecken lassen sich jetzt pixelgenau einstellen. Das lästige „mit der Maus ziehen und hoffen, dass es passt…“ entfällt.

Bei Design-Prototypen kommt es allerdings nicht nur auf Schatten und abgerundete Ecken an. Die Schrift ist eines der wichtigsten Gestaltungselemente eines Interfaces und immer auch ein zentrales CI-Element (CI=Corporate Identity). Mit Axure 7 können jetzt die jeweiligen Schriften als Webfont oder als Schriftdatei direkt in den Prototypen eingebunden werden. Aber Axure 7 geht noch weiter: für Kursiv- oder Fettschriften kann nun der jeweilige Typ aus der Schriftart ausgewählt werden. Ein Feature, das selbst einem Typograf gefallen dürfte!

Styles konnten bisher nur auf Widgets angewendet werden. Bilder mussten stattdessen immer per Hand in Photoshop in ihre zukünftige Form zugeschnitten werden. In Axure 7 bekommen nun auch Bilder ihre eigenen Styles: mit abgerundeten Ecken, Schatten und Transparenzeinstellungen sind händische Anpassungen der Bilder nicht mehr notwendig. Tipp: um kreisrunde Bilder zu erstellen, sollten diese idealerweise quadratisch vorliegen. Sonst muss per „Crop“ oder „Slice“ nachgeholfen werden.

CropApropos „Crop“: das ist ebenfalls eine neue Funktion, die das relativ unflexible „slicen“ eines Bildausschnittes unnötig macht. Aber Vorsicht: genau wie das „slicen“ wird das Bild beschnitten. Hier gehört oftmals viel Sorgfalt dazu.

Ein Beispiel

Wetter-Icon BeispielIn Sachen Styles und Widgets hat sich also so einiges bei Axure getan. Wir haben ein wenig mit den Funktionen gespielt und das Wetter-Icon aus iOS7 samt App-Icon Raster erstellt. Durch Axure 7 war es ein Kinderspiel, die einzelnen Widgets anzuordnen. Auch der Schatten hat uns überzeugt, denn er ist furchtbar-einfach umzusetzen. Viel Spaß damit!

 

 
11. März, 2013

UX-Roundtable bei eparo: Das Unterbewusstsein zum Verbündeten machen…

Unbewusste Wahrnehmung, Neuromarketing und das Implizite sind die Hebel, um wirklich erfolgreiche digitale Produkte zu entwickeln. Das wollten wir im Rahmen des UX Roundtables in Hamburg am 4. März vermitteln. Konkreter: Wie funktioniert menschliche Wahrnehmung und wie kann ich das bei der Konzeption und Gestaltung optimal berücksichtigen?

Neurodesign und Implicit UX stoßen auf reges Interesse.

Viele Zuhörer beim UX-Roundtable

Viele Zuhörer beim UX-Roundtable

Intuitive Bedienbarkeit ohne Nachdenken zu müssen: Die Messlatte für wirklich gute digitale Produkte und Services liegt inzwischen schon ziemlich hoch. Intuitives Handeln geht natürlich nur über das Unterbewusstsein. Begriffe wie Neuromarketing und Neurodesign rücken daher als Themen ins Visier von Produktmanagern und UX-Designern.

Das wurde auch bei den Anmeldungen zum UX-Roundtable schnell deutlich. Ursprünglich sind wir von 40 Teilnehmern ausgegangen. Dann mussten wir die Zahl aufgrund immer neuer Anfragen fast im Zwei-Stunden-Takt auf schließlich 100 Teilnehmer erhöhen und einen guten Schwung Stühle mieten. Mit den üblichen Absagen waren am Schluss über 80 Gäste bei uns im Büro. Die Weinprobe von copito, dem Weingroßhändler bei uns im Gebäude, hatte da nichts mit zu tun. Das stand nicht in der Einladung :-)

Wir haben uns jedenfalls sehr gefreut über den bisher größten UX-Roundtable. An dieser Stelle daher nochmals vielen Dank für dieses enorme Interesse!

Hier die Slides zum Vortrag auf slideshare.com
Mehr zum Thema Implicit-UX gibt’s regelmäßig auf 53nord.de
Und der von Matthias Müller-Prove (@mprove) mitgeschnittene Ton im UX-HH Roundtable-Archiv

Implicit UX macht das Unterbewusstsein zum Verbündeten.

Im Kern ging es in meinem Vortrag „Unbewusste Wahrnehmung – Der vergessene Supercomputer“ um die Rolle des Unterbewusstseins für gute digitale Produkte und Services. Das Credo: Wirklich erfolgreiches UX-Design muss die unbewusste Wahrnehmung und die Erkenntnisse aus Neuromarketing und Implicit UX berücksichtigen. Neben vielen Beispielen aus der Forschung standen praktische Tipps für Konzeption und Design im Zentrum des Vortrags. Nach dem Vortrag gab es dann Wein von unserem Büronachbarn copito (www.copito.de) und noch sehr spannende Gespräche. Das Fazit dabei: Das Wissen um die menschliche Wahrnehmung ist die Grundvoraussetzung, um wirklich gute User Experience zu schaffen.

Zum Schluss: Das machen wir jetzt öfter!
Unser Fazit: Wir freuen uns noch immer über das Interesse an unserem Thema und denken, dass so ein Abend eigentlich die perfekte Nutzungsweise für unseren großen Flur ist. Bald feiern wir den Relaunch unseres benachbarten Weinhändlers. Das ist dann wieder eine schöne Gelegenheit für ein paar nette Gespräche und Gedanken – nicht nur zu Neuromarketing und Implicit UX. Einladung folgt.

folie33

Nutzer sind wie Elefanten: Unbeirrbar zielorientiert

 
10. Januar, 2013

Zweitbeste iPad-App Deutschlands – Viel Lob für die Immonet-App

Es ist ja erst knapp drei Wochen her, dass Apple die Immonet iPad-App, an der eparo mitgewirkt hat, zur zweitbesten iPad-App des Jahres 2012 gekürt hat. Neben der Auszeichnung von Apple hat die Anwendung auch von anderer Seite bereits viel Lob erhalten. Einige Stimmen wollen wir hier wiedergeben:

Immonet iPad-App

Immonet iPad-App

Das Apple Team selber begründet seine Entscheidung wie folgt:

„Mit dieser intuitiven und intelligent umgesetzten Immobilien-App lassen sich die gewünschten Objekte schnell finden. Merk- und Favoritenlisten ganz einfach verwalten und vieles mehr.“

Für die Chip setzt die App neue Maßstäbe in der Immobiliensuche:

„Alles richtig gemacht, Immonet: Mit einer App wie dieser macht die Immobiliensuche auf dem iPad richtig Spaß. Wir stellen den PC beiseite und suchen Wohnungen nur noch mit dieser App.“

Computerbild lobt insbesondere das völlig neuartige Bedienkonzept:

„Mit der Immonet-App machen die virtuellen Besichtigungen richtig Spaß. Dafür sorgt die außergewöhnliche Bedienung, die die Funktionalität des iPad-Touchscreens nutzt.“

Was unseren Part angeht sagen wir Danke für so viel Lob – und versprechen, dass wir gerne mit weiteren Projekten nachlegen ;)

 
15. Dezember, 2012

Eine wie keine – Die eparo App-Entwicklung für Immonet

App-Entwicklung kann man gut machen – aber man kann Apps auch irgendwie großartig machen. So jedenfalls sollte es sein, und so ist das mit der Immonet iPad-App – ein UXD-Projekt par excellence, mit toller Zusammenarbeit und einem perfekten Ergebnis. Das jedenfalls ist der Tenor der Weave (03/12), die über das Projekt berichtet hat. Und weil wir uns darüber ebenso freuen, wie über das Projekt-Ergebnis selber, will ich den Artikel zum Anlass nehmen, und einfach auch nochmal über das Projekt und die Unterstüzung durch eparo für Immonet berichten…

Immonet iPad-App

Immonet iPad-App

Alles auf Anfang – Die Suche nach einer Produktidee

Im Grunde bringt es Ralf von Immonet im Weave-Artikel selber direkt auf den Punkt: Ideen für Features und Funktionen der neuen iPad-App hatte das Immonet-Team genug. Was fehlte, waren „eine tragende Produktidee und ein Leitgedanke in der Anwendung“, so Ralf. Was die Anwendung noch brauchte, als Ralf mit seinem Team zu eparo kam, waren ein stringenter Blick auf die Nutzer und eine Antwort auf die Frage, wann eine App jemandem, der eine Wohnung sucht, wirklich hilft. Wir haben uns im gemeinsamen Workshop mit Immonet also gefragt: Was muss die App zur Wohnungssuche leisten, um das Suchen zu verbessern – und nicht die Darstellung der Angebote.

„Sie kamen, um zu testen – und fingen nochmal ganz von vorne an“ – Lena in ihrem Artikel in der Weave

Faktisch haben wir uns mit den Kollegen von Immonet dann erst einmal zwei Tage eingeschlossen. Auf unzähligen Post-It’s haben wir unsere Aufgabe durchdekliniert und uns gefragt, wie das Suchen einer Wohnung real abläuft. Dabei haben wir Personas und Nutzungsszenarien entwickelt, Ideen jongliert, Skizzen erstellt – und am Ende eine neue und überzeugende Antwort auf unsere Frage gefunden: Wer Wohnraum sucht, macht sich Notizen. „Dieses Angebot ist interessant, dieses nicht, …“. Die Idee: Die Immonet iPad-App soll diesen Schmierzettel ersetzen, und die komplette Idee der Wohnungssuche digital abbilden.

Die App-Idee – Der digitale Schmierzettel zur Wohnungssuche

Was heißt das konkret? Was der Weave-Artikel sehr schön deutlich macht, finde ich, ist unser Verständnis davon, was es bedeutet, eine solche Grundidee für eine Anwendung zu finden und stringent umzusetzen. Denn was macht so ein Schmierzettel eigentlich? Wozu wird er genutzt? Die einfache Antwort: Er fasst zusammen und sortiert. Denn natürlich geht es bei der Wohnungssuche am Ende nicht darum, die Vielzahl der möglichen Angebote zu überblicken, sondern darum, das Angebot auf die passende(n) Wohnung(en) zu reduzieren. Auf dem Schmierzettel notieren wir alle wichtigen Informationen, tragen Zeiten und Termine für eine Besichtigung ein und streichen am Ende durch, was uns nicht (mehr) interessiert.

Die Kraft eines bewährten GUI-Prinzips: Make it physical

In der App sollte es genauso sein! Auch in der App sollten Nutzer eigene Notizen sowie Photos zu Wohnungen anlegen und Besichtigungstermine eintragen können, die sich dann direkt mit ihrem Kalender synchronisieren. Und vor allem: Einmal aussortierte Wohnungen tauchen nicht wieder in der Suche auf – es sei denn, der Nutzer fischt aus dem Stapel der aussortierten Angebote wieder hervor. Aber es gibt noch mehr…

Lob zuhauf: „Ein konkurrenzlos userfreundliches Feature mit neuen Kundenbindungseffekten“

Wer je umgezogen ist, kennt das: Man sitzt am Tisch vor seiner Karte, kreist mit dem Stift in der Hand über der Stadt und sucht sein liebstes Wohngebiet: „Hier wäre super, oder hier, oder hier: direkt am Hafen, …“ . Hier ist quasi die Karte der Notizzettel, auf dem wir unsere Suchgebiete markieren – und genau das wollten wir auch für die App: Auf der Karte kann der Nutzer mit dem Finger das Gebiet seines Interesses einkreisen und bekommt unabhängig von Postleitzahlen oder Stadtgebieten, die zu seiner Anfrage passenden Angebote in seinem Suchfeld angezeigt. Passt perfekt zum touch-basierten Bedien-Konzept des iPads – und wer schon unterwegs ist, kann sich seinen Standort in der Karte einblenden lassen und gleich auch den besten Weg zur neuen Wohnung finden.

eparo Prototyp zur Immonet iPad-App

eparo Prototyp zur Immonet iPad-App

Die Feuertaufe – Höchstnoten im Nutzertest

Um zu sehen, ob die User unsere Ideen denn auch wirklich gebrauchen können und wirklich haben wollen, haben wir natürlich intensiv getestet. Weil wir mit so ziemlich allen Features Neuland betreten haben und dazu belastbare Ergebnisse wollten, haben wir die App zunächst als detaillierten Prototypen aufgesetzt. Das hat uns – mal aus dem Nähkästchen gesprochen – dann schon auch einiges an Prototyping-Know-How gekostet…

„Cool! Wann kann ich das nutzen?“ – Die Probanden-Höchstnote im Nutzer-Test

Die User Experience-Tests waren dann aber ein großartiger Beleg für das neue App-Konzept: Alle Probanden haben die Kernidee ganz intuitiv verstanden und sie begeistert aufgenommen. Gleichzeitig konnten wir aus den Tests natürlich wichtige Hinweise sammeln, um die entwickelte Produktidee noch weiter zu schärfen. Funktioniert hat das, weil wir exakt passende Probanden im Test hatten – dass aussortierte Wohnungen nicht wieder auftauchen sollten, zum Beispiel, ist ein Ergebnis der Tests.

Das Ergebnis – Ein Produkt ohne Vergleich, und stetig steigende Nutzerzahlen

Die Weave schreibt: „Eine Geschichte vom Nutzen frühzeitiger UX-Tests und iPad-gerechter App-Konzeption“ und fasst das Projekt damit schon ganz gut zusammen. Die wichtigsten Tips zum Nachahmen haben wir dann für den Artikel gleich noch mit zusammengestellt (10 Tips zur Entwicklung erfolgreicher digitaler Produkte). Zur Geschichte gehört dabei auch, dass auch das beste Konzept nur überzeugen kann, wenn auch eine starke Umsetzung erfolgt. Das Immonet Mobile Team hat hier großartig gearbeitet. Am Ende ist es aber natürlich wie immer: Man muss die App sehen und benutzen, um sie wirklich zu erleben – und wenn das nicht so wäre, hätten wir (Immonet und eparo) unseren Job ja auch irgendwie doch nicht so gut gemacht…

Weave-Artikel zur Immonet_iPad-App-Entwicklung

 

 
11. Mai, 2012

Gute und bessere Prototypen: High-Fi versus Low-Fi

Was sind gut Prototypen – und was macht sie noch besser? Zwei grundlegende Varianten lassen sich unterscheiden – und für belastbare User Experience Tests jeweils unterschiedlich einsetzen. In einem grundlegenden Beitrag stellen wir die wesentlichen Merkmale und Differenzierungen zwischen Prototypen vor und schildern, wie wir sie bei eparo einsetzen und für die Weiterentwicklung digitaler Produkte nutzen.

Prototyp für die KfW-Gruppe

eparo Prototyp für die KfW

Prototyp für die Techniker Krankenkasse

eparo Prototyp für die Techniker Krankenkasse

Prototypen: Halb fertig und schon aussagefähig

Zunächst mal ganz allgemein: Prototypen, so die Standarddefinition, sind Vorab-Exemplare von Produkten – so kurz, so einfach. Sie dienen dem Zweck, Eigenschaften oder Funktionen, die das finale Produkt haben soll, bereits in der Entwicklungsphase ausprobieren, testen und bewerten zu können. Prototypen sind demnach per  Definition nie fertig – und es stellt sich schnell die Frage, wie aussagekräftig beispielsweise die Bewertung einer Funktion oder eines Designentwurfs auf der Basis solcher halbfertigen Entwicklungsmodelle ist?

Prototypen sind im Grunde nie fertig – aber immer fertig genug, um präzise Ergebnisse zu liefern

Die grundsätzliche Antwort ist natürlich einfach. Die erste Grundbedingung für jedes Prototyping lautet: Selbst einfachste Prototypen liefern präzise Ergebnisse, wenn sie nur die Funktion, die es zu beurteilen gilt, hinreichend genau abbilden. Wichtig ist mithin nicht, dass ein Prototyp als Ganzes möglichst fertig ist, sondern lediglich, dass er in den Bereichen, die aktuell beurteilt werden sollen, detailliert genug ausgearbeitet ist, um allen Testparametern begegnen zu können.

High- und Low-Fidelity: Prototypen jeder Detailschärfe

Der Umkehrschluss heißt natürlich: Je differenzierter die Fragestellung ist, desto detaillierter muss auch der Prototyp ausgearbeitet sein. Das Fachchinesisch unterscheidet dazu zwischen High-Fidelity- und Low-Fidelity-Prototypen. Je genauer ein Prototyp die Funktionen oder Eigenschaften, die bewertet werden sollen, abbildet, desto High-Fi – und umgekehrt. Typische Low-Fi-Prototypen umreißen die Funktionen oder Eigenschaften, die bewertet werden sollen, dabei vor allem strukturell und spezifizieren deren Handhabe nur rudimentär: Hier steht dies, dort das, ein Klick hierhin führt dorthin, verändert das und das und so weiter. Auf eine elaborierte Optik wird meist ebenso verzichtet wie auf die vollständige Abbildung der Interaktionsmuster. Stellt ein Prototyp auch die (mehr oder weniger) finale Gestaltung dar und werden die Interkationsverläufe voll ausgearbeitete, indem immer mehr Bedienschritte spezifiziert werden, wird ein Prototyp immer mehr High-Fi – bis er am Ende das finale Produkt nahezu komplett abbildet.

Der Königsweg zu besseren digitalen Produkten, ist sauberes Prototyping über mehrere Detailstufen hinweg

>> Prototyping von eparo unter www.eparo.de.

Je nach Projekt- und Problemlage sind Prototypen unterschiedlicher Detailschärfe sinnvoll. Ideal ist es, wenn Prototyping bereits von Beginn an und dann kontinuierlich in den Entwicklungsprozesse mit einbezogen wird. Prototypen werden dann schon in einem sehr frühen Stadium der Produktentwicklung erstellt und getestet und es werden die Ergebnisse direkt in die Weiterentwicklung des Produktes eingespielt. Das Muster ähnelt der agilen Softwareentwicklung. Zusätzlich zu einer  funktionalen Bewertung, die primär die Interaktionsmuster und Navigationsstrukturen betrachtet, können dabei auch schon am Prototypen das Erleben und die Anmutung des entstehenden Produktes sehr früh beurteilt werden. Prototyping wird damit nicht nur zu einer zentralen Methode der digitalen Produktentwicklung, sondern auch des Marketings allgemein.

Prototypen Sketch

Prototypen Sketch

Test High-Fidelity Prototyp

Test High-Fidelity Prototyp

Wesentliche Merkmale von Low- und High-Fi-Prototypen

Hier die wesentlichen Merkmale von Low- und High-Fi Prototypen für Web und Software, aber auch für iPhone- und iPad-Anwendungen einmal konkret zusammengefasst:

Low-Fi-Prototypen:
  • rein strukturelle Umsetzung, Verzicht auf Optik/Gestaltung
  • Dummy-Bilder, Platzhalter-Texte
  • reduzierte Interaktionslogik: primär testrelevante Features
  • Zwischenschritte/-screens als Dummies nicht ausgearbeitet
  • keine Effekte oder dynamischen Elemente
  • keine Perspektive auf Look & Feel, Brand-Experience
High-Fi-Prototypen:
  • differenzierte Interaktionslogik: mehrere Ebenen, Nebenpfade, Navigation, …
  • detaillierte optische Ausarbeitung/Gestaltung
  • Originalbilder und -texte
  • ausgearbeitete Einzelschritte und -seiten
  • Effekte und dynamische Elemente
  • Look & Feel und Brand Experience umgesetzt

Zwischen beiden Extremen sind dann natürlich sämtliche Zwischenstufen möglich.

Und am Ende: Prototypen im richtigen Text

Wie gesagt: Prototypen werden erstellt, um Funktionen und Erleben von Produkten (und Produktversionen) zu testen. Ebenso wichtig wie der Prototyp ist für den Erfolg jedes Prototyping-Projekts mithin das Testing. Denn ebenso wie der Prototyp entscheidet auch die Qualität des Tests, dem er unterzogen wird, direkt mit über die Belastbarkeit und Güte der Ergebnisse. Besonderes Augenmerk richten wir bei eparo daher auf sorgfältig ausgewählte Probanden, erfahrene Testleiter und detailliert ausgearbeitete Usecases, um alle relevanten Nutzungsszenarien realistisch nachbilden und bewerten zu können.

Findet Prototyping erst zu einem bereits späten Zeitpunkt der Produktentwicklung statt, hat sich in diesem Sinn ein mindestens zweistufiges Vorgehen bei eparo etabliert, bei dem wir zunächst einen schon recht weit ausgearbeiteten Prototypen testen. Dieser zeigt bereits die finale Optik, kennt wesentliche Effekte und zeigt alle für den Test relevanten Interaktionsmuster bereits vollständig an. Elemente und Features, die zum Look & Feel oder zur Brand Experience beitragen, die aber nicht testrelevant sind, setzen wir im Prototypen hingegen als Low-Fi-Elemente um. Anschließend arbeiten wir die Ergebnisse des Tests nochmals in den Prototypen ein und testen diese vor dem Produkt-Launch erneut ab.

Ein ganz wesentlicher Vorteil von Prototypen-Tests liegt dabei schließlich darin, dass solche Tests nachgerade jeder UX-relevante Testmethode erlauben. So lassen sich Prototypen beispielsweise ebenso problemlos qualitativ befragen wie wir sie auch quantitativ bewerten lassen können. Entscheidend ist, dass das Testdesign darauf ausgelegt ist, die Testpersonen sicher und zielgenau auf die Usecases zuzusteuern, die analysiert werden sollen. Und das wiederum heißt am Ende, dass auf Seiten der Testleiter und Beobachter Erfahrung im Design von Prototyping-Tests unerlässlich ist.