Dienstag, 22. August 2006
Thema: Informationsarchitektur
Bei Spirit Link habe ich gelernt, Wireframes (auch Funktionale Layouts) für die Konzeption zu nutzen und habe großartige Erfahrungen in der Kombination mit Use-Cases gemacht.
Wireframes sind schematische Abbildungen von Screens, die Funktion und Information, vom Design jedoch nur die Anordnung enthalten (keine Abstände, nur ungefähre Größenverhältnisse, keine Farben und gestalteten Icons). Sie dienen dazu, die benötigte Funktion und Information auf Screens aufzuteilen und nutzbar zu machen. Siehe auch in Wikipedia.
Ich erstelle Use-Cases, um mir einen Benutzungs-Ablauf und die benötigte Information zu überlegen. Der Use-Case zwingt mich, das Ziel des Benutzers und seinen Weg durch die Applikation zu formulieren.
Parallel dazu beginne ich damit, Wireframes für den Use-Case zu zeichnen. Die Wireframes zwingen mich, alle Benutzungs-Eventualitäten zu bedenken.
In Kombination decken sie die funktionalen Anforderungen ab.
Die Wireframes ermöglichen zudem (natürlich), die Usability zu optimieren. Häufig erkenne ich anhand eines Wireframes zusätzliche nützliche Funktionalität, die ich dann im Use-Case ergänze. Der Use-Case sichert dann die Vollständigkeit und Konsistenz der Funktionalität. Iterativ beleuchte ich so verschiedene Aspekte und optimiere so das Konzept.
Ich habe außerdem festgestellt, dass jeder Kunde eines der beiden bevorzugt. Einige Kunden sprechen lieber über formulierte Anforderungen / Use-Cases. Viele Kunden bevorzugen Wireframes, anhand derer sie die Abläufe des Systems leicht nachvollziehen können.
Die Entwickler benötigen beides, um das System umzusetzen.
Wireframes eignen sich ausschließlich für Funktionalität, die an der Oberfläche sichtbar ist. Algorithmen und Constraints sind nur im Use-Case dokumentiert.
Besteht ein System nur aus Algorithmen und kommuniziert nur mit Systemen, eignen sich Wireframes natürlich nicht. Bei Spirit Link sind praktisch alle Projekte für menschliche Anwender, die häufig über keinen Informatik-Background besitzen. Der Usability-Aspekt ist hier natürlich doppelt interessant.
Wireframes sind schematische Abbildungen von Screens, die Funktion und Information, vom Design jedoch nur die Anordnung enthalten (keine Abstände, nur ungefähre Größenverhältnisse, keine Farben und gestalteten Icons). Sie dienen dazu, die benötigte Funktion und Information auf Screens aufzuteilen und nutzbar zu machen. Siehe auch in Wikipedia.
Ich erstelle Use-Cases, um mir einen Benutzungs-Ablauf und die benötigte Information zu überlegen. Der Use-Case zwingt mich, das Ziel des Benutzers und seinen Weg durch die Applikation zu formulieren.
Parallel dazu beginne ich damit, Wireframes für den Use-Case zu zeichnen. Die Wireframes zwingen mich, alle Benutzungs-Eventualitäten zu bedenken.
In Kombination decken sie die funktionalen Anforderungen ab.
Die Wireframes ermöglichen zudem (natürlich), die Usability zu optimieren. Häufig erkenne ich anhand eines Wireframes zusätzliche nützliche Funktionalität, die ich dann im Use-Case ergänze. Der Use-Case sichert dann die Vollständigkeit und Konsistenz der Funktionalität. Iterativ beleuchte ich so verschiedene Aspekte und optimiere so das Konzept.
Ich habe außerdem festgestellt, dass jeder Kunde eines der beiden bevorzugt. Einige Kunden sprechen lieber über formulierte Anforderungen / Use-Cases. Viele Kunden bevorzugen Wireframes, anhand derer sie die Abläufe des Systems leicht nachvollziehen können.
Die Entwickler benötigen beides, um das System umzusetzen.
Wireframes eignen sich ausschließlich für Funktionalität, die an der Oberfläche sichtbar ist. Algorithmen und Constraints sind nur im Use-Case dokumentiert.
Besteht ein System nur aus Algorithmen und kommuniziert nur mit Systemen, eignen sich Wireframes natürlich nicht. Bei Spirit Link sind praktisch alle Projekte für menschliche Anwender, die häufig über keinen Informatik-Background besitzen. Der Usability-Aspekt ist hier natürlich doppelt interessant.
... kommentieren