224
Чат читателей @uxnotes · Редактор: @zGrav
Привет!
Хочу почитать что-то полезное про фильтры в интерфейсах — про логику, UX, хорошие и плохие примеры. Может кто то видел статьи на эту тему? Буду очень благодарна 🙏
В нынешних реалиях чтобы устроится дизайнером нужно пройти жестоясайший отбор.
Если раньше реальная работа «перекрасить цвет кнопки» сопровождался требованием «дизайн системы и десяток реальных проектов в проде» то сейчас тоже самвя работа подразумевает еще компетенции в исследованиях, анализе метрик, софт скиллов, знании корпп культуры, скорринге на эмоциональны интеллект, прохождение таролога и красивой презентации этих не встречающихся в реальной работе навыков и предлагает вдвое меньшую зп без учёта инфляции
Три варианта дизайна? Почему не десять?
Одна из самых горячих тем для компаний (как исполнителей, так и заказчиков), работающих с дизайном, — это количество вариантов.
Традиционно в нашей отрасли клиентам предлагают три варианта дизайна. На мой взгляд, это огромная ошибка, тянущаяся из диких времён — 90-х и начала 2000-х. Почему я так думаю?
Во-первых, перебор вариантов — это самый неправильный подход. Это значит, что заказчик не понимает, что хочет. А исполнитель не понимает, что делает. Не очень перспективное сочетание. Сейчас подходы изменились, исследовательская и проектная база проектов позволяет сделать сразу то, что нужно.
Во-вторых, ни одна студия и ни один дизайнер не делает всерьёз три равнозначных варианта. Это надо просто честно признать. Обычно делается один нормальный вариант, второй — так себе, третий — чтобы просто был. Это знают все: и дизайнеры, и менеджеры, и сами клиенты.
В-третьих, и это самое главное: три варианта — это логический тупик. Вот вы сделали три, и все они не подошли. Что дальше? Четвёртый вариант не включён в стоимость и начинается конфликт. Но самое главное то, что скорее всего ошибка была на этапе брифинга, во вводных данных или их передаче, возможно в исследовании. И чтобы это исправить, проект нужно начинать сначала. Либо клиенту придется доплатить, либо подрядчику работать бесплатно. Никакого винвина не получается.
Как должно быть?
Должен быть последовательный путь к решению. Если клиент хочет несколько вариантов, то они должны быть последовательными. Сделали один — показали, обсудили, поняли, что не так. На основе этой обратной связи — второй. Снова обсудили — третий точно попадет.При такой модели не попасть три раза подряд — практически невозможно.
Но мы в Nimax чаще всего используем другую практику — один вариант, но с максимально глубокой проработкой. Тщательно брифуемся. Проводим исследования если данных не хвататет. Проектируем или пишем стратегии. Проводим тщательную работу с референсами и ожиданиями на мудбордах. Показываем промежуточные направления и идеи. Делаем один финальный вараинт, который в 80% случаев принимается с первого раза, но всегда с правками.
С остальными 20-ю процентами разбираемся индивидуально. Если ошибка на нашей стороне — делаем новый полход за свой счет. Если ошибка на стороне клиента, то новая итерация за счет клиента.
Реже делаем два варианта силами разных дизайнеров, но на одной платформе. Для каждого из дизайнеров концепт один и он в него вкладывается всерьез. Здесь бывают неожиданные эффекты, иногда клиенты хотят использовать оба направления (для разных направлений бизнеса обычно) и это осложняет проект.
Ну и конечно, если клиент настаивает на нескольких вариантах — да, мы можем так сделать. Но считаем эту модель неправильной.
Успех не в количестве вариантов, а в продуманном пути к ним.
Ничего не будет: ни кино, ни театра, ни книг, ни газет (тестовых заданий) — одно сплошное телевидение (вайтборд)
Читать полностью…
а еще лучше не давать тестовые, потому что они плохо работают и для нанимателей, и для кандидатов)
Читать полностью…
Маргарита Хохлова в последнее время только и публикует находки из разных исследований, в основном связанных с текстом и интерфейсом: @microcopy — можно на неё подписаться
Читать полностью…
Егор, спасибо за комментарии — они очень ценны для меня, как автора статьи. Не факт, что я на 100% согласен с каждым из них, но в любом случае, каждый подкидывает дополнительных дровишек в топку моих размышлений на эту тему. По поводу достаточности контекста — это действительно один из пунктов, вызывающих у меня больше всего сомнений. Знаю за собой одну особенность — излишнюю многословность в письменном тексте, поэтому обычно пытаюсь ужать его до состояния маскимальной полезности для читателя при минимуме лишней информации. Иначе любой текст рискует распухнуть до того, что его будет сложно прочитать до конца. В данном случае контекст, о котором ты говоришь, посчитал нужным высушить до минимума. Но тут всегда вопрос золотой середины — как ее нащупать, каждый атвор решает сам, и возможно, ошибается. В любом случае, спасибо за ценный фидбэк! Постараюсь использовать его в будущем. 🤟
Читать полностью…
И снова я не удержался от комментария. Надеюсь, он чуть-чуть поможет как автору, так и читателям.
В статье описан фреймворк работы при найме специалистов. И как по мне — самая важная информация, которая нужна для того, чтобы обратить на этот фреймворк внимание и попробовать использовать его в работе (или не использовать, но внимательно ознакомиться и стать чуточку умнее) — это контекст автора.
Кто такой Никита Наджаров (hr, руководитель, основатель)? Что у Никиты за компания? К какому рынку относится? Сколько дизайнеров Никита нанял в команду? Сколько собеседований проводит в месяц, год, за всё время? Сколько собеседований проводил во время пиковых нагрузок? Было ли это как-то связано с экономической ситуацией в компании?
Во вступлении:
«По статистике, одна из самых больших болей кандидатов…» — по какой конкретно статистике?
«Можно назвать множество причин того, почему компании не дают кандидатам фидбэк…» — какие именно компании? По каким причинам раньше не давала фидбэк компания Никиты, а затем исправилась?
«Среди компетенций, которыми должен владеть руководитель, есть такие» — если бы мы знали контекст Никиты, мы могли бы понимать, на чём основано это заявление, а так не можем
В выводах
«Качество найма выросло» — в чём конкретно это выражается?
«Субъективность в оценке снизилась до минимума» — в чём это выражается и почему это хорошо?
«Вероятность того, что он вернётся к нам… повышается» — сколько вернулось?
«Честная и корректная обратная связь производит хорошее впечатление на кандидата вне зависимости от исхода дела и формирует позитивное впечатление о культуре компании» — как об этом узнали? В чём это выражалось? Это же были бы отличные кусочки сторителлинга, вводящие в контекст!
При этом сам фреймворк кажется мне здравым и логичным (когда я нанимал сотрудников, использовал похожий подход, с оговоркой, что мне никогда не нужно было нанимать на потоке и я не заморачивался над оптимизацией эргономики процесса). И если бы описание было сопровождено контекстом — я бы пошёл гуглить, кто такой Никита Наджаров, чтобы следить за новыми публикациями.
Соглашусь, при этом зная, что можно найти более свежие исследования, очень странно опираться на данные 2008 года
Читать полностью…
Маша Русскова поделилась выводами из исследований текста в интерфейсе.
— За одно посещение веб-страницы люди в среднем успевают прочитать не более 28% слов;
— При средней длине предложения в 14 слов читатели понимают 90% написанного. Наш предел — 25 слов;
— Вопросы в заголовках привлекают больше внимания, чем утверждения (больше CTR). Лучше работают персонализированные вопросы со словами «вы», «ваш». «Оцените главную страницу» → «Как вам главная страница?»;
— Цифры в коммуникациях работают лучше числительных: больше CTR и выше доверие производителям с сомнительной репутацией. «Сдадим квартиру за семь дней» → «Сдадим квартиру за 7 дней»;
— Действительный залог лучше страдательного: люди лучше понимают информацию. «Деньги будут возвращены» → «Мы вернём деньги»;
— Плюс это соответствует тренду новой искренности. В примере выше стало понятно, кто несёт ответственность за возврат.
#writing
Взяли на работу как раз после вайтборда. Согласна с автором, что нужно читать задачу и решать именно тз без особого углубления
Читать полностью…
Пользуясь случаем если в вашем продукте вас зае... вам надоела дизайн система которая из всех пьет соки приду и уволю весь отдел дизайн системы и наконец о начнем заниматься продуктом, пишите в личку 🤝🤝
Читать полностью…
Игорь Бутков понятно написал для начинающих о стилях, переменных и дизайн-токенах в Фигме.
— Минус стилей: если в большой дизайн-системе надо заменить один цвет на другой, каждый стиль придётся обновлять по отдельности;
— С переменными такой проблемы нет: цвет становится значением переменной (корневого токена), с которой можно связать другие переменные;
— Корневые токены варьируются по цветам и контрастности, например: purple-500;
— С ними могут быть связаны семантические токены — абстрактные названия, указывающие не на сам цвет, а его функцию, например: background.primary;
— Если нужна возможность отдельно настраивать, например, цвета кнопок, можно добавить компонентные токены, например: button.primary.default;
— Минус: таких токенов будет очень много;
— Преимущества абстрактных названий: если вместо button.purple будет button.primary, фиолетовый цвет можно легко заменить на розовый, и логика названий не сломается;
— Для обозначения числового шага используют S, M, L или числа с большим шагом: 100, 200, 300;
— Числа удобны, если размеров много и могут добавляться промежуточные шаги (250 добавить проще и он будет понятнее, чем 2L).
Токены Atlassian. #figma #design_system #color
Очень похожая система используется и у нас, с небольшими отличиями: вместо нумерации я использую структуру бредкрамбов (Flow: Screen: State) и стрелочки тоже не ведём, ибо становится сложно менеджить контент когда нужно в середину flow что-то добавить.
Читать полностью…
Особенно фреймят дизайн системы. Когда годами собираешь интерфейсы из ДС-шных компонентов, получив несколько раз по рукам за креатив, то теряется навык смотреть шире
Читать полностью…
Есть бюджет. Можно и пять разных вариантов пяти разных дизайнеров/команд.
Нет бюджета — один вариант. Возможно с доработками, возможно нет.
Это да, как чел говорил какой-то, мол, когда метрика становится целью она перестаёт быть ценной метрикой, потому что, ну блин, вот вам три дизайна просто, чтобы что? Чтобы было.
Читать полностью…
Илона Арзуманян написала об онбординге новичков в команду.
— Онбординг нужен, чтобы погрузить во все аспекты работы как можно быстрее и не взорвать его мозг;
— Один документ, где всё описано, лучше отдельных ссылок в мессенджере или проговаривания большого объёма информации;
— Включите в него, что нужно сделать в первые дни: ссылки на программы, инструкции по настройке и получению доступов;
— Соберите ссылки на полезные материалы: редполитика, брендбук, гайды по проведению исследований, работе с дизайн-системой;
— Навигация по проектам поможет найти макет или сценарий, когда сотрудник ещё плохо знает принципы хранения макетов;
— Важно донести структуру компании: кто чем занимается в разных командах, к кому с какими вопросами обращаться;
— В каждой компании есть особенности взаимодействия между отделами. Опишите процесс работы от планирования до релиза. По каждому этапу укажите нужные ссылки, файлы, контакты коллег;
— Подробнее опишите этапы работы именно дизайнера: работа в таск-менеджере, получение (обсуждение и уточнение) задачи, исследование и анализ, работа с библиотекой паттернов, графикой, текстом, исследованиями и дизайн-системой, ревью с дизайн-командой, лидом, продактом и бизнес-заказчиками, ревью на соответствие дизайн-системе, передача макетов и дизайн-ревью;
— Также полезно донести, что вы ожидаете от сотрудника в ближайшие 3 месяца, но это больше относится к процессу прохождения испытательного срока.
#management
Если я правильно понял, этот подход для создания заданий и оценки решений в формате вайтборда тоже подходит
Читать полностью…
Ещё Юля Кондратьева пишет о результатах исследований интерфейсов: @chem_dokazhesh
Читать полностью…
Так хотелось удержаться и похвалить Машу, которая потратила свое время, чтобы научить коммьюнити пользоваться пипеткой. Но все факты настолько банальные и избитые, неужели ничего нового не наисследовали в последние годы?
Читать полностью…
Поправлю: здесь речь не про собеседования, а именно про тестовые задания и обратную связь по результатам их выполнения.
По поводу контекста автора. Что даст ответ на вопрос, что это за компания, к какому рынку относится, было ли это связано с экономической ситуацией в компании?
По поводу роли. Кажется вполне очевидным, что такого рода задачами занимаются руководители, так как HR не оценивает результат выполнения тестового. И что это не основатель, так как когда компания становится достаточно большой для периодического найма продуктовых дизайнеров, основатели уже успевают нанять для этого руководителей.
Про количество нанятых дизайнеров — хороший вопрос, можно понять, насколько этот подход апробирован. Но причём тут пиковое количество собеседований? Подход не увеличивает и не уменьшает время, необходимое для того, чтобы изучить результат выполнения тестового задания. Он просто структурирует то, что руководители делают и так и позволяет прозрачно оценивать результаты соискателей.
«Среди компетенций, которыми должен владеть руководитель, есть такие» — как мне кажется, любой руководитель. Для этого не нужен контекст конкретно автора.
По остальным пунктам согласен, можно добавить конкретики и примеров, чтобы проиллюстрировать выводы.
Никита Наджаров написал, как оценивать результат выполнения тестового задания и упростить подготовку обратной связи.
— Придумывая тестовое, определите, какие задачи (или их типы) надо решать дизайнеру в ближайшее время (например, месяц);
— Составьте список, какие навыки для этого потребуются;
— Тестовое должно помочь эти навыки оценить и при этом вдохновлять на его выполнение;
— Идеально, если его можно выполнить не больше чем за 4 часа (или за 1 час в формате вайтборда);
— Придумайте несколько задач на выбор, чтобы соискатель мог поработать над тем, что больше по душе. Выбор раскроет его предпочтения и профессиональный профиль;
— У задач должно быть множество решений, чтобы можно было показать креативность, способность синтезировать концептуальные решения, выбрать лучшее из возможных;
— Они должны быть интересными (нетиповыми, нелёгкими) и включать возможность трактовки или противоречия. Как дизайнер с этим справится, покажет его уровень;
— Подготовьте критерии оценки (не более 20). Они должны основываться на том, какого подхода, профессиональных качеств и способностей вы ждёте от специалиста, которому надо будет решать определённые в начале задачи;
— Например: даны полные ответы на все вопросы, ни один не проигнорирован (внимательность и фокусировка); решения учитывают цели бизнеса и интересы пользователя (способность работать в сложном контексте);
— Сгруппируйте критерии по компетенциям. Например, критерии понял ли соискатель проблематику, учел ли крайние сценарии, решает ли его предложение задачу относятся к компетенции «Полнота и глубина проработки»;
— Результат выполнения тестового оцените по критериям от 1 до 5 баллов. Когда критериев 20, максимумом будет 100 баллов;
— Больше 80 баллов — отлично, 70–80 — можно доучиться в процессе, меньше 60 — есть риск несоответствия вакансии;
— К каждой оценке меньше 5 баллов добавляйте комментарий;
— Оценки и комментарии показывать соискателям не надо. На встрече расскажите, что понравилось в работе, а затем опишите те моменты, по которым есть комментарии (своими словами, можно более развёрнуто);
— Послушайте ответы, чтобы понять, как соискатель работает с обратной связью — тоже важный навык;
— При оценке в 70–80 баллов подскажите, что прокачать.
#hiring
Не удержался от коммента.
«За одно посещение веб-страницы люди в среднем успевают прочитать не более 28% слов».
Далее даётся ссылка на статью Якоба Нильсена 2008 года. А уже в статье есть ссылка на исследование, недоступное в открытом доступе.
Но я могу предположить, что оно проводилось на носителях английского языка до 2008 года. Помните, каким был веб в те времена? Каким был дизайн? Какими были устройства, с которых мы читали? Если что, первый айфон появился за полгода до этого, поэтому речь идёт о настольных компьютерах.
В общем, исследования и ссылки на них — это круто. Но в 2025 году опираться на мир 2008 года по мне так менее полезно, чем поделиться цифрами по собственному продукту безо всяких отсылок на что-то ещё.
ну на мой взгляд тупая практика у Т-банка. Что это даёт в реальной работе... В любом случае дизайнер взаимодействует со стейкхолдерами и нужно много контекста, а подобное вот по верхам эти бич Т-банка.
Которые типо придумали свою фишку, которая ничего не даёт кроме как потерю сильных кандидатов на мой взгляд
Влада провалила вайтборд и написала о своих ошибках.
— Время ограничено. Хорошо, если вы умеете быстро въезжать в тему;
— Попробуйте узнать заранее, из какой предметной области будет задача или над чем работает команда, которая вас собеседует;
— Готовясь, можно натренировать выстраивание диалога о задаче. Поговорите со знакомыми дизайнерами об их задачах, как если бы это был вайтборд;
— Ответы на вопросы «Чего хочет бизнес», «Кто ваш пользователь» и «Какие метрики» скорее сбивают, чем помогают найти лучшее решение. Спросите о целях и не уходите глубоко в анализ;
— Решение не должно быть лучшим. В какой-то момент придётся остановиться и выбрать из того, что получилось придумать. Важнее показать навыки коммуникации и рассуждения;
— На случай тупняка заранее подумайте над вопросами, которые будете задавать интервьюеру;
— Есть шаблоны дизайн-процесса для вайтборда (например, генерация идей там может быть отдельным этапом). Но чужие неотработанные на практике подходы будут сбивать, лучше придерживаться своего привычного процесса, адаптировав его под формат вайтборда;
— Примеры задач для вайтборда от компаний вроде Озона и Яндекса.
#career #whiteboard_challenge
Шел 2025 год, мы всерьез создаем и репостим вредные советы... Дайте подушнить:
# палитра с шагом 100,200,300...
Не создавайте лишних цветов. Используйте только те что у вас есть в проекте. Не надо их солить как огурцы на будущее эти ленты цветов. Чем больше лента тем больше сомнения в выборе, тем больше ошибок в проекте.
# с серьезным лицом обсуждать что выбрать hsl или lch для генерации палитры
Ни одна математическая модель пока что не создаёт ленту цветов нормально. Пикните цвета вручную в любой цветовой модели какая вам нравится. (Свидетели OKLCH туда же)
# создавать переменную третьего уровня (компонентный слой)
Овертокенизация про которую чето мало говорят. Если каждый компонент обдрочить собственным токеном типа button primary default то что это даст кроме жжения пятой точки у ревьювера и ошибок у разрабов? Вы сука из цветов рокет-саенс придумали. Остановитесь на семантическом surface.primary и покрасьте им все что подходит под этот цвет.
Вместо бесконечного создания токенов договоритесь с собой что -- чем меньше токенов тем лучше для всех. Меньше ошибок, меньше проверок, меньше проблем с переделкой. Используйте принцип -- токена достойна только мама. Каждый токен должен доказать свою нужность иначе он уходит под нож.
# сравнивать НЕПРАВИЛЬНЫЙ прямой нейминг переменных цвета с нормальным семантическим...
Просто никогда не используйте прямое название типа text blue. Всегда вместо этого text primary или если объединяете иконки и текст вместе то symbol primary
Опять же, чем меньше токенов тем лучше.
# создавать токены отступов и скруглений. Наверное одна из худших идей которая неприменима в жизни. Чем больше проект тем утопичнее идея о изменяемости отступов.
Для адаптивности на разных устройствах достаточно одного набора отступов которые названы прямо 2,4,8,12,16... Без маек и абстрактных цифр.
Хм-м-м, но ведь это логично и естественно для ит, все ориентированны на бизнес, ведь если ты не поднимаешь метрики - ты не конкурентоспособен...
Если вам хочется видеть творцов, то рассмотрите такие сферы как моушен, 3д и тд, ведь цель их работы во первых - создание красивого дизайна, а не влияния на бизнес🤷🏻♂️
Влад Крят написал об оформлении макетов.
— Отсутствие стандартов усложняет работу с чужими макетами, особенно в большой команде;
— Дизайнеры работают в тёмной и светлой теме примерно поровну, поэтому оптимальный цвет фона рабочей области #6B6B6F;
— Макеты лежат внутри секций, фоновый цвет которых зависит от того, какая тема интерфейса показана в макетах: светлая (#DADAE2) или тёмная (#38373D);
— Секции показывают: 1) happy flow: основной путь только с ключевыми ответвлениями, чем линейнее, тем лучше, 2) дополнительные экраны: ошибки, загрузки, альтернативные состояния экранов;
— На дополнительные экраны можно ссылаться в основном пути;
— Основной путь можно разделить на логические части и показывать их в отдельных секциях;
— Сценарии-микросхемы, где развилки и состояния компактно расположены и связаны сеткой соединительных линий, выглядят круто, но изучать их неудобно;
— Уникальные экраны идут слева направо, их состояния — сверху вниз;
— В нумерации экранов (например, «1.1») первое число — номер уникального экрана, второе — его состояние. Но иногда достаточно лишь названия, например, в наборе экранов с ошибками;
— Соединительные линии выходят из места, с которым пользователь взаимодействует. Если их начало лежит рядом с макетом, место взаимодействия может быть неочевидным;
— Если появляется много пересечений стрелок, значит макеты превращаются в микросхему. Надо декомпозировать;
— Макеты можно сопровождать полезными метками, например: Prod (экран в показанном сценарии уже разработан), Webview, Copyright (требуется редактура);
— Единые правила для расстояний между макетами, блоками с комментариями и так далее помогают воспринимать любой макет быстрее.
#handoff