Design digitaler Produkte. Zweck, Rolle, Methode

    Ich habe zufällig eine Designabteilung in der Alfa-Bank gegründet und arbeite als Designdirektor. Es hat fünf Jahre gedauert. Als Ergebnis haben wir ein Design-System (im Code) und einen Ansatz für das Design digitaler Produkte. Eigentlich werde ich hier über diesen Ansatz berichten. Genauer gesagt ist dies der Text des Vortrags, den ich Anfang 2018 in Moskau, Perm, Nowosibirsk und St. Petersburg gelesen habe. Im Mai entschied ich mich, die Bank zu verlassen. Jetzt habe ich den Text der Vorlesung in die Hände bekommen.

    Im Alpha Lab haben wir Produktentwicklungsprozesse direkt über dem Bildschirm aufgebaut, wobei jedes Team eine unabhängige Einheit ist, die so schnell wie möglich liefern kann (idealerweise wöchentlich oder zweiwöchige Sprints).

    Wichtiger Hinweis: Der gesamte Text behandelt die Arbeit des Designers im Scrum Team. Dies ist eine sehr wichtige Einschränkung. In Vorträgen erwähnte ich dies selbstverständlich nebenbei, so dass jemand die Bedeutung der Geschichte verlieren könnte. Bei Kanban und traditionellen Ansätzen (Contract-Design-Layout-Assembly-Act) kann diese Methode sogar Schaden anrichten. Wenn das Konzept des „Scrums“ für Sie neu ist, sollten Sie den Ansatz studieren. Vielleicht hilft dies jemandem dabei, seine Arbeit besser zu organisieren. Im Laufe des Textes habe ich Links zu Artikeln und Büchern gegossen.

    Ende 2017 befanden sich im Labor etwa 30 Teams (vielleicht mehr), und fast jeder brauchte einen eigenen Designer. Selbst in einem relativ großen Maßstab ist es wichtiger, auf der Ebene der Strategie, der Konzepte und Ansätze auf höchster Ebene zu arbeiten, da es technisch nicht möglich ist, die Arbeit von 30 Designern zu „kontrollieren“, die an verschiedenen Produkten und in verschiedenen Teams und mit unterschiedlichen Geschwindigkeiten arbeiten. Die Taktik wird von jedem Team für sich bestimmt, das ist das Schöne.



    1. Zweck: Ein funktionierendes Produkt, das die Menschen verwenden


    So ein einfaches Ziel. Lassen Sie uns jedes Wort analysieren, weil es nicht nur durch diese Wörter formuliert wird.


    Achten Sie auf das Fehlen von Wortprozessen wie "Erstellung", "Design" usw. Prozesse sind überhaupt kein Ziel. Das Ziel kann nur das Ergebnis sein, nicht der Prozess. Designer auf der ganzen Welt geraten jedoch in die mentale Falle von Prozessen. Daher sind die Ergebnisse ihrer Arbeit Prozessartefakte und keine Arbeitsprodukte.


    Ich habe eine traurige Statistik. Von den zehn Designern, die "ein Produkt herstellen und beeinflussen", konzentriert sich einer auf das Ergebnis, die übrigen Prozesse. Erreicht eine lange Zeit und gut, wenn es überhaupt kommt.



    Bevor die Empörung fließen kann, werde ich klarstellen: Ich lehne die Bedeutung der Prozesse nicht ab und verstehe sie. Framework, Forschung, Design, Methodik, Spezifikationen, Richtlinien, Design-Systeme, professionelle Software und so weiter. Sobald das Produkt in die Hände des Benutzers gerät, verliert es seine Bedeutung: Das Produkt funktioniert entweder oder nicht.



    Eine langweilige Erklärung über den Prozess und die Ressentiments

    Если пользователь скачивает приложение, а оно не работает или не решает его задачу, становится неважным абсолютно всё: как собирались данные и проводились исследования, какими были макеты, в каком ПО они выполнялись, какие были блок-схемы и серые квадратики, как отчаянно работали программисты перед запуском и какое классное видео получилось с вечеринки в честь запуска продукта.


    Любая профессиональная надстройка для «ускорения» или «совершенствования» процессов часто просто (уже будучи надстройкой, то есть фактически избыточным явлением) добавляет процессов и бюрократии, не решая задачи и не двигая команду к цели, а отдаляя от неё. Взять то же прототипирование1: вместо разработки, мы создаем эмуляторы, которые дают от силы 10-30% опыта, который будет в продукте. И проектирование. И исследования. И макеты. И вайрфреймы ДО макетов (некоторые отличают эту стадию от проектирования и вкладывают в одни и те же термины разные смыслы). Потом описание гайдов. И ещё «авторский надзор» (очень пошлое название подглядывания за работой разработчиков и ворчание — тут-то вскрывается миллиард неучтенных во всех этих «исследованиях» и «прототипах» нюансов). Так, вместо того чтобы стремиться к результату в виде продукта, дизайнеры или менеджеры создают массу высокозатратной возни. Вырастают отдельные профессии типа «проектировщик», «дизайнер интерфейсов», «UX/UI-дизайнер», «исследователь» и так далее. На конференциях вполне всерьёз начинают обсуждать легитимность склеивания UX и UI, мол этим должны разные люди заниматься, разные инструменты и задачи. Вместо фокуса на работающем продукте получается фокус на процессах, и каждая надстройка только отдаляет от реальной цели.


    Надо понимать, что здесь речь идёт только о процессах, наиболее тесно связанных с работой людей, которых мы называем дизайнерами (что бы кто в это собирательное понятие ни вкладывал). Об устоявшихся процессах внутри давно существующей компании, которые называются «бизнес-процессами», и которые часто наиболее сильно влияют на продукт и опыт пользователя, здесь речи не идёт.



    Wie auch immer, zurück zum Wortlaut.


    1. Ein funktionierendes Produkt kann verwendet werden, um Probleme zu lösen. Es geht um die technische Fähigkeit, das Problem mit dem Produkt zu lösen.
    2. Ein Produkt ist eine Art vollständige Essenz, in der Summe der Zutaten, die einen höheren Wert haben als alle getrennt betrachtet.
    3. Genießen - spricht von Nachfrage und Komfort.
    4. Menschen sind ein breiteres Konzept als "Kunden", "Benutzer", "Mitarbeiter" usw. Bei der Arbeit für Menschen berücksichtigen wir die Ergonomie und einige Normen.

    Angenommen, das Produkt funktioniert nicht. Alles ist klar: Sie werden nicht verwendet (zumindest nicht gemäß dem beabsichtigten Zweck).


    Oder es handelt sich nicht um ein Produkt: eine Reihe separater Komponenten, die in keiner Beziehung zueinander stehen (dies geschieht auch).


    Oder es gibt ein Produkt, aber es wird (überhaupt) nicht verwendet. Es ist auch ein Misserfolg, vielleicht jemandes Wunsch: mangelndes Marketing, unbequem, verlangsamt sich.


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


    Diese Idee wird aus verschiedenen Blickwinkeln diskutiert, wenn sie über Agile, über häufige Lieferungen, über Scrum und über die Arbeit in Teams sprechen, aber selbst bei solchen Praktiken geraten Designer manchmal aus einem bestimmten Grund in einen gemütlichen "Prozess". Ich gebe folgende Gründe zu:


    • verstehe keine Technologien und deren Einfluss auf sie,
    • kann das Ergebnis nicht beeinflussen (Angst "hört nicht zu", mangelnde Motivation, geschminkte Unterordnung "Mir wurde das nicht gesagt")
    • verstehe ihre Rolle nicht
    • Scrum wird ausgenutzt, ohne den Zweck zu verstehen, als Rahmen (siehe auch „ Ladungskult “) - dann ist es definitiv nicht besser als ein Wasserfall (oder schlechter).
    • Sie ordnen kleine Wasserfälle in den Abfällen ein :-) - "Zuerst Design, dann Frontend", anstatt zumindest paarweise zu arbeiten. Aus irgendeinem Grund ist dies sowohl für Designer als auch für Entwickler besonders schwierig (aber wenn und wenn, dann wollen sie nicht mehr zum Mini-Wasserball-Modell zurückkehren, da es in jeder Hinsicht fehlerhaft ist).

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




    2. Die Rolle des Designers im Scrum-Team





    Oft ist die Rolle des Designers im Produktteam übertrieben, weil sie anstelle des Ergebnisses nach den Prozessen und der Reihenfolge der Aktionen (Wasserfall) denken.


    (Um richtig über das Ergebnis nachzudenken, in Zweckkategorien.)


    Ein Entwickler, der einfach alles nach Standards und Spezifikationen durchführt, wird das Problem wahrscheinlich besser lösen, als wenn er die Modelle des Designers durchläuft. Wahrscheinlich werden sogar Produktkennzahlen besser sein. In Abwesenheit eines Designers.


    „Wir warten auf Modelle“ - wenn dies klingt, sind die Prozesse im Team falsch organisiert.


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


    Achten Sie auf Startups - Facebook, Vkontakte, Odnoklassniki und den gleichen Apple mit Microsoft: Sie basieren auf Engineering-Lösungen (Wozniak, Gates), die später von Designern unterstützt wurden. Sie kreierten Produkte gemäß dem Ziel.


    Erstens - ein funktionierendes Produkt.


    (Schön, Fairness wegen der ideologischen Jungs im Xerox-Labor, aber das Ausmaß der Konsequenzen ist ziemlich unterschiedlich.)


    •••


    Was ist dann die Rolle des Designers?


    In Wertschöpfung .


    Sie können etwas hinzufügen , Hinweis.


    Wert in den Augen von Kunden, Anwendern.


    •••


    Oft wird die Sequenz auf den Kopf gestellt und "auf das Design gewartet". Dies spricht natürlich von der Unreife des Teams und der unzureichenden Führung dieses Teams.


    •••


    „Layouts“ ist ein Anachronismus, ein Erbe eines statischen Netzes, das zuvor der Ästhetik und den Vorbereitungen für die Erstellung von Zeitschriften- und Zeitungsgrafiken folgte. Im Produktdesign ist dies nicht mehr relevant, 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 Layouts in der Arbeit des Produktdesigners oft unangemessen und widersprechen dem Ziel.


    Aus diesem Grund migrieren fortgeschrittene Designer zu Prototypen mit realen Daten. Ist es gut Ich denke, das ist überflüssig - warum sollte man einen Prototyp programmieren, wenn es möglich (und logisch) ist, ein Produkt sofort zu programmieren?


    Es ist besser, sofort von Design zu Design zu wechseln. Es ist mit dem Prototypcode zu beginnen, der die Aufgaben des Kunden in einer minimalen Form ausführt. Der Prototyp, der zur Arbeitszustellung gehen kann (Rückruf später an Customer Development).


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


    Lyrischer Exkurs: ein Beispiel aus der physischen Welt

    Сравнение с бумажной, физической вещью очень привлекательно, потому что пока что понятно больше других. Поэтому поддамся соблазну и приведу аналогию из жизни графического дизайнера.


    Представьте себе что работающий продукт это контент издания (книги, журнала, газеты). Важно его правильно «упаковать» и представить читателю. Без контента смысл в оформлении отсутствует. Пустая книга не удовлетворяет читателя. Роль разработчика сравни роли автора. А без хорошего оформления содержание книги всё равно имеет ценность.


    А контент дальше можно распределить как угодно. Кстати, сейчас контент распределяется между массой носителей — от бумажных до электронных. Те же книги в электронном виде живут в разных форматах и читалках, подтверждая приоритет контента над оформлением.


    (К слову о дизайн-системах: это стилевые решения для быстрого оформления контента. Инструмент разработки, а не оформления.)


    Zum Mitnehmen


    Realisieren Sie die Aufgabe des Benutzers.


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


    Verbessern Sie das Arbeitsprodukt anstelle von Layouts.


    Denken Sie in Bezug auf Ziele, Ergebnisse statt auf Prozesse.


    Der Produktdesigner erstellt das Produkt, nicht die Layouts.


    3. Methode


    Diese Methode wurde zusammen mit der Komponentenbibliothek zur Grundlage des Bankdesignsystems .



    Ich schlage vor, in der folgenden Reihenfolge zu arbeiten:


    1. Die Aufgabe des Kunden (Benutzers) verstehen und in Form von User Story erfassen.
    2. Metriken definieren Wie verstehen wir, dass die Aufgabe des Benutzers gelöst ist? Zu beheben.
    3. Formulieren Sie Hypothesen. Zu beheben.
    4. Customer Journey Map.
    5. Arbeitsprototyp. MVP. Kundenentwicklung.
    6. Layouts. (Mit einer gut abgestimmten Arbeit des Teams und dem vorhandenen Konstruktionssystem können Sie auf Layouts verzichten.)

    Kundenaufgabe


    Es scheint, dass hier alles klar ist, oft aber nicht. Die Schnittstellenhypothesen werden mit den Aufgaben des Kunden verwechselt. Sie werden von den Wishlist-Managern herausgegeben und im Allgemeinen für nicht die schönsten Manipulationen des Teams verwendet.


    Die Aufgabe des Kunden wird entweder aufgrund von Beschwerden ("Klientenschmerzen") oder Bedarfsforschung identifiziert.


    (Wir stellen nebenbei fest, dass eine Beschwerde und eine Aufgabe unterschiedliche Dinge sind, und es ist wichtig, einen kühlen Kopf zu bewahren und nicht zu eilen, um "ein Problem" auf der Grundlage einer Beschwerde zu lösen - die Aufgabe kann anders sein, und die Beschwerde wird durch nicht verwandte Umstände verursacht. Kommt mit der Erfahrung Manchmal hilft es, dem Grund auf den Grund zu gehen, aus dem eine objektive Aufgabe formuliert werden kann.)


    Wenn die Aufgabe erfüllt ist, wird sie in Form einer User Story aufgezeichnet. Es wurden viele Artikel und Bücher darüber geschrieben, daher werde ich es hier nicht wiederholen - studiere auf eigene Faust.


    Zum Eintauchen in die Frage 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. Formulierte Antwort auf die Frage "Wie verstehen wir, dass die Aufgabe des Benutzers gelöst ist?" Was wollen wir als Lösung?
    2. Digital: relative und absolute Werte. Häufiger über quantitative Indikatoren (finanziell, Geschwindigkeit, Kunden, Zeit). Wie verstehen wir, dass die Lösung erfolgreich ist?Es gibt einen Trick: In Präsentationen verstecken, übertreiben oder verlieren sie oft den objektiven Entscheidungsspielraum für relative Größenordnungen. Zum Beispiel "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 ihrer Verwaltung), ist dies bereits eine beeindruckende Zahl, obwohl es wie eine Kleinigkeit erscheint. Andererseits ist "300% Gewinnwachstum", wenn es 300 Rubel pro Monat ist, bereits eine zweifelhafte Zahl. Wenn wiederum 150.000 Menschen einen statistischen Fehler in Bezug auf die Größe des Publikums für das gesamte Produkt darstellen (z. B. das Aufrufen der Hauptseite einer Suchmaschine pro Jahr), können diese Dimensionen höchstwahrscheinlich vernachlässigt werden, obwohl wir über die Bevölkerung dieser sehr urbanen Siedlung sprechen.

    Es stellt sich oft heraus, dass Metriken durchdacht werden, nachdem ein Produkt oder eine Funktion bereits erstellt wurde. Für Berichte und schöne Präsentation. Das ist traurig und zeigt keine Beherrschung, aber im Gegenteil, verdirbt das Bild und schafft ein falsches Gefühl der Ruhe (Zahlung kommt immer). Die Situation wird sehr gut durch einen Witz über den besten Bogenschützen der Welt veranschaulicht.


    Scherz pro Bogenschütze

    Лучший в мире лучник


    Жил-был лучший в мире лучник. Допустим, дело было в Японии — для остроты сюжета. Он мог поразить цель лучше всех с самой большой дистанции, и даже как Робин Гуд попасть в собственную стрелу. Лучник путешествовал по стране и удивлял своим мастерством окружающих, делился опытом.


    В одной деревне он обнаружил множество пораженных целей, и были они в самых неожиданных и труднодоступных местах. Лучник понял, что здесь живет Мастер, уровня искусности которого ему никогда не достичь.


    Лучник понял, что миссия его выполнена и дальше жить смысла нет. Он готовился сделать ритуальное самоубийство — сепукку — когда мимо него проходил крестьянин.


    — Что случилось, Лучник? — удивился крестьянин.


    — Я обнаружил, что в вашем поселении обитает Великий Мастер, который значительно превосходит меня в умении, посему миссия моя выполнена и я могу оставить этот мир.


    — Ты наверное говоришь про пораженные цели в самых причудливых местах? — внезапно догадался крестьянин.


    — О да, ты прав — с сожалением молвил Лучник.


    — О Лучник! Знай: это — проделки местного дурачка. Он выпускает стрелы наугад, а мишени обводит позже. Мы все жалеем его. Ты ошибаешься.



    Hypothese - die Antwort auf die Frage nach der schnellsten Lösung eines Benutzerproblems.


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


    Mache geistige Arbeit und finde mindestens drei verschiedene Lösungen.


    Denken Sie daran, dass die „Entwicklung“ einer Idee in Form eines sich allmählich ändernden Layouts eine Entscheidung ist und nicht drei (oder wie viele verschiedene Layouts Sie erstellt haben).


    Versuchen Sie der Einfachheit halber drei Ansätze:


    1. Schnittstellenlösung. Sie können auch mehrere sein.
    2. Automatisch (z. B. wird beim Auftreten eines Ereignisses eine Task auf dem Server ausgeführt) - ohne Eingreifen des Benutzers.
    3. Prozesse - Was kann in Prozessen geändert werden, so dass der Benutzer überhaupt nicht auf eine Aufgabe stößt, sondern im richtigen Moment eine Lösung erhält.

    Die beste Lösung wird ausschließlich empirisch gefunden (siehe „Wissenschaftliche Methode“). Jede auf den ersten Blick wildeste Entscheidung / Idee sollte geprüft werden. Hypothesen müssen geprüft werden. Idealerweise sollten alle drei Hypothesen in Form von MVP getestet werden. Dafür machen Sie einen Prototyp.


    Customer Journey Map stürzt den Kontext ab


    Wenn Sie ein kleines Produkt mit einer einzigen Funktion haben, können Sie mit CJM den gesamten Prozess der Problemlösung durch einen Benutzer sehen und Schmerzpunkte erkennen und die tatsächliche Durchführung einer Aufgabe erkennen.


    Wenn es sich bei einer Aufgabe um das Studium einer Funktion in einer vorhandenen Anwendung handelt, taucht CJM in den Kontext ein und bietet eine nahtlose, nahtlose Lösung für das Problem. Durch das Ignorieren des Kontexts erstellen Designer und Produktmanager häufig einen "neuen Abschnitt", der Entitäten repliziert, die Navigation kompliziert und die Benutzeroberfläche verwirrt.


    Über CJM wurde schon viel geschrieben, Sie müssen es selbst studieren und in Ihrer Arbeit anwenden.


    Sie können mit Jeff Pattons User Stories beginnen .


    Arbeitsprototyp. MVP. Kundenentwicklung.


    Stimmen Sie sich mit dem Entwickler ab und erstellen Sie einen Prototyp, um jede Hypothese zu testen. Dies ist nicht unbedingt eine technisch und ästhetisch perfekte Lösung - es ist wichtig, ein minimal realisierbares Produkt ( MVP ) zu entwickeln, in das neue und bestehende Kunden eingebunden werden können (Kundenentwicklung).


    Lesen Sie mehr darüber in dem Buch von Eric Rees „Business from scratch. Die Lean Startup-Methode zum schnellen Testen von Ideen und Auswählen eines Geschäftsmodells . Das Buch zu erzählen macht keinen Sinn.


    Wenn Sie mit dem Begriff " MVP" nicht vertraut sind , beginnen Sie mit einem Artikel in Wikipedia . Das Buch ist jedoch viel nützlicher.


    Auf Layouts verzichten wir, denn es gibt ein fertiges Produkt


    Während der Entwicklung von MVP- und Prototypentests werden Sie wahrscheinlich in jeder Lieferung und nach jeder Feedback-Sitzung der Benutzer eine Menge kleiner Dinge verfeinern. Das Maximum, das getan werden muss, ist, die Bildschirme der fertigen Lösung stilgerecht auszurichten und erneut zu testen. Ein neuer Blick auf das Produkt kann zu neuen Lösungen führen, etwas noch mehr vereinfachen und überdenken, das Ergebnis für den Benutzer noch komfortabler und attraktiver machen - hier zeigt sich Mehrwert.


    Zum Mitnehmen


    User Story
    Wie definieren wir Erfolg ?
    Hypothese (Lösungen)
    CJM
    Prototyp, MVP,
    Kundenentwicklungslayouts ( falls erforderlich)

    Zur Information


    Das Größte, was du tun kannst


    In letzter Zeit ist es zunehmend notwendig, zu wiederholen, dass ein Produkt / Unternehmen so gut ist, wie seine schlechteste Komponente funktionieren kann. Er wiederholte bei Vorträgen und erzählte neue Mitarbeiter.


    Wir müssen erklären.


    Zum Beispiel haben Designer ein super cooles Konzept entwickelt, das alle Aufgaben des Benutzers löst. Schön, mit angemessenen Animationen, unter Berücksichtigung aller Grenzfälle. Superhelden. Das Produkt wurde jedoch mit großen Unstimmigkeiten bei den Kleinigkeiten zum Kunden ausgerollt: Selbst wenn sich die Jungs zurückgezogen haben, aber jemand an der Front machte Kompromisse, das defekte Produkt erreichte den Kunden. Und die Bewertung durch den Benutzer und die Zuschauer richtet sich danach, welches Produkt in die Schlacht gebracht wird, und nicht danach, wie cool das Konzept gemacht wurde und welche schönen Bilder der Designer gemacht hat.


    Nun, oder mit dem Thema der Sites: Selbst wenn es ein Team talentierter Entwickler gibt, aber im Team höllischer Designer, dann wird ihr talentiertes Potenzial nicht offenbart. Und wird ein Potenzial bleiben. Nicht realisierte Gelegenheit, da das Maximum, das in Form eines Produkts angegeben werden kann, den Kunden erreicht.


    Oder wenn der Rücken so offen ist, dass Designer ausschließlich Krücken bauen. Sie verbringen Zeit damit, buchstäblich schlechte Schnittstellen (für das Gehalt) zu erfinden, weil sie nicht darüber nachdenken, wie die Benutzererfahrung verbessert werden kann, sondern wie sie an die Prozesse angepasst werden müssen. Dies ist keine Phantasie, dies ist eine Realität (wenn Sie über die Einschränkungen der Systemfähigkeiten informiert werden, stellt sich der Unsinn heraus, nicht „Einschränkungen“; bieten Sie diesen Kunden Limiter an, um diesen Unsinn von der Straße zu erklären - Sie werden etwas mehr Unterhaltung bekommen).


    Analogie aus der physischen Welt: Wenn schlechte Räder an einem Rennwagen montiert sind, wird es nicht cool. Wird genau so weit gehen, wie sie die gleichen Räder ziehen können. Auch wenn alles andere super cool ist: ein kraftvoller Motor, überall solider Carbon usw. - auf Felgen kann man nicht schnell gehen. Obwohl der Ingenieur höchstwahrscheinlich super cool war, war das Auto erst einmal geschaffen. Dasselbe gilt für Banken, Anwendungen, Studios, Verlage, Agenturen usw. Je größer die Toleranz für Mittelmäßigkeit und Fehler (dies wird als "Kompromiss" bezeichnet), desto schlechter wird das Produkt / die Firma sein. Das Produkt / die Firma ist so gut wie der schlechteste Angestellte oder Prozess: Der Laden kann phänomenal coole / seltene Produkte haben, aber wenn der Verkäufer unhöflich ist, wird der Verkauf schwach.


    Ich denke, die Idee ist schon lange klar.


    Es stellt sich heraus, dass viele nicht verstehen.


    Warum darüber schreiben?


    Dann, damit die Anfänger / Fortgeschrittenen kein eigenes Gefühl für ihre eigene Coolness haben (falsch) und sich nicht darauf konzentrieren, wie und mit welchen coolen Modellen sie versandt werden können, sondern auf das Ergebnis, das sie dem Benutzer geben können. Was bei der Arbeit wichtig ist, ist das, was und als Ergebnis die Kunden erhalten. Natürlich, wenn es wichtig ist, das Produkt herzustellen, nicht die Bilder zu versenden.

    Das Prinzip gilt überall, nicht nur für Produkte.


    Zur Hälfte


    Ein Blick auf das Layout: Wie löst man das Problem mit der Hälfte der Oberflächenelemente?


    Den halben Text entfernen? Zweimal kürzer formulieren?


    Wie kann das Problem in der Hälfte der vorgesehenen Zeit gelöst werden?


    Treffen Sie sich in 30 Minuten anstatt einer Stunde? Im Allgemeinen abbrechen?


    Grafiken entfernen? Mach es überhaupt nicht anfangs?


    Brauche ich Icons?


    Was passiert, wenn Sie die Hälfte der Elemente in der Navigation entfernen?


    Akzeptanz - um das Ziel zu fixieren und alles Unnötige abzuschneiden, das nicht zu dem zu lösenden Problem passt. Es kann pro Zeit nur ein Ziel geben.


    Wenn weitere Ideen vorhanden sind, können Sie diese in den Backlog aufnehmen. Baclog kann kein verbindlicher Rahmen sein - das Leben ist reicher als Pläne, Sie müssen flexibel auf die Realität reagieren: Feedback annehmen und analysieren, Lebensmittelkennzahlen verfolgen. Viele der Konstruierten werden in der Testphase nutzlos sein.


    Delhi um zwei.


    Im weiteren Sinne empfehle ich, sich mit dem Prinzip von " Occam's Razor " vertraut zu machen , wenn Sie immer noch nicht wissen, was es ist.


    Wissenschaftliche Methode


    Ich mag einfache, verständliche Ansätze in der wissenschaftlichen Welt. Zum Beispiel die evidenzbasierte Medizin. Und die wissenschaftliche Methode im weiteren Sinne. Natürlich werden solche praktischen Dinge irgendwie überarbeitet und für ihre Arbeit angepasst. Es stellte sich also als eines meiner Prinzipien für das Design von Lebensmitteln heraus.


    Zitat aus Wikipedia, um nicht zweimal aufzustehen

    «Нау́чный ме́тод — система категорий, ценностей, регулятивных принципов, методов обоснования, образцов и т.д., которыми руководствуется в своей деятельности научное сообщество.


    Метод включает в себя способы исследования феноменов, систематизацию, корректировку новых и полученных ранее знаний. Умозаключения и выводы делаются с помощью правил и принципов рассуждения на основе эмпирических (наблюдаемых и измеряемых) данных об объекте. Базой получения данных являются наблюдения и эксперименты. Для объяснения наблюдаемых фактов выдвигаются гипотезы и строятся теории, на основании которых в свою очередь строится модель изучаемого объекта.


    Важной стороной научного метода, его неотъемлемой частью для любой науки, является требование объективности, исключающее субъективное толкование результатов. Не должны приниматься на веру какие-либо утверждения, даже если они исходят от авторитетных учёных. Для обеспечения независимой проверки проводится документирование наблюдений, обеспечивается доступность для других учёных всех исходных данных, методик и результатов исследований. Это позволяет не только получить дополнительное подтверждение путём воспроизведения экспериментов, но и критически оценить степень адекватности (валидности) экспериментов и результатов по отношению к проверяемой теории.»



    In meiner Interpretation ist die Idee des Prinzips einfach: Nur gewaltsame Aufklärung ist gültig.


    Haben Sie eine Lösung gefunden? Kunden ausrollen Bestehen Sie auf einem anderen Hintergrund? In der Schlacht


    Alle Anträge müssen experimentell überprüft und verifiziert werden. In einer zivilisierten Umgebung werden sie Hypothesen genannt, in Laiengruppen - "Meinung" :-)


    Die experimentellen Bedingungen sollten transparent sein und gegebenenfalls von anderen Personen reproduziert werden.


    Um zu überprüfen, gibt es eine Reihe von Tools und Methoden. Alle Ergebnisse können digitalisiert werden: Trichter, Geschwindigkeit, die Summe der subjektiven Bewertungen usw.


    Zur gleichen Zeit rütteln alle Argumente, Visionen und so weiter die Luft, nichts mehr. Nur die Beobachtung des Verhaltens der Benutzer unter realen Bedingungen wird Antworten auf Fragen geben (und nicht ihre Meinungen und Geschichten).


    Außerdem: Nur im Kampf werden alle echten Vor- und Nachteile von Lösungen aufgezeigt, unaufgezeichnete Situationen entdeckt und echtes Feedback von Kunden gesammelt. Gleichzeitig führt dieses Feedback in verschiedenen Phasen der Produktentwicklung zu unterschiedlichen Konsequenzen: von der Änderung kritischer Indikatoren eines ausgereiften Produkts bis zu einer vollständigen Umkehrung / Konzeptänderung bei einem jungen Produkt.


    Nach diesem Prinzip komme ich zu diesen Überlegungen:


    1. Jedes Teammitglied kann es unabhängig von der formalen Rolle hypothetisch machen und testen: Designer, Produktkünstler, Entwickler von irgendetwas (vorne / hinten / Mitte und was sonst noch passiert). Jeder kann einen Beitrag zum Erreichen des Ergebnisses leisten. Teams sollten einen transparenten und einfachen Mechanismus für die Aufzeichnung und Einführung solcher Ideen in Betracht ziehen (wenn es viele davon gibt).
    2. Der Designer hat keinen Nachsicht, das Recht auf Recht, nur weil er Designer ist. In einigen Teams beobachte ich dieses Ungleichgewicht und in beide Richtungen: Entwickler und Produkte werden durch die Tatsache manipuliert, dass „sie warten, bis der Designer das Design erstellt“ (sie weigern sich, für sich selbst zu denken), gleichzeitig verwenden Designer häufig das, was sie in der Post haben. Designer “und für einige ist ein Berufstitel ein Argument in Streitfällen. Ein Produkt ist eine Kombination aller Bemühungen eines Spezialisten.
    3. Es kommt vor, dass die wildesten und auf den ersten Blick unlogischen Lösungen am besten funktionieren. Wir umgeben uns mit Vorurteilen und können nicht aus ihnen herauskommen, von der anderen Seite schauen - das ist wirklich sehr schwierig. Widerstand gegen Veränderungen wird immer einbezogen - sowohl innerhalb des Teams / der Organisation als auch der Kunden. Der einzige ehrliche Ausweg ist, entschlossen zu handeln, Risiken einzugehen, gewaltsam zu testen, Feedback zu sammeln, die Ergebnisse zu beobachten und darauf zu reagieren. Auf andere Weise erscheint nichts Interessantes. Festgestellt und bewiesen, dass das Ungewöhnliche vorgestern heute zur Norm und zur Alltäglichkeit von morgen wird - siehe " Das Everton-Fenster ".

    Gesamt


    1. Teste durch Kämpfen - geh zumindest für einen Teil des Publikums aus und teste alle Hypothesen.
    2. Alles digitalisiert - die Ergebnisse sollten transparent sein.
    3. Die "wildesten" Hypothesen müssen auch überprüfen können.
    4. Alles, was nur durch "Expertenmeinung" und "Erfahrung" (in bestimmten Schnittstellen- / Produktlösungen) unterstützt wird, wird kühn an die Mülltonne gesendet - Sie müssen sich nur auf das Verhalten der realen Benutzer konzentrieren.

    Und noch ein Bonus


    Ich habe eine thematische Zusammenstellung gemacht - meistens über Design. Seit ich die Bank verlassen habe, gab es auch eine unvermeidliche Reflexion über das Thema Design in einer Corporation. Ein Blick auf die Arbeit ohne rosarote Brille.


    Laden Sie ePub herunter


    Schauen Sie sich den Inhalt der Sammlung an

    Дизайнер 2022, по мотивам лекции в Сочи.


    Мысли на тему развития профессии дизайнера в ближайшие пять лет. Лекцию готовил для студентов и школьников, и для России, поэтому она затрагивает вопросы демографии, ретроспективу (как было 20 и 10 лет назад) и фантазии на тему среднесрочной перспективы.


    ***


    Дизайн цифровых продуктов — обещанный текст лекции из трёх частей:


    1. Цель дизайнера цифровых продуктов
    2. Роль дизайнера в продуктовой команде
    3. Метод — как работать над продуктом. Этот метод был описан для дизайнеров в Альфе, чтобы донести до новобранцев суть работы и ожидания.

    Надо понимать что речь там идёт по большей части о работе в скрам-командах, а это исторически мой любимый формат сотрудничества.

    ***

    Тройка принципов: чем я часто руководствуюсь в работе над продуктом:

    • Научный метод
    • Пополам
    • Самое большое, на что вы способны

    ***

    Инструкции или «Секретный секрет успешного успеха в успехе» — почему у вас не работает то, что работает у других и как мы себя научились обманывать.

    ***

    Ловушка корпорации

    На удивление для меня, резонирующий пост; даже незнакомые мне люди писали и обсуждали, даже просили перевести на английский чтобы дать почитать коллегам в других странах.

    ***

    Рекрутмент как продукт или «Ваня, найди нам дизайнеров!» —

    подробное описание кейса разработки продукта с нуля, внутри корпорации. Я люблю эту историю, она вдохновила многих знакомых и бывших коллег, а ещё её рассказывали (уже без меня) эйчары Альфы на паре митапов и конференций.

    Пост я приправил ссылками на все артефакты процесса — наши посты, публикацию Молиноса, статью в Коммерсанте и так далее. Мне самому было интересно сравнить то, как я думал год назад с тем, что я написал спустя год после запуска проекта. Этот феномен описан в одной из научных публикаций Умберто Эко, а здесь я посмотрел как это работает на своем примере. Занимательно.

    ***

    Мой первый продукт —

    история про то, как мы с одноклассником сделали настоящий продукт, из которого получилась компания. История аж из 1998 года, но очень показательная, рассказывает о том, как сложились мои принципы и подходы, которые я применяю в работе и о которых я здесь иногда пишу.

    ***

    И о спорте

    Считаю, что за пределами профессиональных тем забыты и напрасно оставлены темы физической культуры. Кто меня помнит хотя бы даже трехлетней давности — поймёт, о чем я: суета и работа довели меня до истощения и выглядело это ужасно. Надеюсь, этот текст поможет ещё кому-то крепко задуматься о своём здоровье заблаговременно, не дожидаясь печальных результатов какие были у меня.

    Jetzt auch beliebt: