Редактор GeekTimes
389,4
рейтинг
14 сентября 2014 в 03:01

Дриббблификация дизайнеров перевод

Примечание: Dribbble — сервис, где графические дизайнеры хвастаются друг перед другом своими работами.


Лишь одно из этих погодных приложений пытается решить насущную проблему.

В сообществе дизайнеров наблюдаются расходящиеся тенденции. С одной стороны мы наблюдаем интересные блоги от Райана Сингера и Джулии Жуо, которые развивают наше ремесло. С другой стороны, всё большее количество народу постят свои работы и обсуждают их на Dribbble, что в целом двигает наше ремесло в обратную сторону. Этот пост – не про Dribbble, как таковой, он про то, что ценит это сообщество. Я буду использовать термин «дизайн продукта», но также буду иметь в виду дизайн пользовательских взаимодействий с продуктом.

«Выглядит круто!» — как сообщество Dribbble вознаграждает поверхностные работы


За прошлый год я ознакомился со множеством дизайнерских резюме, и обнаружил беспокоящую меня тенденцию, Слишком многие дизайнеры делают свои работы, чтобы впечатлить коллег, а не чтобы решать реальные проблемы бизнеса. Это долго было проблемой в рекламе, когда собирали награды креативные работы, вместо тех, что решают проблемы клиентов. Теперь это всё более очевидно в дизайне продуктов и взаимодействий.

Приличная часть работ, созданная соискателями, была поверхностной, созданной с оглядкой на Dribbble. Нечто, что хорошо выглядит, но плохо работает. Идеальные воплощения плоского дизайна, которые не достигают целей реального бизнеса, не решают каждодневных проблем, не рассматривают всю экосистему бизнеса. Dribbble располагает дискуссии к обсуждению цветовой палитры или всяких мелких поверхностных деталей интерфейса. Люди смотрят и эмулируют. Большинство работ на ресурсе похожи одна на другую. Социальный софт, софт для бухгалтерии, маркетинга, погоды – стили у них одинаковые. Попробуйте найти десять отличий:



Самая важная работа в продуктовом дизайне обычно самая уродливая


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

Худшие работы соискатели присылали в PNG. Никаких связей с решаемой проблемой, никаких бизнес- и технических ограничений, без контекста. Эти идеально выверенные, подготовленные для ретина-дисплеев PNGшки отлично смотрелись бы на Dribbble, но как реальный дизайн для реальных вещей они не представляли ценности.

Поэтому, редизайн работы других людей – это глупость. Новое лого Yahoo, iOS7, изменения Facebook, New New Twitter, ребрендинг American Airlines.

У занятых в этих проектах людей не было контекста для работы, не было информации об ограничениях и организационной политике.

Если дизайн продукта – это решение задач для людей, с соблюдением ограничений конкретного бизнеса, то чувствуется, что много людей, называющих себя дизайнерами продукта и UX, на самом деле просто дизайнеры цифровой графики. Художники. Стилисты. Создание прекрасных вещей – важный навык, но не навык практики продуктового дизайна.

Продуктовый дизайн – это миссия, видение, архитектура.


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

Миссия – для чего, кроме зарабатывания денег, существует компания? Её цели?

Видение – каким мы видим будущее компании? Как это поможет нам в достижении нашей миссии?

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

После этого настаёт время архитектуры продукта. Не технической, а просто какие части есть у продукта, и как они соотносятся между собой. Система. В первое утро первого рабочего дня в Facebook, Крис Кокс (вице-президент по продукту) даёт отличную вводную речь перед аудиторией из людей из всех департаментов.

Он мог бы говорить о чём угодно, но концентрируется он на объяснении архитектуры продукта, и о том, как он связан с миссией компании.

Для Facebook, архитектура – справочник по людям, их друзьям и их интересам. Справочник по бизнесам, от международных компаний до местных магазинчиков. И всё это имеет карту, показывающую взаимоотношения всех частей. Чёткое и ясное представление продукта, которое понятным образом связано с миссией. Очень сложно заниматься дизайном без хорошо определённой архитектуры продукта. Во многих случаях, дизайнер же и развивает эту архитектуру. Объясняя людям со стороны работу Facebook, я часто чертил подобные диаграммы:



Архитектура продукта – это не информационная архитектура. Это не набор страниц с перекрёстными ссылками, не демонстрация форм или объяснение работы кнопок. Прототип с этим лучше справится. Это на уровень ниже – это структура, это основные блоки. Объекты в системе и их взаимодействие. В компании Intercom мы также думаем о дизайне в контексте продуктовой архитектуры:



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

Как только вы чётко представили миссию, видение и архитектуру, можно думать о деталях. Цели, которые есть у людей, что делает их счастливыми, удовлетворёнными, успешными. Что ваш продукт делает для них, где он хорошо работает, а где – не очень.

Грубые наброски и каракули, описывающие эти вещи, более важны, чем png с Dribbble. С начала создания до поставки готового продукта, psd и png мне наименее интересны. Более важно – обсуждения того, какие были компромиссы, что было «за» и «против». Как идеи сочетаются с видением или улучшаются в связи с архитектурой продукта. Зарисовки на доске, на бумажках, на салфетках – вот, что нужно постить на Dribbble. Вот это мне покажите. Даже текстовое описание будущего продукта важнее, чем png, pdf и psd.

Четыре уровня дизайна


Дизайн – процесс многоуровневый. По моему опыту, есть оптимальный путь продвижения по ним. Проще всего представить эти уровни так:

Результат – чего мы хотим достичь. Что людям станет лучше и легче делать?

Структура – необходимые компоненты системы и связи между ними

Взаимодействие – микровзаимодействия. Последовательности поведения и событий. Компоненты интерфейса и как с ними работать. Что как движется, меняется? На этом этапе постоянно возвращайтесь к структуре и подгоняйте её.

Внешний вид – после прохождения предыдущих слоёв можно заняться внешним видом. Сделать всё красиво. Теперь уже можнозаниматься сетками, цветом, шрифтами и иконками.

Один за другим, дизайнеры концентрируются на четвёртом слое, не думая об остальных. Работают снизу вверх. Сетки, шрифты, цвет и эстетика не важны, если три первых слоя не отработаны. Многие говорят, что они их учитывают – но на самом деле пропускают, потому что рисовать красивые картинки всегда веселее и проще, чем рассматривать сложные бизнес-процессы и удовлетворять разные требования людей. Хорошо, оставайтесь на четвёртом уровне, но тогда это будет не дизайн, а цифровое искусство.

С повсеместным проникновением Сети дизайн будет значить всё больше


Изобретение Сети ведёт общество к сильнейшим изменениям со времён индустриальной революции. Веб проникает везде – в дома, на рабочие места, на прикроватную тумбочку и в карманы одежды. Веб всегда с нами. Он уже проник в автомобили, одежду, в вещи. К 2020 году любой бизнес будет связан с вебом. Как сказал Чарльз Эймс, «в конце концов всё соединяется».



Разработка статичных страничек с линками – умирающая профессия. Подъём мобильных технологий, API, SDK и открытых взаимодействий между платформами и продуктами рисует нам картину будущего, где все мы будем разрабатывать системы. PDF с каркасами и фотошоп с картинками – отмирающие инструменты. Продвинутые дизайнеры работают с набросками, досками и инструментами прототипирования (Quartz Composer, After Effects, Keynote, CSS/HTML).

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

Разработка дизайна в соответствии с Задачей


В компании Intercom мы работаем с «Фрейморком задач» Клэя Кристинсена. Офоромляем каждую задачу, фокусируясь на событии, которое её вызывает, мотивации, цели, и желаемом результате.

«Когда происходит ……, мне надо ……, чтобы я смог ……»

Пример: «Когда важный новый клиент логинится, мне надо об этом узнавать, чтобы я смог начать с ним диалог».

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

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

Примечания: четырёхуровневая модель является адаптацией шестиуровневой модели UX (предложение, концепция, структура, информация, взаимодействие, внешний вид), которую мы использовали лет восемь назад, а она в свою очередь произошла от диаграммы Джесси Джеймса Гаррета “The Elements of User Experience”.

В следующей статье автор даёт некоторые разъяснения и развивает тему.
Перевод: Paul Adams
Вячеслав Голованов @SLY_G
карма
125,2
рейтинг 389,4
Редактор GeekTimes
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (32)

  • 0
    Если дизайнер начнет писать код для проекта — он станет программистом (хотя лично мне больше нравится термин — «разработчик»).
    Хорошие full-stack разработчики и так — большая редкость, а с навыками дизайна и подавно, да и стоят они очень дорого.
    Т.е. это конечно замечательно — иметь в штате такого специалиста, но многие ли компании могут себе это позволить?
    • +2
      Да ладно, при чем тут код? Достаточно взять ручку и листочек и четко сформулировать задачу, обозначить контекст, в котором это задача решается (предметная область), выдвинуть идею как решить эту задачу — в случае дизайнера — на уровне UX / UI, словами и набросками.
      • 0
        При том, что автор именно это и предлагает:
        … дизайнеры должны писать код.
        Как я понял из статьи — автор пишет о дизайне в самом широком смысле.
        Т.е. применительно к разработке ПО — от дизайна базы данных до дизайна пользовательского интерфейса.
        По сути эффективно работать на всех описанных четырех уровнях дизайна ПО: Результат/Структура/Взаимодействие/Внешний вид — может только full-stack разработчик (вот такой например для веба). Т.е. такой дизайнер=разработчик должен обладать хорошими знаниями во всем стеке технологий, методик, подходов и т.д. в разработке своего продукта.
        Но такие специалисты по определению будут очень дорогими и соответственно не доступными для небольших проектов.
        Хотя возможно я не правильно понял автора статьи и речь идет о каких-то других дизайнерах.
        • 0
          Окей, действительно — статью прочитал не то что бы совсем по диагонали, но с купюрами — и фраза про «дизайнеры должы писать код» проскочила мимо :) И правда странное предложение. Как UX соотносится с кодом — мне не очень понятно. Задача все-таки гораздо более общая, код — очень низкоуровнево уже. Хотя техническая грамотность дизайнера, конечно, очень желательна, т.к. позволяет экономить на коммуникации.
          • 0
            С купюрами был перевод. Более точно по смыслу:

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

            Судя по списку програм, которые приводит автор, и по упоминанию о библиотеках вместо фотошопа, речь идет не о полновесном программировании, а о некоторых технических навыках.
    • 0
      Если дизайнер пишет HTML/CSS, то это очень здорово и логично. У меня такие ребята вызывают дикое уважение. А что касается дриббблизация, не знаю насколько качественно все могут разработать структуру, но «покрасят» отлично)
  • +16
    Я дизайнер который умеет писать код, иногда бывает даже стыдно в этом признаваться, т.к. некоторые дизайнеры считают это неправильным. Я уверенно владею HTML/CSS ( + Sass), так же на базовом уровне выучил джаваскрипт, чтобы иметь возможность создать некий базовый функционал в основном для UI. Я считаю, что умение писать код для дизайнера не must, но большое преимущество.

    Умение писать код позволяет лучше понять как продукт работает, что можно делать, а что нельзя.

    Насчет Dribbble, этот сервис изначально был создан для людей которым важно внимание к деталям. Туда выкладывают небольшие детали проектов, а не сами проекты.

    Вот сюда я выложил проект целиком:
    www.behance.net/gallery/19665371/Games-Catalog-mobile-APP

    А на dribbble я выложил только анимацию прелоадера:
    dribbble.com/shots/1719391-Simple-clock-loader-Animation
  • –3
    Я так и не понял претензию автора к Dribbble. Для меня Dribbble — это площадка, куда выкладываются концепты дизайнов чего-угодно. При чем здесь вообще бизнес?
    • +6
      Этот пост – не про Dribbble, как таковой, он про то, что ценит это сообщество.
      Слишком многие дизайнеры делают свои работы, чтобы впечатлить коллег, а не чтобы решать реальные проблемы бизнеса.
      Приличная часть работ, созданная соискателями, была поверхностной, созданной с оглядкой на Dribbble. Нечто, что хорошо выглядит, но плохо работает
      Вроде так.
    • +11
      Как я понял, при том, что dribbble набрал популярность, и теперь все начинающие дизайнеры думают, что эти красивости — это и есть работа дизайнера продукта, в то время как это всего лишь её малая и не самая важная часть.
      • +4
        Пффф. Большинство этих как бы дизайнеров дизайнера не являются. Таков бич нашей профессии. Большинство людей считает, что дизайн это когда красиво. Даже тут, на Хабре, где вроде бы много образованных людей, мало кто знает, что дизайн — это красиво + функционально.

        Бороться с этим почти бесполезно.

  • +2
    Верно, дизайн над UX преобладает все больше и больше. И в большинстве случаев создается дизайн ради дизайна, без исследований, прототипов, изучения поведения пользователя в интерфейсе.

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

    Сейчас каждый уважающий себя дизайнер должен хотя бы иметь представление о том, как работают интерфейсы технически, о CSS/HTML хотя бы на уровне фреймворков. Не требуется же писать на pure — существует огромное количество фреймворков, которые облегчают процесс создания прототипов без не нужного углубления в дебри.

    Что касается меня, то да, я сам часто пользуюсь css/js для прототипирования. Почему? Потому что это удобно, быстро и красиво. И в этом нет ничего сложного. Например, FramerJS — framerjs.com. Отличный способ создать прототип интерфейса приложения на js/coffee — на чем угодно.

    А кто желает инвайт на Dribbble — welcome drbl.in/mmhp
    • +1
      Сейчас подумал, а разве не всегда так было? И это «больше» получается лишь от количественного роста.
      Просто раньше не было возможности у машин поддерживать творческие порывы, а как только мощности появились то всё, разноцветные менюшки, тени, яркие картинки, вспомнить-то ранний веб и GUI.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Я имел ввиду визуальный дизайн.
  • +1
    Не стоит так уж серьезно относиться к дриббблу. Это как если критиковать твиты финансового специалиста за то, что он написал о том, что сдал наконец финансовый отчет. А где сам отчет? Как ты к нему пришел? Где заветные цифры?

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

    А в остальном, думаю, полезная статья. Оказывается применял многое из того, что вы описали, но на подсознательном уровне. Рано или поздно любой адекватный дизайнер, если у него появится достаточный опыт, должен сам прийти к какому то алгоритму работы над тем или иным проектом.

  • 0
    Отчасти, эта нежизнеспособная карамель — эхо бутафорских «интерфейсов» из «железного человека», «особого мнения», «трона» и т.п.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Graphic designer и UX designer — две разные профессии. Дрибл с его красивостями для первых, а вторым часто бывает достаточно одноцветных вайрфреймов.
  • 0
    Уже давно ищу сотрудника, который будет подсказывать верстальщику (или билдеру), как лучше выстраивать и раскрашивать элементы интерфейса, а также самостоятельно улучшать внешний вид готовых интерфейсов. От него требуется отличный эстетический вкус, хорошее владение графическими редакторами и привычка уделять много времени мировым эстетическим трендам.

    Я всегда думал, что это дизайнер, но дизайнеры почему-то отказываются — говорят, что им западло быть «операторами фотошопа». Кого тогда я должен искать?
    • 0
      Вам нужен product designer, прежде всего заинтересованный в целом проекте, всех его этапах, с ответственностью за продукт который попадет в руки конечному потребителю. Потому что пользователи не с макетом работают, а со сверстанным по макету интерфейсу. И на этом этапе можно многое упустить без должного контроля качества.

      Так же дизайненр может создать ui-kit, из элементов и компонентов которого верстальщик уже будет собирать готовые интерфейсы, тем самым не задумываясь какой цвет выбрать для кнопки или прочего элемента. Но и без предварительного проектирования и прототипирования тут не обойдется: просто так ставить элементы или выбирать цвета нельзя, всегда стоит опираться на user-flow и UX в целом.
      • 0
        А у меня не продукт, а процесс: три (пока) вебсайта, в которых постоянно меняется структура контента и сервисы. Затем тестируются на аудитории и снова идут в обработку, и так уже два года. Я не могу позволить нам ждать, пока какой-то отдельный человек осмыслит всё, нарисует у себя, а потом еще будет дорабатывать, потому что не учел результатов последнего теста. Тем более, что к тому времени подоспеют новые тесты и требования. А если он член команды, то тем более должен большую часть работы проводить, корректируя верстальщика по ходу дела.
        • 0
          Тот, кто вам нужен, product designer-ом и называется нынче. Не задизайнил-выпустил-забыл, а как вы и сказали — поддерживает, мониторит и реагирует на изменения. Притом понимая и про стадии производства, и про юзера, и про бизнес. И есть слона он начнет по кусочкам и сейчас, а не целиком через год. Вот живой пример из мейл-ру: jvetrau ;]
          • 0
            Спасибо. Я пришел к выводу, что именно продукт-дизайнер и есть настоящий, правильный дизайнер с правильным подходом к делу. Всё остальное — от лукавого. А «задизайнил как нравится и бросил» — это для лохов, по сути.
    • 0
      Обычно нужных вам ребят называют техническими дизайнерами. Могут использовать и другие названия, например, дизайнер веб-контента.
  • 0
    Есть ли какие-нибудь нотации для описания структуры системы, чтобы создавать подобные диаграммы как в статье? Мне на ум приходит нотация IDEF0, но она больше подходит для описания бизнес-процессов.
  • +1
    7 лет переделываю дизайн одного продукта, доводя его до идеально работающего результата, так что от вашей статьи аж прослезился.
    +1
  • 0
    Есть еще проблема в формулировках — у нас слишком много описываеться термином «дизайн».

    Вот что я имею ввиду. В статье описан более глобальный вариант, но бывают задачи очень локальные. Вот лично мне доводилось делать дизайн по полностью готовым прототипам (axure). То есть это как бы и не дизайн, но все же красоту нужно было навести и выверить каждый пиксел (это, то чем занимаются люди с дриббл).

    Так что задачи бывают разные и разные специ нужны.

    Что касаеться статьи, то как по мне дизайнер продукта должен в первую очередь понимать цели пользователей, который продукт должен решить и это первостепенно. Мне тут не совсем понятно причем тут «миссия компании» и все такое. Если компания=продукт, то я согласен, а вот если нет, то…

    И, кстати, на каком-то уровне придется делать очень качественную картинку, чтобы привлечь внимание клиента или инвестора. Каким бы гениальным не был продукт, но если на «скринах» при продаже г**но, то продаж не будет.
    • +1
      И, кстати, на каком-то уровне придется делать очень качественную картинку, чтобы привлечь внимание клиента или инвестора. Каким бы гениальным не был продукт, но если на «скринах» при продаже г**но, то продаж не будет.

      Более того, бывают ситуации, когда по запросу продвигающих продажи приходится изменять интерфейс, понижая удобство пользования, но повышая его чисто визуальную привлекательность.
      Например, в серьезных приложениях, с которыми пользователь будет работать продолжительное время, некоторые недостатки вылезут не сразу, либо пользователь вообще не узнает, что на какой-то стадии разработки продукт был удобнее.
      Зато на решения о покупке «крутость» внешнего вида влияет, подчеркивая, что продукт инновационный.
      • 0
        Ну вообще странно, что нужно уменьшать удобство для внешнего вида. Что мешает навести лоск без ухудшения?
        • 0
          Простое наведение лоска имеет свои пределы.
          Например, продукт может содержать обилие таблиц, графиков и прочих элементов со сложной интерактивностью и кучей маркируемых состояний. Причем, большая часть цветовой шкалы отдана значащим цветам, которые нельзя использовать в интерфейсе. А продажники хотят, чтоб он не потерялся среди простых ярких приложний для гаджетов…
  • 0
    Хороший пример плохого дизайна на второй картинке — аватары в круглой рамке смотрятся круто, но абсолютно бесполезные в реальной жизни.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.