UX Notes

CX/UX Конф — конференция о клиентском опыте и человекоцентричности Почему одними продуктами хочется пользоваться снова, а другие забываются через минуту? Поговорим о том, как рождается клиентский опыт — от первых дизайн-решений до эмоций, которые остаются после взаимодействия с продуктом. Разберём: 🔘как создавать продукты, которые подстраиваются под человека, а не наоборот 🔘как проектировать эмоциональный дизайн, к которому хочется возвращаться 🔘как визуальные решения влияют на доверие, привычки и впечатления пользователей 🔘как превращать ограничения в источник сильных и неочевидных решений 🔘как персонализация меняет опыт взаимодействия с сервисами сегодня Проведите время с экспертами из агентства ИКРА, CreativePeople, Домклик и Сбера. 📆3 сентября 📍Москва, Кутузовский проспект и онлайн ➡️ Если вам интересно, как создаются продукты, которые запоминаются, — бронируйте место сейчас. Регистрация открыта

Должен ли исследователь быть мультифункциональным? Или узкая экспертиза остается главной ценностью? Развитие AI меняет не столько методы, сколько границы профессии и объем ожиданий. Мы все чаще оказываемся в новых зонах компетенций: от ответственности за метрики до вайбкодинга. Приходите на митап «UX-рисерч и точка?» — своим опытом поделятся эксперты Lamoda Tech, RWB, Atom и других компаний.

В программе: ▪️ Как не дать результатам исследований умереть: чат-бот вместо забытых ссылок на вики Егор Стрельцов, UX researcher, Lamoda Tech ▪️ Python и JavaScript для автоматизации работы исследователя Анна Мингариева, Lead UX researcher, RWB ▪️ Навык, который превращает исследования в решения Михаил Хананашвили, HMX Research Lead, Atom ▪️Круглый стол с приглашенными экспертами

🗓 27 августа, 19:00 📍 Москва, офис Lamoda (Крылатская, 15) ➡️ ЗАРЕГИСТРИРОВАТЬСЯ Реклама. ООО "ЛАМОДА ТЕХ". ИНН 7734461512. erid: 2W5zFG3DBUV

Русалина Ушакова написала о приёмах, используемых в онбординге Дуолинго. — Хорошо: профиль создаётся в самом конце, после выбора языка, вопросов о цели и уровне и завершения первого урока; — Это Gradual engagement, когда пользователь доходит до ощутимой ценности и только потом «платит» (в этом случае своими данными); — После урока появляется счётчик серии «1 день в ударе». Это Loss aversion, когда появляется что-то, что пользователю жалко потерять; — Экраны «За первую неделю выучите 50 новых слов» и «Вот чего можно достичь за 3 месяца» настраивают на результат и создают ощущение, что продукт настроен под пользователя; — Можно отнести к тёмным паттернам: повторные запросы разрешений на отправку уведомлений и добавление виджета; — Это Nagging — повторный запрос после отказа, который не только раздражает, но и обесценивает первое решение пользователя; — В интерфейсе отображается будущее окно с запросом разрешения, на котором выделен вариант «Разрешить». Гайдлайны Apple советуют от такого воздерживаться; — В запросе на добавление виджета кнопка «Добавить виджет» выглядит основной. Это Visual interference — влияние на выбор не содержанием, а визуальной иерархией; — Гайдлайны Apple рекомендуют запрашивать согласие в момент обращения пользователя к функции с понятным объяснением причины. Такой контекстный запрос даёт на 25% больше согласий, чем «холодный» вариант в начале сессии; — Выделение варианта пути «Определите мой уровень» меткой «Рекомендуем» — это Nudging; — Его можно отнести и к честным, и к тёмным паттернам. Для этого надо ответить на вопрос: был бы пользователь благодарен за это дизайнерское решение, если бы понимал его механику целиком? #onboarding #dark_patterns

🚀 Запускаем исследование продуктовых дизайнеров, 2026 Вновь копаем в самое интересное: 🤖 как AI на самом деле меняет работу: где экономит время, а где все приходится переделывать 🔄 куда смещается роль: забирают ли продакты и разработчики то, что было задачей дизайнеров 📉 что с рынком труда и тревогой за будущее 📊 Часть вопросов задаем не первый год, так что увидим честную динамику: зарплаты, инструменты, настроение профессии. ⏱️ Опрос займет 10–15 минут. В конце октября поделимся публичным отчетом со всеми срезами и полезными ссылками. 👉 Пройти: https://survey.devcrowd.ru/pd-2026 Чем больше ответов, тем точнее картина. Перешлите своим дизайнерам, соберем срез всей профессии 🙏

Новые материалы в @uxwork (кроме вакансий): — На что дизайн-лиды и хеды смотрят в портфолио при найме (на основании опроса 36 человек чуть больше года назад); — Как оформлять резюме и портфолио и готовиться к откликам и интервью; — Как проверить работодателя при устройстве на работу.

Антонина из ЮMoney написала о поле для ввода OTP (One-Time Password). — В отличие от обычного поля принимает фиксированное количество определённых символов (например, 4–6 цифр), которые валидны ограниченное время; — Современные браузеры могут предложить подставить код из смс или пуша. К свойствам поля надо добавить autocomplete="one-time-code"; — Одно поле проще в реализации, меньше проблем с доступностью; — Сегментированное поле своим видом подсказывает, сколько символов надо вводить, в мобайле превосходит одно поле по ощущению контроля; — Устанавливайте фокус на первый сегмент поля сразу после загрузки; — Даже если фокус не на первом сегменте, при вставке скопированного кода подставляйте его с первого сегмента; — Если используете одно поле, пишите количество символов и не прячьте эту подсказку в плейсхолдер, который пропадает при вводе; — При нажатии на кнопку «Получить новый код», очищайте поле; — Если пользователь печатает быстро, обработчик onChange может пропустить символ. Используйте события input или keyup; — Скрывайте сообщение об ошибке сразу же, если введён корректный код или изменены символы предыдущего некорректного кода; — Не очищайте поле при неверном вводе. Пользователь мог ошибиться в последнем символе, надо дать возможность исправить только его; — Если у вас автоматическая отправка при вводе максимального количества символов, можно добавить задержку 500–800 миллисекунд после ввода последнего символа, чтобы пользователь успел заметить ошибку и исправить её; — Давайте свободу перемещения между сегментами: клик, стрелки, Tab. #otp

Дизайнер обязан везде видеть хуи, жопы и говно Любой дизайн может содержать паразитный образ — то, что автор не хотел показать, но оно там появляется из-за того, как устроено восприятие человека А устроено оно так, что мы видим образы помимо своей воли. Мемная фраза «Как теперь это развидеть?» отражает именно эту нашу особенность. Вы видели массу примеров на этом канале Если человек однажды увидел хуй в логотипе вашего банка, он навсегда это запомнит, у него сложится ассоциация и он будет видеть хуй каждый раз, когда видит ваш логотип Да, не каждый человек увидит. Но даже если их половина или треть, что это меняет? Вы действительно хотите, чтобы каждый второй считал вашего маскота говном, а не зефиром? Хороший дизайнер просто обязан проверять дизайн на наличие сторонних образов и ассоциаций. Это буквально графическая гигиена. Способность видеть хуи в графике — это тест на профпригодность

Юля, Лика и Настя из Alfa Research Center написали о триангуляции в UX-исследованиях. — Это сочетание методов (не обязательно трёх, зависит от ресурсов) в одном исследовании, позволяющее получить более полную картину; — Нельзя оценивать отдельно, как человек справляется с задачей в интерфейсе и как воспринимает процесс; — Таким образом можно сочетать интервью, юзабилити-тестирование и количественный немодерируемый тест; — А также метрики (субъективной удовлетворенности, успешности и эффективности выполнения заданий) и данные из разных источников (другие исследования по теме, внутренние логи обращений пользователей, собственные исследования с респондентами); — Один лишь юзабилити-тест выявит проблемы, но не объяснит, почему решение работает плохо. Оно непонятное, незаметное или просто неожиданное? — Например, новый дизайн приложения для безналичных чаевых проверяли немодерируемыми тестами и юзабилити-тестами с айтрекером и оценкой эмоционального отклика; — Айтрекер показывает, в каком порядке человек смотрит на элементы интерфейса, позволяет оценить их заметность; — Кнопка «Получить чек» была заметной, но непонятной (какой чек, если оплаты ещё не было?), и на неё не нажимали; — Sense Machine считывает с лица респондента эмоциональный отклик: радость, злость, грусть, страх, отвращение, удивление и нейтральное состояние; — Альтернатива — опросник на когнитивную нагрузку и шкалирование по субъективным ощущениям; — На экран загрузки добавили баннер. Айтрекер показал, что на него смотрели. Но к концу 10-минутного теста далеко не все респонденты помнили его содержание. Эмоциональный отклик показал, что реклама не раздражала. В итоге её решили оставить; — Иногда при разных методах исследования выигрывают разные варианты. Нужен сводный отчёт, чтобы команда не получила противоречивые выводы; — Карандаш для ввода своей суммы чаевых замечали. Большинство респондентов количественного немодерируемого теста с заданием справлялось. Но на очных тестах была заметна задержка. Интервью показали, что люди не помнили, был ли способ указать свою сумму; — Карандаш был заметен, но непонятен, поэтому пользователи двигались дальше по сценарию, забывая о нём. В итоге выиграла кнопка с текстом «Своя сумма»; — Триангуляция страхует от ошибок, которые исследователи совершают из-за одностороннего взгляда и ограничений отдельных методов; — При возможности добавляйте в исследования инструменты для измерения внимания, эмоционального отклика, запоминаемости и читаемости. #research #user_testing

Тимур Репин написал о разных видах интерфейса, по каким параметрам их можно сравнить и заменит ли их всех умная строка (нет). — Человеко-компьютерный интерфейс — все элементы, через которые человек взаимодействует с компьютером. Голос может быть таким же элементом; — Интерфейс — бутылочное горлышко на пути от быстрого человеческого мозга до ещё более быстрого компьютера. Его расширение повышает эффективность решения задач с помощью компьютера; — Пропускная способность — сколько информации (как на ввод, так и на вывод) передаётся в единицу времени; — Скорость решения задачи — параметр, который зависит от количества действий, которые человек должен совершить (нажать кнопок, найти элементов на экране, вспомнить команд), и вероятности ошибиться; — Оперативность доступа — сколько времени и усилий требуется, чтобы начать взаимодействие с системой. Она повысилась с переходом от мейнфреймов к персональным компьютерам и мобильным телефонам (достаточно просто протянуть руку); — Переход от командной строки (CLI) к графическому интерфейсу (GUI) повысил скорость решения задач (не надо помнить названия команд и писать их, меньше ошибок) и пропускную способность (нажатие на кнопку вместо написания команды, вместо строк текста — полный графики экран); — Кстати, был ещё TUI (text user interface), когда интерфейс, похожий на графический, создавался текстовыми символами. Пример: Norton Commander (1984); — У носимых устройств выше оперативность доступа (они уже на голове или руке) и скорость решения отдельных задач. AR-очки видят то же, что и пользователь, и могут помочь в контексте: подсветить гайку, которую надо закрутить; — CLI и умная строка удобнее для поиска чего-то конкретного (например, приложения в телефоне по названию), ответа на вопрос в виде небольшого структурированного текста, получения конкретного нужного пользователю результата; — GUI удобнее для поиска и выбора, когда ещё нет точного запроса, когда не знаешь всех возможностей системы, когда нужно что-то подправить (проще указать, чем описывать) или видеть всё сразу (дашборд); — Там, где человеку нужно сформулировать цель, делегировать сложное действие или быстро получить ответ, умная строка будет удобнее кнопок. Там, где нужно сравнить варианты, увидеть состояние системы, управлять сложным процессом или точно указать на объект, GUI останется сильнее. #command_line #ai

Лёха Макаренко рассказал, что делать дизайнеру дизайн-системы, если продуктовому дизайнеру понадобился элемент, которого нет в ДС. — Этот элемент может отличаться от готовых компонентов ДС визуалом или логикой. Например, нужен инпут с маской под номер банковской карты и определением платёжной системы; — Не стоит решать за дизайнера. Лучше предложить 3 варианта; — 1. Использовать существующий компонент, выполняющий базовую функцию, но менее удобный и не такой эстетичный. Например, обычный инпут; — 2. Провести необходимые исследования и прийти к команде ДС с обоснованием, что такой компонент необходим. В идеале он должен переиспользоваться другими командами. Этот путь может занять время; — 3. Сделать кастомный элемент таким, как хочется. Надо будет проработать все нужные состояния, предусмотреть его работу в тёмной теме и так далее; — Такой подход позволяет прозрачно планировать развитие продукта и управлять дизайн-долгом; — Выбрав один из вариантов, со временем можно от него отказаться. Например, сделать кастом и потом затащить его в ДС либо заменить его на базовое решение. Или попробовать простой вариант, а потом кастомный. #design_system

Павел Шерер продолжил серию статей об объединении фреймворков JTBD и Personas (с User story) в одном процессе проектирования. — Находим контекст напряжения и потребность → Формулируем Job story → Понимаем уровень цели → Проверяем важность работы и удовлетворённость текущими решениями → Определяем акторов и персон → Выбираем механику → Пишем User story → Проверяем результат; — Если начинаете с User story, скорее всего, вы уже выбрали механику. Но почему она лучше альтернатив? И нужна ли она конкретному пользователю? — В JTBD интересует момент, в котором привычный способ действия перестаёт справляться с задачей; — Нормальная Job story: когда я возвращаюсь к проекту после нескольких дней отсутствия, я хочу быстро понять, что изменилось, чтобы уверенно участвовать в обсуждении и принимать решения; — Для каждой Job story полезно зафиксировать: какой верхний принцип или желаемое состояние за ней стоит; какое действие должен уметь выполнять пользователь; какое наблюдаемое последствие подтверждает успех; где заканчивается цель и начинается выбранная механика; — Но, возможно, это редкая проблема, звучит страшно, но почти не влияет на поведение, достаточно хорошо решается текущим способом. Здесь пригодится Opportunity landscape; — У конкретной персоны могут быть конкретные требования к предлагаемому решению; — Что фиксировать в персоне: роль в работе, права и ограничения, уровень компетенции, частоту сценария, риски, за которые человек отвечает, критерии успеха, привычные инструменты, страхи и барьеры переключения, отношение к автоматизации, что персона не будет делать ни при каких условиях (особенно важно в B2B); — Persona: продакт-менеджер, который ведёт несколько параллельных проектов, регулярно переключается между ними и отвечает за продуктовые решения; — Выбранная механика: сводка изменений, принятых решений и новых рисков за выбранный период со ссылками на источники; — User story, связанная с Job story, Persona и выбранной гипотезой решения: как продакт-менеджер, который ведёт несколько проектов, я хочу получить сводку изменений, решений и рисков за выбранный период, чтобы восстановить контекст за десять минут до встречи и проверить важные выводы по первоисточникам; — С такой User story понятно: откуда появилась потребность, для кого создаётся решение, почему выбрана именно эта механика, какой результат считается успехом, какие ограничения нельзя потерять по дороге. #user_story #job_story

Новые материалы в @uxwork (кроме вакансий): — Как продуктовому дизайнеру себя презентовать. Тезисы из книги Юрия Ушакова «Не сойти с айти» на довольно актуальную тему: — Как вышло, что многие айтишники сейчас сомневаются в том, что продолжат работать в айти; — Вакансий сильно меньше, чем соискателей. Рынок зрелый, исполнители взаимозаменяемы (а также заменяемы ИИ). Как выделиться на общем фоне; — Как сохранить себя, если ИИ всё-таки отжал у вас работу в айти.

Отношения между сценарием и навигацией в интерфейсе При проектировании интерфейса важно проанализировать сценарии, то есть хорошо представить, как именно, в какой ситуации, с какими знаниями, целями и ожиданиями человек будет пользоваться интерфейсом. Многие забывают про это подумать, и у них получается ерунда. Но иногда ерунда получается, даже если про это подумать, а затем просто положить сценарии в основу навигации. Что будет, если просто положить сценарии в основу навигации? Когда сценариев очень мало, может получиться неплохой интерфейс. Если есть всего три-пять действий, за которыми человек приходит в интерфейс, и мы просто делаем для них кнопки, то всё будет понятно и удобно. Это то, что я предлагал для ПВЗ «Яндекс-маркета»: https://ilyabirman.ru/meanwhile/all/interfeys-pvz-yandeks-marketa/ Но такие интерфейсы встречаются редко. Даже в небольшом продукте есть множество связей между функциями, и число сценариев огромно. Если в таком случае начать строить навигационную модель вокруг сценариев, в интерфейсе станет невозможно разобраться. В заметке об архиве вакансий я как раз указываю на эту проблему: https://ilyabirman.ru/meanwhile/all/arhiv-vakansiy-ne-mozhet-byt-podrazdelom-sozdaniya-vakansii/ Когда я говорю про огромное число сценариев, необязательно представлять что-то необъятное вроде Фотошопа. Даже календарь — это уже целый мир разных сценариев. Ну вот, например: Иван понял, что не успевает на регулярную встречу, и хочет предупредить других участников о переносе. Кому-то из них удобнее написать, кому-то позвонить. В ходе одного из звонков Пётр говорит, что давайте тогда уж вообще перенесём эту встречу на час позже, потому что ему самому трудно на неё успевать всё время. Иван смутно помнит, что где-то через пару недель у него запись к зубному, и хочет убедиться, что перенос не конфликтует с ней, идёт проверяет. Выясняется, что конфликтует, но договариваются всё же перенести на час позже, а там, через две недели, просто сделать исключение. Ну и что, как построить навигационную модель вокруг этого сценария? Да никак. Во-первых, если вы хорошо провели анализ, то даже тех сценариев, которые вы рассмотрели и выделили как ключевые, будет довольно много. То есть даже если для каждого из них есть прям готовая кнопка или раздел в интерфейсе, найти их будет не так просто. Во-вторых, остальные сценарии, которых несравнимо больше, вообще непонятно, где надо будет искать. Развивать такой продукт и поддерживать растущее число сценариев — боль. Хороший интерфейс не ведёт по сценариям, он лишь создаёт для них возможности. Он даёт пользователю свободу, чувство контроля, ту самую «агентность», а не просто направляет его по одной из нескольких заранее проложенных дорожек. Разумеется, в календаре нет готовой кнопки или даже «мастера» для того, что описано в сценарии выше. Календарь просто так устроен, чтобы пройти по этому сценарию не составляет труда. Это похоже на вопрос о том, зачем нужны карты и схемы, когда в телефоне и так есть навигатор. Навигатор очень полезен, но с ним ты не чувствуешь себя хозяином положения, не можешь отклониться от пути. Карта же даёт общее понимание того, как устроен мир, и ты уже можешь сам принимать решения. На карте нет специальной секции для сценария «по пути с ребёнком из школы заехать погулять в парк», но она делает этот сценарий возможным без проблем. В навигаторе можно предусмотреть функцию «заехать по пути», но её ещё нужно будет найти, а также десятки других сценариев останутся непокрытыми. Поэтому в основу навигации в интерфейсе нужно закладывать некую модель того, как мы хотим, чтобы человек представлял себе устройство нашего продукта: какие у нас есть сущности, как они связаны, организованы, что они умеют. Эта модель должна помогать нам реализовывать все важные сценарии, а пользователю — находить способы их реализации. И эта модель должна выдерживать развитие продукта.

В «Работягах» написали, чем заменить сложные таблицы в b2b-интерфейсах. — Таблица с фильтрами, сортировкой, быстрыми действиями — привычный паттерн для работы с любым массивом данных; — Она удобна и понятна команде разработки. Они могут решить использовать её без каких-либо исследований; — Как универсальное решение она плохо помогает выполнять конкретные задачи и часто просто отображает данные; — Когда стоит задуматься о замене: слишком много колонок; горизонтальный скрол; чтобы понять суть, приходится открывать каждую строку или использовать правильные комбинации фильтров; пользователи только выгружают данные, чтобы обработать их в Экселе; — Не трогайте таблицы, если пользователь думает ими. В этом случае попробуйте их улучшить закреплением колонок, инлайн-редактированием и так далее; — Таблицы хороши для сравнения однотипных сущностей по одинаковым параметрам, быстрого сканирования большого массива и поиска расхождений, массовой обработки данных; — Если у сущностей есть жизненный цикл (лиды идут по воронке), таблицу можно заменить на канбан-доску: сразу видно, где затор, легко управлять потоком; — Если пользователь обрабатывает поток сущностей, подойдёт очередь. Важно выбрать параметры для отображения, которые помогают приоритизировать сущности; — Если важны даты начала и окончания и связь сущностей друг с другом, удобнее будет календарь, таймлайн или диаграмма Ганта. Важно дать возможность управления данными при просмотре в этом режиме; — Дашборд заменяет таблицу с метриками, в которой надо самостоятельно искать отклонения, держа в голове норму; — Карточки объектов удобнее, если нужна возможность рассмотреть каждую сущность целиком. В таблице картинки, теги, длинные названия, статусы и действия раздувают строки, и важные признаки теряются; — Ещё вариант: AI-слой, который будет анализировать данные таблицы (отвечают на вопрос «Что у нас есть») и, руководствуясь продуктовой логикой, подсказывать, «Что делать»: саммаризировать, выявлять отклонения, предлагать кнопки действий по каждому пункту; — Чтобы выбрать подходящий паттерн, надо понять, кто работает с интерфейсом и ради чего, какие вообще свойства бывают у объекта, какие из них нужны разным ролям и какие нужны для выполнения конкретных действий; — Не стоит избавляться от таблиц полностью: в b2b почти всегда нужен режим «Все записи» для массового редактирования, экспорта, сверки, аудита продвинутыми пользователями. #table #b2b

Михаил Рубанов публикует в виде сайта свою книгу об адаптации iOS-приложений для людей с ограниченными возможностями. — В книге он рассказывает, как незрячие пользуются скринридером VoiceOver, как управлять телефоном голосом, как полностью парализованный человек может отдавать команды; — А также: как подготовить к такому использованию iOS-приложение, как адаптировать интерфейс для увеличенного размера текста и как это всё протестировать; — Книга ориентирована на разработчиков, но полезна и дизайнерам, поскольку адаптировать интерфейсы можно на уровне контролов, экранов и сценариев; — Часть глав ещё в процессе публикации. Например, глав об адаптации для увеличенного размера текста пока нет; — Есть большая статья — гайд о том, как сделать iOS-приложение доступнее. #book #accessibility #mobile

Михаил Нозик написал, как презентовать объёмные данные, таблицы и отчёты. — Например, в виде материала для презентации дали скриншот с отчётом из 1С; — Если просто вставить его в презентацию, слушатели залипнут в таблицу и пропустят рассказ спикера. Показывать на экране стоит то, что воспринимается быстро, пока люди слушают; — Отчёт может доказывать, что данные не взяты с потолка. Покажите основные цифры и часть скриншота, чтобы люди поняли, что это, но не стали изучать его подробно; — Если данные на скриншоте и есть предмет презентации, покажите его целиком ненадолго, чтобы объяснить, о чём речь. Затем подсвечивайте и увеличивайте те места, на которые надо обратить внимание (не бойтесь сделать много слайдов для этого); — Можно пройтись по скриншоту вживую, от фрагмента к фрагменту. Но важно отрепетировать, чтобы избежать беспорядочного метания по экрану. #slides #presentation

А вы смотрите сторис в приложениях? Кажется, что это просто привычный формат из соцсетей. Но на самом деле сторис могут решать вполне конкретные продуктовые задачи. Кирилл из команды t2.digital разобрал, как с помощью этого инструмента закрывать 5 ключевых задач мобильного приложения. Листайте карточки, чтобы узнать больше. В своем канале ребята рассказывают о новых фичах, делятся внутренней экспертизой и публикуют вакансии.

Эрик Чанг написал о навигации с помощью табов (вкладок). — Вкладки упрощают навигацию, экономят место на странице, группируют контент и обеспечивают быстрый доступ к нему; — Табы хорошо работают, когда их немного, все они видны на экране и нет горизонтальной прокрутки; — На мобильных устройствах может появиться горизонтальный скрол в блоке табов или кнопки для его прокрутки влево и вправо. Также переключаться между табами иногда можно свайпами влево и вправо; — Их лучше не использовать для сложного иерархического контента (табы внутри табов внутри табов); — Они хорошо подходят для навигации второго уровня, когда основная навигация находится в боковом меню; — Также лучше от них отказаться, если нельзя каждой вкладке дать короткое и понятное название, из-за чего текст может обрезаться или переноситься на несколько строк; — Минус табов: для доступа к контенту вкладок, не открытых по умолчанию, пользователю надо на табы нажимать. Если находящийся там контент имеет решающее значение для пользовательских целей, лучше его там не размещать; — Не забывайте выделять активную вкладку, а также реагировать на наведение курсора на десктопе; — Чем отличаются от аккордеонов: обычно вкладки расположены горизонтально, а аккордеоны — вертикально, в аккордеонах часто возможно одновременное раскрытие нескольких панелей. In English. #tab

Маргарита Попова написала об итеративном процессе в дизайне. — Полезен новым продуктам (MVP и R&D-проекты), в условиях неопределённости, без готовой дизайн-системы, для ускорения поставок функциональности пользователям; — В каскадной модели разработка следует за дизайном. Минусы: этап дизайна кажется бесконечным, разработчики приходят с вопросами, когда дизайнеры уже заняты другим; — Дизайн блока функциональности (запланированного в USM) можно разделить, чтобы идти от общих вопросов к частным и чаще получать обратную связь; — 1. Формирование общей картины: работа с PO и PM, создание User flow, схем работы и прототипов от руки, которые легко выбрасывать при переборе идей; — 2. Детализация прототипов, добавление отдельных интерактивных элементов, чтобы провести простые пользовательские тесты сценариев использования и обсудить с разработчиками функциональность. Последние могут приступать к проектированию архитектуры; — 3. Подробный интерактивный прототип со всеми состояниями, дающий возможность провести полноценное тестирование с пользователями. После тестов — внесение правок, запись идей на следующие итерации; — 4. Дальнейший дизайн идёт параллельно разработке: макеты, состояния компонентов, подготовка к вёрстке, UI-кит; — Плюсы: вся команда вовлечена в проектирование и принятие решений, решения тестируются, технические вопросы решаются раньше; — Минусы: сложнее тестировать не финальные макеты, разработка стартует после проработки всего блока функциональности, обсуждения переключают контекст разработчиков; — Если брать не блок, а небольшой кусочек, можно спроектировать его за спринт (хотя бы простой вариант для начала); — Плюсы: у разработчиков и дизайнеров общий контекст, пользователи получат фичу и дадут обратную связь, видны метрики, может оказаться, что цель достигнута и дальше полировать дизайн смысла нет; — Минусы: более сырой интерфейс, большие сценарии не умещаются в спринт, сложнее управлять, больше техдолг; — Чтобы потом вспомнить, какие дизайн-решения были приняты и почему, можно использовать аналог ADR (пример); — Когда останавливаться в полировке прототипа: покрыты все сценарии, улучшения не приносят заметной пользы, у команды не осталось вопросов, появилось желание выровнять отступы; — Итеративный подход снижает тревогу по поводу идеальности результата, а также предлагает задуматься, что считать идеальным результатом (приносит пользу клиентам уже сейчас). #process #prototype