Андрей Шапиро написал книгу о рабочих историях и карте реализации историй.

— Общее представление о них можно получить из опубликованной ранее статьи;
— В книге рассмотрены недостатки User stories, Job stories и некоторых других шаблонов (шаблон вопроса, похоже, используется в Модели информационных ожиданий «Собаки Павловой»);
— Например, они могут наводить на одно конкретное решение, которое часто оказывается неверным, так как задача ещё слабо изучена, либо проблема лишь подразумевается и формулируется в виде решения-кандидата;
— Оперировать альтернативами в разработке крайне важно, так как время и деньги ограничены, и непонятно, какое решение уложится в срок и бюджет;
— Они не описывают предметную область, что нередко приводит к последующему перепроектированию;
— Рабочая история как текстовая модель построена таким образом, чтобы этих недостатков избежать;
— Её состав: цель действия (зачем?), носитель (кто или что выполняет действие), ситуация (контекст, когда происходит действие), способ действия (каким образом что-то делается), объекты оперирования (с чем взаимодействует носитель, что получается в итоге);
— Кроме шаблона истории, инструкции по его заполнению, примеров из многолетней практики и разбора потенциальных ошибок при составлении историй в книге есть даже примеры бесед с заказчиком, в ходе которых история появляется и обрастает деталями;
— Карта реализации историй, подобно User story map, собирает все истории вместе и помогает увидеть всю картину, а также позволяет дополнить истории информацией о возможных формах их реализации (варианты технических решений) и составе блоков соответствующего интерфейса;
— Можно сначала записать «кнопку», которую хочет добавить стейкхолдер, и потом разобраться с её первопричиной и контекстом. Главное, чтобы все слои в конце концов оказались согласованы.

#user_story #book

Татьяна Бублик написала об основах продуктовой колористики.

— Модель OKLCH удобнее RGB, так как сложно задавать цвет, меняя количество красного, зелёного и синего;
— Также она поддерживает расширенный набор цветов P3, что актуально для современных устройств, которые поддерживают на 30% больше цветов, чем есть в RGB;
— Стоит придерживаться схемы процентного соотношения цветов в продукте 3-17-80 (или её вариаций), где 3% — бренд-цвет для всех самых главных акцентов, 17% — остальные хроматические цвета, 80% — белый, чёрный и оттенки серого (ахроматические);
— Так акценты не будут теряться в макетах;
— В серый и чёрный можно подмешивать хрому бренд-цвета, чтобы усилить восприятие бренда, сделать их комфортнее и интереснее;
— Лайфхак: делать длинную тоновую растяжку (25–30 цветов). Это даст при любом изменении или масштабировании подобрать нужный тон.

Копия на Dsgners. #color

Светлана Диденко написала об эвристиках Бена Шнейдермана для проектирования интерактивных систем.

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

#heuristic

Таня Двенадцатова написала о прожарке.

— Она помогает улучшать разрабатываемые фичи и синхронизировать команды. Она похожа на совместное проектирование;
— Это еженедельная встреча на 1–1,5 часа. Лучше выбрать время в начале дня, когда все ещё свежи (самое то для креативных и аналитических задач);
— Докладчики записываются заранее: указывают, какую задачу решали, и добавляют ссылку на артефакт;
— На встрече они презентуют своё решение и отвечают на вопросы и критические замечания зрителей (обычно выстраивается очередь из поднявших руки);
— Вопросы и комментарии лучше не добавлять заранее. Так и комментирующие не тратят на это много времени, и дискуссия получается более живой;
— Обычно участвуют дизайнеры, исследователи, продакты и UX-редакторы, но заглядывают и представители бизнеса, методологи, маркетологи;
— Полезно фиксировать, о чём договорились во время прожарки, чтобы потом учесть это при доработке фичи;
— Участие в прожарке (и необходимость успешно её пройти) можно сделать обязательным шагом в процессе. Для прохождения прожарки может потребоваться несколько итераций;
— По отдельным фичам (незначительное влияние на клиентский путь, регуляторка) можно ограничиться прожаркой и не проводить пользовательское исследование, если зрителям всё было понятно;
— Важно донести, что это не повинность, а полезный процесс. Также это маркер атмосферы и культуры в коллективе.

#design_check

Станислав Хрусталёв написал об интересных решениях ВкусВилла в списке товаров и корзине.

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

#cart #list #ecommerce

Настройка количества товаров с мусоркой

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

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

Но вообще-то хорошо бы, чтобы при уменьшении количества до нуля, товар не удалялся сразу: у пользователя должно быть право на ошибку и возможность вернуть товар обратно. Если же удаление товара неотменяемое, то превращение минуса в мусорку не поможет предотвратить ошибку; тогда надо дисейблить минус, а кнопку удаления ставить отдельно. Что касается остроумности, то это только в голове дизайнера мусорка — частный случай минуса для одного значения, но для пользователя изначально никакого минуса нет, а есть лишь эта мусорка, ведь обычно количество будет «1 шт.».

Короче, не рекомендую так делать. Элемент хуже узнаётся, ощущается нестабильным и не решает никакой задачи.

Алиса Колядова поделилась мыслями о проектировании таблиц.

— Представляйте повторяющиеся данные в виде таблицы, когда пользователю надо сравнивать строки, работать с их множеством, редактировать данные (в том числе массово), фильтровать и искать по структуре, когда важна плотность данных;
— Либо если пользователи для решения конкретной задачи привыкли работать с таблицей;
— В остальных случаях подойдут списки и карточки;
— Если в таблице много столбцов, будет сложно обрабатывать столько параметров. Возможно, большую таблицу можно разделить на несколько небольших с параметрами, нужными для решения конкретной задачи;
— Например, таблица для распределения заявок и таблица для контроля их выполнения. У первой не будет фильтров, а у второй строки будут подкрашиваться в зависимости от статуса;
— Рекомендацию объединять связанные данные в одной ячейке можно встретить в разных гайдлайнах, например, у «Контура»;
— Но это ломает визуальный ритм, снижает плотность таблицы, усложняет сравнение и поиск нужных данных. В небольших таблицах это может сработать, в длинных рабочих таблицах — нет;
— Если появляется горизонтальный скрол, можно слева закрепить первый столбец (который даст контекст остальным данным), а справа — важные показатели и действия;
— Но важно подробно описать поведение таблицы, так как здесь большое поле для трактовок со стороны разработчиков.

#table

В Фигме появились слоты.

— Это области в компонентах, позволяющие вставить любое содержимое в инстансы этих компонентов;
— Они упрощают компоненты со списками элементов внутри вроде аккордеонов, меню и дропдаунов. В них можно размещать любое количество элементов (не надо заранее закладывать какой-то максимум) и легко менять их порядок;
— Проще работать с компонентами с высокой вариативностью содержимого. В компоненте карточки можно задать стиль подложки и заголовка, расположение контролов, а её содержимое — добавлять через слот;
— Алексей Бычков записал видео о слотах;
— В блоге Фигмы [English] также предлагают использовать их для работы с лейаутом страниц: фиксировать в компоненте меню, хедер и футер, а содержимым конкретной страницы управлять через слот;
— Забавно, что они противопоставляют слоты детачу или созданию сложных многовариантных компонентов. Раньше такую же задачу решали добавлением dummy-компонентов и их свапом в инстансах на локальные компоненты с нужным контентом. Но со слотами, конечно, удобнее;
— Консультант по дизайн-системам Нейтан Кёртис написал, как внедрять слоты в библиотеку компонентов [English];
— Как понять, где слоты будут полезны, какие компоненты снабжать слотами первыми (где чаще всего детач), какие настройки применять (без контента, с контентом, списком предпочитаемых компонентов и без него);
— Правила лейаута слотов: не задавать цвет, обводку, скругление углов, паддинги. Паддинги лучше задавать в контейнерах, в которых будут располагаться слоты. Слот должен отвечать за лейаут, направление, отступы между элементами и изменение размеров.

#figma #design_system

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

— Как опытный руководитель проектов в крупной компании видит текущую ситуацию с наймом на IT-рынке;
— Актуальные требования к продуктовым дизайнерам в бигтехе и компаниях поменьше (на основе анализа 100 вакансий);
— Как распределять задачи на день, чтобы снизить когнитивную нагрузку.

7 апреля в 19:00 по Москве команда UX Feedback проведёт вебинар о том, как превращать хорошие исследования в качественные улучшения продукта.

— Даже если вы провели хорошее исследование, сломанный последующий процесс может всё испортить;
— Пользовательские нужды подменяются хотелками, сильные инсайты теряются, вместо точечных изменений в работу уходят большие инициативы;
— Вебинар будет полезен UX-исследователям, продуктовым дизайнерам и всем, кто работает с пользовательским фидбеком;
— Эксперты UX Feedback Арслан Разыков (сооснователь, более 10 лет в продукте) и Вика Макеева (менеджер продукта) разберут свой и клиентский опыт;
— На вебинаре вы узнаете, где между первым фидбеком и релизом чаще всего теряется сигнал;
— Почему не всегда нужно делать то, что просит пользователь;
— Как отличить хотелки от реальных пользовательских проблем;
— Почему маленькие итерации часто дают больше результата, чем большие проекты;
— Как сделать, чтобы исследования и обратная связь не просто копились в артефактах, а влияли на продукт.

👉 Регистрация

Реклама ООО «Фидбек», ИНН 5030094661, erid 2VtzqvtuRTj

Булат Хазимуратов покритиковал эмоциональный дизайн.

— Его считают высшей ступенью в пирамиде дизайна, но до сих пор нет методики его создания. Дизайнеры просто добавляют анимации, эффекты, выразительную графику, маскотов, игры и приколы;
— Любой дизайн вызывает эмоции. Не все они яркие и позитивные. Бывают негативные, нейтральные, сложные;
— Не только дизайн продукта их вызывает, но и, например, поведение сотрудника компании;
— Чтобы порадовать пользователя, дополнительные выразительные приёмы не обязательны;
— Дон Норман ввёл термин в книге «Эмоциональный дизайн». Он писал, что дизайн — это и функциональность, и удобство объекта, и эмоции, которые он вызывает у человека;
— Он не предлагал проектировать эмоции, веселить пользователей специальными выразительными приёмами, делать интерфейс дружелюбнее;
— Он предлагал понимать и учитывать эмоции при проектировании, не ограничиваться рациональностью и эргономикой (обычное дело для 90-х, когда вышла его книга);
— Человек воспринимает взаимодействие на интуитивном уровне (нравится ли то, что видит), поведенческом (насколько удобен и приятен процесс), рефлексивном (правильный ли это выбор, насколько мне подходит) → столпы дизайна: эстетика, эргономика, психология;
— Эмоции — субъективное переживание отношения человека к окружающему миру и себе. Они основываются на опыте и помогают понимать, как действовать;
— Выделяют эмоциональные процессы (по мере увеличения их длительности): аффект, эмоция, чувство, настроение. Дизайнерские приёмы обычно вызывают аффекты, но не что-то более длительное;
— Базовые эмоции по Плутчику: восторг, восхищение, ужас, изумление, гнев, отвращение, горе, настороженность. Есть градации (гнев → злость → досада) и промежуточные эмоции (гнев и отвращение → презрение);
— Аарон Уолтер предложил пирамиду потребностей пользователя: функционально → надёжно → удобно → эмоционально. Но у нас нет потребности в эмоциях, мы испытываем их на каждой ступени пирамиды;
— Эмоции можно разделить по потребностям. Например, есть акизитивные эмоции, связанные с потребностью в накоплении и собирательстве. Чем пытаться вызывать эмоции, лучше делать продукты, удовлетворяющие порой неочевидные потребности, не перечисленные в пирамиде Маслоу;
— Планировать нам помогает информационно-речевая картина мира, формирующаяся с опытом. Цифровые продукты упрощают эту картину: с кредитным калькулятором можно не вникать в условия и формулы. Резкие редизайны разрушают часть картины, вызывают стресс. Небольшой объём новой информации вызывает интерес;
— Чтобы лучше разбираться в эмоциях, изучайте работу влияющих на их формирование нейромедиаторов;
— Идея делать продукты понятнее, отзывчивее, человечнее не нова. Потребности в стабильности, эстетике, новой информации, смысле свойственны людям;
— Есть компании, продукты которых часто приводят в качестве примера эмоционального дизайна. Это восприятие строится не на дизайне продуктов, а на культуре и бренде компаний. Дизайн им соответствует. Причём культура и бренд проникают не только в интерфейс, но и в остальные процессы на уровне корпоративной культуры;
— У Додо получается эмоциональный дизайн, так как в основе лежит бренд с прописанной бренд-платформой. Можно описать бренд как человека с ценностями, характером и убеждениями, прописать контекст пользователей, характеристики целевой аудитории и чем компания отличается от конкурентов;
— Эмоции — не цель, а следствие хорошего проектирования. Они возникают из согласованности бренда и поведения компании. Интерфейс не может этого создать — только поддержать. Ориентируйтесь не на эффекты, а на чувства.

Станислав Хрусталёв написал об интересных решениях в приложении Додо Пиццы.

— Количество калорий, белков, жиров и углеводов отображается на 100 г и на весь продукт — удобно, если съел весь продукт или половину;
— Если приборы не нужны, от них можно отказаться и сократить количество отходов;
— При выборе продукта он улетает в сторону корзины. Такая анимация подсказывает дальнейшее действие, а поскольку продуктов в корзину добавляют не десятками, она не приедается и не раздражает;
— Удалённый из корзины товар некоторое время продолжает в ней отображаться. Если удалили по ошибке, его не придётся снова искать в каталоге;
— При оформлении самовывоза сервис предлагает построить маршрут до пиццерии в одном из установленных на телефоне картографических сервисов;
— Если вы в пиццерии, через приложение можно сделать заказ с доставкой к столику — не надо идти к кассе;
— Стоит упомянуть: удаление ингредиентов, создание своей пиццы, пицца из половинок (и случайный выбор их сочетания), Live Activity, видеотрансляция приготовления пиццы на кухне, рассказ о том, почему готовят без перчаток (частый запрос).

#ecommerce

Дмитрий Сатин написал о недостатках тёмной темы.

— Исследования показали, что при 100% яркости тёмная тема на OLED-экране экономит заряд аккумулятора. Но при 30–50% (обычное значение для большинства пользователей) экономия незначительна;
— Чёрный текст на белом фоне люди читают быстрее и точнее, чем белый на чёрном. Чем меньше кегль, тем хуже работает тёмная тема;
— Исключение: яркий экран в тёмном окружении (в тёмной комнате) создаёт дискомфортный контраст;
— У людей с астигматизмом (30% населения) светлые буквы на тёмном фоне теряют чёткость, сливаются друг с другом;
— Сложнее считывать визуальную иерархию, так как сливаются границы блоков;
— Тонкие шрифты становятся слишком бледными, жирные — слишком тяжёлыми. Снижается контраст между цветами, включая ключевые цвета для индикации состояний: красный и зелёный;
— Отпечатки пальцев на экране, отражения и дневной свет делают тёмный интерфейс на улице слабочитаемым;
— Изменение тона цветов и снижение яркости влияют на восприятие бренда, сдвигают эмоциональное восприятие, что может разрушить целостность бренда;
— Включайте по умолчанию светлую тему, на видном месте расположите переключатель тем, добавьте автоматический режим, привязанный ко времени суток или системным настройкам;
— Тёмная тема требует отдельного раунда юзабилити-тестирования.

#dark_theme

Алекс написал о выборе формата даты для отображения в интерфейсе.

— Дату 06/05/17 люди из разных стран поймут по-разному;
— Это будет 6 мая 2017 года в европейском формате, 5 июня 2017 года в американском, 17 мая 2006 года в японском стандарте;
— Формат YYYY-MM-DD (ISO 8601) исключает двусмысленность и применяется в международных системах;
— Его можно использовать в базах данных, API и серверных логах, финансовых и бухгалтерских системах, где цена ошибки высока;
— Для интерфейсов подойдёт формат с сокращённым названием месяца: 1 Jan 2001 (1 янв 2001) — британский стиль, используемый в международном английском;
— Сокращённое название месяца удобнее полного за счёт более короткой записи и простоты локализации.

#writing #time

Алексей Макаренко рассказал об автоматизации доставки логотипов разработчикам.

— Старый порядок: экспорт ×4 в формате png, оптимизация через приложение ImageOptim, переназывание, загрузка в общую папку с логотипами;
— Со временем появились папки для тёмной и светлой темы, для лого, вписанных в квадрат;
— В Фигме через плагин SVG Export цветные логотипы экспортировали с дефолтным пресетом (просто чтобы сжать), а монохромные — с пресетом Correct color (чтобы разработчики могли красить их в любой цвет);
— Новый порядок: собственный плагин, который смотрит на свойства компонента с изображением логотипа и называет экспортируемый файл, например, avrora_color_dark_compact_square, экспортирует архив с png и svg;
— Дизайнер сохраняет архив в репозиторий, где хранятся логотипы, и запускает bash-скрипт. Он раскрывает архив, оптимизирует файлы (такие же алгоритмы, как в ImageOptim и SVG Export), раскладывает по папкам и называет logo.png и logo.svg;
— Иерархия папок учитывает, что логотипы могут быть цветными и монохромными, цветные варианты нужны для тёмной и светлой темы, также они могут быть широкими и компактными, а компактные — вписанными в круг, квадрат и без формы;
— Вписанный в квадрат логотип компании Avrora для тёмной темы в формате png доступен по адресу logos/avrora/color/dark/compact/square/logo.png;
— Разработчики используют компонент логотипа и обращаются к конкретному файлу в папке.

#image #figma #design_system

Диана Нурекеева написала об онбординге исследователя в новую команду за 3 месяца.

— Шаг 1. Понять, с каким продуктом предстоит работать и какими методами;
— Изучите стратегию и попытайтесь понять, как стейкхолдеры принимают решения, чтобы её реализовать;
— Выясните, какие метрики надо растить в этом квартале и какие барьеры (вроде нехватки знаний) этому мешают;
— Узнайте, как устроен дискавери-процесс, и подумайте, как его можно улучшить;
— Шаг 2. Создайте план проведения исследований, исходя из потребностей команд;
— Ключевые исследования: CJM (выявленные потребности можно количественно валидировать опросами), сегментация клиентов, глубинные интервью для определения УТП;
— Регулярные исследования: замер CX-метрик (NPS, CES и CSAT), немодерируемые тесты, User day (регулярные пользовательские интервью, в которых участвует вся команда), проверки интерфейса по шаблонам UX-эвристик;
— Демократизируйте исследования в команде — вовлекайте в работу с пользователями продактов, дизайнеров, редакторов и разработчиков;
— Для найденных инсайтов и проблем заведите отдельный беклог;
— Определите, как будете оценивать свою работу: бизнес-метрики (ключевые метрики команды, продуктовые KPI, ROI), операционные и процессные (количество тестов, проведённых User day, количество обученных членов команды);
— Шаг 3. Постройте диаграмму Ганта с активностями на 3 месяца и распределите задачи между членами команды;
— Создание карты местности (что понятно, что неизвестно, риски), карты стейкхолдеров и их запросов, схемы процессов и списка узких мест, приоритизация, создание черновика пакета фундаментальных исследований, сетки регулярных практик, хранилища исследований и беклога проблем, плана инициатив, фиксация метрик и договорённостей;
— Станет понятно, какие нужны ресурсы (привлечь агентство?);
— Выделите время под внезапные задачи, новые вызовы или то, что забыли;
— Далее — реализация дорожной карты, рефлексия каждые 1–2 недели (получается ли идти по плану, не изменились ли приоритеты). Допустимо, если план меняется на 30–40% к концу месяца.

#research

25 апреля пройдёт онлайновая конференция «Дизайн конф: что происходит с UX/UI». Дизайн — это уже не про кнопки и сетки в Фигме, а про проведение, решения и пользовательский опыт. В программе:

— Какие тренды задают Азия и Восток;
— Как ИИ перепрошивает команды;
— Почему без исследований не запускается ни один серьёзный сервис;
— Разбор портфолио и реальных кейсов.

Можно смотреть онлайн весь день с 13:00 до 19:00 мск, либо подключаться к отдельным блокам.

Подробности и регистрация → https://bit.ly/494on8Z?erid=2Vtzqunx8gf

Виктор Теплов рассказал, как дизайнеру работать с ИИ.

— Тест Патрика: чаще вы соглашаетесь с ИИ или он с вами? Если вы, то готовьтесь потерять работу;
— Опасные сценарии: профи-скептик не разбирается в ИИ, использует его на удачу и сразу видит некачественный результат; энтузиаст-профан лезет в незнакомую область и полностью доверяет ИИ; дофаминовый наркоман радуется быстрому результату и делает 5 проектов (и ещё 7 в уме);
— ИИ — не партнёр, а инструмент. Человек становится автором продукта и берёт ответственность, когда нажимает на «Принять изменения»;
— По умолчанию ИИ выдаёт массово-приятный результат, похожий на музыку в лифте, которая не бесит, но и не цепляет. Это хорошо для интерфейсов, так как привычные паттерны удобны. Но плохо для творчества, бренда и голоса продукта, где нужна узнаваемость;
— Дизайнеры, которые не хотели разбираться в функциях программ, но хотели «сделать красиво», раньше использовали плагины. Не понимаешь, как работает свет, — плагин Cinematic LUT;
— ИИ может сгенерировать артефакты по фреймворкам вроде JTBD, CJM, Personas, но не может взять на себя ответственность за принятое решение;
— Не получится найти ИИ-инструмент, который просто сделает то, что нужно. Придётся разбираться, как добиться в нём нужного результата;
— План: опишите образ результата, критерии качества и ограничения (что делаем, для кого, в каких условиях). Итерации: делите задачу на шаги, фиксируйте изменения и промежуточные артефакты. Проверка: просите ссылки на первоисточники, объяснить сделанный выбор, дать альтернативы и подсветить риски;
— Рутину надо делать быстро, одинаково и без ошибок. Дизайнер дизайн-системы либо автоматизирует, либо тонет. Раньше для автоматизации надо было стать немного разработчиком, сейчас порог входа снизился. Но ИИ не должен быть автором архитектуры;
— Например, плагин для сбора типографских variables в JSON-стили и построения витрины стилей, плагин для создания шрифта из иконок дизайн-системы;
— Работа с цветовыми токенами. Опишите контракт: структура токенов, устройство имён, запреты, эталонные примеры. Попросите выполнить операцию: добавь новый токен в core-палитру и создай семантический токен bg.main.primary на его основе, добавь во все тематические и брендовые палитры;
— Сначала в режиме Plan, когда ИИ ничего не делает с файлами. Затем просите не только изменить файлы, но и показать изменения, объяснить, почему они соответствуют правилам, подсветить риски, поискать дубли, проверить ссылки;
— В Figma Make можно быстро сделать прототип, проверить поведение компонента в корнер-кейсах и принять решения по вопросам, которые часто всплывают уже во время реализации в коде;
— Доступность инструмента лишь подчёркивает искусность мастера. Кто-то может порубить топором дрова, а кто-то построить дом. Важен опыт, вкус и логика. ИИ не заменяет мастерство, а позволяет делать быстро, много и предсказуемо.

Копия в ВК Видео. #ai #design_system