Татьяна Бублик поделилась своей системой организации файлов в Фигме.

— Все макеты продукта могут находиться в одном файле;
— Из-за этого он может тормозить и даже перестать открываться, обновления дизайн-системы будут применяться ко всем макетам, даже архивным, команде сложно находить нужные макеты;
— В Фигме есть бранчи, но недоработки этого инструмента и ошибки дизайнеров могут принести больше проблем;
— Заведите папки: для файлов дизайн-системы (сюда можно отнести редполитику и любые вспомогательные материалы), для текущих задач (и шаблонов для новой задачи и мастер-файла), для каждой фичи или микросервиса;
— Макеты по отдельной задаче создаются в отдельном файле, в названии которого есть номер тикета, чтобы легко его находить;
— Появляется такой файл в папке для текущих задач. Дизайнер подключает к нему нужные файлы дизайн-системы;
— При передаче макетов в разработку размещает их на странице For dev;
— После успешного дизайн-ревью и завершения разработки перемещает файл в папку фичи;
— А макеты из файла задачи копирует в мастер-файл фичи, в котором отображаются макеты всех флоу фичи;
— Статусы задачных файлов отличаются от статусов задач в таск-трекере: In progress, Ready for dev, Design review, Freeze, Closed (закрыта, но ещё не перенесена в папку фичи), Archive (перенесена в папку);
— В архивных файлах дизайнер не принимает обновлений ДС, макеты выглядят так, как должны были быть разработаны, что важно разработчикам и тестировщикам;
— Мастер-файлы фич содержат макеты всех флоу, что позволяет команде быстро понимать актуальное состояние фичи;
— Система требует времени для поддержания порядка (час каждого дизайнера в спринт). Плюс команде требуется время, чтобы привыкнуть.

#figma #management

Анастасия Ефанова написала, как сокращение количества пушей в 2,5 раза повысило конверсию из пушей в 3 раза и снизило отписки на 38,5%.

— Ключевая метрика — конверсия в завершённую смену, то есть работник согласился на подработку и отработал смену;
— Пуши использовались для онбординга, вывода на смену, информирования об акциях;
— Новые пользователи получали 8–10 пушей в день. Важно конвертировать их в первую смену в течение месяца, иначе такой пользователь отваливается;
— Начали с изучения сценариев отправки пушей. Выяснили, что информируют о закончившихся акциях или работают в соответствии с устаревшей бизнес-логикой (напоминают о чекине в течение часа после выхода на смену, хотя такого требования уже нет);
— По конверсии и адекватности количества пушей все сценарии разделили на худшие (надо отключать), средние (улучшать), лучшие (масштабировать);
— Например, пуш о подработках в радиусе 20 км был бесполезен в Москве и Петербурге, так как местные работники не готовы ездить так далеко;
— Сократили интервалы между онбординговыми пушами, чтобы отправить их за 2 недели вместо месяца и во вторые 2 недели сфокусироваться на конверсии в смену;
— Большинство всё равно загружает документы и выполняет прочие действия сразу, и пушей с напоминаниями не получает;
— Ввели ограничения на пуши о подработке в радиусе 10 км, если работник уже на смене или выйдет в ближайшие дни. Плюс отправляют их не чаще одного раза в день;
— Понизили приоритет пушей об акциях: если уже отправлен пуш о подработке, пуш об акции не отправится;
— Добавили ограничения на уровне сценариев. Триггерный сценарий срабатывает не чаще одного раза в 2 часа. У отдельных сценариев (вроде возвращения доступных подработок) — раз в 2 дня.

#push

Елена Плинер написала о юзерфлоу.

— User flow — это блок-схема пользовательского пути в рамках отдельного сценария с конкретными точками старта и финиша;
— Она позволяет посмотреть на продукт сверху, увидеть его реальный объём и заранее избавиться от лишних шагов и экранов;
— Строить её лучше от точки финиша, потому что она не всегда очевидна. Если есть юзерстори, точкой финиша будет Y из формулы «я как пользователь хочу сделать X, чтобы получить Y»;
— Один большой пользовательский путь почти всегда распадается на отдельные потоки внутри него со своими финальными точками. Это нормально, иначе общая схема будет слишком большой и сложной;
— Юзерфлоу описывает шаги пользователя: не обязательно экраны, это могут быть его действия, смена состояний экранов, а также действия вне интерфейса (если они важны для сценария);
— Двигаясь от финиша к старту, проще включать в схему только то, без чего связать две точки невозможно (физически или из-за технических ограничений), и не заполнять схему всеми возможными ответвлениями;
— Этого достаточно, чтобы продумать сценарий, увидеть спорные места, а также синхронизоваться с командой и зафиксировать требования;
— Перед передачей в разработку можно добавить детали: технические узлы и состояния, логику перехода к конкретным состояниям, цикличность (чтобы донести логику работы);
— Юзерфлоу полезны для аудита текущего флоу продукта, проектирования новых сценариев, сопоставления показанной на схеме воронки с метриками (чтобы понять, где пользователи отваливаются), а также для оценки масштаба проекта;
— Если сценарий линейный, юзерфлоу не нужен;
— В блок-схему можно добавить мокапы экранов, чтобы показать состояния одного и того же экрана, расположенные на одном экране точки входа в разные сценарии или передать больше контекста при значительном ветвлении схемы.

Копия на Хабре. #user_flow

Александр Краснобаев написал об а/б-тестах на малом трафике.

• Нельзя выбирать один из вариантов, если он показал рост конверсии с 1,5 до 2% при 200 визитах (из 3 заявок стало 4);
• Надо тестировать изменения, при которых рост может быть в разы. Например, конкретное обещание: вы продаёте бесплатную консультацию или разбор с понятным результатом;
• Структура страницы и тип медиа (когда посетитель увидит цену и отзывы, живое видео продукта недалеко от первого экрана), отзывы (нужны, вопрос в формате: текст и фото, скриншот переписки, видео), оффер (цена, гарантия, бонусы);
• Тестируйте не меньше 2 недель, чтобы захватить будние и выходные, новых и вернувшихся посетителей;
• Смотрите на результаты сразу, чтобы отловить баги в настройках;
• Не прерывайте тест, увидев, что какой-то вариант побеждает, так как лидер может измениться;
• Оба варианта тестируйте одновременно, случайно распределяя по ним трафик. Если пробовать их по очереди, результат могут исказить непредсказуемые кратковременные факторы вроде погоды;
• Бесплатный способ провести тест: 2 лендинга с разными адресами и эксперимент в Яндекс Директе, либо «Эксперименты» в Метрике, которые работают на Вариокубе;
• Оценивайте результаты отдельно для десктопа и мобайла. Важно, какой из вариантов выигрывает для основного канала трафика;
• В один момент времени на одном пути пользователя проводите один тест, чтобы понять, что именно сработало;
• Если гипотез много, придётся приоритизировать по влиянию на результат, уверенности, что сработает, и простоте реализации;
• Оценивайте результат комплексно. На «бесплатный аудит» будет больше заявок, но меньше людей, готовых заплатить. Скидки могут снизить прибыль;
• Дополнительно можно смотреть сессии в Вебвизоре и карты скролинга (докручивают ли люди вообще до конкретного блока);
• Также при малом трафике по каждой заявке можно выяснить у клиента, кто это, что ему нужно и сколько он готов заплатить.

#ab_testing

Сархан Громов написал о проблеме связи брендинга и интерфейса.

Фирменные приёмы могут отлично смотреться на специально подготовленных статичных картинках. Сайт и приложение — не ещё один рекламный носитель. Здесь у дизайнера меньше контроля. Фирменный стиль нельзя перенести на них буквально. Особенно если айдентика строится вокруг одного сильного приёма. Если использовать его часто, экран станет перегруженным. Если редко, интерфейс будет нейтральным.

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

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

Вместо заметных фирменных приёмов надо искать более спокойные признаки, допускающие более частое повторение, но задающие характер: радиусы, отступы, плотность интерфейса, форму иконок, способ использования фото, отношение к пустому пространству, тон оф войс. Хорошая проверка для приёма — повторить его двадцать раз.

Набор декоративных элементов → способ принимать маленькие решения: насколько жёсткой или мягкой должна быть сетка, как много цвета оставить на одном экране, как выглядит пустое состояние.

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

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

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

Андрей Шапиро написал о слабых местах подхода SDD (Specification-Driven Development) в агентной разработке.

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

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

Решение: когда оператор принимает результат, все удачные решения агента делать частью спецификации. Но всё равно останутся нежелательные феномены.

1) Дрейф — отклонение агента от спецификации.
2) Эрозия — потеря важных деталей при правках. Изменение А приводит к незаметному изменению Б, потому что часть важного для Б контекста исключается как неважная для А.
3) Наплыв — перенос свойств объектов, которые видит агент, без требования о переносе. Пример становится образцом целиком, вместе со случайными чертами вроде оформления.

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

#ai #docs

Новые материалы в @uxwork (кроме вакансий):

• Кого не заменит искусственный интеллект;
• Мнение дизайн-директора корпорации о том, что происходит с рынком дизайна в России (почему столько негативных реакций, объясните в комментариях?);
• Управление своим временем при большом потоке задач.

Роман Горшков рассказал о переходе дизайн-команды с Фигмы на Клод.

Дизайнер может делать больше задач и быстрее разгребать беклог: что занимало 2 дня, делается за 2 часа. И нет торговли с разработчиками, чтобы реализовать какой-то эффект.

ИИ помогает проверять больше версий решения задачи (есть сервисы, где запрос можно отправить сразу в 4 LLM для одновременной генерации) и захватывать смежные области: саунд- и шрифтовой дизайн. Время всё равно тратишь, но получаешь больше.

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

Сейчас опасно ковыряться в кривых и пикселях. Клод создаёт на 99% готовый продукт: специалист может увидеть неправильный рефлекс, баг отражения. Но стоит ли тратить ещё столько же времени, сколько уже потрачено, чтобы довести до 100%? Насколько 1% портит впечатление аудитории? Надо организовывать процесс так, чтобы как можно больше проходить на автомате.

Не нужно знать Фигму с её переменными, плагинами для выгрузки токенов. Она нужна на 5%: поставить рядом пару картинок, собрать историю, подправить что-то небольшое.

Надо научиться не просто вайбкодить (на уровне Фигма Мейк), а пользоваться репозиториями, создавать ветки, коммитить и создавать готовый фронт, использовать скилы и петли проверки. Сейчас таких специалистов мало.

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

Важные софты: 1) Логика, умение рассуждать хотя бы на уровне своего модуля и делать выводы. Раньше Роман предлагал тестовые задания, теперь задаёт вопросы, чтобы понять, как соискатель формулирует мысли и двигается к ответу. 2) Критическое мышление, умение признавать ошибки и обучаться.

Изменение процесса команда приняла с энтузиазмом: по кайфу получать сразу кликабельный результат. Около 10% не захотели отказываться от старого процесса и ушли думать, подходит ли им новая парадигма.

Перестройка заняла полгода. Руководители разобрались, как делать компоненты с Клодом и стабильно собирать экраны с существующим стилем. Обратным инжинирингом выясняли, почему ИИ сделал что-то не так, какие инструкции сработали. Затем подготовили обучающие материалы и провели первопроходцев, чтобы переход был мягким. Теперь дизайн-опс и лиды помогают настраивать репозитории и осваивать новый процесс.

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

В среднем дизайнеру хватает тарифа за 100 долларов, чтобы делать фронт без больших петель проверки и многих параллельных запросов. Загрузка онтологии дизайн-системы съедает все 20-долларовые лимиты.

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

#ai #process

Илья Бирман написал о поле ввода и его отличиях от комбобокса.

Поле ввода позволяет ввести значение с клавиатуры. В состоянии фокуса в поле появляется курсор, в тач-интерфейсе — экранная клавиатура.

Если текст не помещяется в поле, он сдвигается вслед за курсором (из комментария: отсутствие горизонтальной прокрутки — скорее недоработка привычной реализации). Вне фокуса поле отображает начало длинного текста и обрезает его конец.

Бывают однострочные и многострочные поля (text area). В последних текст может переноситься на следующие строки, и возможна вертикальная прокрутка, если высоты поля не хватает для отображения всего текста. Чтобы скрол в поле не конфликтовал с прокруткой страницы, высоту поля можно автоматически увеличивать под введённый текст.

Чтобы размер поля подсказывал, какой объём контента оно ожидает, и был удобен для ввода, многострочное поле по умолчанию делают высотой в 3–4 строки.

Чтобы сократить количество ошибок, можно ограничивать допустимые для ввода символы. Например, можно настроить, чтобы поле принимало только цифры. Для таких полей некоторые системы могут отображать стрелки для изменения значения на единицу вверх и вниз, менять значение стрелками на клавиатуре, отображать специальные экранные клавиатуры только с цифрами (или барабан).

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

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

Введённое вручную значение иногда добавляют в выпадающий список для ускорения последующего ввода. В хороших реализациях список используют как словарь для автодополнения.

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

#input #combo_box