Публикации и ответы на комментарии в блогах JetBrains не выходят на русском языке с 2022 года.
Приносим извинения за неудобства.
«Хороший день — когда есть какой-то осязаемый результат, закончена задача или ее часть»
Одно из правил хорошего интервью гласит: задавайте вопросы, на которые вам интересно услышать ответы. Анна Гаспарян, руководитель отдела технической документации в JetBrains, расспросила Ольгу Бердникову обо всем, что ей хотелось узнать о дизайне продуктов, и об особенностях работы в этой сфере.
Давай прежде всего разберемся с терминологией. Речь о ролях UX-проектировщика и UI-дизайнера. В моем понимании, UX-проектирование больше связано с аналитикой и исследовательской деятельностью, а UI-дизайн — с визуальным дизайном. Есть ли действительно между ними разница, и, если да, кем ты сама себя считаешь?
Для меня нет разницы между дизайнером и проектировщиком. По моему опыту, попытки их поделить скорее приводят к проблемам. Представим, что проектировщик приносит схему с квадратиками и стрелочками, а потом графический дизайнер их раскрашивает, добавляет тени и градиенты, и как будто получается классно. Скорее всего нет, потому что в раскрашивании тоже кроется UX. Для хорошего графического представления тоже важно понимать привычки пользователей, на что обратить их внимание, как помочь разобраться с информацией на экране быстрее.
Ольга Бердникова, UI/UX-дизайнер в JetBrains
Ну то есть это разные этапы одного процесса?
Да. На мой взгляд, их не нужно делить, там не такой разный набор знаний. Я считаю, что дизайнер интерфейсов должен на входе получать проблемы и потребности пользователей, а на выходе отдавать разработчикам готовый макет.
Как вообще построен процесс в команде дизайнеров и взаимодействие с разработчиками? К вам приходят разработчики и говорят: «Мы планируем какую-то функциональность, нам нужен прототип», или вас подключают на стадии ревью? Или вы вообще постфактум смотрите, и потом приходится исправлять какие-то вещи?
Все перечисленное бывает. Часто приходят в начале работы над версией и говорят, что планируют сделать одну штуку, «помогите сделать интерфейс». Бывает, разработчик уже что-то делает и присылает нам на ревью. А бывает, мы узнаем про новый интерфейс, когда выходит EAP (Early Access Program) версия. Но это нормально, потому что кто-то всю жизнь самостоятельно работал, а тут пришли какие-то дизайнеры…
Вообще насколько сложно убедить разработчиков в необходимости прототипирования и участия дизайнеров? Ведь если они сами пользуются своим же продуктом, то у них должно быть представление, как сделать его удобным.
Сейчас не трудно. Возможно, потому что в команде уже несколько лет есть дизайнеры, и коллеги-разработчики знают, что к нам можно обращаться за помощью.
Разработчики действительно могут лучше дизайнеров понимать, как определенным интерфейсом пользуются и какие в нем проблемы. В команде IntelliJ так устроено, что каждый разработчик отвечает за конкретную функциональность и все про неё знает. Пользователи пишут проблемы в трекер на имя такого разработчика, поэтому он хорошо с проблемами знаком. Кроме того, наши разработчики — они же и пользователи. Дизайнеров гораздо меньше, у них нет возможности сфокусироваться на одной функциональности. Ну и мы скорее пользователи Скетча, а не IntelliJ IDEA.
Как ты уже уже сказала, чтобы сделать хороший интерфейс, нужно очень хорошо понимать сценарии использования и проблемы, с которыми может столкнуться пользователь. Насколько вообще это сложная задача для дизайнеров, которые сами не являются разработчиками, но должны «влезть в их шкуру»?
Мы общаемся с разработчиками и техподдержкой, сами смотрим, как работает продукт, читаем наш трекер и что пишут на разных форумах. То есть пытаемся вжиться и понять, как люди пользуются продуктом. Иначе трудно сделать хороший интерфейс. Не могу сказать, что мне сложно разобраться. Возможно, потому что работаю в команде уже несколько лет и есть контекст. Дизайнеру, не знакомому со сферой разработки, потребуется больше времени, чтобы разобраться, что делать.
А какой бэкграунд у дизайнеров в вашей команде?
Нас всего четверо, включая меня, и почти все с техническим прошлым, например, в техподдержке или тестировании.
Где ты сама училась дизайну интерфейсов, и можно ли у нас вообще получить высшее образование в этой сфере?
Сейчас уже можно. В ВШЭ или Британской высшей школе дизайна. Там есть бакалавриат и магистратура. Это полноценное образование из кучи разных секций, часть которого про интерфейсы.
Я училась сама по себе, через опыт. Была тестировщиком, потом бизнес-аналитиком, потом устроилась на работу в компанию, которая занимается только проектированием интерфейсов. Многому там научилась просто в процессе работы.
А что может заставить инженера техподдержки или тестировщика перейти в UI-дизайн? Эта какая-то эмпатия к пользователю, когда ты постоянно сталкиваешься с чем-то, что можно улучшить?
Сложно за всех сказать, но, наверное, это когда видишь, что мог бы сделать лучше, и вроде понимаешь, как. Когда работаешь тестировщиком или в техподдержке, постоянно сталкиваешься с проблемами в интерфейсе и думаешь: «Вот здесь вообще-то можно было сделать так, почему же не сделано?»
А действительно, почему люди не делают «так» — ведь многие вещи лежат на поверхности. Вот я не специалист в дизайне, но даже я часто вижу, что какие-то вещи можно сделать лучше, удобнее. Не очень понятно, почему человек, который их делал, не думал так же?
Люди разные. Скорее всего, разработчик делал, как считает правильным. А потом оказалось, что у кого-то из пользователей мнение другое.
Второй момент в том, что у дизайнера интерфейсов и разработчика интересы могут конфликтовать. Часто, чтобы сделать удобно, нужно больше разработки. Например, компонент нельзя расположить на форме так, чтобы верстка была аккуратная, и нужно его переписывать. Или просто не хватает времени, чтобы подумать над каким-то текстом, а фичу уже надо выпускать. Таких мелких моментов куча. Дизайнер же поспорит, что нужно все сделать хорошо, потратить больше времени, иначе положительного результата не добьемся.
С другой стороны, у разработчиков есть важное умение делать что-то работающее. Ведь можно корпеть над идеальным решением бесконечно, а можно выпустить что-то, что уже работает. Что-то — это лучше, чем ноль. Так мы можем обратную связь получить, а на ноль ничего не получим. (Подразумевается, что выпускать что-то однозначно некачественное мы точно не будем.)
Как принимаются решения о стоимости хорошего дизайна для какой-то фичи? Например, можно нарисовать какой-то крутой дизайн, а разработчик потом скажет, что это полгода работы. И что тут оказывается важнее, будет ли дизайнер убеждать разработчика потратить на это время?
Тут много условий. Часто добавить пользы можно и без длительной разработки, со стандартными компонентами и шаблонами. Просто надо получше подумать. Полгода работы — это когда нужен рефакторинг кода или новые компоненты. А если собираешь из стандартного, то это быстро. Почти всегда можно собрать из стандартного, поэтому стараемся из него и собирать. Дизайнеру полезно понимать возможности библиотеки компонентов, и что сколько времени занимает. Обычно во всяких красотах и микроудобствах не очень много пользы для людей в конечном итоге. Мы стараемся искать компромиссы и руководствоваться здравым смыслом, а не только своими фантазиями о том, как сделать красиво.
В UI/UX буква U — это users. Проводит ли ваша команда исследования и сбор мнений пользователей, и вообще взаимодействуете ли вы с ними? Если да, насколько можно на эти мнения опираться и считать их объективными? Ведь люди часто консервативны в отношении интерфейсов (сужу по себе) и не любят радикальных изменений в том, чем пользуются каждый день.
Исследования проводятся, но не то чтобы много. Основную обратную связь мы получаем через EAP. До него обратную связь дают внутренние пользователи — наше большое преимущество в том, что люди в компании пользуются своими же продуктами. Плюс есть опыт из прошлых релизов: про что-то можем сразу сказать, что не пойдет или вызовет плохую реакцию, а про другое, что, скорее, сработает. Если есть спорное решение и в команде дизайнеров мы не можем решить, стоит ли его разрабатывать, можно пойти показать макеты интерфейса коллегам-пользователям — это коридорное тестирование. Относительно формальные исследования тоже иногда проводим.
По поводу консервативности: мы придерживаемся стратегии, что если нет причин нарушать привычки пользователей, то и не нужно. Причиной может быть, например, предположение, что изменение поможет пользователю быстрее выполнять свою работу. При этом вред от изменения не превысит предполагаемой пользы в будущем. Звучит достаточно абстрактно, сложно точно измерить вред или пользу. Но без такого, пусть неточного, принципа, принимать решения об изменении было бы сложнее.
Можно выделить разные категории изменений. Самые проблемные — когда рушится моторная привычка. Например, нажимаешь привычный шорткат, а он делает что-то неожиданное. Переучиться на новый шорткат сложно. Старый шорткат нажимал не задумываясь, а теперь придется думать. А если подумать забыл, то ошибешься по старой привычке. Лучше моторные привычки не менять.
С визуальными изменениями, на мой взгляд, проще. Поменяли цвет, сначала странно, а где-нибудь через неделю забываешь, какой был старый. И ошибок, как с моторными привычками, тут скорее всего будет меньше.
Что помогает тебе быть в курсе новых тенденций в UI-дизайне? Есть ли какие-то компании (не обязательно в IT), которые задают общий тренд в дизайне и на которые всем приходиться ориентироваться? Кто вообще формирует представление о том, как в современном мире должны выглядеть интерфейсы?
Не могу сказать, что как-то специально слежу за изменениями — они происходят в среде вокруг и просто всем видны. Если говорить про тренды, скорее всего это крупные технологические компании вроде Яндекса, Google или Apple.
Из-за специфики нашего продукта мы обращаем внимание на интерфейсы операционных систем. Например, половина наших пользователей сидит на Windows, поэтому важно знать, что там происходит. Ну и какие-то популярные социальные сервисы, которые у всех на виду. В плане информационного дизайна — это большие интернет-газеты, но к нам этот дизайн достаточно мало относится. Мы про рабочий инструмент и продуктивность, а не про потребление контента. Ну и я постоянно что-то читаю, подписана на разные полезные группы и каналы.
Чувствуешь ли ты себя дизайнером в более широком смысле? Ведь User Experience — это не только про интерфейсы, а про все, что нас окружает. Например, помогают ли тебе твои знания UX, скажем, при проектировании интерьера твоей квартиры? Или бывает так, что ты видишь что-то, что сделано неудобно (например, какая-то мебель или предмет), и понимаешь, как можно было сделать лучше?
Я не всегда знаю, как сделать лучше, потому что мало знаю о промышленном дизайне и о принципах, которые там используются. Но умозрительно могу себе представить. Про планировку квартиры — у меня удобная планировка, которую я сама для себя сделала. В целом, не могу сказать, что чувствую себя дизайнером в широком смысле, потому что свои навыки дизайна редко где-то применяю помимо работы. Не считаю это хорошей ситуацией, потому что дизайнеру полезен кругозор (наверное, в любой работе полезен кругозор). В моем информационном поле есть всякие крутые дизайнеры, и видно, что они чем-то еще занимаются кроме своей работы. Тоже бы так хотела, но пока не знаю, как распределить свое время, чтобы заниматься сторонними проектами и хобби.
Насколько я знаю, ты довольно много путешествуешь. Черпаешь ли ты в этих поездках какое-то вдохновение, появляются ли у тебя новые идеи, или это наоборот способ совсем отвлечься от работы?
И то, и другое. Обычно так происходит: в первую неделю забываю про работу и думаю: «Ура, можно немного выдохнуть». Вместо каши в голове появляется ясность, и можно на все как бы сверху посмотреть и увидеть, что где-то можно проще сделать, удобнее. Я не про конкретные интерфейсы, скорее про процессы. Например, как сделать общение в команде лучше, или как быстрее и лучше принимать решения.
Как выглядит твой типичный рабочий день?
До того, как у нас появились еще дизайнеры в команде, я работала в режиме «вот бы выкроить хотя бы час, чтобы тебя не отвлекали». Я была одна, а вопросов от коллег в какой-то момент стало столько, что качественно ответить всем стало очень сложно. Было тяжело. К счастью, потом наша команда стала больше, и теперь бывает, что я целый день могу заниматься какой-то длинной задачей.
Хороший день — когда есть какой-то осязаемый результат, закончена задача или ее часть. Сложно, когда переключаешься то на одну задачу, то на другую, а в итоге вроде ничего за день толком не сделано. Учусь делить большие задачи на мелкие, чтобы было ощущение, что час поработала и сделала что-то полезное. Не всегда получается.
Есть какие-то особенности работы UI-дизайнером в JetBrains по сравнению с твоим предыдущим опытом?
Это первое место работы, где я имею дело с конечным продуктом и могу видеть, что получается на выходе. Это очень здорово, многому учит. Например, что дизайн интерфейсов — ни в коем случае не самовыражение. Если дизайнеру кажется, что работу можно использовать как поле для творчества, — это вредная иллюзия. Для любого решения должны быть рациональные аргументы. Если у тебя таких аргументов нет, быть успешным дизайнером интерфейсов сложно. Потому что эти аргументы нужны каждый день в разговорах с коллегами-дизайнерами и разработчиками, с пользователями.
Когда я начинала работать, думала, что буду рисовать классные штуки, придумывать, как что должно быть устроено, и играть в этот увлекательный сложный конструктор каждый день с утра до вечера. На самом деле, профессия дизайнера подразумевает очень много разговоров — она процентов на 50% из них состоит. Нужно говорить до того, как начинаешь работать над решением, и после. Потом во время разработки и после релиза. Разговаривать приходится с кучей людей. И это хорошо — разговоры помогают сделать дело быстрее.
Что бы ты могла посоветовать тем, кто хотел бы стать UI-дизайнером, но не понимает, с чего начать?
Я бы посоветовала сделать что-то самостоятельно. Например, знаешь, что есть конкретная проблема в интерфейсе. Садишься и пытаешься придумать, как сделать лучше. Можно на бумажке для начала макет нарисовать — это самый простой шаг. Если учиться на курсах, в интернете или очно, главное, чтобы на них была практика. Если работаешь в компании, где есть дизайн-отдел и есть возможность часть времени потратить на свой проект, можно прийти к дизайнерам и попроситься поработать с ними в рамках такого проекта. Или можно подойти к знакомому дизайнеру и попросить маленькую задачку и помощи в обучении. Это полезно и для обучающего — лучше организуешь свои мысли и потом начинаешь свою работу быстрее делать. Объяснять другим полезно.
Анна Гаспарян, руководитель отдела технической документации в JetBrains