Тонкости продуктового дизайна



    Продуктовый дизайнер — это не совсем дизайнер. Он может неделями не открывать графический редактор и не произвести ни одного макета за месяц. Потому что основная цель его работы в другом.

    За последние полтора года я работал над двумя продуктами. С первым (BINO CX) прошел путь от нуля до выручки в 1 млн рублей меньше чем за год, а второй развиваю в данный момент.

    Я знаю, что многие дизайнеры хотят перейти в продукт из-за более высокой оплаты, размеренного ритма и возможности напрямую влиять на бизнес. Поэтому я решил написать эту статью, в которой учел личный опыт и знания, полученные от ведущих продуктовых дизайнеров нашей страны.

    Не творческое просветление


    Дизайнеры не любят, когда их просят что-либо нарисовать, ведь половина их работы происходит вне графического редактора.

    Дизайнеры проводят исследования, проектируют решения, продумывают сценарии, в то время как руководство продолжает считать их творцами.

    Не справедливо? Отнюдь.

    Если руководство считает дизайнера творцом, значит дизайнер не правильно преподносит себя и свою работу.

    Чтобы повысить свою значимость в компании, от дизайнера требуется показывать понимание бизнес-задач и завоевывать доверие грамотными дизайн-решениями.

    На старте карьеры я этого не понимал, поэтому каждая моя идея выглядела как творческое просветление (отчасти так и было). Спустя несколько лет я понял свою ошибку и теперь вкладываю усилия только в те вещи, которые требуют улучшения и способны положительным образом повлиять на показатели бизнеса.

    Вы можете сказать руководству, что визуальный язык сервиса устарел, но этот аргумент меркнет и бледнеет на фоне задач, от которых напрямую зависит прибыль компании.

    Продуктовые дизайнеры тоже крадут


    Очень полезно обратиться к опыту схожих сервисов, даже если вы создаете новый продукт. Это могут быть прямые конкуренты или сервисы с похожей механикой.

    Слушая курс ux-design от AIC, мне стало очевидно, что изучение конкурентов помогает не только в поиске вдохновения, но и при аргументации своих решений заказчику/руководителю. Стоит показать пример успешного сервиса и доверие к вашей идее возрастает в разы.

    Авиакомпании могут анализировать интерфейсы сервисов по продаже билетов в кино. Сайты футбольных клубов могут обратиться к опыту медиа-сервисов. И кто угодно может посмотреть на соцсети.

    Создавая сервисы для крупных банков, я анализировал игровые механики приложений по изучению английского языка. Интересные идеи я выписывал в отдельный файл и разбивал по категориям. Лучшие использовал.

    Анализ конкурентов — не копирование, а использование накопленного индустрией опыта. И очень глупо его игнорировать. Но несмотря на это, перед внедрением новой функции нужно хорошо подумать.

    “Так делает Google!” — не аргумент.

    “Так делает Google, потому что он таким образом решает схожую задачу” — совсем другое дело.

    Главные друзья


    Разработчики — главные друзья дизайнеров (и самый главный их инструмент).

    Цель продуктового дизайнера — создать успешный продукт. И этого нельзя достичь в одиночку, не понимая логики работы своих коллег. Не обязательно посещать курсы по программированию. Достаточно просто просить разъяснения в ситуациях, когда между отделами возникает конфликт.

    Порой дизайнеру следует пойти на уступки, если реализация предложенной идеи требует неадекватного количества времени (в соотношении с потенциальной пользой). С другой стороны, в важных моментах вы должны отстаивать свои решения и контролировать их воплощение.

    Это не является проявлением неуважения к коллегам. В этом проявляется ваше уважение к создаваемому продукту.

    О чем они говорят


    Прочитав Канемана и Талеба, я стал аккуратнее относится к любого типа статистике.

    Однажды к нам в офис залетел маркетолог чтобы поделиться открытием. Он узнал, что люди работают “по-другому”, поэтому нам придется переработать продукт. Маркетолог привел актуальный пример, его заявление выглядело логичным и основатель готов был с этим согласиться, но совершил бы большую ошибку.

    Добавляя любой функционал, опираясь на реальные примеры, узнайте какой процент ваших потенциальных пользователей будет его использовать. Возможно, вы перелопатите продукт ради 1% пользователей, которые ничего бизнесу не приносят.

    Да, это больше аналитика, чем дизайн, но это не значит, что продуктовый дизайнер не должен этого знать.

    Прочитайте “Думай медленно… решай быстро”. Эта книга сильно повлияла на мое восприятие исследований и помогает избегать типичных заблуждений.

    Фильтр шума


    Однажды, один из инвесторов настаивал на определенном решении. Я готов был согласиться с ним, но только в том случае, если сотрудники поддержки этот факт подтвердят. Поговорив с ними, оказалось, что мир изменился и клиенты теперь ведут себя по другому.

    Основатели/инвесторы обладают авторитетом, но не всегда имеют глубокую экспертизу, как сотрудники, ежедневно работающие “в поле”. Именно поэтому, работая над прошлым проектом, я регулярно общался с поддержкой и интересовался вопросами пользователей.

    Эта практика помогает выявить места, на которых у пользователей возникают затруднения. И если эти места критически важные, уделите им достаточно внимания.

    Где-то будет достаточно текстовой подсказки, а в некоторых случаях придется менять интерфейс.

    Гибкий фреймворк


    Фреймворк — базовая структура, вокруг которой строятся элементы интерфейса.

    Чем гибче у вас фреймворк, тем лучше.

    Каждый продукт развивается: получает новые функции и избавляется от устаревших. Поэтому иметь гибкую структуру удобно, так как при каждом изменении вам не придется переделывать интерфейс.

    Чтобы создать гибкий фреймворк, нужно понимать возможные варианты развития сервиса, в чем вам поможет “База знаний” (ниже). Анализируя потенциальные изменения, вы сможете принимать стратегически правильные дизайн-решения.

    База знаний


    Первые годы работы я об этом не думал, но в последнее время все больше осознаю важность ведения базы знаний. Помимо того, что коллеги могут воспользоваться собранной информацией, фиксирование помогает лучше запоминать и понимать информацию.

    В моей базе знаний хранится несколько типов материалов:

    Анализ конкурентов. В этом файле выписаны все сервисы со схожей механикой и интересные функции, найденные в ходе исследовани

    Сценарии. У каждого сервиса есть несколько сценариев и дизайнер должен знать их и хорошо помнить.

    Customer Journey Map. Отличный инструмент, который помогает проанализировать сценарии на наличие потенциальных проблем. CJM основных сценариев я делаю в таблице:


    Много конфиденциальной информации :)

    Интерфейсы. Здесь я собираю мысли и идеи о ключевых местах сервиса.

    Идеи. Общие мысли по будущему развитию продукта.

    Кто они?


    Я периодически оказываюсь в студии AIC, где дважды сталкивался с интересными случаями. Один раз рядом с монитором дизайнера я увидел фотографию Владимира Машкова, в другой — Сергея Гармаша. Догадываетесь почему?

    Оба актера были лицами клиентов студии — банков ВТБ и “Почта Банка”. Маркетинг специально подбирал актеров под целевую аудиторию, поэтому дизайнеры повесили их портреты на видное место.

    Знать пользователей — это значит понимать их мотивы, желания, привычки, график жизни, используемые устройства, средний доход, семейное положение, …

    Интерфейс проектируется для этих людей, а не для вас. Поэтому своих пользователей нужно знать.

    Видение


    Продуктовый дизайнер с самого начала имеет видение проектируемого сервиса. Я долго думал откуда берется видение и остановился на следующем:

    Видение — это синтез опыта и полученных знаний.

    Видение будущего продукта позволят отвергать некоторые идеи в пользу тех, которые этому видению соответствуют. В итоге формируемый продукт отражает видение его создателей, как было со Стивом Джобсом и Джони Айвом, которые создали философию Apple.

    Каким образом можно обрести “правильное” видение сказать сложно. Неплохая идея — вдохновляться чужим: читая книги великих инноваторов и изучая успешные продукты. Для начала этого может быть вполне достаточно, а дальше все будет зависеть от вашей способности анализировать опыт и на основе него принимать грамотные решения.

    Опыт — ключевая вещь не только в логике, но и творчестве. Поэтому набирайтесь его ежедневно, осмысливайте полученные знания и не останавливайтесь.

    Терпение — ключ ко всему.
    • +11
    • 5,7k
    • 4
    Поделиться публикацией
    Комментарии 4
      0
      Мне кажется, задача составления виденья и в целом функционала продукта, дело не дизайнера а продукт менеджера. Дизайнер естественно должен критически относиться к входящему тз, предлагать свои решения, но чаще всего у него не будет полной картины происходящего, а если он свое время будет посвящать всестороннему изучению потребностей бизнеса, фидбеку, анализу пользователей, конкурентов и т.д. когда он собственно сам дизайн делать будет???
      Я работаю в продуктовой компании как раз на позиции руководителя веб разработки (читайте продукта) и вы ровненький описали мои задачи )
        0
        Тут скорее серая зона когда каждая компания понимает под этими двумя понятиями свои особые задачи. Продуктовый дизайнер вроде-бы должен совмещать UI, User Experience, узкие места и общую логику задачи. Продукт манагер вроде-бы должен отвечать за общее развитие приложения, координировать работу отделов, делать roadmap… но часто нужно все это в одном лице и как можно дешевле!
          0
          А еще их иногда называют Продуктовый архитектор…
            0
            вот картинка hsto.org/files/1b4/c53/4a6/1b4c534a6bd244e9ab480a316bac25f9.jpg

            у нас вообще никого из этих нет) пришла задача «реализовать виджет для партнёров»… всё! неделя уходит чтоб понять что конкретно нужно, виденье результата каждого топ-а, и прикинуть хоть какую-то концепцию. Всё приходится делать фронтендеру(
            Раз было раскошелились на дизайн-макет от подрядчиков — так очень сильно удивились насколько быстрее был результат, когда УЖЕ есть дизайн)

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое