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

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

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

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

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

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

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

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

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

Андрей Шапиро написал о слабых местах подхода 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

Алексей Кирдяев написал о чистом дизайне.

Чистый минималистичный дизайн — не стандарт качества, а культурное предпочтение. 73% поведенческих данных получено из исследований, в которых участвовали в основном WEIRD-респонденты (Western, Educated, Industrialized, Rich, Democratic). Они представляют всего 12% населения Земли.

Чистая форма заявки на кредит из 3 полей, прогресс-бара и кнопки не конвертила на мексиканском рынке. Пользователи ей не доверяли. У конкурентов были плотные многостраничные формы, много институционального брендинга, государственной символики и значков безопасности.

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

В странах с высокой дистанцией (Индия, Мексика, Бразилия, Филиппины, Индонезия, Малайзия и большая часть Ближнего Востока и Центральной Азии) институты, которые не демонстрируют свой авторитет, не задают много вопросов, кажутся несерьёзными.

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

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

#localization

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

Так бывает, когда агенту отдают всю Figma целиком: он в ней тонет и начинает додумывать. Ему нужно объяснить, что уже есть в дизайн-системе, где это найти и как использовать. Для этого собирают карту дизайн-системы.

28 октября в 18:00 мск продуктовый дизайнер Даниил Шишко проведет бесплатный эфир и покажет, как собрать такую карту в Codex. Начнет с пустой папки и на дизайн-системе Желтого банка настроит агента, который соберет экран из готовых компонентов с нужными шрифтами, цветами и отступами. Подойдет и тем, кто ни разу не открывал агента.

Что получат зрители:
• скилл для сборки карты дизайн-системы;
• инструкцию по работе с Codex и Claude, которая поможет избежать блокировки аккаунта.

Эфир бесплатный, нужно только зарегистрироваться

Денис Зеленых написал о подходе «Атомарная матрёшка» к организации дизайн-системы.

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

Иерархия отражается и на структуре файлов в Фигме: набор сценариев в рамках пользовательской истории (страница файла) → все сценарии модуля (файл) → сервис (папка) → продукт (командное пространство). Легко искать нужные макеты.

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

У Фигмы есть ограничение в 2 ГБ на вкладку, в которые должны уместиться и файл, и все подключённые библиотеки. Глобальный UI-кит включает дизайн-токены, базовые компоненты и универсальные элементы. Продуктовая библиотека — общие шаблоны, навигацию, паттерны продукта. Сервисные и модульные библиотеки — всё сложное и специализированное: экраны, тяжёлые лейауты, паттерны взаимодействия.

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

Не всё в компоненте должно быть вариантом. Простые штуки вроде скрытия иконки, подмены контента и изменения текста надо делать через свойства компонента: boolean, instance swap, text. Это уменьшает комбинаторику вариантов даже сильнее, чем дробление по неймингу («button / basic», «button / icon»).

Полезные практики: именовать слои по БЭМ-подобному принципу, чтобы совпадало с именами в коде, на странице компонента показывать все возможные состояния и лог изменений, переносить компоненты из локальных библиотек в глобальные, как только они начинают жить в нескольких местах.

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

Дополнение подхода экосистемой продуктов. #design_system #figma

Анна Исламова написала, как использовать деинфлюэнсинг — критические пользовательские разборы продуктов — для подготовки UX-исследований.

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

Выбор площадки влияет на находки: короткие ролики показывают заметные затруднения, длинные видео и текстовые обсуждения позволяют раскрыть многошаговые сценарии. Поэтому выборку стоит собирать на нескольких платформах. Для SaaS и финтеха подходят Reddit и Hacker News.

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

Затем проводят по 6–8 интервью на каждую тему, чтобы подтвердить, опровергнуть или уточнить гипотезы. Проверенные темы выносят в опрос 100–200 реальных пользователей и расставляют приоритеты для дизайна.

Весь цикл рассчитан на 4–7 недель. Его преимущество — масштаб поиска гипотез. Частота жалоб не показывает распространённость проблемы: алгоритмы усиливают эмоциональный контент, а люди с нейтральным опытом редко публикуют разборы.

#ugc #research

Павел Шерер написал о моделях информационной архитектуры — предпоследняя статья цикла.

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

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

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

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

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

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

#information_architecture