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

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

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

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

У Фигмы есть ограничение в 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

Сергей Гуров написал об эволюции от модульной сетки до алгоритмической.

Первым модульную сетку в книжной вёрстке применил Макс Билл около 1940 года. Во 2-й половине XX века Йозеф Мюллер-Брокманн называл модуль «проявлением воли к порядку и ясности, объективности взамен субъективности». Однако он строил сетку для оформления уже готового материала (сначала композиция, потом сетка).

В 1962 году Карл Герстнер подготовил для журнала Capital систему, допускающую от 2 до 6 колонок, так как формат был фиксированным, но контент ещё неизвестен. Подходящий вариант для каждого выпуска должен был выбирать дизайнер.

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

Сетка — способ организации пространства формата. Рудер вместо «пространства» говорил «объём» и лист считал плоскостью. У Фаворского (ВХУТЕМАС) было пространство, а линия — процарапанной, то есть трёхмерной неровностью. В цифровых пространствах и контент непредсказуем, и формат становится живым, что требует другого подхода.

Например, у веб-страницы заголовок может оказаться вдвое длиннее, карточек будет то 7, то 17, а ширина окна у каждого пользователя своя. Композицию собирается в момент показа страницы. Три макета (для телефона, планшета и десктопа) не описывают все промежуточные состояния. Прежние способы учесть эту вариативность приводят к однообразию, что во времена ИИ теряет востребованность у заказчиков.

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

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

Можно задать алгоритм: изображения вписаны в квадратные модули с сохранением пропорций, горизонтальные прижаты к низу, вертикальные — к левому или правому краю (в зависимости от того, на какой линии модуль). Модули опираются на вертикальные силовые линии. На нечётных этажах модули на линиях 1 и 3, на чётных — на 2 и 4. На линиях 3 и 4 модули смещены вниз. Через каждые 3 строки — модуль в высоту экрана. При изменении ширины окна все размеры пропорционально пересчитываются. При переходе к ширине планшета или телефона — другой набор параметров.

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

#layout #adaptive

Алексей Арустамов написал, как сделать взаимодействие через чат более детерминированным.

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

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

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

Но будущее не просто за чатом, а за чатом и набором детерминированных инструментов (обычные программы), подключённых через MCP. Model Context Protocol — открытый стандарт подключения ИИ к внешним данным и инструментам, предложенный в 2024 году компанией Anthropic.

Например: пользователь пишет в чате «Рассчитай скидку для компании Х» → ЛЛМ находит подходящий для запроса инструмент, уточняет у пользователя критически важные параметры запроса и формирует вызов в формате JSON → инструмент возвращает результат расчёта (например, {"discount": 3}) → ЛЛМ отвечает пользователю «Скидка для Х составит 3%».

ИИ не берёт логику расчёта скидок из MD-файла, не собирает данные из баз клиентов и заказов и не считает сам, а обращается к программе. Это позволяет экономить токены и избегать неправильных расчётов из-за галлюцинаций ЛЛМ.

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

MCP‑сервер должен работать с правами, унаследованными через стандартные протоколы вроде LDAP или OpenID. Отдаваемые ему сценарии должны учитывать принцип минимальных привилегий.

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

#chat #ai

Аня Карпова написала, как провести User Day — день общения продуктовой команды с пользователями.

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

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

Если команда большая, разделите её на группы по 4–5 человек, чтобы респондентам было комфортно. Чтобы слова одного респондента не воспринимались как то, что касается всех пользователей, каждая группа общается с 2 респондентами.

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

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

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

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

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

#research

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

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

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

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

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

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

#minimalism #affordance

Алина Гильманова написала о презентации и защите дизайн-решений.

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

Многие решения дизайнер принимает интуитивно, не замечая последовательности умозаключений. Кнопку — повыше. Почему? Иначе она теряется → пользователь не понимает, где основное действие → приходится сканировать интерфейс и сравнивать разные действия → заметная кнопка сделает следующий шаг очевидным.

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

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

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

Сильная аргументация выглядит так: «Сейчас пользователь сталкивается с А. Мы хотим получить Б. Поэтому предлагаем В. Это решение позволяет… Мы рассматривали альтернативу Г. Если сомневаемся в предположении, можем проверить его через Д».

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

#presentation

Никита Лакеев рассказал, кто такой Staff Product Designer.

Это грейд уровня дизайн-лида, но на параллельной экспертной ветке Individual Contributor (IC). Роль создана для специалистов синьор+, которые не хотят заниматься менеджментом, а хотят прокачивать экспертизу и масштабнее влиять на продукт.

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

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

Основные архетипы:
1. Архитектор — мастер спроектировать и упростить сложнейшие продуктовые сценарии и информационную структуру.
2. Тейстмейкер — специалист с высочайшим мастерством в UI и моушне, развитым вкусом и чувством стиля.
3. Визионер — лидер, формирующий долгосрочное видение продукта и объединяющий команду.
4. Платформер — эксперт по выстраиванию процессов, разработке паттернов и развитию дизайн-системы.

На ветке IC следующий шаг после стаффа — Principal, но это редкие специалисты, надо быть лидером индустрии с мировым именем вроде Тобиаса ван Шнайдера. Однако в некоторых компаниях вроде Zalando позицию стафф пропускают, и экспертов выше синьоров называют принципалами.

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

По теме есть книга «Staff Product Designer» Артёма Дашинского.

#career #definition