Axure Prototyping – Verwendung von Notizen

Dokumentieren von Intentionen und Ideen.

Axure bietet von Haus aus die Möglichkeit Notizen zu einer Seite zu hinterlegen und zusätzliche Notizfelder anzulegen. Axure Notizen werden oft vergessen, da sie für die funktion des Klickdummies unwichtig sind und in der Programmoberfläche auch nicht sofort angezeigt werden. Jedoch entfalten sie wenn sie richtig und konsequent gepflegt werden ihre volle Wirkung und sind im Gegenteil zu manch anderem Feature von Axure auch in Projekten sinnvoll, in denen nur ein Einzelner an einem Projekt arbeitet – wer erinnert sich schließlich nach 3 Monaten noch was er sich bei der Gestaltung einer Seite im Detail gedacht hat?

Projektnotizen sind also eine Form der „Vor-Ort“ (In-Place) Dokumentation, ähnlich wie Kommentare im Quellcode für einen Entwickler.

Damit man die Notizfunktion optimal nutzen kann, bietet es sich an mit fogenden Feldern zu arbeiten:

  • Seitenintention / erwünschtes Nutzerverhalten
  • Konversionsgründe / -anreize
  • Konversionshemnisse/-hindernisse
  • Verbesserungspotenzial

Zusätzlich nutze ich noch gerne folgende Felder – welche ich jedoch nicht als zwingend erforderlich sehe:

  • Zielversion / Umsetzung in
  • Mobiles Verhalten

Wie aus dem Screenshot zu ersehen ist, leiten die Notizfelder den Fokus auf die richtigen Fragen, die man sich bei der Seitengestaltung fragen stellen sollte, und greift somit Kerngedanken der Usability (was soll passieren, wie soll es passieren, was kann schiefgehen) auf und führt sie den Planer in Form von Eingabefeldern wieder vor Augen. Somit bleibt der Fokus immer auf den essenziellen Informationen hinter dem jeweiligen Oberflächendesign.

Ziel der Notizfelder ist es also zum einen dazu geeignet die Metainformationen und Kriterien, welche zur Erstellung einer Seite beigetragen haben zu bündeln und abzufragen, als auch die Informationsfülle zu unterteilen. Die Unterteilung in einzelne themenbezogenen Notizen, hilft zudem die Schreibbarriere zu brechen und klarer zu vermitteln, was gefordert ist. Ein einzelnes Notizfeld schreckt entweder ab, oder lädt dazu ein alles mögliche dort „abzuladen“.

Notizen an den Elementen – wofür?

Zusätzlich zu Seitennotizen bietet Axure die Möglichkeit direkt an Elementen Notizfelder zu verwenden. Dies ist besonders sinnvoll, um elementspezifische Eigenschaften festzuhalten. Beispiele hierfür wären:

  • CMS-Angaben
  • Angaben zu alternativen Designs (bspw.: Kachel ohne Icon)
  • Informationen zu möglichen Verbesserungen (Bsp.: Button Primärfarbe, bekommt Mouse-Over-Effekt in invertierter Farbgebung)

Um die Übersicht am Element zu gewährleisten und beim Export besser steuern zu können, welche Informationen verwendet werden, können die Notizen noch gruppiert werden in sogenannten „Sets“.

Ich benutze dabei gerne ein Set namens Planung, welches aus den Feldern Alternativen und Verbesserungen besteht.

Tipp:

Notizen können während des Exportvorgangs von Axure (HTML, Word) auch ausgeschlossen werden. Somit werden kritische Informationen ausgeblendet und bleiben zum Beispiel bei einer Kundenpräsentation oder bei Bereitstellung von Wireframes auf einem internen Webserver, dem fachfremden Betrachter, verborgen.

Axure Widget Library – Checkliste für neue Widgets

Im nachfolgenden wird der Begriff Widget und Komponente synonym verwendet.

Die folgende Checkliste dient zur Qualitätssicherung von zentralen Widgets in einer Axure Widget Library. Insbesondere wenn diese Library von mehreren Personen gepflegt wird, entstehen oft unterschiedliche Ausbaustände in der Endversion. Meist erfüllen alle Widgets ihren Zweck und Verhalten sich wie gewünscht, jedoch gibt es einige Kniffe, die wenn beachtet den Kollegen einige Zeit und Frust bei der Verwendung der Widgets ersparen.

Mit diesem Hintergrund ist folgende Checkliste entstanden.

Folgende Punkte sollten erfüllt sein, bevor eine Komponente in einer Axure Widget Library freigegeben ist.

  • Eine Komponente hat einen eindeutigen und sprechenden Namen
  • Eine Komponente ist einer beschreibenden Gruppe zugeordnet (Beispiele: Basiselemente, funktionale Elemente, zusammengesetzte Komponenten)
  • Alle Elemente der Komponente sind zusammen gruppiert, die Gruppe ist gleichnamig zum Widget. Diese Maßnahme erleichtert es im späteren Projekt das Widget/die Komponente wiederzufinden bzw. zu suchen. Gleichzeitig bleiben die zusammengehörigen Elemente gruppiert und es entsteht kein „Salat“ aus Bausteinen, welche auf der Projekt-Prototypenseite zusammengewürfelt sind. Besteht das Widget aus einem dynamischen Panel, so ist das dynamische Panel trotzdem zu gruppieren.
Beispiel für eine Gruppierung
Axure Elemente sind gruppiert und die Gruppierung ist gleichnamig zur Komponente.
  • Die Komponente ist in sich funktional –  bei einer Auswahlliste (Dropdown) klappt zum Beispiel die Liste aus wenn auf das Icon für „Erweitern“ gedrückt wird und verschwindet wieder wenn das Icon für „Zusammenklappen“ gedrückt wird.
  • Alle Elemente des Widgets sind sauber benannt.
  • Das Widget verwendet nach Möglichkeit nur die eigenen Styles (bspw.: „IF_Icon Farbe Füllung„) oder eigens für das Widget definierte Styles (bspw.: „Dropdown Iconfarbe„). Dies ermöglicht es später in Projekten Farbänderungen einfacher umzusetzen und genau abzugrenzen.
  • Das Widget hat alle adaptiven Ansichten definiert, sofern dieses Feature verwendet wird. Widgets, die in einer bestimmten Ansicht keinen Sinn machen, werden aus der entsprechenden Ansicht gelöscht. Das Fehlen der mobilen Variante wird in der Seitennotiz „Mobiles Verhalten“ begründet und vermerkt, ebenso wie andere Verhaltensänderungen.
Die mobile Ansicht ist durch eine Notiz erklärt.
  • Das Widget verwendet keine globalen Variablen.
  • Es ist ein Icon hinterlegt für beide Icon-Felder (28 x 28 px & 56 x 56 px)
  • Die Check In-Notiz enthält eine explizite Auflistung aller erstellten Komponenten (eigene Sektion innerhalb der Nachricht).
Erstellt:
#Drowdown 1/1
#Dropdown 1/3
im Rahmen von TICKET-123.
----
Verändert:
..
....
----
Gelöscht:
....

Eine ähnliche Form dieser Checkliste verwenden wir um im Rahmen des Prototypings von Oberflächen, um zu gewährleisten, dass alle Widgets grundlegende Standards einhalten, was das Arbeiten deutlich vereinfacht. Da die Komponenten einer zentralen Komponentenbibliothek jedoch in vielen Projekten zum Einsatz kommen, ist es wichtig diese Standards zu forcieren, um das Arbeiten mit diesen Widgets erheblich zu vereinfachen und nacharbeiten zu verringern.
Jeder Planer kann sich somit sicher sein, dass wenn er beispielsweise die zum Widget hinterlegten Styles bearbeitet, er auch wirklich nur für diese Widgets Farb-/Stilanpassungen vornimmt. Würde das Widget beispielsweise Axure Default-Styles (Box1, Linie, …) verwenden, so könnte eine Farbänderung in allen möglichen Komponenten seines Projektes „durchschlagen“, was unnötige Nacharbeiten nach sich ziehen könnte.

Durch die Bereitstellung und Abarbeitung dieser Checkliste wird geholfen, diesen Mindeststandard zu dokumentieren und nachzuhalten.