Modelle: Codierung gegen Zeichnung?

Hier geht es nicht um Webdesign, sondern um Interface-Design im Allgemeinen. Ist es besser, Interface Mockups zu codieren oder in einem Grafikprogramm wie GIMP, Photoshop usw. zu "zeichnen"?

Stellen Sie sich folgende Fragen:

• Wie viele UI-Layouts / -Optionen können Sie in 30 Minuten durch Codierung erkunden? Wie viele können Sie durch Skizzieren erkunden?

• Wie oft erhalten Sie beim ersten Versuch genau das richtige UI-Design? Wenn nicht sehr oft, wie schnell / einfach ist es, eine Skizze gegenüber einem codierten Modell zu ändern?

• Können Sie eine Farbe sofort identifizieren, indem Sie sich den Hex / RGB-Code ansehen (nicht nur eine Vermutung, sondern auch den genauen Farbton)? Wenn Sie sich eine Farbe in Ihrem Kopf vorstellen, können Sie diese sofort in Hex übersetzen? Wie schnell können Sie ein Farbschema auswählen, indem Sie Hex-Codes eingeben, anstatt einen echten Farbwähler zu verwenden?

Die Tatsache, dass Sie diese Frage stellen, zeigt mir, dass Sie höchstwahrscheinlich ein Programmierer und kein Designer sind. Wenn Sie ein Designer wären, wäre dies genauso absurd wie das Entwickeln einer Anwendung, ohne die Klassenstruktur, das Datenbankdesign, die Anwendungsarchitektur usw. zu planen und direkt in die Codierung einzusteigen - und wenn Sie ein erfahrener Entwickler sind, wissen Sie es Welche Probleme verursacht diese Art der Bottom-up-Entwicklung?

Wenn Sie direkt zum Code springen, ohne zuerst Ihre Benutzeroberfläche zu entwerfen , werden die Ergebnisse nicht schön sein, schon allein deshalb, weil es unpraktisch ist, ein gutes Design durch blindes Codieren zu perfektionieren.

Ich würde zuerst für "Zeichnen" stimmen. In der grafischen Benutzeroberfläche ist das richtige Layout / die richtige Präsentation der Schlüssel und erfordert die Gestaltung visueller Mittel. Durch das visuelle Entwerfen der Benutzeroberfläche können Sie Ihr Design schnell ändern, ohne sich jede Änderung "vorstellen", "in Code übersetzen" und schließlich testen zu müssen. Der andere Weg ist ebenfalls möglich, aber selten besser (z. B. ist das Projekt extrem klein, wie nur ein paar Schaltflächen, und Sie sind vertraut und daran gewöhnt, auf "Code" -Ebene zu arbeiten. Während des Entwurfs können einige Muster auftreten, die gerecht sein können mit geringfügiger Änderung wiederverwendet).

Wenn Sie für ein bestimmtes Widget-Toolkit entwerfen, können Sie auch eine "GUI Designer" -Anwendung verwenden, sofern verfügbar. Dies beschleunigt den GUI-Entwurfsprozess noch weiter, da beide genau zeigen, wie die gestaltete GUI im laufenden Programm aussehen wird, und eine gebrauchsfertige GUI-Beschreibung auf Präsentationsebene exportieren können.

Für das UI-Design habe ich drei Phasen mit unterschiedlichen Zielen:

1. Skizzierung. Zunächst möchten Sie sich einen Überblick darüber verschaffen, welche Elemente vorhanden sein werden und wie sie zusammenpassen. Jedes feine Detail oder jeder ästhetische Perfektionismus in dieser Phase ist eine Ablenkung. Ich benutze ein Whiteboard und einen fetten löschbaren Stift, damit es unmöglich ist, sich von zu vielen Details ablenken zu lassen und einfach jede Menge verschiedener Ideen zu kritzeln und jederzeit von vorne zu beginnen. Ich habe von Leuten gehört, die nur auf kleinen Haftnotizen skizzieren oder nur ihre Hand (z. B. die linke Hand, wenn Sie Rechtshänder sind) verwenden, um sich zu zwingen, der Ästhetik überhaupt keine Aufmerksamkeit zu schenken und sich zu 100% zu konzentrieren auf die Idee und Funktion. (Bild nicht von mir, von Frank Prendegast )

2. (2!) Simulieren.Zweitens möchten Sie einen Blick nach unten werfen und Feedback erhalten, um so viel wie möglich über die Intuitionen und unaufgeforderten Antworten der Menschen herauszufinden, bevor Sie mit der zeitaufwändigen Implementierungsarbeit beginnen. Dies sollte in allem geschehen, in dem Sie am effizientesten arbeiten, denn wenn Sie es richtig machen, sollten Sie häufig zum Zeichenbrett zurückkehren, Kritik suchen und versuchen, so viele unerwartete Probleme wie möglich so früh wie möglich zu identifizieren. Wenn Sie eine verrückte Codiermaschine sind und es das ist, in dem Sie am bequemsten arbeiten, ist das Codieren in Ordnung, aber die meisten Leute arbeiten schneller in Fireworks, Photoshop, dedizierter Wireframing-Software oder einem UI-gesteuerten Interface Builder wie Flash Catalyst (Gut, wenn das Endprodukt nicht Flash ist, besteht das Ziel darin, vor Beginn der Implementierung ein gutes Feedback zu erhalten.)

3. (3!) Implementierung. Schließlich implementieren Sie die Sache und möchten dies so tun, dass Sie früh und häufig mehr Feedback erhalten.

Diese drei Teile des Projektzyklus haben unterschiedliche Ziele. Wenn es sich also um ein großes Projekt handelt, ist es sinnvoll, in jeder Phase das am besten geeignete Werkzeug für den Job zu verwenden.

Diese Frage ist etwas vage und ebenso die Antworten.

Darüber hinaus werden Projekte und Teams sehr unterschiedlich sein.

Das heißt, es gibt kein "Bestes". Es geht darum, alle Tools in einem Workflow zu verwenden, der für Sie und Ihr Team am sinnvollsten ist.

Generell würde ich sagen, dass dies die Art von Workflow ist, die Sie anstreben sollten:

1. Skizzieren. Bleistift + Papier. Whiteboards. Iterieren. Arbeiten Sie mit so vielen Teammitgliedern wie möglich.
2. Low-Fi-Modelle. Könnte PSD sein, könnte visio sein. Könnte Papier sein. Benutzer testen diese.
3. Machen Sie sich daran, Prototypen zu bauen. Hier möchten Sie so viel wie möglich im Arbeitscode tun. Wechseln Sie nach Bedarf in Photoshop und bringen Sie das Material so schnell wie möglich in Code um. Setzen Sie das Testen / Iterieren des Benutzers fort.

Was für mich funktioniert, ist das Erstellen von Modellen mit einem Programm, das betont , dass keine pixelgenauen Layouts erstellt werden. Für mich sind das Balsamiq Mockups, die Sie unter http://www.balsamiq.com/products/mockups einsehen können