Важно говорить прямо: как живется UX/UI дизайнеру в технологической компании
Дизайн — творческая профессия, в том числе такая ее прикладная разновидность, как UX-дизайн. Каково быть творческим человеком, который работает в технологической компании? Мы в DDoS-Guard решили спросить об этом своих дизайнеров напрямую. Получилась объемная беседа об особенностях работы на технических специалистов, нюансах коммуникации и расширении персонального кругозора.
Кто мы: DDoS-GUARD — российский оператор связи, занимающий лидирующие позиции на рынке услуг по обеспечению защиты от DDoS-атак и доставке контента с 2011 года. Мы предоставляем защиту от распределенных атак типа «отказ в обслуживании» на всех основных уровнях по модели OSI: нарушение функционирования сетевой инфраструктуры (L3), эксплуатация слабых мест TCP-стека (L4), атака непосредственно на веб-приложения (L7).
Чем занимается UX/UI дизайнер
UX-дизайнер отвечает за «пользовательский опыт»: каким образом пользователь взаимодействует с интерфейсом сайта; какими должны быть диалоговые окна, кнопки, формы и другие элементы, чтобы сделать их максимально доступными и удобными.
UI-дизайнер подбирает подходящие для интерфейса сочетания цветов, шрифты и иконки. Все должно быть одновременно приятным глазу пользователя и интуитивно понятным его мозгу. Поскольку функциональность интерфейса и его внешний вид — это две неразрывно связанные части одного явления, наши специалисты занимаются ими одновременно.
Но даже это не полное описание комплекса задач, которые каждый день встают перед нашими дизайнерами. Есть, например, такое мнение:
Основной особенностью нашей работы является то, что мы работаем над онлайн продуктом. В разработке участвует большая команда людей, с которыми приходится взаимодействовать нам, дизайнерам интерфейсов, постепенно превращаясь в полноценных продуктовых дизайнеров. Фокус смещается на решение бизнес-задач, у каждого из нас происходит погружение в продукт команды. Дизайн должен быть уже не просто удобным, он должен быть эффективным, с точки зрения бизнеса, и приносить прибыль.
Жертвами нашей дружеской беседы были выбраны четыре сотрудника: Евгений Горлинский (команда L7), Мария Емелина (команда защиты сетевой инфраструктуры), Анастасия Белоусова (команда облачных сервисов) и Виктория Талашко (команда PR/Main).
Каждый продукт компании разрабатывается отдельной командой, и у каждого своя сложная техническая специфика. При этом очень важно при оформлении продуктовых страниц на сайте выдержать единый визуальный стиль.
Таким образом, перед нашими дизайнерами каждый день стоят такие задачи:
договариваться между собой;
вникать в происходящее, не будучи при этом техническим специалистом;
коммуницировать с разработчиками и Product Owner’ами (PO), у которых могут быть свои представления о прекрасном.
Коммуникация дизайнеров между собой
Основной потенциально сложный момент в работе дизайнера в технической компании — это коммуникация. Поначалу эта проблема стояла не так остро, так как наши дизайнеры рассредоточены по командам и направлениям, и их задачи также соприкасались минимально.
Когда началась разработка новой главной страницы сайта, обновление графических элементов, а также переосмысление дизайн-стратегии компании в целом, они пришли к выводу, что периодические собрания необходимы.
Проблема, которая затронула меня после перехода в продуктовую компанию: как скооперироваться со всеми дизайнерами со всех команд, чтобы все работали по одному принципу, и все макеты были одинаковыми. У каждого из нас свой опыт и свое видение работы (не говоря уже про видение прекрасного, терпеть не могу эту формулировку), поэтому мы постоянно обсуждаем любые мелочи в общем чате, и только так получается прийти к чему-то общему.
Между собой нашим дизайнерам найти общий язык достаточно просто. Но как обстоят дела с коммуникацией с людьми, будни которых проходят внутри строчек кода и менеджерских процессов?
Коммуникация с разработчиками
Мы спросили дизайнеров, с какими коммуникационными сложностями они сталкивались при общении разработчиками, получается ли у них найти компромисс и отстоять свое видение, если PO настаивает на собственных требованиях. Да и каково это вообще, создавать визуальную оболочку для продуктов, принцип работы которых ты можешь не понимать досконально?
Мне повезло с командой. Мне без проблем рассказывают необходимую техническую информацию («на пальцах»). Споры возникают нечасто, я обычно занимаю сторону обычного юзера, не сильно понимающего в технической части. А наши «технические» коллеги — сторону продвинутого юзера, и где-то на середине мы сходимся.
Все опрошенные однозначно высказались в пользу четко составленного ТЗ, которое опирается на первоочередные цели РО, маркетинга и SEO. Если же вопрос состоит именно в «субъективщине», то последнее слово остается за дизайнером как за специалистом по визуальной составляющей.
Если команда спорит с дизайнером по конкретному решению, очень выручает наличие согласованного UI-kit, где собраны все элементы дизайна и в целом выбранный визуальный стиль. Это делает дизайн однородным и минимизирует пустые споры.
Необходимо делегировать неналаженные бизнес-процессы. Дизайнер — это дизайнер. Не менеджер, не маркетолог, не SEO, не бизнес-аналитик. Задача должна пройти некоторый круг обсуждений и согласований. Если пропустить этот важный шаг, то с большой вероятностью работа уйдет «в стол».
Вечный вопрос для дизайнера: должен ли твой голос быть решающим или обязательно прислушиваться к требованиям РО? Для PO, вероятно, этот вопрос выглядит так: как понять, что дизайнер хороший, и в данном случае его решение верно?
Сложности во взаимодействии связаны с тем, что работа UX/UI дизайнера — это не только технические знания и понимание психологии пользователя, но и вопрос творчества, которое каждый человек оценивает по-своему. Каждая компания и каждая команда находит свой способ оценить работу дизайнеров: кто-то смотрит на конверсию и метрики продукта, кто-то коллективно оценивает визуальную составляющую макета, кто-то измеряет «хорошесть» дизайна оценкой заказчика.
Как правило, подобные ситуации можно разрешить простым человеческим «поговорить начистоту». Во время разговора запросто может выясниться, что например инициатор споров и правок боится, что клиенты не разберутся в интерфейсе, что продажи упадут, и тому подобное. В этом случае можно применять уже точечные аргументы, которые будут «закрывать» конкретные опасения.
Самое плохое, что может сделать дизайнер в таких сложных ситуациях, — это ставить себя в позицию самого умного, прекратить слушать и разговаривать. Любые сложные ситуации в работе дизайнером можно разрешить, если быть эмпатичным и понимающим человеком. Ваши коллеги — тоже люди, у них есть свои страхи, свой опыт, свой визуальный вкус. Соберите команду, задайте дружественный тон беседы и выясните, что движет вашими коллегами в споре и мотивирует постоянно вносить правки.
Как работать (почти) без референсов?
Специфика работы нашей компании в том, что сфера информационной безопасности и защиты от DDoS весьма узка и закрыта в силу своей природы и ситуации на рынке. Это создает ощутимые технические трудности для UX/UI дизайнера, которому нужно понимать логику взаимодействия пользователя с интерфейсом.
Особенность нашей ниши в том, что ты не найдешь в свободном доступе интерфейсы, чтобы проанализировать, как пользователь ведет себя, или понять, что ему предлагают конкуренты. Даже какие-то популярные сервисы из других сфер не предлагают удобных решений, нацеленных на реальных пользователей. Поэтому приходится погружаться глубоко в задачи и где-то придумывать свое решение, где-то подгонять решения под нужды нашей аудитории.
Технологические продукты, как правило, сложны для восприятия обычного пользователя. Исходя из этого возникает сложность: как сделать интерфейс таким, чтобы он был понятен и привычен?
В моей команде мы нашли решение этой проблемы: для любого функционала/заголовка/кнопки мы пишем подсказки или инструкции, где простыми словами рассказываем пользователю, что он может сделать на этой странице и что последует после каких-либо его действий.
Выводы и советы
Все дизайнеры, которых мы опросили, сходятся на том, что проблемы коммуникации можно решить с помощью двух ложек простого советского...
...с помощью коммуникации. Открытой и честной. Необходимо понимать, в чем корень вопросов, которые возникают — в непонимании со стороны команды или, может быть, в том, что дизайнер сам недопонял что-то с технической стороны.
Взаимная прозрачность и готовность мыслить outside the box требуется от обеих сторон: разработчики и РО должны уметь принимать творческие решения от дизайнеров, а дизайнеры — пытаться хотя бы в общих чертах понять, каким именно невидимым механизмам они придают понятный и красивый облик.
Напоследок мы попросили ребят поделиться советами, как, с их точки зрения, можно минимизировать бесконечный поток правок и наладить бизнес-процесс, чтобы жизнь дизайнера стала счастливее.
Насчет правок: всегда перед началом выполнения задачи нужно просить максимально развернутое ТЗ. В идеале должен быть шаблон/бриф, где менеджер или заказчик опишет все требования к макету, на какую аудиторию нацелен дизайн и тд. Такой подход поможет избежать бесконечного потока правок, потому что можно будет предъявить ТЗ и сказать, что дизайнер сделал все четко по нему. Также за любые пожелания или правки, которые приходят вне ТЗ, нужно брать доп. плату или решать, как можно компенсировать доп. работу. Дизайнеру в самом начале своей работы в компании/команде нужно расставить границы: в нерабочее время он не будет отвечать на звонки или сообщения; выполнять задачу — четко по брифу; любые правки должны быть компенсированы и так далее.
Что я считаю важным: хороший менеджмент, грамотно составленное ТЗ, собрания/обсуждения с дизайнерами-коллегами из других команд для создания общего стиля и решения насущных проблем.
Нужно осознавать, что сейчас дизайн — это не про красивую картинку, а про решение задач, часть из которых могут напрямую влиять на дальнейшее развитие бизнеса. Это делает роль дизайнера гораздо более важной и ценной.
Конечно, во время разработки прототипа и функционала у нас возникают спорные ситуации. В эти моменты главное не забывать, что ты — часть команды, а все мы нацелены на общий результат. И для меня важно услышать мнение команды. Если у нас возникают вопросы, то, скорее всего, они появятся и у пользователя. Можно быть даже супер крутым юзабилити-специалистом, но с реальной обратной связью все непонятное становится более понятным.
Скоро мы расскажем о UX-писателях и о том, чем они занимаются в DDoS-Guard. Если у вас есть вопросы об IT-профессиях, задавайте их в комментариях, а мы попросим коллег ответить на них в наших следующих постах.
Потрясающе)
Очень хорошая статья.
Мне нравится, что вы говорите не обо всяких там пресловутых идеальных исследованиях, юзабилити-тестированиях и так далее, а о реальной рабочей обстановке (хотя бы об аспекте коммуникации).
Аж прямо почувствовалось, что у вас настоящие дизайнеры в команде! :D