Продуктовый дизайнер это что
Тонкости продуктового дизайна
Продуктовый дизайнер — это не совсем дизайнер. Он может неделями не открывать графический редактор и не произвести ни одного макета за месяц. Потому что основная цель его работы в другом.
За последние полтора года я работал над двумя продуктами. С первым (BINO CX) прошел путь от нуля до выручки в 1 млн рублей меньше чем за год, а второй развиваю в данный момент.
Я знаю, что многие дизайнеры хотят перейти в продукт из-за более высокой оплаты, размеренного ритма и возможности напрямую влиять на бизнес. Поэтому я решил написать эту статью, в которой учел личный опыт и знания, полученные от ведущих продуктовых дизайнеров нашей страны.
Не творческое просветление
Дизайнеры не любят, когда их просят что-либо нарисовать, ведь половина их работы происходит вне графического редактора.
Дизайнеры проводят исследования, проектируют решения, продумывают сценарии, в то время как руководство продолжает считать их творцами.
Не справедливо? Отнюдь.
Если руководство считает дизайнера творцом, значит дизайнер не правильно преподносит себя и свою работу.
Чтобы повысить свою значимость в компании, от дизайнера требуется показывать понимание бизнес-задач и завоевывать доверие грамотными дизайн-решениями.
На старте карьеры я этого не понимал, поэтому каждая моя идея выглядела как творческое просветление (отчасти так и было). Спустя несколько лет я понял свою ошибку и теперь вкладываю усилия только в те вещи, которые требуют улучшения и способны положительным образом повлиять на показатели бизнеса.
Вы можете сказать руководству, что визуальный язык сервиса устарел, но этот аргумент меркнет и бледнеет на фоне задач, от которых напрямую зависит прибыль компании.
Продуктовые дизайнеры тоже крадут
Очень полезно обратиться к опыту схожих сервисов, даже если вы создаете новый продукт. Это могут быть прямые конкуренты или сервисы с похожей механикой.
Слушая курс ux-design от AIC, мне стало очевидно, что изучение конкурентов помогает не только в поиске вдохновения, но и при аргументации своих решений заказчику/руководителю. Стоит показать пример успешного сервиса и доверие к вашей идее возрастает в разы.
Авиакомпании могут анализировать интерфейсы сервисов по продаже билетов в кино. Сайты футбольных клубов могут обратиться к опыту медиа-сервисов. И кто угодно может посмотреть на соцсети.
Создавая сервисы для крупных банков, я анализировал игровые механики приложений по изучению английского языка. Интересные идеи я выписывал в отдельный файл и разбивал по категориям. Лучшие использовал.
Анализ конкурентов — не копирование, а использование накопленного индустрией опыта. И очень глупо его игнорировать. Но несмотря на это, перед внедрением новой функции нужно хорошо подумать.
“Так делает Google!” — не аргумент.
“Так делает Google, потому что он таким образом решает схожую задачу” — совсем другое дело.
Главные друзья
Разработчики — главные друзья дизайнеров (и самый главный их инструмент).
Цель продуктового дизайнера — создать успешный продукт. И этого нельзя достичь в одиночку, не понимая логики работы своих коллег. Не обязательно посещать курсы по программированию. Достаточно просто просить разъяснения в ситуациях, когда между отделами возникает конфликт.
Порой дизайнеру следует пойти на уступки, если реализация предложенной идеи требует неадекватного количества времени (в соотношении с потенциальной пользой). С другой стороны, в важных моментах вы должны отстаивать свои решения и контролировать их воплощение.
Это не является проявлением неуважения к коллегам. В этом проявляется ваше уважение к создаваемому продукту.
О чем они говорят
Прочитав Канемана и Талеба, я стал аккуратнее относится к любого типа статистике.
Однажды к нам в офис залетел маркетолог чтобы поделиться открытием. Он узнал, что люди работают “по-другому”, поэтому нам придется переработать продукт. Маркетолог привел актуальный пример, его заявление выглядело логичным и основатель готов был с этим согласиться, но совершил бы большую ошибку.
Добавляя любой функционал, опираясь на реальные примеры, узнайте какой процент ваших потенциальных пользователей будет его использовать. Возможно, вы перелопатите продукт ради 1% пользователей, которые ничего бизнесу не приносят.
Да, это больше аналитика, чем дизайн, но это не значит, что продуктовый дизайнер не должен этого знать.
Прочитайте “Думай медленно… решай быстро”. Эта книга сильно повлияла на мое восприятие исследований и помогает избегать типичных заблуждений.
Фильтр шума
Однажды, один из инвесторов настаивал на определенном решении. Я готов был согласиться с ним, но только в том случае, если сотрудники поддержки этот факт подтвердят. Поговорив с ними, оказалось, что мир изменился и клиенты теперь ведут себя по другому.
Основатели/инвесторы обладают авторитетом, но не всегда имеют глубокую экспертизу, как сотрудники, ежедневно работающие “в поле”. Именно поэтому, работая над прошлым проектом, я регулярно общался с поддержкой и интересовался вопросами пользователей.
Эта практика помогает выявить места, на которых у пользователей возникают затруднения. И если эти места критически важные, уделите им достаточно внимания.
Где-то будет достаточно текстовой подсказки, а в некоторых случаях придется менять интерфейс.
Гибкий фреймворк
Фреймворк — базовая структура, вокруг которой строятся элементы интерфейса.
Чем гибче у вас фреймворк, тем лучше.
Каждый продукт развивается: получает новые функции и избавляется от устаревших. Поэтому иметь гибкую структуру удобно, так как при каждом изменении вам не придется переделывать интерфейс.
Чтобы создать гибкий фреймворк, нужно понимать возможные варианты развития сервиса, в чем вам поможет “База знаний” (ниже). Анализируя потенциальные изменения, вы сможете принимать стратегически правильные дизайн-решения.
База знаний
Первые годы работы я об этом не думал, но в последнее время все больше осознаю важность ведения базы знаний. Помимо того, что коллеги могут воспользоваться собранной информацией, фиксирование помогает лучше запоминать и понимать информацию.
В моей базе знаний хранится несколько типов материалов:
Анализ конкурентов. В этом файле выписаны все сервисы со схожей механикой и интересные функции, найденные в ходе исследовани
Сценарии. У каждого сервиса есть несколько сценариев и дизайнер должен знать их и хорошо помнить.
Customer Journey Map. Отличный инструмент, который помогает проанализировать сценарии на наличие потенциальных проблем. CJM основных сценариев я делаю в таблице:
Много конфиденциальной информации 🙂
Интерфейсы. Здесь я собираю мысли и идеи о ключевых местах сервиса.
Идеи. Общие мысли по будущему развитию продукта.
Кто они?
Я периодически оказываюсь в студии AIC, где дважды сталкивался с интересными случаями. Один раз рядом с монитором дизайнера я увидел фотографию Владимира Машкова, в другой — Сергея Гармаша. Догадываетесь почему?
Оба актера были лицами клиентов студии — банков ВТБ и “Почта Банка”. Маркетинг специально подбирал актеров под целевую аудиторию, поэтому дизайнеры повесили их портреты на видное место.
Знать пользователей — это значит понимать их мотивы, желания, привычки, график жизни, используемые устройства, средний доход, семейное положение, …
Интерфейс проектируется для этих людей, а не для вас. Поэтому своих пользователей нужно знать.
Видение
Продуктовый дизайнер с самого начала имеет видение проектируемого сервиса. Я долго думал откуда берется видение и остановился на следующем:
Видение — это синтез опыта и полученных знаний.
Видение будущего продукта позволят отвергать некоторые идеи в пользу тех, которые этому видению соответствуют. В итоге формируемый продукт отражает видение его создателей, как было со Стивом Джобсом и Джони Айвом, которые создали философию Apple.
Каким образом можно обрести “правильное” видение сказать сложно. Неплохая идея — вдохновляться чужим: читая книги великих инноваторов и изучая успешные продукты. Для начала этого может быть вполне достаточно, а дальше все будет зависеть от вашей способности анализировать опыт и на основе него принимать грамотные решения.
Опыт — ключевая вещь не только в логике, но и творчестве. Поэтому набирайтесь его ежедневно, осмысливайте полученные знания и не останавливайтесь.
Продуктовый дизайнер: кто это такой, какие скиллы ему нужны и как ему развиваться
Привет! Меня зовут Вероника Жалкая, я дизайн-директор IT-компании Artsofte. В прошлой статье я рассказала, как начинающему дизайнеру выстроить систему развития, чтобы быть востребованным на рынке.
Сейчас я хочу подробнее разобрать навыки, которые нужны продуктовому дизайнеру.
Давным-давно, на заре IT-рынка, первичны были технологии. И люди под них подстраивались. Это работало, потому что продуктов было мало и конкуренции не было — всем было важно, чтобы продукт работал, а желания пользователей никого не волновали.
Если посмотреть на старые системы, то глазам становится больно. Пользователи страдали. Они месяцами (или даже годами) осваивали новый софт и его функционал.
Поэтому у огромных продуктов до сих пор проблемы и с юзабилити и с UI — не так просто взять и изменить логику и интерфейс всей системы, когда она разрослась в нечто огромное с миллионами пользователей.
Со временем ситуация стала меняться. Быстрый рост технологий, распространение интернета, увеличение числа пользователей и снижение порога входа в мир IT привели к росту конкуренции. Если раньше были большие продукты, которые закрывали потребности пользователя во всем, но были максимально неудобными, то теперь есть много маленьких продуктов, из который пользователь может выбирать сам.
А пользователь выбирает удобное. И ему проще выбрать несколько удобных продуктов на разные задачи, чем одного непонятного, страшного и перегруженного, но функционального монстра. Это и изменило подход к разработке — потребности человека и его удобство стали первичны.
Сегодня пользователи очень привередливы, поэтому на первый план выходят исследование аудитории, тестирование, выявление потребностей, и, конечно, UX и UI. Любую технологию нужно упаковать так, чтобы людям было легко и просто с ней разобраться. Иначе конкуренты скопируют идею, но сделают более удобный продукт, а вы умрете с голоду.
Сейчас продуктовый дизайн важен как никогда. От работы дизайнера и его решений зависит большая часть успеха продукта. Дизайнер в продукте отвечает за:
Работа дизайнера очень тесно связана с работой менеджера продукта, в идеальном мире они дополняют друг друга настолько, что иногда их можно спутать. Но дизайнер больше отвечает за визуал и мыслит со стороны пользователя, а менеджер — со стороны бизнеса и рентабельности продукта.
Профессия достаточно молодая и четких требований к ней еще нет. Разные компании ждут от дизайнеров разного функционала, но все сходятся на том, что недостаточно просто рисовать, прототипировать или заниматься аналитикой.
Продуктовый дизайнер – это специалист с широчайшим спектром знаний и навыков. Здесь и аналитик, и проектировщик, и UX/UI дизайнер, и даже моушн и копирайтер. А еще это человек, который, чтобы достичь нужного результата должен уметь найти подход к каждому члену команды, а значит иметь прокачанные софт-скилы, лидерские качества, постоянно совершенствовать навык ведения переговоров.
Профессия продуктового дизайнера состоит из нескольких блоков, и в каждом — свои скиллы:
Классические дизайнерские навыки. Навыки по композиции, цветоведению, типографике.
Бизнес-навыки. В первую очередь это понимание предметной области и рынка, понимание продуктовых и интерфейсных метрик. Далее – построение и проверка продуктовых гипотез. И, конечно, анализ всего этого, а очень часто это огромные объемы данных.
Исследовательские навыки. Здесь понимание и описание портретов пользователей, а также проверка дизайн-решений.
Навыки проектирования. Продуктовому дизайнеру нужно будет проектировать структуру и навигацию по продукту, проектировать сами интерфейсы, следить за тем, чтобы все пользовательские сценарии при этом были закрыты, потому что если пользователь может все посмотреть, выбрать, но не может, например, оформить заказ из-за непродуманной логики, то толку от такого продукта не будет.
Здесь важно думать не только о взаимодействии онлайн, но и как пользователь будет действовать вне вашего продукта. Например, у вас есть приложение, но вы не можете в него внедрить оплату, и оплачивать можно только по счету. Нужно убедится, что пользователь поймет, что ему нужно сделать: оплатить через десктопную версию продукта, зайти на сайт или дождаться письма со счетом на почту. Нужно продумать все пути, чтобы определить все места, где он может споткнуться, и вовремя предложить поддержку, описать следующие шаги. Будьте максимально внимательны на этом этапе, продумайте все возможные проблемы заранее.
Навыки копирайтинга. Не обойтись без базовых навыков копирайтера, потому что дизайнеру нужно будет писать интерфейсные тексты, продумывать формулировки, названия кнопок. Важно следить, чтобы ваш продукт был целостным, не появлялись отдельные элементы с отличным tone of voice.
Здесь же важно помнить о том, что свою идею иногда нужно продать, пусть даже своей же команде. А это требует развитых навыков презентации.
Навык работы с анимацией. Передавая плоды ваших усилий в разработку, нужно максимально подробно описать, как должен работать тот или иной компонент, показать, как работает анимация. Для этого нужны навыки моушн-дизайнера.
Навык работы с иллюстрациями. Продуктовому дизайнеру не обязательно быть художником, но он должен уметь создавать отдельные иллюстрации, разрабатывать пакеты иконок для своего продукта.
А вот верстка — навык сомнительный. Многие считают, что продуктовый дизайнер должен уметь сверстать все то, что он создал, но в нашей компании это необязательный навык. Я считаю, что дизайнер, безусловно, должен понимать принципы верстки, но саму верстку лучше доверять профессионалам. Продуктовый дизайнер и без того «и жнец, и жрец и на дуде игрец», к тому же верстка постоянно развивается, появляются новые способы, новые подходы. Чтобы знать и уметь еще и это, дизайнеру нужна вторая голова и 46 часов в сутках. Но некоторые компании могут требовать этот навык, вы должны быть готовы к этому.
На этом харды заканчиваются. Давайте перейдем к софт-скиллам.
Продуктовый дизайнер — что это за профессия?
Как и в любой другой профессии, дизайнер не может уметь всё. Графический дизайнер, дизайнер интерфейсов, веб-дизайнер — это разные люди с разными задачами и компетенциями. Относительно недавно компании начали искать продуктовых дизайнеров. Что он должен уметь и почему стоит учиться этой профессии?
На эти вопросы ответили участники паблик-тока онлайн-университета Skillbox по курсу «Продуктовый дизайнер».
Это довольно «молодая» профессия, в которой соединены разные функции и задачи. Нужно уметь заниматься прототипированием, проводить исследования пользователей, использовать навыки анимации и графического дизайна.
руководитель продуктового направления в Альфа-банке
Для продуктового дизайнера важно уметь смотреть на то, что ты делаешь, не только собственными глазами — т.е. дизайнера, который работает с макетами. Нужно учитывать интересы бизнеса, стратегию коммуникации.
Чтобы все это сделать, этого нужно много разговаривать с командой. Грубо говоря, если у тебя есть какая-то задача, ходить и «мучить» всех вокруг.
руководитель продуктового дизайна в ПСБ-банке
Продуктовый дизайнер сфокусирован на нескольких задачах: вижн продукта, как этот продукт зарабатывает деньги и как решает проблемы пользователей.
Главное в работе продуктового дизайнера — соединить «хотелки» бизнеса с проблемами и болями пользователей в единый продукт, который удовлетворит всех. Довольно часто бизнес хочет, чтобы пользователь за что-то заплатил, а пользователь платить не хочет.
Поэтому в работе важно находить решения — придумать связку между бизнесом и пользователем.
Когда-то я работал продуктовым дизайнером и делал приложение для телевизоров, мобильных телефонов и веба. Это было мое второе место работы как дизайнера — я много рисовал и прокачивал свои навыки.
Сейчас все изменилось. Около 70% рабочего времени уходит на коммуникации. Я узнаю у всех участников, что происходит с проектом, собираю данные, провожу исследования, общаюсь с заказчиками, убеждаю их, что предложенное решение работает. На сам дизайн — уходит максимум 40-30% времени.
Я не переживаю, что стал меньше рисовать. С помощью коммуникаций с разными членами команды я набираюсь знаний. У меня есть люди, которые имеют невероятную экспертизу — аналитики, технологи. Общаясь с ними, я приобретаю новый опыт. И это больше плюс, чем минус.
Наши дизайнеры работают в похожем режиме. С утра «дсм-ка» — собрание команды, на котором каждый рассказывает, что делал вчера и что собирается делать сегодня. Это помогает понять, как продвигается работа.
Обычно утренняя планерка занимает около 20 минут. Потом дизайнеры идут работать. Основную часть времени занимает общение с командой.
Сейчас у меня, к сожалению, практически нет «ручной» работы. Под моим руководством работают около 60 дизайнеров, я просто не успеваю погружаться в макеты. Я помогаю настроить диалог с бизнесом, с продуктовой командой, ребятами из маркетинга — чтобы никто ни на кого не обижался и продукт в итоге получился хорошим.
Помимо работы надо не забыть поесть. На удаленке нет ощущения отключения от работы. Иногда я вижу, как дизайнеры что-то пишут в рабочих чатах даже поздно ночью.
Мы обычно строим работу так: дизайнер разработал проекты на месяц вперед, и команда их разбирает. В это время у дизайнера есть возможность заняться большой задачей. И он снова подключается к работе команды, когда появляется дополнительные данные или вопросы от разработчиков.
То есть, продуктовый дизайнер обычно находится на несколько спринтов вперед. Так работа команды организуется эффективно.
Но многое зависит от задач. Когда дизайнер работает над большой задачей, он зачастую не в спринте. Быть в спринте — это работать над чем-то неделю или две.
Нет единого метода. Каждая команда выбирает стиль работы, который ей подходит.
У нас действовал такой принцип: дизайнеры начинают работать только над продуктом, когда его разработка уже запланирована. Это помогает не рисовать «в стол». Если что-то планируют разрабатывать через полгода, дизайнеры подключались незадолго до начала разработки.
Product owner — это человек, который отвечает за продукт, над которым работает продуктовый дизайнер. Многие не понимают, чем именно занимаются владельцы продуктов и как они общаются с дизайнерами.
Для нашей команды — это люди из классической части банка, которые формируют сам банковский продукт. Финансовые сервисы, различные бонусы и предложения разрабатывают специальные люди. Для примера, они могут предложить такую идею: «Клиент в месяц тратит больше 30 тысяч рублей с карточки, нужно сделать бесплатное обслуживание».
В этот момент они вступают в роль product owner при общении — объясняют, что придумали и просят реализовать. Мы пытаемся учить продактов именно такому стилю общения с дизайнерами.
В нашем случае, Product owner играет роль заказчика и «адвоката бизнеса». Он отвечает за то, чтобы продукт зарабатывал деньги, а команда фокусировалась на стратегических задачах. А продуктовый дизайнер больше похож на «адвоката пользователя». Он пытается сделать удобный и понятный продукт, которым удобно пользоваться.
При сложных задачах решения предлагает вся команда. Собираются все: продакты, дизайнеры, технологи, разработчики. Вместе мы пытаемся найти оптимальное решение.
Продуктовый дизайнер: правила эксплуатации
Дизайнеры продолжают эволюционировать.
В ширь, ввысь и даже вкось.
Если раньше было достаточно назваться дизайнером и научиться без запинки произносить слово «Фотошоп», то сейчас этих навыков уже явно недостаточно для поиска приличной работы.
Один из видов дизайнеров достаточно нового направления — продуктовый. В статье именно о нем я и хочу поговорить.
Ударю по теории и практике.
В теории хочу разобраться кто это такой и что от него хотят.
На практике — описать процесс работы этого самого дизайнера над тем самым продуктом.
Поехали!
Часть первая. Теоретическая.
Кто такой, сколько стоит и чего ожидают
Итак, в первых строках своего письма, уважаемая публика, хочу все-таки пояснить, что ж это за зверь такой «Продуктовый дизайнер» и чего от него хотят компании, принимая в ряды свои славные.
Перво-наперво, обратилась к курсам, которые учат этому самому продуктовому дизайну.
Вот что говорят курсы.
Нетология обещает зарплату от 120 тыщ. рублей
«UX/UI дизайнер, дизайнер продукта — одна из самых востребованных digital-профессий с широкими возможностями для роста и высокой заработной платой
Она сочетает в себе аналитику и творчество, инженерный подход и нестандартность решений. Грамотная работа дизайнера увеличивает прибыль клиента и улучшает взаимодействие пользователя с продуктом.»
«Продуктовый дизайнер отвечает за создание и развитие продукта: от идеи до выхода на рынок.
Вы научитесь продумывать бизнес-стратегию, работать с IT-командой, проводить исследования и проектировать дизайн-системы.»
«Формирует концепцию продукта, определяет, как с помощью дизайна решать проблемы бизнеса и достигать поставленных целей, и вместе с менеджером продукта ведет продуктовую команду к воплощению стратегии. Учитывает ограничения и потребности рынка и технологий. Инициирует исследования и тестирования. Имеет целостное представление обо всей экосистеме продукта, разрабатывает или курирует создание всей дизайн-системы. Знает все о пользователе, его потребностях и целях. Итог работы продуктового дизайнера — работающий цифровой продукт.»
В общем, достаточно размыто все в описаниях.
Теперь кинем взор на hh.ru и посмотрим, чего же реально ждут работодатели от человека, именуемого продуктовый дизайнер.
Действовала я топорно и без изысков: вбила в поисковую строку «Продуктовый дизайнер» и выписала часто встречающиеся требования.
Хозяйке на заметку: в вакансиях уровень зарплат часто не указывают, поэтому реальную картину понять достаточно тяжело.
Но могу огорчить обещателей и ожидателей зп от 100 тыщ.
Есть, есть компании, которые хотят много, но платить за это много совсем не готовы.
Ну и погнали теперь по общим требованиям:
Вообщем, требования достаточно обширные. Где-то больше, где-то меньше.
Надеюсь основное направление понятно.
Продуктовый дизайнер должен, в идеале, совмещать в себе дизайнера, проектировщика интерфейса, бизнес-аналитика, исследователя, оратора, креативного логика и вообще прекрасного человека с широкий душой и мощным кругозором.
На самом деле все у всех по-разному.
Но я точно знаю, что какая-то часть грозно составленных требований, без которых ну вот никак вам работу не потянуть, на деле оказывается либо не нужна, либо в совсем малом объеме.
Но это лично мой опыт. Может у кого-то совсем и не так.
Причина же такого положения дел бывает достаточно банальной: просто не хватает времени на все вот эти сюсю-пусю с исследованиями, тестированиями и прочей лабудой. Потому что уж замуж невтерпеж и партия сказала надо, а мы сказали есть.
Честно, я думаю, что когда-нибудь человек-оркестр закончится и один продуктовый дизайнер развалится на отдельные специальности. Потому, что и нагрузка бывает достаточно высока, и склад мозгов у всех разный.
Это как история с дизайнерами-верстальщиками.
В теории звучало хорошо. На практике, я не видела ни одного верстальщика, который мог бы качественно сделать дизайн с нуля и наоборот. Возможно, плохо искала или зрение меня подводит.
Но а пока я сижу, болтаю ножкой, жалуюсь на жизнь и называюсь продуктовым дизайнером, хочу поделиться опытом, как выстраивала процессы, что бы потом не было мучительно больно…
Потому что делать все равно надо.
Во-первых, искать время и выстраивать процесс работы над продуктом так, что бы после запуска не падать в нервный обморок от осознания того, что вместо счастливого смеха пользователя ты слышишь его отборный мат. Ну и разрабы, опять же, как то нехорошо косятся в твою сторону.
Часть вторая. Практическая.
Основана на реальных событиях.
Не скажу, что на всех проектах у меня получилось сделать так, как задумывалось. Но были… были в моей биографии светлые пятна, когда получалось.
И об этих светлых пятнах и будет мой рассказ.
Тут стоит отдельно обратить внимание на то, что последние года четыре я занимаюсь разработкой проектов с нуля. Поэтому описание процесса будет касаться их. Но что-то мне подсказывает, что процесс можно примерить и к уже готовым продуктам.
И да, в статье я коснусь только процесса разработки и запуска именно нового функционала. Про генерацию гипотез, сбор обратной связи и прочее потом, иначе совсем много будет.
Сбор требований с заказчика
Требования можно собирать от Product Owner, заказчика, или другого ответственного лица.
На этом этапе важно понять как это работает сейчас и как это видится ответственному лицу. Причем не только здесь и сейчас, а и с зазором на будущее.
Ведь когда видишь картину целиком, а не кусками, всегда проще закладывать основы на дальнейшее масштабирование и доработки.
Требования надо собирать тщательно, не оставляя ни одного белого пятна.
По хорошему, этим должен заниматься бизнес-аналитик. Узнал, записал, принес, сделал «Чмоки» и махнул ручкой на прощание.
Но, имея за плечами горький опыт сломанного телефона, уверена, что этим должен заниматься продуктовый дизайнер. Ну или присутствовать при сборе требований.
Потому, как есть вещи, которые аналитику не так важны, а вот при проектировании интерфейса без них никак. Поэтому сам и только сам, ну или рядом, как рояль в кустах с блокнотом, ручкой и диктофоном.
О диктофоне, кстати, хочу сказать отдельно: если не используете его в своей работе — начинайте использовать. Функция полезная до безобразия. Когда ты знаешь, что весь разговор записывается, ты можешь на нем сосредоточиться, не растеряв по пути фокус внимания, отвлекаясь на записи и прочее.
Сбор требований с пользователя
Это уже другая сторона медали.
Вот ты сейчас понял как это работает наверху, а теперь надо пойти и копнуть глубже. Копать надо в сторону тех, кто знает не только вершки, но еще и корешки.
Посидеть и посмотреть как он работает с тем, что уже есть.
Спросить что устраивает, а что нет. А как хотелось бы. Что важно при совершении определенного действия, принятия решения и прочее.
Даже если делаем то, чего еще нет, все равно они каким-то образом решают эти задачи.
Потыкав палкой в обе стороны, уже имеешь более-менее внятную картинку с которой можно работать.
Еще из важного: про то, как работает и что не так, лучше узнавать ни у экспертов, а у конечных пользователей. Потому, что у экспертов может оказаться только теория или воспоминания минувших дней, а у конечных пользователей реальная практика, боль и слезы.
Почему я обращаю на это внимание? Потому что опять же шишки из практики. Собрал проблемы от экспертов, выпустился и поехал смотреть, насколько рады конечные пользователи свалившемуся на них счастью в виде решения их проблем.
И вдруг, внезапно, оказалось, что часть проблем не валидна, часть возникает не тут и не в это время, а часть вообще звучит странно и хз им бедным, что с этим делать. Короче, спасибо, решили, правда только хуже сделали.
Схема пути пользователя
Эту часть можно назвать CJM, можно еще как-то.
Ее суть состоит в том, что после полученной кучи знаний, эту кучуя нужно преобразовать в какой-то удобряемый для дальнейшей работы вид, это раз. Два — решить, все ли понято, учтено и записано со слов потерпевшего верно.
Напоминаю, что сейчас рассказываю про разработку нового продукта. Как я это делала. Возможно, кто-то делает по другому или не делает совсем.
А я брала и раскладывала весь пользовательский путь употребления какой-то функцией от точки А до Б, от Б до С и так далее.
Так как часто приходилось делать то, чего еще нет, то реальные проблемы, радости и прочее передать не могла.
Прикидывала, в теории, что там может быть, в какой момент они рискуют свернуть на темную сторону зла, пройти не по тому пути и прочее.
Когда весь путь чист, как слеза младенца, можно уже и к прототипу приступать.
Прототип первый: бумажный
Не знаю, может для кого-то этот шаг не обязательный, но я его делаю всегда. Помогает быстро накидывать и исправлять решения, не отвлекаясь на красоту кнопок и градиентов.
Бумажки можно разложить в ряд и оценить логику и понятность будущего продукта.
На бумажках можно даже выписать какие-то моменты, которые нужно еще подумать или сразу выписывать возникающие вопросы, которые нужно будет уточнить у разработки, например.
Прототип второй: динамический
Я его делаю в Axure.
Честно, пробовала в других программах, но мне элементарно не удобно, особенно когда будет достаточно большое количество экранов.
Динамический прототип нужен для того, что бы показать высшим силам, что все идет как надо и пользователю в момент тестирования.
Не скажу, что я его прям дизайню, но какие-то важные акценты и цвета делаю.
Тестирование прототипа
Прогон по сценарию с прототипом помогает убедиться, что вы таки попали туда, куда целились. А может попали, но не туда. А может вообще не попали.
В любом случае, все правки прототип переносит легче, чем продукт, запущенный в прод.
Тестирую на проход по определенным сценариям, насколько пользователь понимает значение символов, удобно ли ему представлена информация и прочее.
Не скажу, что все проходит гладко и правильно.
Были и ограничения по времени, когда просто приходишь и показываешь итог своей работы. Типа, вот смотрите: вы просили, а мы вот чего сделали. Потом сидишь и слушаешь обратную связь.
Первый раз думала, что фиг из такого подхода что хорошее получится, но нет. Ошибки, непонятные и спорные моменты найти все-таки удалось.
Поэтому сделала вывод, что если уж не получается выделить время «на поговорить», то можно ограничиться показом, собрав обратную связь.
Это точно лучше, чем ничего.
Показ прототипа разработке
Вообще, получается такой фокус не всегда, но считаю важным находить на это время двум сторонам.
Часто, когда время ограничено, что-то можно упростить, не теряя при этом качества.
Можно еще отметить места, которые потребуют более детального описания логики работы, чтобы разработчикам потом жилось легче.
Тадам! Финишная прямая: дизайн
Тут рассказывать особенно нечего. Садишься, открываешь программулину и начинаешь рисовать хорошо или не очень то, над чем трудился в предыдущих сериях.
Позволяет время — идешь набираться визуального и прочего вдохновения на ресурсах, названия которых нельзя произносить, потому что последнее время их часто хают.
Передача в разработку
Раньше описывала сценарии в формате user story.
Звучало это примерно так:
Я, как …., хочу…
Далее описывалась сама функция, действия с ней пользователем, дополнительные возможности и пр.
Оказалось, что иногда получается много и никто это читать не желает, поэтому стала лепить примечания в самом прототипе и раскладывать в miro путь уже надизайненными экранами.
Оказалось, что разработчикам так работать значительно удобней.
Они видят все сразу, могут задать вопросы или наклеить стикеры, что бы что-то не забыть.
Собственно, это практически все, что я хотела поведать о том, как продуктовый дизайнер должен работать с задачей.
Заключение
Повторюсь, что это мое виденье и мой опыт.
Каждый из шагов важен для того, что бы получилось хорошо. И на каждый из шагов необходимо время.
Наверно, поэтому я не очень верю в историю о том, что позиция продуктовый дизайнер проживет долго. Ну или у каждого будет по мешку времени, или что-то будет прорабатываться не так тщательно.
Очень хотелось бы узнать ваше мнение о построении процессов работы, обязанностях и возможностях продуктового дизайнера.
Будет ли актуальна эта профессия в будущем или распадется, в конце-концов, на отдельных узких специалистов.