Ist die Überplanung von Wireframing?

Question

37 Signal Getting Real überzeugte mich, dass wireframing und das Schreiben von funktionalen Spezifikationen Dokumente sind Vermittler Schritte unnötig für den Aufbau von Web-Anwendungen und dynamische Websites.

Ist der Overhead für diese Schritte sein Gewicht wert? Ist das Prototyping in HTML/CSS oder sogar in PhotoShop-Dokumenten (damit Designer direkt an ihnen arbeiten können) eine bessere Option als die Verwendung von Software wie Visio? Persönlich schwanke ich zu Letzterem, bin mir aber nicht sicher.

Answer 1

"Nicht planen ist Plan zu scheitern" - oder so ähnlich.

Wireframing ist nicht auf Web-Apps beschränkt; Es wird überall dort eingesetzt, wo ein umfassender Überblick über ein System benötigt wird (es wird nur etwas anderes genannt).

Funktionelle Spezifikationen, wenn Sie wissen, was zu tun ist &, wie es in der Tat wäre Overkill. Ein hohes Diagramm Ihrer Absichten würde ausreichen. Und es wird nie unnötig sein. Es hilft Ihnen hauptsächlich, sich auf den Umfang und die Absicht/das Ziel dessen zu konzentrieren, was Sie tun möchten.

Der Fokus sollte auf der Vermeidung von verschwendeten Anstrengungen liegen - es ist nicht das, was Sie entdecken wollen, wenn Sie etwas Wesentliches herausfinden, das Auswirkungen auf alle anderen Objekte hat. Wireframing würde in diesem Fall helfen, die wichtigsten funktionellen Bedürfnisse zu erkennen. Sie müssten nur auf funktionelle Spezifikationen eingehen, wo absolut notwendig. Mit Photoshop zu entwerfen, Ihr Wille auch "verschwendete Anstrengung" - viel besser, evolutionäre Prototyping (RAD-Technik) mit CSS/HTML zu verwenden - aber immer noch Stift & Papier Mock-up Ihrer Absichten.

Answer 2

37Signals befürwortet, sogar Photoshop zu überspringen und direkt zu HTML zu gehen. Siehe http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop. Ich stimme ihrer Einschätzung der Vorplanung zu. Ich denke nicht, dass es auf lange Sicht die Zeit wert ist, wenn Sie Zeit damit verbringen könnten, einen funktionierenden Prototyp in HTML/CSS/JS zu erstellen.

Answer 3

Es hängt wahrscheinlich davon ab, mit wem Sie arbeiten. Wenn Sie und ein Designer sind, dann könnte eine funktionale Spezifikation zu viel Mühe sein. Aber in meinem Job wollen die Führungskräfte genau wissen, was sie am Ende eines Projekts bekommen werden, und so hatten wir es wirklich schwer, iterative Entwicklung zu implementieren. Normalerweise werden die Iterationen mit Wireframes, funktionalen Spezifikationen und Mockups definiert. :)

Answer 4

Ich glaube, es hängt davon ab wie gut Sie verstehen, was Sie zu tun versuchen.Wenn Sie für einen Kunden arbeiten und sie nicht viel in Bezug auf die Anforderungen ausgedrückt haben, möchten Sie vielleicht einen Ansatz mit extrem schnellen Iterationen.Wenn Sie bereits ein gutes Verständnis haben und produzieren können etwas substanzielleres, ohne sich darum zu sorgen, dass es weggeworfen wird, weil es die falsche Richtung war, dann kann mehr Zeit verausgabt werden. Wie auch immer, ein klickbarer Prototyp kann viel dazu beitragen, zu bestimmen, was die reale Seite am Ende sein muss Vereinbarung über den Prototyp, dann, wenn Ihre Anwendung mit dem Prototyp übereinstimmt, wissen Sie, dass es abgeschlossen ist.

Answer 5

Im wirklichen Leben wollen Sie vermeiden, nach dem "idealen" Weg zu suchen, Dinge zu tun. Verwenden Sie stattdessen, was Sie für klare und spezifische Zwecke verstehen.

Mockups können Sie viel Zeit und Mühe sparen. Da es sich dabei nur um zusätzliche Zeit handeln kann, die Sie für die Erstellung und Pflege dieser Elemente aufgewendet haben.

Wirkliches Leben Beispiel # 1: Mockups rettete den Tag. Großes System für die Regierung, Frist ist lächerlich.

Begründung: Monate sind in der Herstellung aller Arten von Architekturdokumenten vergangen, die tatsächlich völlig unnötig sind, weil sowohl die HW- als auch die SW-Architektur bis ins kleinste Detail in Stein fixiert sind und tatsächlich bereits existieren.

Lösung: 20 hektische Tage von Mockups zusammen mit dem Kunden zu schaffen, bis wir einfach die Bildschirme mit unseren Notizen über die Entwickler übergeben. Die Entwickler mussten nach einigen Abklärungen fragen, aber mit einer festen Architektur und klaren und visualisierten Anforderungen waren sie in der Lage, in kürzester Zeit die benötigten Funktionen auszuliefern.

Beispiel des realen Lebens # 2: Mockups ruinierten den Tag. Großes Regierungssystem, das die Notwendigkeit von Modellen "erkannte".

Dieser zeigt menschliche (oder korporative?) Fähigkeit, das Beste, was in der Welt in einen Alptraum zu verwandeln.

Big Regierungsbehörde gebeten, die großen Beratungsunternehmen der großen IT-Unternehmen zu führen, ein Problem zu lösen. Die Regierungsbehörde richtete auch eine große Ad-hoc-Gruppe von Experten aus der Regierung ein, um den Prozess zu unterstützen und zu beschleunigen.

Monate haben in großen Worten und bei der Entscheidung über geeignete Methoden zu verwenden und die richtige Art und Weise zu verwenden, sie übergeben. Es wurden natürlich alle möglichen Kompromisse gemacht, um die Gefühle oder die Wichtigkeit eines anderen nicht zu verletzen.

Ergebnis: SW-Architektur war die Quelle für alles, einschließlich Mockups zu sein. Die sollten zuerst entworfen und als zweites gezogen werden. Mapping der Aktionen von OOAD und Sequenzdiagrammen, UX-Diagrammen wurden erstellt, logische Objekte und Inhaltsbündel der UI wurden erkannt, aktuelle Schirme wurden gezeichnet und in formelle Use-Cases aufgenommen, UCs wurden den Benutzern in formellen Workshops im Monat vorgestellt, diese Workshops wurden zu Anerkennungssitzungen, da jemand herausfand, dass die Zeit verging.

Aus diesen Workshops, auch mit Gewalt Kunden nicht undestand gemacht werden kann (hoch formal, mit vielen Tabellen Datenattribute beschreiben und so weiter) UCs, das jeweils etwa 30 Seiten lang. Wenn die Kunden Feedback hatten, waren es die Modelle. Es wurde jedoch davon abgeraten, Feedback zu geben, da jede Änderung am Modell zu einer Änderung der Sequenzdiagramme, Komponentendiagramme, des Betriebsmodells, UX-Diagrammen, Überprüfung der Rückverfolgbarkeitsmatrizen, Aktualisierung von UC-Texten usw. führte. Und nur um mehr Feedback zu erhalten. ("Verdammt die Kunden, sie sind nie zufrieden." War das Moto). Nach dem Rollout von v1.0 mit eingeschränkter Funktionalität kümmerte sich niemand mehr um Dokumentation, es gab so viel davon. Die Entwickler kämpften um ihr Leben und machten jeden Tag unzählige kleine Änderungen, nur um das System zum Laufen zu bringen (nachdem die gestrige Reihe der Änderungen etwas anderes zum Bruch gebracht hatte).

Dies ist NICHT die Art, Modelle zu verwenden. Das Projekt dauerte fast 2 Jahre länger als geplant.

Mit anderen Worten, suchen Sie nicht nach der idealen Methodik. Oder irgendeine Methode, die du nicht verstehst. Was ist dein Ziel im Moment? Was ist der schnellste Weg, den Sie kennen (andere Wege zählen nicht), um dieses Ziel zu erreichen? Tue es.

Answer 6

Der Hauptzweck der Drahtrahmen ist, Anforderungen zu klären. Es ist immer ratsam, Anforderungen klar zu dokumentieren, und es gibt keinen besseren Weg, als eine Anforderung zu visualisieren. Wireframes helfen hier sehr gut, sie geben dem Product Owner (Client) eine klare Vorstellung davon, was er vom Endprodukt erwarten kann. Auf die Zustimmung des Produkteigners hin gibt es dem Entwicklungsteam auch ein klareres Bild, was zu entwickeln ist. Auf eine Art und Weise spart es viel Entwicklungszeit und vermeidet Konflikte. Meiner Meinung nach sind Drahtrahmen immer nützlich für eine reibungslose Projektausführung, selbst wenn das Projekt klein ist.