Warum Designs rendern?
Wie verwenden Sie in Ihrem Entwurfsprozess Modelle, insbesondere hochwertige Modelle (keine Drahtmodelle), und warum / würden Sie sie empfehlen?
Ich bin ein Entwickler, in der Vergangenheit gaben meine Produktbesitzer manchmal Anforderungen in Form von Modellen an, aber selbst dann fiel mir im Allgemeinen auf, dass dies ohne all die zusätzliche Arbeit (0 künstlerische Fähigkeiten mit Stift und Stift) hätte kommuniziert werden können Papierskizze hätte gereicht).
Letzte Woche habe ich mir einige YouTube-Videos angesehen, um Design-Inspiration für ein Neben- / Hobbyprojekt zu erhalten, an dem ich arbeite. Dabei habe ich einige ihrer Aktivitäten nachgeahmt, aber aufgehört, als mir klar wurde, dass sich die Bemühungen nicht übertragen haben. Die meiste Design-Software, die ich gesehen habe, ähnelt eher Photoshop als einem Webbrowser, sodass die normale Leinwand- / Palettenarbeit nicht ohne weiteres in (S) CSS übersetzt werden kann - ich habe noch nie (* nicht seit Anfang der 2000er Jahre) daran gearbeitet Ein Projekt, bei dem ein Hintergrundbild verwendet wurde, sodass ich nicht sicher bin, welche Rolle die Skizze in einem Entwurfs- / Entwicklungslebenszyklus spielt.
Ich klopfe nicht an Designer oder an Ihre Arbeit - ich erinnere mich an das Internet in den späten 90ern und möchte nicht zurück. Ich habe nur Schwierigkeiten zu verstehen, warum Unternehmen so viel Zeit / Geld damit verbringen, hochwertige digitale Kunst zu generieren - das muss dann in bilder, HTML & CSS übersetzt werden?
Antworten
Ich denke, das ideale Szenario besteht darin, Designer zu haben, die das Front-End codieren. Aber die Realität ist, dass die meisten Designer dies nicht tun. Es gibt jedoch immer mehr Orte, an denen dies die Norm ist.
Aus Sicht des Designers dienen die Entwürfe in erster Linie drei Hauptzielen:
- Kritik im Team
- Mit Benutzern testen
- Besprechen Sie mit Kunden
Papierskizzen können für keine der oben genannten Aufgaben verwendet werden, selbst Drahtgitter sind für Kunden und einige Benutzer schwer zu verstehen. Da jedes Element seinen Zweck hat, ist das Skizzieren auf Papier (wie das Skizzieren auf einem Whiteboard) am besten geeignet, um eine schnelle Diskussion über Kleinigkeiten oder Ideen zu ermöglichen. Es kann keine Dinge wie Branding, Look and Feel darstellen.
Ein anderer Ort, an dem es glänzt, ist die Darstellung anfänglicher grober Ideen, um schnell zu optimieren. Es gibt Dinge, die als Papier-Prototyping oder Kartonmodelle von Produkten usw. bezeichnet werden. Sie werden häufig verwendet, um ein Szenario zu durchlaufen und ein Gefühl dafür zu bekommen, wie es sich anfühlt, das Produkt zu verwenden und ob die Vision große Löcher aufweist. Es ist leicht, wichtige Dinge zu übersehen, wenn man sie nicht ausspielt.
Jetzt erfüllen sowohl Hifi-Prototypen als auch Straight HTML / CSS die obigen Punkte. Es kommt nur auf den Designer und die unternehmensinternen Prozesse an. Es gibt keine Regel, die besagt, dass HiFi-Prototypen ein Muss sind.
Was Sie verwenden, hängt von Ihren Anforderungen und den Projektbeschränkungen ab. Müssen Sie etwas kommunizieren, das durch Skizzieren auf Papier erreicht werden kann? Bitte tun Sie dies, verschwenden Sie keine Zeit. Tun Sie es jederzeit zu jedem Zeitpunkt im Projekt. Müssen Sie mit Benutzern testen? Kunden verstehen nur HiFi-Sachen? Haben Designer in HTML / CSS gelebt? Sie können auch Photoshop / Figma / Skizze usw. überspringen. Haben Sie einen Kunden, der 2 sehr unterschiedliche Wege erkunden möchte? kostet die Iteration von Prototyping-Tools weniger? Überspringen Sie dann das HTML / CSS für eine Weile.
In vielerlei Hinsicht ist der Wireframe> Photoshop> Code-Fluss ein Legacy. Tools mischen jetzt Wireframes und Photoshop mit logischen Regeln. Einige dieser Prototyping-Tools erschweren dies so sehr (sie werden im Grunde genommen zu visuellen Darstellungen von Code), dass Sie sich fragen, ob es schneller geht, wenn Sie direkt mit Javascript arbeiten (was auch der Fall ist, wenn Sie technisch versiert sind). Ich bin sicher, dass sich diese Entwicklung immer mehr nur mit Code bewegen wird. Das Feld entwickelt sich weiter, es kommen viele neue Leute herein, die nicht technisch sind. Und die Werkzeuge, die Sie sehen, sind auf sie zugeschnitten, nicht auf Front-Entwickler.
Es gibt auch dieses Konzept der Treue. Je mehr etwas wie das Endprodukt aussieht, desto mehr Menschen glauben, dass sie kein Feedback und keine Änderungen geben können. Sie werden sich zurückhalten, selbst wenn Sie ihnen sagen, dass es in Ordnung ist zu geben. Ein Drahtgitter lädt natürlich mehr ein als etwas, das poliert und fertig aussieht. Wenn Sie einem Kunden ein poliertes Design zeigen, erhalten Sie möglicherweise nicht das gewünschte Feedback. Aber auch hier können Sie ein Drahtmodell codieren. Niemand sagt, dass du nicht kannst.
Denn Designer tun dies nicht ausschließlich, um mit Entwicklern zu kommunizieren, sondern um mit Benutzern und Steakhaltern zu kommunizieren.
Wie testen Sie eine Designlösung, die Sie mit Stift und Papier gekritzelt haben? Wie finden Sie heraus, welche Lösung zu einer besseren Konvertierung führt? Woher wissen Sie, ob Sie Ihre Lösung anpassen müssen, weil Benutzer Schwierigkeiten haben, sie zu verstehen usw.?
Designer tun dies, um gemeinsam mit Steakhaltern, bei denen es sich in der Regel um Personen vom visuellen Typ handelt, etwas auszuarbeiten und ihre Arbeit durch Testen mit Benutzern zu validieren.
Am Ende wird die Designlösung auf Entwickler übertragen, und Tools wie Sketch, Adobe XL usw. bieten eine Möglichkeit, Entwicklern mit relativ geringem Aufwand Styling-Attribute usw. aus der bereits geleisteten Arbeit mitzuteilen.
Wir haben vor einigen Jahren bei meiner Arbeit auf tatsächlich gerenderte Designs verzichtet. Wir sind zu Rapid Prototypen übergegangen und haben Proxy / Mock Json als Backend verwendet. Unsere Stakeholder bekommen das Gefühl einer echten App und können sie frühzeitig kritisieren, ohne dass ein Backend-Code entwickelt wurde. Wir sind alle auch anständige UI-Designer und verwenden Bootstrap als Basis. Nachdem unser Prototyp fertig / genehmigt ist, starten wir das Backend, da das Frontend buchstäblich schon fertig ist. Wir verwenden ein benutzerdefiniertes Javascript-Framework namens Atomic Stack, das von Tyree Jackson geschrieben wurde. Hör zu!