Моя бабушка может лучше?
Отвечаем на стыдные вопросы про дизайнеров в 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. Хотя все перечисленные по правде лишь скребут ногтем вершину айсберга, который выглядит примерно так:
Под Service Design здесь понимается проектирование полного цикла услуги/продукта включая как взаимодействие пользователя с ним, так и внутренних элементов друг с другом. Типичный пример: проектирование сервиса авиаперелетов начиная с момента, когда заскучавшему потребителю взбредет в голову куда-нибудь рвануть на выходные, до момента выхода в пункте прилета. Как заставить все это работать эффективнее для бизнеса и удобнее для клиента?
Под Experience Design (иногда Customer Experience, или CX) понимается проектирование лишь пользовательского опыта, хотя и необязательно интерактивного. Онлайн-букинг, регистрация, вай-фай на борту: работает ли все это как части единого целого?
Под UX имеется в виду проектирование взаимодействия уже в рамках отдельного решения. В реальности это, увы, чаще всего банально сменяющие друг друга экраны приложения, хотя вообще-то UX включает и сами данные, и анимацию, и звук.
Наконец, Visual наносит последние недостающие штрихи, подчеркивая важное и делая полезное приятным: четкие цветовые акценты, понятные иконки, остроумные иллюстрации. Иными словами все то, что создает впечатление о продукте.
Где-то в далеких краях, куда улетают на зиму синьоры, можно встретить и такие диковинные профессии как Information Architecture Designer или Content Designer, по сути, занимающиеся отдельными аспектами UX. Иногда к нам залетают UX Designer/Developer, исполняющие еще и трагическую роль front-end разработчика, устраняя тем самым лишнее звено в рабочем процессе. Такие же позиции как Web Designer или Mobile Designer, кажется, постепенно уходят в прошлое — но оно и к лучшему. Все-таки глупо фокусировать внимание на платформе, а не на кругу решаемых задач.
Ну а для простоты и наглядности далее мы будем рассматривать главным образом UX/UI-дизайнера как вроде бы устоявшийся элемент джентльменского набора среднестатистической продуктовой команды.
О чем с дизайнером можно говорить?
В принципе обо всем, что связано с функциональностью продукта, о которой он вообще-то должен кое-что знать. Если же это что-то, напрямую касающееся результатов его работы, то встаньте и подойдите же к нему прямо сейчас!
Если вы разработчик или QA, то любые вопросы по макетам, противоречия между спецификациями и тем, что вы видите на экране, и даже банальные неточности — более чем достаточный повод обратиться напрямую к дизайнеру. Не стесняйтесь также обсуждать с ним и сам формат передаваемых артефактов. В конце концов, именно для этого он и включен в команду, а не для того, чтобы производить впечатление таинственного инкогнито, раз в две недели обновляющего исходники на дропбоксе.
А если вы, допустим, PM, то он вообще ваш лучший друг!
За что именно отвечает дизайнер ? За дизайн, да?
В узком смысле да. В широком — он вместе с PM/BA отвечает за то, чтобы в продукте были в одинаковой степени учтены требования бизнеса, ожидания конечного пользователя и ограничения объективной реальности.
Всякий бизнес, по существу, начинается с простой гипотезы о том, что тот или иной продукт может быть востребован на рынке. Часто к моменту начала работ нет ничего кроме этой гипотезы, в лучшем случае дополненной отвлеченными фантазиями под названием «бизнес требования». Нет четкого понимания, кто и как будет пользоваться продуктом и почему он станет пользоваться именно им, каковы истинные мотивы людей и причины спроса, наконец, какие функции критичны для запуска, а какие могут подождать. Чтобы не наделать обидных ошибок на почве голых предположений хорошо бы ответить на все эти вопросы, на что отводится самая первая и, пожалуй, самая важная стадия работы над продуктом, которая, как вы наверное догадались, непосредственно связана с обязанностями нашего героя.
Так и есть: в компаниях, в полной мере осознающих важность product definition, дизайнер включается в работу как можно раньше, часто играя при этом ведущую роль, хотя и в тесном партнерстве с PM. Веб-аналитика, опросники, интервью/воркшопы с пользователями и стейкхолдерами, competitive analysis и даже технические консультации со смежными командами — все это в их общих интересах. После чего ожидается, что совместными усилиями они корректно сформулируют задачу, которая, как известно, половина решения.
Как именно строится их совместная работа? Зависит от предпочтений обоих. Всегда можно договориться, кто организует встречу, а кто подготовит материалы, кто будет вести интервью, а кто делать заметки, кто покопается на конфлюенсе, а кто созвонится с индийской командой, которая год назад делала то же самое, но на джаве. В конце концов это общее дело, хотя и в дальнейших, уже, казалось бы, сугубо своих делах дизайнер редко предоставлен сам себе: брейнсторминг, дизайн и тестирование прототипов, анализ результатов и принятие решений — большинство этих задач лишь выигрывают от обмена мнениями. В общем, коммуникация важна ничуть не меньше чем индивидуальные таланты участников, и даже в привлечении дизайнера к регулярным активностям работающих по скраму команд есть определенный смысл, несмотря на то что у него и свой backlog, и свой roadmap.
Ситуации же, когда дизайнер выполняет не более чем функцию рисующей руки, к сожалению, нередки и в каком-то смысле даже эффективны, но при этом предельно порочны. Если бы можно было нагрузить его пачкой требований, а через месяц подойти за результатом, то это так бы и работало. Но это так не работает. Точнее, именно так это, к сожалению, часто и работает. Точнее, не работает(((
Но подождите: я и сам все это могу! Нам точно нужен дизайнер?
Точно. Ключевая его задача — быть голосом пользователя в команде и заботиться о том, чтобы продукт решал истинные проблемы, а не делал то, что было проще или интереснее всего написать. Может показаться, что обе стороны обречены на вечный антагонизм, но в этом и смысл: каждый вынужден делать шаги навстречу друг другу, сокращая расстояние между тем, что нужно и что реально достижимо — чтобы встретиться в точке, прямо напротив которой находится дверь с надписью «успех».
Выполнять эту задачу крайне сложно, если все без исключения участники погружены в бизнес-логику или тем более разработку: перекос в мышлении практически неизбежен, даже если вы намеренно стараетесь этого избежать. Примерно по этой же причине принято держать в команде QA, а не тестировать собственный код.
К слову, интересно, что оба — дизайнер и QA — одинаково не должны заботиться о том, как приложение устроено внутри, а значит вроде бы находятся по одну сторону воображаемых баррикад. В реальности же именно QA часто оказывается главным критиком дизайнерских решений. Но не потому что злой, а потому что это тоже часть его работы — и пускай лучше это будет он чем взбешенный пользователь.
Но как никто другой понимать проблемы юзера — лишь половина дела. Вторая половина — уметь найти для них изящное решение. С этим умением не рождаются и не приходят к нему при помощи духовных практик или воздержания от мяса. Ему учат и оно-то и формирует суть профессии. Составляющие основу этих навыков дизайн-процессы, способность извлекать из них пользу, а главное, убеждать в их ценности всю команду, собственно, и отличает профессионального дизайнера от того, кто считает, что он тоже может им быть.
Какие еще дизайн-процессы?
По сути, это набор шагов, рекомендаций и методов, следование которым повышает качество принимаемых решений — ни много и ни мало. Подобно agile-методологиям эти процессы не гарантируют успешного результата, который все еще находится в прямой зависимости от опыта и усердия команды, но помогают прийти к нему кратчайшим путем.
Agile, waterfall — все эти термины, кстати говоря, одинаково применимы как к разработке так и к проектированию интерфейсов, и в каком-то смысле их можно считать прототипами или простейшими формами дизайн-процессов. Из более изощренных наибольшее распространение получил, пожалуй, Design Thinking, который почему-то принято изображать в виде угрожающих очертаний молекулы:
Как видим, начальной фазе постановки задачи уделяется здесь особое внимание, а активному взаимодействию с пользователями даже отведен отдельный этап. В числе других популярных процессов можно отметить, пожалуй, Lean UX и Design Sprint. Они делают ударение уже на других аспектах — ускоренной цикличности или, скажем, генерации решений, но для всех в той или иной степени характерен общий и, если задуматься, единственно разумный принцип: повторяющаяся последовательность шагов Define— Design — Validate, хотя первый чаще всего достаточно сделать лишь однажды.
В рамках каждого из шагов при этом существует ряд методик: разного рода пользовательские исследования, способы анализа и формулирования задачи, эффективные методы поиска идей, прототипирования и, наконец, тестирования. Им нет числа, и в выборе наиболее подходящего сочетания в условиях конкретного проекта, а также в умении их применять как раз и состоит мастерство дизайнера. Среди самых одаренных можно даже встретить способность успевать все это до дедлайна.
Мне не нравится то, что предлагает наш дизайнер. Что делать?
Для начала важно уяснить, что предлагаемые им решения и не должны вам нравиться. Они должны решать поставленную задачу.
И если вам кажется, что они ее не решают или решают неэффективно, и при этом вы в состоянии аргументировать свою позицию, совершенно уместным будет ему об этом сказать. Несмотря на то, что именно дизайнер отвечает за интерфейсные решения, его идеи — как и ничьи другие — нельзя считать автоматически лучшими по определению. Хороший дизайнер без колебаний воспользуется резонным советом. В конце концов чья угодно идея заслуживает быть рассмотренной, взвешенной и протестированной — если, разумеется, на это есть время, бюджет и вдохновение. Если же нет, то слушайте дизайнера и не спорьте!
А как вообще отличить хорошего дизайнера от плохого?
Так же как и любого другого профессионала: никак. Есть тем не менее ряд маркеров, свойственных хорошим и не очень хорошим, или лучше будем говорить опытным и не очень опытным профессионалам.
Если попытаться обобщить эти черты, то можно сказать, что опытный дизайнер гораздо меньше занимается собственно дизайном, а куда больше не связанными напрямую с условным фотошопом задачами: исследованием и анализом проблемы, анализом и тестированием решений, координацией действий команды, планированием.
Не слишком опытный дизайнер наоборот гораздо больше времени уделяет двиганию плашек, причем начинает заниматься этим слишком рано, часто привязывается к ранним идеям и в результате оказывается неспособным взглянуть на проблему под разными углами.
Как нетрудно догадаться, для успеха в профессии критически важны софт-скилы: способность действовать в условиях неопределенности, работать в команде, активно продвигая свои идеи, но при этом уметь находить компромиссы — словом лидерские качества. Очень многие, как мне кажется, недооценивают этот список, излишне заостряя внимание на технических навыках. Но если задуматься, профессия дизайнера состоит, по сути, в том, чтобы из ничего делать что-то — чертовски нетривиальная и, надо сказать, не всякому под силу работа.
Дизайнеру обязательно нужен мак? А борода и татуировка на руке? А приходить не раньше 12?
Не всегда, но часто. Нет и нет. Нет.
Дело в том, что ряд инструментов, некоторые из которых успели стать фактически стандартом в UI/UX-дизайне, доступны только под мак: Sketch, Flinto, Principle. С другой стороны эти стандарты довольно живо меняются, а кроме того конкретно взятый человек может быть адептом старой школы или членом радикальных сект и творить в программах, совместимых с Windows или же вообще не привязанных к платформе. Но если дизайнер говорит, что мак ему необходим, то скорее всего это так и есть. Если же вы только планируете нанимать дизайнера, то имейте в виду, что мак ему скорее всего понадобится.
Что если у нас нет (и не будет) дизайнера?
Во-первых, не отчаивайтесь. Дизайн — не столько талант сколько навык. Хотя это также и талант. Но исходим из того, что талант у вас уже есть!
В общем, если дизайнер вашей команде не светит, это еще не значит, что все потеряно. Вряд ли вы сильно хуже тысяч тех, кто как-то умудряется выкручиваться, выпуска на рынок более или менее законченный продукт без помощи дизайнера. Роль последнего в таких случаях чаще всего берет на себя PM, и вот что ему стоит при этом помнить:
- Любой продукт должен в первую очередь решать задачи пользователя, а потом уже бизнеса, и если у вас есть возможность пообщаться с непосредственными или потенциальными пользователями, не упустите ее! Никакого rocket science в этом нет, и ваша цель — выяснить, кто, зачем и при каких обстоятельствах будет пользоваться продуктом. В ходе этих разговоров вы можете открыть для себя нечто неожиданное или т. н. инсайты, а можете и не открыть — но в любом случае этот опыт сослужит вам хорошую службу, когда позже вы будете спрашивать себя, по-прежнему ли вы решаете ту задачу, которую должны.
- Кстати, я уже говорил, что важно систематически спрашивать себя, по-прежнему ли вы решаете ту задачу, которую должны?
- Всеми силами старайтесь не придумывать решение прежде чем не разберетесь со всеми доступными неизвестными. Кроме того старайтесь не затрагивать интерфейс там, где это не нужно. Если заказчик упоминает в брифе search button next to the input, то не поленитесь уточнить, почему он уверен, что это непременно должна быть button и почему именно next to the input, как бы намекая, что на данном этапе важно вовсе не это.
- Помните, что нет «золотой пули»: не существует никакого алгоритма действий, выполняя который можно гарантированно прийти к хорошему решению. Единственный проверенный способ найти по-настоящему хорошую идею — это предлагать как можно больше идей. При некотором опыте, настойчивости и везении одна из них наверняка окажется удачной.
- (Unethical life pro tip) Если идеи не приходят или, напротив, альтернатив слишком много и непонятно, по какому пути двигаться, не стесняйтесь копировать. Гугл, майкрософт, амазон, фб и ряд других гигантов из самых разных индустрий вкладывают титанические ресурсы в свои интерфейсные решения. Следуя им вы необязательно победите, но и в лужу сядете с гораздо меньшей вероятностью. Но это неточно.
- (Life pro tip) Если возможности для пользовательского тестирования нет, то пройдитесь сами хотя бы по базовым эвристикам.
Ну а если вы ощущаете в себе потребность в более фундаментальных знаниях, силы ими овладеть и располагаете временем, то можно смело начинать знакомство с ключевых фигурантов списка рекомендованной литературы (1, 2, 3, 4, 5 … 100500) и кто знает — возможно, спустя какое-то время понять, что, кажется, вы нашли свое новое призвание.
В таком случае добро пожаловать! Вы не ошиблись с выбором: здесь раздают всем маки и можно приходить на работу после 12.
