Неразрывный дизайн

Наткнулась на видео с альтернативным мнением про эмоциональный дизайн, про который сейчас говорят просто везде (больше обсуждают только ИИ). Я не прямо на 100% со всем согласна, но с большей частью — да. Особенно важна мысль о том, что навертеть анимаций поверх всего ≠ сделать дизайн эмоциональным и просто хорошим.

Про Figma MakeНекоторые коллеги там уже делают прототипы, я тоже хотела попробовать. Нужен был поиск с результатами в дропдауне, у нас такой паттерн нигде не используется. Важно было учесть наши специфичные условия и не кастомить ДС по возможности.Обычный прототип пришлось бы собирать на переменных и, главное, всё равно без ручного ввода данных.В итоге получилось как на гифке. Сначала собрала прототип с переходами по клику, потом отправила в Мейк с минимальным описанием. Уже на этом этапе он справился неплохо. Дальше дорабатывала в чатике, один раз приложила дополнительный макет. Графику он не потянул (картинка «ничего не найдено» и иконка не такие, как в макете), исправить было можно, но зачем)Заняло полчаса, наверное, может, меньше.В целом вся эта штука не для пользователей, а во-первых для меня — проверить, ничего ли не упустила, во-вторых — показать команде, чтобы они точно поняли, что нужно сделать.

Действительно качественная и глубокая работа продуктового дизайнера возможна, когда он работает над одним продуктом. Когда я начала активно погружаться и подхватывать задачи разных продуктов, вовлечённость в каждый стала сокращаться. Когда отвечаешь не только за интерфейс, но и на ТоВ в чатике с пользователями, потому что пользовательский опыт это всё вместе — вот это свелось к минимуму.Но появился и позитивный момент: стало больше идей и альтернативных решений. Дело не в насмотренности даже, а в том, что начинаешь видеть, какие подходы можно адаптировать из одного контекста в другой.А ещё ушло ощущение, что я как будто повторяю саму себя и погружаюсь в лёгкий застой.Контексты важно иногда менять. Есть несколько способов делать это аккуратно, а не как у меня (по возрастанию эффективности):3. Дизайн-синки — это не для галочки и не для отчётности. Важно не только показывать свою работу, но внимательно слушать других а не просто сидеть в ожидании своей очереди, разбираться, почему сделано именно так и что можно попробовать у себя.2. Кросс-ревью — тут уже точно не получится просто послушать 😁 вовлечённость в чужую работу выше.1. Подключаться в другие продукты на помощь, не на постоянку, а на ограниченное время и объём. Приходится разбираться в чужих решениях и находить свои в новых ограничениях. Продукт даже может быть похож на свой — это всё равно работает.Как это всё делать, когда ты соло-дизайнер — честно, намного сложнее. Но лучше смотреть разборы чужих работ на ютубе, чем вообще ничего. В общем, глубина важна, но переключение тоже нужно, чтобы не застревать в одних и тех же решениях.

Метрики в b2b и b2e Обычно мы живём в парадигме, что у нас мало пользователей, поэтому количественные исследования затруднительны и в целом мы на цифры не смотрим. И ещё есть мнение, что хороший дизайн на метриках не построишь.Я с этим согласна, но метрики нужны для другого. Во-первых, проверить, сработали ли идеи, это нужно для себя и для собственного роста. Во-вторых, для разговоров с продуктовой командой и бизнесом (защитить решение, затащить идею, подсветить свою ценность, чтобы не сократили).Метрики бэкофиса можно разделить на 4 основные группы. Удовлетворённость пользователей, производительность, ошибки, метрики относящиеся к дизайн-процессу. С продуктовыми метриками они соотносятся примерно так: производительность (эффективность) влияет на финансовые показатели, метрики ошибок почти одинаковые, метрики дизайн-процесса влияют на ttm (time to market). Самое сложное, но очень важное — объяснить как удовлетворённость пользователей влияет на продукт. Часто встречается контраргумент: у пользователей нет выбора, это их рабочий инструмент, поэтому их удовлетворённость не критична. Сложно представить, что пользователи станут саботировать свою работу из-за неудобного интерфейса. Но когда мы хотим проверять продуктовые гипотезы, затаскивать новые бизнес-процессы или подключать другие группы пользователей — вот тут удовлетворённость начинает играть большую роль, потому что при проблемах будет сложно понять, это просто гипотеза не подтвердилась или дело в другом.Как их мерить — отдельная тема, постараюсь когда-нибудь расписать подробнее. Но что важно: многое можно померить без систем аналитики и без привлечения разработчиков, хватит опросов и даже интервью. И ещё, метрики нужны только для работы внутри продукта, рисовать их для красоты кейса в портфолио — сомнительная история, требовать их на собесах — ещё более сомнительная.

Раздражает, когда создатели роботов пытаются всеми силами преодолеть зловещую долину и сделать так, чтобы их детище невозможно было отличить от живого человека.По-моему, какая-то бессмысленная трата усилий. Сейчас голосовые дозвонщики даже специально заикаются и мэкают, лишь бы ты принял его за человека — зачем? Зачем называть колонки популярными женскими именами — чтобы казалось, что это член семьи, а не просто колонка?Так с этой задачей прекрасно справляется наша человеческая природа. Мы даём имена роботам-пылесосам, видим лица во всём, что хоть немного похоже на лицо, очеловечиваем простеньких чатботов. Это буквально биологические особенности нашего вида. Людям обычно комфортнее общаться с людьми, но в некоторых ситуациях — с роботами (пруф). А самый сильный дискофморт вызывает ощущение обмана, когда ты думаешь, что говоришь с человеком, а это не так. Или когда не уверен, человек ли на другой стороне.По-моему, самый крутой робот-помощник из кино — ТАРС из Интерстеллара, он не похож на человека, но от этого менее классным не становится.Дело не в том, что роботы пока не совершенные и палятся. Проблема в самой концепции, цель стать неотличимым от человека вызывает вопросы. Робот быстрее думает, справляется с огромным объёмом информации лучше человека — это его достоинства, не нужно их прятать под бессмысленную мимикрию.

Какой самый дорогой, но эффективный инструмент дизайнера? Не платная Фигма, не Курсор и другие ИИ, время.Дорогой, потому что его почти никогда не хватает.Есть это чувство замыленного глаза, когда слишком долго работаешь над задачей и уже не видишь даже очевидных косяков, допиливаешь мелочи и упускаешь большие решения.А стоит отложить задачу на какое-то время, вернуться к ней — и сразу появляются классные идеи, как сделать понятнее, красивее, иногда даже понимаешь, что надо вообще всё переделать и будет огонь, а не решение.Но если в задачах у вас почему-то нет дедлайна — не спешите радоваться. Тут тоже ничего хорошего, можно делать что-то бесконечно и так и не прийти к какому-то результату. Дизайн всё-таки это всегда работа в рамках ограничений.Если есть возможность отложить задачу ненадолго и потом к ней вернуться — пользуйтесь, пусть незакрытая повисит, ничего страшного. Если нет, то стоит попытаться хотя бы минимальную паузу взять и сменить фокус на что-то другое. Возвращение к макетам с посвежевшей головой почти всегда сделает их сильнее.

Чтобы обсуждение с командой проходило быстро и без лишних вопросов, достаточно принести такую схему — все впечатлятся объёмами предстоящей работы и от шока не смогут ничего оспорить))Если серьёзно, сценарии — незаменимая штука. Когда их делаешь, сразу видно, как всё будет взаимодействовать: где вылезут ошибки, корнер-кейсы, тупиковые ветки. Становится понятно, логично ли вообще решение и поймёт ли пользователь, что происходит. На схеме проще увидеть, как сократить путь к цели и упростить процесс.Сценарии — отличный артефакт для обсуждения с командой, не тратя время на отрисовку макетов. Уже по схеме разработка может подсветить риски и предложить альтернативы. Все быстрее погружаются в единый контекст.Как их составлятьЕсли в компании нет строгих правил, достаточно самых простых фигур в фигджеме.Определяем точку входа — зачем пользователь вообще начинает действие — и финальный результат (решил заказать чипсы → получил чипсы).Дальше строим самый короткий путь между ними — это основной сценарий (нашёл → выбрал → оплатил).Потом добавляем ответвления (пошёл в каталог, добавил несколько, решил взять кетчуп) — дополнительные сценарии.И отдельно ошибки (чипсов нет, интернет отвалился).Можно собрать всё в одну большую схему, так лучше видно общую картину и пересечения.Можно делать несколько маленьких, их проще редактировать и в них легче ориентироваться.Схемы могут быть некрасивыми. Они нужны не сами по себе, а чтобы сделать удобный продукт.Если они понятны дизайнеру и команде, значит, всё ок.На встрече с заказчиками мы вообще поверх схемы разложили макеты некоторых экранов для наглядности. Формально это, конечно, франкенштейн и методологическая ересь, но к взаимопониманию мы пришли раньше, чем закончилась встреча.

А сегодня про UX, победивший UI 😁Делала опрос в Анкетологе, потому что в гуглоформах сложно настраивать сложную логику переходов. Сначала я думала, что пришла туда умирать. Чтобы просто найти свою папку в бесконечном несворачиваемом дереве, пришлось пользоваться поиском по странице. Поясняющие тексты в настройках такие, что их можно было бы вообще не писать, хуже бы не стало. Но когда я начала настраивать свою сложную логику — вот тут я преисполнилась. Хотя форма выглядит страшненько, она очень простая и понятная. Подписи, логика появления элементов — всё чётко. А самое удивительное, что оно сразу заработало как надо, без единой правки. Похоже, что основной сценарий там спроектировали отлично, а всё остальное ушло в вечный дизайн-долг 😁знаю про существование других опросников, но выбор был ограничен имеющимися доступами

UI, победивший UXМне достался чужой корпоративный подарок — две свечи и подставка под них.Не знаю, какая там была метафора, но свечи красиво выстраиваются в слово UI (вряд ли это задумывалось).UI радовал минут 10, а потом 30 минут разбиралась с непродуманным UX.Почему-то мне казалось (профдеформация), что раз это комплект, то кто-то подумал, как это будет работать и всё предусмотрел, парафин аккуратно сгорит, распадётся на кусочки или что-то ещё, но никак не то, что мне придётся отковыривать его от всех поверхностей 🤪UI, победивший UXМне достался чужой корпоративный подарок — две свечи и подставка под них.Не знаю, какая там была метафора, но свечи красиво выстраиваются в слово UI (вряд ли это задумывалось).UI радовал минут 10, а потом 30 минут разбиралась с непродуманным UX.Почему-то мне казалось (профдеформация), что раз это комплект, то кто-то подумал, как это будет работать и всё предусмотрел, парафин аккуратно сгорит, распадётся на кусочки или что-то ещё, но никак не то, что мне придётся отковыривать его от всех поверхностей 🤪

Иногда бывает, что дизайнеру никто не ставит задачи.От этого грустно, кажется, что ты бесполезный член команды, ничего не делаешь и вообще не развиваешься. Но можно посмотреть с другой стороны: можно самому выбрать, чем заняться, с пользой для себя и для команды.Задачи, которые можно поставить себе самостоятельно:🔹 Почитать поддержку и найти там проблемы и боли. Сформулировать гипотезы и придумать решения 🔹 Если есть доступ к метрикам, посмотреть что там происходит. Найти странные места отваливания пользователей и другие проблемные зоны и пойти выяснять, почему так🔹 Пройти ключевые сценарии в продукте как пользователь, зафиксировать все моменты, которые можно улучшить, и по логике, и по UI🔹 Провести аудит всех незаметных вещей: текстов ошибок, пустых состояний, уведомлений. Например, проверить, все ли модалки консистентны по тексту и структуре🔹 Разобрать дизайн-долг на актуальность, если он есть🔹 Сравнить существующие макеты с тем, что реально на проде, собрать в одном месте все расхождения🔹 Актуализировать макеты, навести там порядок🔹 Составить карту продукта с привязкой к макетам🔹 Составить карту стейкхолдеров🔹 Навести порядок в компонентах и локальных UI-китах, пересобрать раздетаченные компоненты, проверить, что цвета и тексты оформлены через стили🔹 Составить текущие пользовательские сценарии и попробовать сделать улучшенные версии — там почти всегда находятся точки роста🔹 Собрать библиотеку референсов: паттерны, удачные флоу конкурентов, решения, которые подходят вашему продукту🔹 Попробовать выделить и описать паттерны продукта (поведение уведомлений, скачивание и импорт файлов, формы заведения данных и т.д.)Что-то можно делать полностью самостоятельно. А всё, что связано с развитием продукта или техническими расхождениями, нужно оформлять в понятные задачи / документы, чтобы любой в команде мог понять, в чём суть.Почему вообще возникает ситуация, когда дизайнеру нечего делать? Чаще всего одна из 3 причин:1. Разовая история, например, команда рефак