224
Чат читателей @uxnotes · Редактор: @zGrav
И снова я не удержался от комментария. Надеюсь, он чуть-чуть поможет как автору, так и читателям.
В статье описан фреймворк работы при найме специалистов. И как по мне — самая важная информация, которая нужна для того, чтобы обратить на этот фреймворк внимание и попробовать использовать его в работе (или не использовать, но внимательно ознакомиться и стать чуточку умнее) — это контекст автора.
Кто такой Никита Наджаров (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 что-то добавить.
Читать полностью…
Особенно фреймят дизайн системы. Когда годами собираешь интерфейсы из ДС-шных компонентов, получив несколько раз по рукам за креатив, то теряется навык смотреть шире
Читать полностью…
дизайнеры узнают что они рабочие на заводах, многие еще удивятся когда их заменят условным UIzardom
да нет никаких метрик, это чисто каргокульт хрюш и продактов, которые они придумали, чтобы не платить много
Так же как и грейды это просто способ объяснять зп
1. При найме редкий лид смотрит... барабанная дробы... на дизайн. Всем нужны измеримые результаты.
2. Мало какой компании нужно что-то новое, им надо растить циферки. И не дай бог что то завалить.
3. Да. Приходится идти по матрицам компетенций и грейдам, чтобы потом апнуть грейд и зп. За любопытство не доплатят.
4. Категорически согласен. Переход в любой менеджмент - ад и новая профессия.
5. Когда идёшь наниматься, то опять интересно, что ты дал бизнесу. Им ок, если тихо и незаметно нагадил юзеру в карман, но принес деняк.
В больших проектах процесс появления нового очень болезненный. А в маленьких что угодно можно самонаменировать на прорыв, но пока это не приносит прибыль, непонятно, может вы все это время изобретали велосипед. В конечном счете все упирается в деньги. И вас не смущает формулировка: стали ориентированными на потребности бизнеса и забыли про потребителя…а бизнес на чьи потребности ориентируется?
Владелец любого продукта заинтересован в удовлетворенных потребителях и окупаемости вложений. Чем больше продукт, тем больше риски. Поэтому, мне кажется, никто и не спешит реализовывать «смелые идеи» не опираясь на метрики. Конечно, если бы задачи формулировались - эй, ребят, у нас тут завалялось пара лишних миллиардов, можете любую смелую идею, которая в голову придет, реализовать, вот ни в чем себе не отказывайте и пилить можете год-два, вот прям сколько захочется, а не взлетит и ладно, гарантий никаких не требуем, главное вы тут самовыразились… да и вообще, дизайнер, который шарит за метрики это благословение небес для любого бизнеса и для большого, и для маленького
Если честно, я тоже об этом думал, что давненько в дизайне не было прорывных методологий. Типа не новые контексты, а именно принципы, как и было отмечено. Может пора придумать их самим? :))
Читать полностью…
Ну, начнем с того, что окружение и рынок меняются, а значит появляются вещи, которых до этого не существовало. И под них нужно дизайнить :) конечно, если этот мир вам абсолютно понятен, то и к таким вещам можно подходить с заготовленным подходом. Но и решение получится... Банальным. Может это и хорошо, а может нет — хз, ведь и так будет работать. Но скажу точно, что банальное решение можно улучшить. Возможно немного, и несоразмерно усилиям, но можно, если интересно :)
И не подумайте, что я тут в оппозиции, я скорее о том, что понимаю обе стороны :)
Никита Наджаров написал, как оценивать результат выполнения тестового задания и упростить подготовку обратной связи.
— Придумывая тестовое, определите, какие задачи (или их типы) надо решать дизайнеру в ближайшее время (например, месяц);
— Составьте список, какие навыки для этого потребуются;
— Тестовое должно помочь эти навыки оценить и при этом вдохновлять на его выполнение;
— Идеально, если его можно выполнить не больше чем за 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
Ваня Соловьёв написал, к чему готовиться дизайнерам, ставшим лидами.
— Часто ими становятся дизайнеры, прекрасно справляющиеся со своими обязанностями. Но управление — совсем другая компетенция;
— Учитесь у менеджеров, читайте книги о менеджменте;
— Бизнесу не важно, как вы выстроите процесс, важно, чтобы команда достигала бизнес-целей;
— Чтобы определиться со стилем управления, прочитайте книгу Ольги Лукиной «Бизнес и/или свобода»;
— «Надзиратель» помогает получить быстрые результаты, но подавляет творческую свободу;
— «Яблочное дерево» подразумевает создание условий для развития дизайнеров. Принципы: самостоятельность важнее контроля (возможность совершить ошибку), аргументы выше авторитета;
— При делегировании важно не убить инициативу, передавая только мелкие или скучные задачи, и не оставлять совсем без контроля, чтобы сохранить качество и выдержать дедлайн;
— И придётся научиться конкретно и достаточно детализировано формулировать задачи;
— Детализация зависит от уровня специалиста. Джунам нужны чёткие инструкции, мидлам достаточно видения решения проблемы, синьорам можно лишь задать ориентиры;
— Попросите дизайнера кратко изложить своё понимание задачи, чтобы избежать недоразумений;
— Критикуйте приватно, хвалите публично;
— Микроменеджмент указывает на то, что что-то пошло не так. Возможно, задача не соответствует уровню дизайнера. Но он допустим в период адаптации;
— Фасилитируйте встречи: придерживайтесь темы встречи, давайте высказаться всем, фиксируйте, что обсуждали и о чём договорились;
— Анализируйте свой опыт и извлекайте уроки из ошибок.
#management
Есть же классика… табурет нормана, к чему эти разговоры… бизнес.. пользователи…
Даже тут уже все давно обсудили и написали 😁
Не эхокамера, скорее нетерпимость к хамству и призывам типа "сиди и не бухти".
Читать полностью…
как и ожидалось от автора поста - эхокамера классическая.
ровно такая же история происходит внутри команд на проектах.
считаю, что это и есть причина стагнации отрасли в области больших коммерческих продуктов.
там просто нечего делать, если ты пришел туда не за деньгами(очевидно), ну и отбор потому проходит под задачи совсем другого "не дизайнерского" характера.
структура и жесткая вертикаль даже в рамках одной команды мотивируют тебя сидеть на попе ровно и получать свои шекели.
возможно, если мы реально хотим сделать заебись, то надо заменить отдельные руководящие должности на "коллегии".
но тут хуй его знает как это скажется на производительности и вообще кто позволит так сделать.
Я согласен. Я всё жду когда банальную корзину во всяких online grocery store доработают, и добавят функцию сортировки по категориям товаров (очень важная фича если собираешь что-то на 20к). Но в такие апки впихнули сториз 😔не понятно зачем.
Я же говорил о принципах дизайна. То есть про то что нужно, чтобы в дизайне было (типа "система всегда должна сообщать о своем состоянии"). А то, как это дизайнера делает - на стороне дизайнера и той среды в которой в которой дизайнер пилит интерфейс. Это уже про то КАК сделать. И здесь подходы меняются, и без обучения и наработки опыта не обойтись.