10 ноября 2014 в 21:55

Бородатые дизайнеры о дизайне думают в последнюю очередь

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

Итак, речь пойдет о дизайнерах в маленьких компаниях. Но не о тех, кто рисует одноразовые художественные промо-сайты (где часто работает подход «чем оригинальнее, тем лучше»), а о тех, кто создает функциональные, полезные приложения и веб-интерфейсы, рассчитанные на долгосрочное использование. Вроде бы, какая разница, что рисовать – везде кнопки, странички, картинки, текст… А вот и нет. Это совершенно разные задачи и решать их должны люди с совершенно разными навыками и талантами. Но, обо всем по порядку.

Что не так


Заглянем в обычную среднестатистическую компанию, в которой начинается разработка продукта. В голове у руководителя есть видение будущей системы, он понимает, что хочет от нее получить. Какие-то схемы и куски интерфейса нарисованы на бумаге, функционал частично описан в виде текста и диаграмм, бывает, что даже есть ТЗ. Приглашается дизайнер, чтобы нарисовать красивый интерфейс. Загвоздка в том, что ставя задачу дизайнеру, директор представляет себе только основные сценарии работы продукта, причем идеальной ситуации. Отдельно выделенных архитекторов, проектировщиков и юзабилити специалистов, как правило, нет (мы говорим о маленьких компаниях). Поэтому, часто задача выглядит неполно, противоречиво и непродуманно. Заполнять пустые места и устранять противоречия в постановке приходится самому дизайнеру. И от того, насколько грамотно он это сделает, зависит успех проекта.

По моему опыту, если дизайнер просто отрисовывает то, что ему говорят, то в большинстве случаев получается старательно нарисованная бесполезная картинка. На этапе внедрения половина красивого макета разъезжается, т.к. он натягивается на реальные данные, обнаруживаются нестыковки в навигации и др. Результат не нравится ни самому дизайнеру, ни директору (или заказчику). После этого либо все остается как есть, либо начинаются утомительные переделки, ведущие к костылям и подпоркам. Кто виноват – дизайнер?



От большего к меньшему


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

Начав с целей пользователей и основных сценариев взаимодействия их с продуктом, мы сможем посмотреть на систему «с высоты птичьего полета». Сфокусироваться на основных частях системы и проследить основной путь пользователя от входа в приложение до целевого действия, и все свои усилия сконцентрировать на том, чтобы сделать этот путь наиболее понятным и удобным. Этот подход называется «целеориентированным» и очень хорошо описывается в книге Алана Купера «Об интерфейсе. Основы проектирования взаимодействия».

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

У нас будет гораздо более сильная позиция, если мы видим, что эти решения помогают в достижении наших целей и если пользователи понимают, что и как они могут делать на странице и ведут себя так, как мы хотим. Как написал Эрик Рис в книге «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»:
«Хороший дизайн – тот, который меняет поведение потребителей к лучшему».

И это единственный объективный критерий хорошего дизайна. И вот вам еще одно высказывание на эту тему из книги Getting Real компании 37signals. Тут нет слово «Дизайнер», но по-моему, к нам эта фраза относится напрямую:
«Лучшие проектировщики и лучшие программисты – не те, у кого лучшие навыки, или самые проворные пальцы, или не те, кто может сделать красивый макет в Photoshop, – это те, кто может определить, что имеет значение. Это те, кто принимает выгоды от решения.»

Думать не надо рисовать


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

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



Можно, конечно, не высовываться и аккуратно отрисовывать все, что говорят. А когда на свет появится очередной зомби-проект, развести руками и сказать «Вы сами настояли на таком решении, оно мне сразу не нравилось». Но, лично мое мнение, это – слабая позиция. Мы – дизайнеры – ребята амбициозные. Нам важно гордиться своей работой и наполнять портфолио живыми эффектными работами. Поэтому такой подход не для нас.

Возможно, многие со мной не согласятся и скажут, что дело дизайнера – рисовать, а не гайки крутить. И если руководитель не дал нормального ТЗ, то сам виноват, пусть ищет проектировщика или информационного архитектора, чтобы тот все продумал. Для крупных компаний это имеет смысл, но для шустрой и легкой команды стартапа такой подход неоправдан. Здесь каждый должен быть универсалом, быстро обучаться и нести ответственность за успех проекта. Так, что учитесь проектировать, определять цели пользователей, и думать обо всем проекте сразу. А если вы при этом сможете писать техническую документацию и тексты на сайт, общаться с клиентами, немного верстать и разбираться в архитектуре приложения, то вы станете гораздо более полезным для всей команды и ваш дизайн от этого только выиграет.

Изменчивость задачи


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

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

Короче говоря


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

Просто так рисовать красивые кнопочки – скучно и быстро надоедает. Ворчать на тему того, что нам плохо поставили задачу – непрофессионально. Мы легко можем превратить нашу работу во что-то гораздо более интересное и полезное, так почему бы этого не сделать?

Ольга Шаврина @Lo_ony
карма
9,2
рейтинг 0,0
UI/UX дизайнер
Похожие публикации

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

  • +4
    Предлагаю задуматься о понятии дизайна.
    Если мы говорим о дизайне как наборе эстетических элементов (цвета кнопочек, шрифты, оформление того или иного элемента), то на этапе проектирования интерфейса это вообще не нужно.
    Но на самом деле не забываем, что «дизайн» от слова «design», т.е. проект, прототип, функциональность…
    Мы часто подменяем эти понятия. На этапе создания интерфейса приложения надо думать о поведении пользователя, о том, как он будет взаимодействовать с интерфейсом. Исходя из этого, на каком-то завершающем этапе проектирования, приглашаем «дизайнера», которому предоставим макет с контентом, и попросим его отрисовать иконки, настроить шрифты, цвета и т.д.
    • 0
      Не соглашусь, мне дизайнер нужен и на начальных этапах. Звучит странно, но пользователь обычно подменяет себе понятия удобства и эстетики. Если кнопочки нарисованы красиво, он скажет «Ух ты, какое удобное приложение!» и, несмотря на то, что это всего лишь кривой прототип, попытается с ним работать и даст мне бесценный материал на тему будущих улучшений и оптимизаций.

      Но и здесь есть место только для художника-оператора фотошопа, который должен следить за мировыми трендами (какими бы ужасными они ни казались) и рисовать красивые интерфейсы. Однако придумывать логику работы программы он не должен и не может.
      • +3
        Мне кажется, вы путается понятия дизайн и UX. Еще Купер писал, что на первом этапе приложением должен заниматься архитектор UX, а задача — дизайнера на основе исследования UX создать интерфейс.
        • –1
          Я просто не считаю его подход оправданным. Сами смотрите: если держать UX в штате, то именно он будет создавать интерфейс, который затем раскрасит художник — но тогда мы ждем, что прототип изначально будет более-менее привлекателен. Если функции UX выполняет автор концепции (что всё более актуально в мире гаджетов), то дизайнер нужен ему на всём этапе работ: кто-то должен оглядываться на тренд; для автора это убийство, а маркетолог рождает чудовищ — так что остается дизайнер.
          • +3
            но тогда мы ждем, что прототип изначально будет более-менее привлекателен
            Вот тут ошибка. Над привлекательностью должен работать один человек, а над проектированием взаимодействия — другой человек. Так же, как программист не может работать тестировщиком того же продукта. Абсолютно прямая аналогия. Результат деятельности одного человека = сырой материал для работы другого человека. Отдавать их одному человеку — да, можно. Но это несерьёзно.

            Почему так? Потому что в обоих случаях (создание ПО и создание UX) неизбежны компромиссы: всегда есть такие задачи, когда потраченные усилия несоизмеримы с результатом. Как эти компромиссы должны решаться? Во взаимодействии между людьми, а не в голове одного человека: «а ладно, ерунда, сделаю как проще, никто не заметит».
            • +1
              Я, в общем, именно об этом и говорю, нужно разделять функции: над внешним видом работает один, над логикой — другой, а не так, как описано в посте. Причем в течение всего цикла разработки. Сделали интерфейс — дизайнер его раскрасил — пустили в тестирование — учли ошибки — далее пункт 1. Часто такой подход приводит к тому, что дизайнер не сам рисует, а говорит верстальщику, что, куда, и как ставить, и это дизайнеров бесит. Но ничего, привыкают…
              • 0
                Еще более правильный подход, когда дизайнер в начале рисует набор UI элементов, а архитектор потом их раскидывает.
                • 0
                  Зачем? Обычно есть готовые пакеты элементов интерфейса, например Jquery UI. Но вот при их комбинировании в прототипах, как правило, и возникает каша. Именно на этом этапе у нас впервые зовут дизайнера: расставить их по сетке, установить визуальную иерархию элементов и следить за ней в дальнейшем.
                  • 0
                    Намного проще иметь сразу готовый «фирменный стиль» проекта — это уменьшает количество итераций при разработке и позволяет ускорить процесс внесения изменений. Архитектор сразу видит почти готовый результат, дизайнер не изобретает велосипед под каждый отдельный кейс, пм офигевает от скорости работы, панды размножаются в неволе. Рекомендую в общем.
                    PS «Установка визуальной иерархии» не входит в компетенцию дизайнера, имхо. Ну и сетку надо сразу готовую видеть.
                    • 0
                      А где ж его взять, этот стиль, если проект еще разрабатывается и непонятно, каким он будет?
                      • 0
                        По опыту скажу, есть откуда взять. То есть часто у клиента есть готовый фирменный стиль, по которому уже можно делать элементы интерфейса. Да и в общем случае набор элементов ни к чему не обязывает и не ограничивает разработчиков. Взять тот же Twitter Bootstrap, на нем делают самые разные проекты.
              • +1
                Скорее всего, это один из самых рациональных подходов, но так, к сожалению, бывает нечасто. В ряде случаев вообще приходится работать в условиях «пойди туда, не знаю куда, принеси то, не знаю что». Вот и получается ерунда.
        • 0
          Мне кажется, вы путается понятия дизайн и UX

          Если говорить по понятиям, то есть две конкретные вещи: «UI design» и «UX design». Всё.

          Ну по-русски да, часто мешают в кучу в разных сочетаниях, т.к. слово «дизайн» ≠ «design» почему-то…
          • 0
            Я бы разделил графический дизайн (цифровой художник, по сути) и UX/UI дизайн (т.к. интерфейсы — тоже часть опыта взаимодействия пользователя с системой)
            • +1
              А, ну да, понятие «UI design» тоже размыто. В общем, есть графические дизайнеры, а есть проектировщики взаимодействия.
    • 0
      Всё кроме
      на каком-то завершающем этапе проектирования, приглашаем «дизайнера», которому предоставим макет с контентом, и попросим его отрисовать иконки, настроить шрифты, цвета и т.д.

      Каким бы хорошим программистом/архитектором ты ни был. Для толкового проектирования серьёзного интерфейса без опыта и навыков настоящего UX-профессионала не обойтись.

      А вы описали случай, когда программист/архитектор/создатель проекта является UX-профессионалом. А это на самом деле редкость.
  • +1
    Прошу прощения за резкость, но это очередное нытье на тему «Сколько много всего, что не относится к моей специальности! Все такие „малопонимающие“ на работе, а я один копаю за всех и умею быть профессионалом». Не надо так.
    • 0
      Полностью поддерживаю. Дизайнеры думают, что типографика и цветовые комбинации это то от чего заказчик должен оргазмировать, едва увидев эскизы. Но на деле 15% непосредственно рисования и все остальное это грамотная и методичная работа с заказчиком, задача которой наглядно показать почему надо делать так и прочно убедить заказчика красноречием и доводами. И даже если он просит воплотить откровенную глупость всегда можно «скруглить» углы и шероховатости, чтобы и его не оскорбить и пользователям было удобно. Хороший дизайнер это хороший дипломат.

      Доходишь до этого со временем.
      • 0
        Правильно вы говорите.

        Разве что вместо «убедить заказчика» я бы сказал «выяснить цели и задачи заказчика, после чего подготовить решение, которое будет очевидно эти задачи решать». К сожалению, многие дизайнеры забывают о том, что их наняли для решения конкретной задачи, после чего поиск решения этой задачи заменяется на поиск подходящего тренда.
  • 0
    Большинство дизайнеров выросло из «рисовальщиков» людей со слабыми инженерными навыками. Этому способствует сама медиасреда: начиная от игр, заканчивая ширпотребной «фантастикой» типа железного человека, краеугольным камнем которых является «eye candy» — говоря по нашему свистелки и мигалки. Пожинаем плоды, то ли еще будет.

    • 0
      Ситуация катастрофическая. Сколько было сделано проектов, когда уже на стадии создания понимаешь, что оно не выстрелит из-за плохого дизайна. Но заказчику нравятся yoba-эффекты и анимации.
      • 0
        Катастрофическая для заказчика или вас? Если для заказчика, то это естественный отбор, пусть платит за свою недальновидность.
        • +1
          Мне же выгоднее, чтобы заказчик заработал стопицот миллионов и потом еще со мной работал. А когда люди спускают деньги в трубу, это плохо.
  • +2
    В данном процессе есть следующие роли персонажей:
    1) UX дизайнер (UI дизайнер, проектировщик взаимодействия, и т.д.)
    2) Графический дизайнер (визуальный дизйанер, художник и т.д.)
    3) Руководитель продукта (product manager. B данном случае, он просто руководитель).

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

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

    Поэтому, если у руководителя есть видение и даже наброски интерфейсов, как бы к ним не относился дизайнер, «дело дизайнера – рисовать, а не гайки крутить». ИМХО конечно, но вышеописанный сценарий я наблюдал неоднократно.

    Другое дело, что если руководитель не претендует на вникание в процесс создания продукта, тогда дизайнеру надо брать дело в свои руки и делать ставку на UX.

    Ну и идеальный вариант, когда есть и компетентный руководитель продукта и компетентный граф.дизайнер, которые отлично понимают пользователей, бизнес-цели и продукт и которым удается жестко разграничить свою деятельность в ходе работы над продуктом и наладить процесс взаимодействия. Но я такое наблюдал в жизни, увы, только один раз.
    • 0
      Поэтому, если у руководителя есть видение и даже наброски интерфейсов
      … то это отстой! Вот я сейчас пытался полтора года совмещать обязанности ПМ и UX-проектировщика (деля их с дизайнером). Маленькая компания, отдельного юзабилиста нет, всё понятно. В итоге, моё мнение — это безобразие, потому что те компромиссы, о которых я писал выше, возникают постоянно не только между UX-дизайнером и художником. Но и между ПМ и UX-дизайнером. А если они в одном лице (хотя так везде) — получается непонятно что.

      В итоге если оценивать последствия для фирмы — соотношение «цена/качество» было бы гораздо лучше, если бы наняли отдельного UX-проектировщика. Это, конечно, из разряда «если бы да кабы», но я уверен на 100%.
  • 0

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