Моя бабушка может лучше? Cтыдные вопросы про дизайнеров в IT
Привет! Меня зовут Костя Череповский, я дизайнер с интересами в диапазоне от транспортной навигации до нумизматики. В свободное от праздных увлечений время успел приобрести опыт работы и некоторое представление об устройстве IT-индустрии, включая как аутсорс, так и продуктовые компании внутри Украины и за ее пределами, о чем и хотел бы рассказать.
Для кого этот материал?
Этот материал адресован product-менеджерам (PM), бизнес-аналитикам (BA), разработчикам, тестировщикам (QA) — словом, всем участникам продуктовых команд. Но при этом таких, у которых либо еще нет дизайнера, либо они обзавелись им лишь недавно, либо же имеют определенный опыт работы с ним, но пока не слишком гладкий. Материал вряд ли будет полезен командам, давно и успешно практикующим дизайн-процессы, а также, собственно, самим дизайнерам — разве что самым маленьким.
Почему это важно?
По скромным наблюдениям автора отсутствие дизайнера в команде превращается скорее в исключение, чем правило, и с каждым годом все более вопиющее. Даже нацеленный на экономию бизнес начал понимать, что отсутствие критических багов в коде — еще не гарантия успеха.
Вместе с тем иногда приходится видеть, что даже если дизайнер в команде и есть, то не все участники до конца понимают, что здесь делает этот парень и о чем с ним вообще разговаривать. Результаты этого непонимания сказываются в лучшем случае на эффективности работы, а в худшем — на качестве самого продукта, хоть мы от него и отчуждены, если верить Марксу. В совсем запущенных случаях дизайнер воспринимается как чужеродный элемент, задача которого — плодить максимально нереализуемые идеи сомнительной ценности, которую к тому же нельзя проверить. Или нет? Давайте разбираться!
UX, UI, Product, Service Designer — что значат все эти буквы?
Скажем прямо, в реалиях украинского IT более или менее высоки шансы встретить лишь кого-то из первых двух: UX (User Experience) или UI (User Interface), известного также как Visual Разница между двумя этими направлениями, грубо говоря, состоит в том, что первые занимаются утилитарными сторонами продукта, в то время как вторые — эстетическими. Или совсем по-простому: UX-дизайнеры делают удобно, UI-дизайнеры — красиво.
Когда возможности содержать сразу две позиции нет, их сокращают в одну, немного предсказуемо называя UX/UI Designer, или часто Product Designer, или Whatever Fancy Name Designer. Хотя все перечисленные, по правде, лишь скребут ногтем вершину айсберга, который выглядит примерно так:
Зоны поражения при взрыве штаб-квартиры Adobe
Под Service Design здесь понимается проектирование полного цикла услуги/продукта, включая как взаимодействие пользователя с ним, так и внутренних элементов друг с другом. Хороший пример — Uber: между идеей мобильного приложения для каршеринга и доминирующим на рынке продуктом был проделан целый массив работы по сервис-дизайну.
Под Experience Design (иногда Customer Experience, или CX) понимается проектирование уже лишь пользовательского опыта, хотя и необязательно интерактивного.
Под UX имеется в виду проектирование взаимодействия в рамках отдельного решения/платформы. В реальности это, увы, чаще всего банально сменяющие друг друга экраны приложения, хотя вообще-то UX включает и анимацию, и звук, и тактильную реакцию — словом, любые элементы собственно интерфейса.
Наконец, Visual наносит последние недостающие штрихи, подчеркивая важное и делая полезное приятным: вразумительные цветовые акценты, понятные иконки, остроумные иллюстрации. Иными словами, все то, что создает впечатление о продукте.
Где-то в далеких краях, куда улетают на зиму синьоры, можно встретить и такие диковинные профессии как Information Architecture Designer или Content Designer, по сути, занимающиеся отдельными аспектами UX. Вместо них к нам иногда залетают UI Designer/Developer, исполняющие еще и трагическую роль front-end разработчика, устраняя тем самым лишнее звено в рабочем процессе. Такие же позиции как Web Designer или Mobile Designer, кажется, постепенно уходят в прошлое — но оно и к лучшему. Все-таки глупо фокусировать внимание на платформе, а не на кругу решаемых задач.
Для простоты и наглядности далее мы будем рассматривать главным образом UX/UI-дизайнера как вроде бы устоявшийся элемент джентльменского набора среднестатистической продуктовой команды.
О чем с дизайнером можно говорить?
Для начала обо всем, что связано с функциональностью продукта, о которой он вообще-то должен кое-что знать. Если же это что-то, напрямую касающееся результатов его работы, то встаньте же и подойдите к нему прямо сейчас! В конце концов, именно для этого он и включен в команду, а не для того, чтобы производить впечатление таинственного инкогнито, раз в две недели обновляющего исходники на дропбоксе.
Если вы разработчик или QA, то любые вопросы по макетам, противоречия между спецификациями и тем, что вы видите на экране, и даже банальные неточности — более чем достаточный повод обратиться напрямую к дизайнеру. Не стесняйтесь также обсуждать с ним и сам формат передаваемых артефактов. Front-end разработчикам помимо прочего наверняка будет интересно обсудить с дизайнером вопрос эффективности взаимодействия. Поиск по ключевым словам design system и design library послужит здесь хорошим подспорьем для начала диалога.
А если вы, допустим, PM, то дизайнер — вообще ваш лучший друг!
За что именно отвечает дизайнер? За дизайн, да?
В узком смысле да. В широком — он вместе с PM/BA отвечает за то, чтобы в продукте были в одинаковой степени учтены требования бизнеса, ожидания конечного пользователя и ограничения объективной реальности.
Прежде чем браться за дизайн или тем более разработку, крайне желательно получить представления о том, кто и как будет пользоваться продуктом, почему он станет пользоваться именно им, каковы истинные мотивы людей и причины ожидаемого спроса, наконец, какие функции критичны для запуска, а какие могут подождать. Словом, прежде чем решать задачу, настоятельно рекомендуется ее как следует сформулировать, дабы не наделать обидных ошибок на почве голых предположений.
Если вам не повезло — а вам, будем откровенны, скорее всего, не повезло, и позиция User Researcher у вас в штате не числится — то этот первый и, пожалуй, самый важный этап работы над продуктом, как вы наверное догадались, непосредственно связан с обязанностями нашего героя. Так и есть: в компаниях, в полной мере осознающих важность product definition, дизайнер включается в работу как можно раньше, часто играя при этом ведущую роль, хотя и в тесном партнерстве с PM. Веб-аналитика, опросники, интервью/воркшопы с пользователями и стейкхолдерами, competitive analysis и даже технические консультации со смежными командами — все это в их общих интересах. После чего ожидается, что совместными усилиями они корректно сформулируют задачу, которая, как известно, половина решения.
Как именно строится их совместная работа? Зависит от предпочтений обоих. Всегда можно договориться, кто организует встречу, а кто подготовит материалы, кто будет вести интервью, а кто делать заметки, кто покопается на конфлюенсе, а кто созвонится с индийской командой, которая год назад делала то же самое, но на джаве. В конце концов это общее дело, хотя и в дальнейших, уже, казалось бы, сугубо своих делах дизайнер редко предоставлен сам себе. Брейнсторминг, дизайн и тестирование прототипов, анализ результатов и принятие решений — большинство этих задач лишь выигрывают от обмена мнениями. В общем, коммуникация важна ничуть не меньше, чем индивидуальные таланты участников. И даже в привлечении дизайнера к регулярным активностям работающих по скраму команд есть определенный смысл, несмотря на то что у него и свой backlog, и свой roadmap.
Ситуации же, когда дизайнер выполняет не более чем функцию рисующей руки, к сожалению, нередки и в каком-то смысле даже эффективны, но при этом предельно порочны. Если бы можно было нагрузить его пачкой требований, а через месяц подойти за результатом, то это так бы и работало. Но это так не работает. Точнее, именно так это, к сожалению, часто и работает. Точнее, не работает :(
Но подождите: я и сам все это могу! Нам точно нужен дизайнер?
Точно. Ключевая его задача, как ни странно, — не столько генерировать идеи, сколько быть голосом пользователя в команде и заботиться о том, чтобы продукт решал истинные проблемы, а не делал то, что было проще или интереснее всего написать. Может показаться, что обе стороны обречены на вечный антагонизм. Но в этом и смысл: каждый вынужден делать шаги навстречу друг другу, сокращая расстояние между тем, что нужно и что реально достижимо — чтобы встретиться в точке, прямо напротив которой находится дверь с надписью «успех».
Выполнять эту задачу крайне сложно, если все без исключения участники погружены в бизнес-логику или тем более разработку. Перекос в мышлении практически неизбежен, даже если вы намеренно стараетесь этого избежать. Примерно по этой же причине принято держать в команде QA, а не тестировать собственный код.
К слову, интересно, что оба — дизайнер и QA — одинаково не должны заботиться о том, как приложение устроено внутри, а значит вроде бы находятся по одну сторону воображаемых баррикад. В реальности же именно QA часто оказывается главным критиком дизайнерских решений. Но не потому что злой, а потому что это тоже часть его работы. И пускай лучше это будет он, чем взбешенный пользователь.
Но как никто другой понимать проблемы юзера — лишь половина дела. Вторая половина — уметь найти для них изящное решение. «Решение» — ключевое слово в жизни дизайнера, важность которого не до конца ясна тем, кто путает дизайн с искусством.
С умением решать задачи не рождаются и не приходят к нему при помощи духовных практик или воздержания от мяса. Ему учатся, и оно-то и формирует суть профессии. Составляющие основу этих навыков дизайн-процессы, способность извлекать из них пользу, а главное, убеждать в их ценности всю команду, собственно, и отличает профессионального дизайнера от того, кто считает, что он тоже может им быть.
Какие еще дизайн-процессы?
По сути, это набор шагов, рекомендаций и методов, следование которым повышает качество принимаемых решений — ни много и ни мало. Подобно agile-методологиям эти процессы не гарантируют успешного результата, который все еще находится в прямой зависимости от опыта и усердия команды, но помогают прийти к нему кратчайшим путем.
Agile, waterfall — все эти термины, кстати говоря, одинаково применимы как к разработке, так и к проектированию интерфейсов, и в каком-то смысле их можно считать прототипами или простейшими формами дизайн-процессов. Из более изощренных наибольшее распространение получил, пожалуй, Design Thinking, который почему-то принято изображать в виде угрожающих очертаний молекулы:
Химия на службе народного хозяйства
Как видим, начальной фазе постановки задачи здесь уделяется особое внимание, а активному взаимодействию с пользователями даже отведен отдельный этап. В числе других популярных процессов можно отметить, пожалуй, Lean UX и Design Sprint. Они делают акцент уже на других аспектах — ускоренной цикличности или, скажем, генерации решений. Но для всех в той или иной степени характерен общий и, если задуматься, единственно разумный принцип: повторяющаяся последовательность шагов Define — Design — Validate. Хотя первый чаще всего достаточно сделать лишь однажды.
В рамках каждого из шагов при этом существует ряд методик: разного рода пользовательские исследования, способы анализа и формулирования задачи, эффективные методы поиска идей, прототипирования и, наконец, тестирования. Им нет числа, и в выборе наиболее подходящего сочетания в условиях конкретного проекта, а также в умении их применять как раз и состоит мастерство дизайнера. Среди самых одаренных можно даже встретить способность успевать все это до дедлайна.
Мне не нравится то, что предлагает наш дизайнер. Что делать?
Для начала важно уяснить, что предлагаемые им решения и не должны вам нравиться. Они должны решать поставленную задачу. И если вам кажется, что они ее не решают или ее можно было решить лучше, и при этом вы в состоянии аргументировать свою позицию, совершенно уместным будет ему об этом сказать.
Несмотря на то, что именно дизайнер отвечает за интерфейсные решения, его идеи — как и ничьи другие — нельзя считать автоматически лучшими по определению. Хороший дизайнер без колебаний воспользуется резонным советом. В конце концов, чья угодно идея заслуживает быть рассмотренной, взвешенной и протестированной — если, разумеется, на это есть время, бюджет и вдохновение. Если же нет, то слушайте дизайнера и не спорьте!
А как вообще отличить хорошего дизайнера от плохого?
Так же, как и любого другого профессионала: никак. Есть тем не менее ряд маркеров, свойственных хорошим и не очень хорошим, или лучше будем говорить опытным и не очень опытным профессионалам.
Если попытаться обобщить эти черты, то можно сказать, что опытного дизайнера отличает более системный подход к работе. Во-первых, он гораздо меньше занимается собственно дизайном, а куда больше не связанными напрямую с условным фотошопом задачами: планированием, анализом, тестированием, координацией работы. Во-вторых, он старается думать не только о качестве решения, но и о продуктивности работы, экономя себе и команде время в будущем (см. дизайн-системы).
Не слишком опытный дизайнер наоборот гораздо больше времени уделяет двиганию плашек. Причем начинает заниматься этим слишком рано, часто привязывается к ранним идеям и в результате оказывается неспособным взглянуть на проблему под разными углами. Когда же дело подходит к финалу, то работа часто сводится к бессистемной генерации все новых скринов.
Для успеха в профессии, к слову, критически важны и soft skills: способность действовать в условиях неопределенности, работать в команде, активно продвигая свои идеи, но при этом уметь находить компромиссы — словом лидерские качества. Очень многие, как мне кажется, недооценивают этот список, излишне заостряя внимание на технических навыках. Но если задуматься, профессия дизайнера состоит, по сути, в том, чтобы из ничего делать что-то — чертовски нетривиальная и, надо сказать, не всякому под силу работа.
Дизайнеру обязательно нужен мак? А борода и татуировка на руке? А приходить не раньше 12?
Не всегда, но часто. Нет и нет. Нет.
Дело в том, что ряд инструментов, некоторые из которых успели стать фактически стандартом в UX/UI-дизайне, доступны только под мак: Sketch, Flinto, Principle. С другой стороны, эти стандарты довольно живо меняются. А кроме того, конкретно взятый человек может быть адептом старой школы или членом радикальных сект и творить в программах, совместимых с Windows или же вообще не привязанных к платформе. Но если дизайнер говорит, что мак ему необходим, то, вероятно, это так и есть. Если же вы только планируете нанимать дизайнера, то имейте в виду, что мак ему, скорее всего, понадобится.
Что если у нас нет (и не будет) дизайнера?
Во-первых, не отчаивайтесь. Дизайн — не столько талант, сколько навык. Хотя это также и талант. Но исходим из того, что талант у вас уже есть!
В общем, если дизайнер вашей команде не светит, это еще не значит, что все потеряно. Вряд ли вы сильно хуже тысяч тех, кто как-то умудряется выкручиваться, выпуская на рынок более или менее успешный продукт без помощи дизайнера. Роль последнего в таких случаях чаще всего берет на себя PM, и вот что ему стоит при этом помнить:
- Любой продукт должен в первую очередь решать задачи пользователя, а потом уже бизнеса. Если у вас есть возможность пообщаться с непосредственными или потенциальными пользователями, не упустите ее! Никакого rocket science в этом нет, и ваша цель — выяснить, кто, зачем и при каких обстоятельствах будет пользоваться продуктом. В ходе этих разговоров вы можете открыть для себя нечто неожиданное или так называемые инсайты, а можете и не открыть. Но в любом случае этот опыт сослужит вам хорошую службу, когда позже вы будете спрашивать себя, по-прежнему ли вы решаете ту задачу, которую должны.
- Кстати, я уже говорил, что важно систематически спрашивать себя, по-прежнему ли вы решаете ту задачу, которую должны?
- Всеми силами старайтесь не придумывать решение, прежде чем не разберетесь со всеми доступными неизвестными. Кроме того, старайтесь не затрагивать интерфейс там, где это не нужно. Если заказчик упоминает в брифе search button next to the input, то не поленитесь уточнить, почему он уверен, что это непременно должна быть button и почему именно next to the input, как бы намекая, что на данном этапе важно вовсе не это.
- Помните, что нет «золотой пули»: не существует никакого алгоритма действий, выполняя который можно гарантированно прийти к хорошему решению. Единственный проверенный способ найти по-настоящему хорошую идею — это предлагать как можно больше идей. При некотором опыте, настойчивости и везении одна из них наверняка окажется удачной.
- (Unethical life pro tip) Впрочем есть и второй способ — копировать готовые идеи. Google, Microsoft, Amazon, Facebook и ряд других гигантов вкладывают титанические ресурсы в свои интерфейсные решения. Следуя им, вы не обязательно победите, но и в лужу сядете с гораздо меньшей вероятностью. Но это неточно.
- (Life pro tip) Если возможности для пользовательского тестирования нет, то пройдитесь сами хотя бы по базовым эвристикам.
Ну а если вы ощущаете в себе потребность в более фундаментальных знаниях, силы ими овладеть и располагаете временем, то можно смело начинать знакомство с ключевых фигурантов списка рекомендованной литературы (1, 2, 3, 4, 5... 100500), и кто знает — возможно, спустя какое-то время понять, что, кажется, вы нашли свое новое призвание.
В таком случае добро пожаловать! Вы не ошиблись с выбором: здесь всем раздают маки и можно приходить на работу после 12.
