1. Zweck: Ein funktionierendes Produkt, das von Menschen verwendet wird

So ein einfaches Ziel. Wir werden jedes Wort analysieren, weil es nicht nur durch diese Wörter so formuliert ist.

Achten Sie auf das Fehlen von Prozesswörtern wie "Kreation", "Design" usw. Prozesse sind überhaupt kein Ziel. Das Ziel kann nur ein Ergebnis sein, kein Prozess. Aber Designer auf der ganzen Welt geraten in die mentale Falle von Prozessen. Das Ergebnis ihrer Arbeit sind Prozessartefakte, keine funktionierenden Produkte.

Ich habe traurige Statistiken. Von zehn Designern, die kommen, um „ein Produkt herzustellen und es zu beeinflussen“, konzentriert sich einer auf das Ergebnis, der Rest auf Prozesse. Es kommt lange und gut, wenn es überhaupt kommt.

Bevor die Empörung kommt, werde ich klarstellen: Ich vermindere nicht die Bedeutung der Prozesse und verstehe sie. Framework, Forschung, Design, Methoden, Spezifikationen, Richtlinien, Designsysteme, professionelle Software und so weiter. Sobald das Produkt in die Hände des Benutzers fällt, macht dies alles keinen Sinn: Das Produkt funktioniert entweder oder nicht.

Wie auch immer, zurück zum Wortlaut.

1. Ein funktionierendes Produkt kann zur Lösung von Problemen verwendet werden. Es geht um die technische Fähigkeit, das Problem mit dem Produkt zu lösen.
2. Das Produkt ist eine Art vollständige Einheit in Bezug auf die Menge der Inhaltsstoffe, die mehr Wert hat als alle getrennt genommen.
3. Verwendung - spricht von Nachfrage und Bequemlichkeit.
4. Menschen sind ein umfassenderes Konzept als „Kunden“, „Benutzer“, „Mitarbeiter“ usw. Bei der Arbeit für Menschen berücksichtigen wir die Ergonomie und einige Standards.

Angenommen, das Produkt funktioniert nicht. Hier ist alles klar: Sie werden nicht verwendet (zumindest nicht für den beabsichtigten Zweck).

Oder ist es kein Produkt: eine Reihe unterschiedlicher Komponenten, die durch kein Zeichen miteinander verbunden sind (dies geschieht auch).

Oder es gibt ein Produkt, das sie jedoch (überhaupt) nicht verwenden. Auch ein Misserfolg, es könnte jeder sein: Der Mangel an Marketing, unangenehm, verlangsamt sich.

Wenn die Leute es nicht benutzen ... dann, gebe ich zu, wird es völlig andere Designprinzipien geben.

Diese Idee wird aus verschiedenen Blickwinkeln diskutiert, wenn sie über Agile, häufige Lieferungen, Scrum und Teamwork sprechen, aber selbst mit solchen Praktiken geraten Designer manchmal in eine gemütliche Furcht vor „Prozessen“. Ich gebe solche Gründe zu:

• Sie verstehen die Technologien und ihren Einfluss auf sie nicht.
• kann das Ergebnis nicht beeinflussen (Angst "sie hören nicht zu", mangelnde Motivation, erfundene Unterordnung "sie haben mir nicht gesagt, dass ich das tun soll")
• verstehe ihre Rolle nicht
• Ein Scrum wird ausgenutzt, ohne den Zweck zu verstehen, wie ein Framework (siehe auch Cult of Cargo ) - dann ist es definitiv nicht besser als ein Wasserfall (oder noch schlimmer).
• Ordne kleine Wasserfälle im Gedränge an :-) - „Erst Design, dann Frontend“, anstatt mindestens zwei / zwei zu arbeiten. Dies ist aus irgendeinem Grund für Designer und Entwickler gleichermaßen besonders schwierig (aber wenn und wenn dies der Fall ist, möchten sie nicht mehr zum Mini-Wassermodell zurückkehren, da es in jeder Hinsicht fehlerhaft ist).

PS Links zu Beschreibungen der aufgeführten Methoden, Wikipedia:

• Agile (Agile) - Flexible Entwicklungsmethode
• Scrum (Scrum) - ein Framework für agile Softwareentwicklung (Teamarbeit)
• Kanban (Kanban) - ein System zur Organisation von Produktion und Lieferung, mit dem das Prinzip "just in time" umgesetzt werden kann.

2. Die Rolle des Designers im Scrum-Team

Oft ist die Rolle eines Designers in einem Produktteam übertrieben, weil er in Prozessen und Abfolgen von Aktionen (Wasserfall) anstelle des Ergebnisses denkt.

(Um aus dem Ergebnis richtig zu denken, nach Kategorien des Zwecks.)

Der Entwickler, der gerade alles gemäß den Standards und Spezifikationen getan hat, wird das Problem höchstwahrscheinlich besser lösen, als wenn er die Modelle des Designers durchläuft. Wahrscheinlich sind sogar Lebensmittelkennzahlen besser. In völliger Abwesenheit eines Designers.

„Wir warten auf Layouts“ - wenn das klingt, sind die Prozesse im Team nicht richtig organisiert.

(Leider sind sich viele Entwickler und Designer der Standards nicht bewusst - zumindest W3C für das Web, und es gibt viele grundlegende Prinzipien, die dazu beitragen, die beste Erfahrung zu erzielen. Analog gibt es Beschreibungen / Standards für führende mobile und Desktop-Plattformen; iOS , Material .)

Achten Sie auf Startups - Facebook, Vkontakte, Odnoklassniki und Apple mit Microsoft: Sie basieren auf technischen Lösungen (Wozniak, Gates), denen Designer später beigetreten sind. Sie haben Produkte in Übereinstimmung mit dem Zweck erstellt.

An erster Stelle steht ein funktionierendes Produkt.

(Gut, aus Gründen der Gerechtigkeit haben es die ideologischen Leute im Xerox-Labor getan, aber das Ausmaß der Konsequenzen ist völlig anders.)

•••

Was ist dann die Rolle des Designers?

Mehrwert schaffen .

Sie können etwas Vorhandenes hinzufügen , achten Sie darauf.

Wert in den Augen von Kunden, Anwendern.

•••

Oft wird die Sequenz auf den Kopf gestellt und „auf das Design gewartet“. Dies spricht natürlich für die Unreife des Teams und das unzureichende Management dieses Teams.

•••

„Layouts“ ist ein Anachronismus, das Erbe eines statischen Netzes, das früher der Ästhetik und den Prozessen der Erstellung von Zeitschriften- und Zeitungsgrafiken folgte. Im Produktdesign hat dies aufgehört, relevant zu sein, aber der Ansatz - in Abwesenheit eines anderen - ist sowohl in Prozessen als auch im Bewusstsein geblieben.

Beginnen Sie mit Code anstelle von Layouts.

Anwendung - Dynamik, Bewegung, Interaktion. Daher sind die Layouts in der Arbeit des Produktdesigners oft unangemessen und widersprechen dem Ziel.

Aus diesem Grund migrieren fortgeschrittene Designer zu Prototypen mit realen Daten. Ist das gut Ich denke, das ist überflüssig - warum einen Prototyp programmieren, wenn Sie (und logischerweise) sofort ein Produkt programmieren können?

Es ist besser, sofort von der Entwicklung zum Design zu wechseln. Beginnen Sie mit dem Code - dem Prototyp, der die Aufgabe des Kunden auf minimale Weise ausführt. Ein Prototyp, der in die Arbeitsversorgung aufgenommen werden kann (Rückruf später zur Kundenentwicklung).

(Die Offenheit und Reife der Entwickler ist hier wichtig - ihre Bereitschaft, zu experimentieren und das Programm zu verbessern und möglicherweise sogar den Code mehrmals neu zu schreiben. Ich bin sicher, dass es dafür schon lange viele vorgefertigte Lösungen gibt.)

Imbiss

Verwirklichen Sie die Aufgabe des Benutzers.

Beginnen Sie mit der Entwicklung. Arbeiten Sie mit dem Entwickler zusammen (als Art Director und Texter).

Verbessern Sie ein funktionierendes Produkt anstelle von Layouts.

Denken Sie in Zielen, Ergebnissen statt in Prozessen.

Der Produktdesigner erstellt das Produkt, nicht die Layouts.

3. Methode

Diese Methode ist zusammen mit der Bibliothek der Komponenten zur Grundlage des Bankdesignsystems geworden .

Ich schlage vor, in der folgenden Reihenfolge zu arbeiten:

1. Erkennen Sie die Aufgabe des Clients (Benutzers) und legen Sie sie als User Story fest.
2. Metriken definieren. Wie verstehen wir, dass die Aufgabe des Benutzers gelöst wurde? Festschreiben.
3. Hypothesen formulieren. Festschreiben.
4. Customer Journey Map.
5. Ein funktionierender Prototyp. MVP Kundenentwicklung.
6. Layouts. (Mit der Teamarbeit und dem vorhandenen Designsystem können Sie auf Layouts verzichten).

Kundenaufgabe

Hier scheint alles klar zu sein, aber oft ist es nicht so. Schnittstellenhypothesen werden mit Kundenaufgaben verwechselt, sie werden von der Wunschliste des Managers ausgegeben und im Allgemeinen für nicht so schöne Teammanipulationen verwendet.

Die Aufgabe des Kunden wird entweder anhand von Beschwerden („Kundenschmerzen“) oder aufgrund von Forschungsbedürfnissen identifiziert.

(Nebenbei stellen wir fest, dass eine Beschwerde und eine Aufgabe zwei verschiedene Dinge sind. Es ist wichtig, einen kühlen Kopf zu bewahren und sich nicht zu beeilen, um ein Problem aufgrund einer Beschwerde zu lösen. Die Aufgabe kann unterschiedlich sein und die Beschwerde wird durch nicht verwandte Umstände verursacht. Kommt mit Erfahrung. Verwenden Sie die Methode „Fünf warum“. manchmal hilft es, der Basis auf den Grund zu gehen, auf der eine objektive Aufgabe formuliert werden kann.)

Wenn eine Aufgabe realisiert wird, wird sie als User Story aufgezeichnet. Viele Artikel und Bücher wurden darüber geschrieben, deshalb werde ich mich hier nicht wiederholen - lernen Sie alleine.

Für einen Einblick in das Problem empfehle ich das Buch User Story Mapping: Entdecken Sie die ganze Geschichte, bauen Sie das richtige Produkt (Jeff Patton und Peter Economy) .

Zwei Arten von Metriken (es ist wichtig, beide zu korrigieren!)

1. Die formulierte Antwort auf die Frage "Wie verstehen wir, dass die Aufgabe des Benutzers gelöst wurde?" Was wir in Form einer Lösung bekommen wollen.
2. Digital: relative und absolute Werte. Häufiger über quantitative Indikatoren (Finanzen, Geschwindigkeit, Kunden, Zeit). Wie verstehen wir, dass die Entscheidung erfolgreich ist? Es gibt einen Trick: In Präsentationen werden relative Werte häufig ausgeblendet, übertrieben oder verlieren den objektiven Maßstab der Entscheidung. Zum Beispiel „das Publikumswachstum betrug 3%“ - ist es viel oder wenig? Wenn es sich um 150.000 Menschen handelt (eine städtische Siedlung mit Schulen und Kindergärten, Geschäften und eigener Verwaltung), dann ist dies bereits eine beeindruckende Zahl, obwohl es sich um Kleinigkeiten handelt. Auf der anderen Seite ist „300% Gewinnwachstum“ bei 300 Rubel pro Monat bereits ein zweifelhafter Indikator. Wenn 150.000 Personen einen statistischen Fehler in der Größe des Publikums des gesamten Produkts darstellen (z. B. Besuch der Hauptseite der Suchmaschine pro Jahr), können diese Größen höchstwahrscheinlich vernachlässigt werden, obwohl es sich um die Bevölkerung desselben städtischen Dorfes handelt.

Es stellt sich häufig heraus, dass Metriken angezeigt werden, nachdem ein Produkt oder eine Funktion bereits ausgeführt wurde. Für die Berichterstattung und eine schöne Präsentation. Dies ist traurig und zeigt keine Geschicklichkeit, verdirbt aber im Gegenteil das Bild und erzeugt ein falsches Gefühl der Ruhe (Abrechnung erfolgt immer). Die Situation wird sehr gut durch den Witz über den besten Bogenschützen der Welt veranschaulicht.

Hypothese - die Antwort auf die Frage, wie das Problem des Benutzers am schnellsten gelöst werden kann

Es gibt immer mehrere Lösungen für das Problem. In der Entwicklung (Design) kann man sich nicht auf eins beschränken! Niemand weiß im Voraus, welches am besten funktioniert.

Machen Sie mentale Arbeit und finden Sie mindestens drei verschiedene Lösungen.

Denken Sie daran, dass das „Entwickeln“ einer Idee in Form eines sich ständig ändernden Layouts eine Lösung ist, nicht drei (oder wie viele verschiedene Layouts Sie erstellt haben).

Versuchen Sie der Einfachheit halber drei Ansätze:

1. Schnittstellenlösung. Es kann auch mehrere geben.
2. Automatisch (zum Beispiel wird beim Auftreten eines Ereignisses eine Aufgabe auf dem Server ausgeführt) - ohne Benutzereingriff.
3. Prozesse - Was kann in Prozessen geändert werden, damit der Benutzer überhaupt nicht auf eine Aufgabe stößt, sondern zum richtigen Zeitpunkt eine Lösung erhält.

Die beste Lösung wird ausschließlich empirisch gefunden (siehe „Wissenschaftliche Methode“). Jede selbst auf den ersten Blick wildeste Lösung / Idee muss überprüft werden. Hypothesen müssen überprüft werden. Der Idealfall besteht darin, alle drei in Form von MVP durchgeführten Hypothesen zu testen. Sie werden dafür einen Prototyp erstellen.

Customer Journey Map taucht in den Kontext ein

Wenn Sie ein kleines Produkt mit einer einzigen Funktion haben, können Sie mit CJM den gesamten Prozess der Problemlösung durch den Benutzer sehen und Schwachstellen identifizieren und den tatsächlichen Abschluss der Aufgabe realisieren.

Wenn die Aufgabe darin besteht, eine Funktion in einer vorhandenen Anwendung zu entwickeln, taucht CJM in den Kontext ein und bietet eine nahtlose, nahtlose Lösung für das Problem. , , « », , .

CJM , .

« » .

. MVP. Customer Development.

. — ( MVP ), (Customer Development).

« . Lean Startup -» . .

MVP, . .

,

MVP . , — . , - , — - .

Takeaway

,

, / , . , .

.

, - , . , , . -. : , - , . , , , .

: , , . . , , .

, . ( ), , , , . , ( , «»; — ).

: , . , . — -: , — . -, . , , , , . ( «»), /. / , : / , , .

, .

, .

?

, / (), , , , . . , , .

, .

: ?

? ?

?

30 ? ?

? , ?

?

, ?

— , . .

, . — , : , . .

.

« », .

, . , . . , - . .

: .

? . ? .

. , — «» :-)

.

. : , , .

, , . ( ).

: , . : / .

:

1. , : , -, (// ). . ( ).
2. , , — . , : , «, » ( ), , «», . — .
3. , . , — . — /, . — , , , , . - . , — . « ».

Insgesamt

1. — .
2. — .
3. «» .
4. , « » «» ( / ) — .

— , , . .

ePub