224
Чат читателей @uxnotes · Редактор: @zGrav
Ну вот да, будучи джуном я по полгода искала работу. Как только подняла грейд - два раза была в поиске и оба раза меньше месяца занимал процесс собесов и тестовых 🤷♀️
Читать полностью…
Павел Шерер написал о терминах UX и CX и кто кого включает.
— Они связаны, но UX — фундамент. Если вы улучшите форму оплаты, NPS может не сдвинуться, потому что претензии к колл-центру останутся. И наоборот: идеальный CX-чеклист не спасёт, если кнопка «Оплатить» лагает;
— Дон Норман: «UX — все аспекты взаимодействия конечного пользователя с компанией, её услугами и продуктами»;
— ISO 9241-210:2019: «UX — восприятия и реакции человека, возникающие до, во время и после использования системы»;
— То есть это доставка, колл-центр, утилизация, компенсация за некачественную услугу и вообще всё, что потом назвали CX;
— Customer — тот, кто платит. User — любой, кто взаимодействует. CX-сценарии с платящими клиентами — подмножество более широкого множества UX-сценариев;
— Исторически сервис-дизайн и CJM выросли из UX-исследований;
— В плане методологий почти всё берётся из изначальных UX-практик;
— Кто-то считает, что CX важнее, так как фокусируется на том, что приносит компании деньги, помогает растить LTV. Хороший UX тоже влияет на метрики: снижает churn rate и увеличивает retention, что также влияет на выручку.
#definition #cx
Ну почему же. То, что применение outline stroke создает лишние точки и удлиняет пути svg в коде - факт. А дальше уже ситуативно: где-то на удорожания пофиг, где-то нет. Где-то можно обойтись просто вектором с обводкой, а где-то outline stroke оправдан
Читать полностью…
Привет всем!
Меня зовут Алексей, мне 23 года, и я ищу новую возможность в сфере UX-анализа. У меня более 5 лет опыта работы в UX/UI дизайне, графическом дизайне и SEO. Но сейчас понимаю, что у меня очень хорошо получается в UX-аналитику, а дизайн оставить все-таки как приятный опыт). С удовольствием предоставлю резюме, если я вас заинтересую.
Мои ключевые навыки:
Проведение пользовательских исследований и анализ поведения
Проектирование пользовательского опыта и информационной архитектуры
Дизайн пользовательских интерфейсов (UI) и взаимодействия (IxD)
Аналитика данных и работа с метриками
Опыт работы с инструментами: Figma, Google Analytics, Hotjar, Salesforce и другими
Ищу:
Полную занятость с гибким графиком, желательно удаленно.
Возможности для применения и развития моих навыков в UX/UI дизайне и аналитике.
Если у вас есть полезные контакты или советы, буду признателен за помощь!
Telegram: @alexey_gulevich,
email: leshagulevich.123@gmail.com.
Спасибо за внимание!
Виктор Теплов рассказал, как работать с иконками в Фигме. А я немного дополнил из других источников.
— Иконку преобразуйте в векторную форму (flatten);
— Исходник полезно сохранить, чтобы не перерисовывать иконку, если в будущем потребуется её изменить;
— Назовите слой Vector. Это стандартное имя для таких слоёв. Можно удалить текущее название и нажать Enter, Фигма подставит слово Vector;
— Иногда слой называют Shape, чтобы название отражало суть;
— Чтобы цвета не слетали при смене иконок в компонентах: создайте копию слоя Vector, объедините эти 2 слоя (union), появится объединяющий слой с именем Union, удалите копию слоя Vector. Задавайте цвет слою Union;
— Иногда этот слой называют Color, чтобы отразить его суть;
— Если во всех иконках будут аккуратно названные слои Vector, то красить можно и их, цвета слетать не должны. Подход со слоем Union позволяет сохранить цвет, когда внутри иконки один вектор полностью меняется на другой;
— Лучше использовать обычный #000000, а не цветовой токен. Так в макетах и компонентах можно отследить, какие иконки не покрашены;
— Можно выбрать какой-нибудь необычный цвет (например, коричневый), чтобы он бросался в глаза, но не слишком, чтобы не усложнять просмотр иконок в библиотеке;
— Векторный слой иконки должен скейлиться;
— Расположите его внутри квадратного контейнера (например, 24×24 px);
— Называть компоненты иконок лучше по тому, что изображено (например, magnifying_glass), без префикса icon или обозначения размера;
— В поле Description можно записать синонимы, по которым могут искать такое изображение в ассетах (например, search);
— В компоненты вставляйте иконки и создавайте свойство Swap instance с именем icon, выбирайте свои иконки в Preferred values.
#figma #icon #design_system
Статья хорошая, сам часто такое разгоняю с коллегами. Но не надо выдавать желаемое за действительность: «Задача дизайнера не повысить метрики, а сделать продукт понятнее, честнее, человечнее» — ни один руководитель, который платит зарплату, не согласится с этим
Читать полностью…
Владимир Павлов написал об обманчивости метрик.
— Иногда случается (по мнению Владимира, слишком часто), что метрики растут, а продукт становится хуже;
— Нельзя судить о качестве продукта только по метрикам;
— При расчёте Retention важно, зачем пользователь возвращается. Он может вернуться, чтобы отменить подписку на рассылку, так как не нашёл такую ссылку в письме;
— Conversion rate взлетает, если упростить флоу, убрать лишнее. Но часто это «лишнее» — это честность, объяснения, без которых пользователи начинают делать то, чего не планировали. Может вырасти количество жалоб и возвратов, снизиться рейтинг в сторе;
— Пользователь должен идти вперёд, когда понимает и хочет, а не когда не заметил подвоха;
— Проводимое в продукте время не всегда означает вовлечённость. Это может быть и растерянность, когда пользователь потерялся в навигации;
— CTR можно повысить, пообещав больше, чем дашь;
— Задача дизайнера не повысить метрики, а сделать продукт понятнее, честнее, человечнее;
— Сначала поймите, чего хотите добиться, а потом — как это измерить;
— Объединяйте количественные и качественные данные: цифры и интервью, поведение и ощущения;
— Встраивайте обратную связь в продукт. Маленький опрос после действия, кнопка «Оставить обратную связь», быстрые реакции. Они не заменят аналитику, но дадут душу цифрам.
#metrics
Привет!
Хочу почитать что-то полезное про фильтры в интерфейсах — про логику, UX, хорошие и плохие примеры. Может кто то видел статьи на эту тему? Буду очень благодарна 🙏
В нынешних реалиях чтобы устроится дизайнером нужно пройти жестоясайший отбор.
Если раньше реальная работа «перекрасить цвет кнопки» сопровождался требованием «дизайн системы и десяток реальных проектов в проде» то сейчас тоже самвя работа подразумевает еще компетенции в исследованиях, анализе метрик, софт скиллов, знании корпп культуры, скорринге на эмоциональны интеллект, прохождение таролога и красивой презентации этих не встречающихся в реальной работе навыков и предлагает вдвое меньшую зп без учёта инфляции
Три варианта дизайна? Почему не десять?
Одна из самых горячих тем для компаний (как исполнителей, так и заказчиков), работающих с дизайном, — это количество вариантов.
Традиционно в нашей отрасли клиентам предлагают три варианта дизайна. На мой взгляд, это огромная ошибка, тянущаяся из диких времён — 90-х и начала 2000-х. Почему я так думаю?
Во-первых, перебор вариантов — это самый неправильный подход. Это значит, что заказчик не понимает, что хочет. А исполнитель не понимает, что делает. Не очень перспективное сочетание. Сейчас подходы изменились, исследовательская и проектная база проектов позволяет сделать сразу то, что нужно.
Во-вторых, ни одна студия и ни один дизайнер не делает всерьёз три равнозначных варианта. Это надо просто честно признать. Обычно делается один нормальный вариант, второй — так себе, третий — чтобы просто был. Это знают все: и дизайнеры, и менеджеры, и сами клиенты.
В-третьих, и это самое главное: три варианта — это логический тупик. Вот вы сделали три, и все они не подошли. Что дальше? Четвёртый вариант не включён в стоимость и начинается конфликт. Но самое главное то, что скорее всего ошибка была на этапе брифинга, во вводных данных или их передаче, возможно в исследовании. И чтобы это исправить, проект нужно начинать сначала. Либо клиенту придется доплатить, либо подрядчику работать бесплатно. Никакого винвина не получается.
Как должно быть?
Должен быть последовательный путь к решению. Если клиент хочет несколько вариантов, то они должны быть последовательными. Сделали один — показали, обсудили, поняли, что не так. На основе этой обратной связи — второй. Снова обсудили — третий точно попадет.При такой модели не попасть три раза подряд — практически невозможно.
Но мы в Nimax чаще всего используем другую практику — один вариант, но с максимально глубокой проработкой. Тщательно брифуемся. Проводим исследования если данных не хвататет. Проектируем или пишем стратегии. Проводим тщательную работу с референсами и ожиданиями на мудбордах. Показываем промежуточные направления и идеи. Делаем один финальный вараинт, который в 80% случаев принимается с первого раза, но всегда с правками.
С остальными 20-ю процентами разбираемся индивидуально. Если ошибка на нашей стороне — делаем новый полход за свой счет. Если ошибка на стороне клиента, то новая итерация за счет клиента.
Реже делаем два варианта силами разных дизайнеров, но на одной платформе. Для каждого из дизайнеров концепт один и он в него вкладывается всерьез. Здесь бывают неожиданные эффекты, иногда клиенты хотят использовать оба направления (для разных направлений бизнеса обычно) и это осложняет проект.
Ну и конечно, если клиент настаивает на нескольких вариантах — да, мы можем так сделать. Но считаем эту модель неправильной.
Успех не в количестве вариантов, а в продуманном пути к ним.
Ничего не будет: ни кино, ни театра, ни книг, ни газет (тестовых заданий) — одно сплошное телевидение (вайтборд)
Читать полностью…
а еще лучше не давать тестовые, потому что они плохо работают и для нанимателей, и для кандидатов)
Читать полностью…
Маргарита Хохлова в последнее время только и публикует находки из разных исследований, в основном связанных с текстом и интерфейсом: @microcopy — можно на неё подписаться
Читать полностью…
Егор, спасибо за комментарии — они очень ценны для меня, как автора статьи. Не факт, что я на 100% согласен с каждым из них, но в любом случае, каждый подкидывает дополнительных дровишек в топку моих размышлений на эту тему. По поводу достаточности контекста — это действительно один из пунктов, вызывающих у меня больше всего сомнений. Знаю за собой одну особенность — излишнюю многословность в письменном тексте, поэтому обычно пытаюсь ужать его до состояния маскимальной полезности для читателя при минимуме лишней информации. Иначе любой текст рискует распухнуть до того, что его будет сложно прочитать до конца. В данном случае контекст, о котором ты говоришь, посчитал нужным высушить до минимума. Но тут всегда вопрос золотой середины — как ее нащупать, каждый атвор решает сам, и возможно, ошибается. В любом случае, спасибо за ценный фидбэк! Постараюсь использовать его в будущем. 🤟
Читать полностью…
Интересный разброс.
По моему опыту найма, если соискатель долго ищет работу, значит он как-то не так себя подаёт, и щепотка невезения. В целом, все выше джуна могут быстро найти работу, если будут реалистичные требования
Наталия Бажан написала, как дизайнеру улучшить взаимодействие с разработчиками.
— Научитесь читать API и сразу его учитывать при проектировании. Это позволит не предлагать того, к чему не готов бекенд, или заранее понимать, когда придётся идти договариваться;
— Передавайте списки данных, необходимых для отображения проработанных вами состояний и кейсов, коллегам, отвечающим за тестовые данные. Сэкономите время разработчикам и скажете себе спасибо на дизайн-ревью;
— Привлекайте тестировщиков и бекендеров к ревью макетов;
— Описывайте даже то, что считаете очевидным. Дефолтное поведение компонентов может отличаться, как и мнение фронта. Не заставляйте его решать, как должен работать интерфейс;
— Расширяйте знания в том, как работает современный веб. Например, как работают серверная и клиентская сортировка, фильтрация, поиск, пагинация, как загружается и обновляется страница, как верстаются таблицы и так далее;
— Обсуждайте кейсы ошибок, предлагайте решения, фиксируйте в своей проектной документации, можно даже ставить задачи по обработке ошибок на бек. Особенно важно, если данные могут поступать из других сервисов или импортироваться из файлов;
— Используйте автолейауты, компоненты, переменные и не детачте инстансы, чтобы не костылить и зря не увеличивать сложность реализации. Подсвечивайте любые отступления от дизайн-системы.
#handoff
Вижу просьбу о совете. Дам один.
Неплохо было бы посмотреть на портфолио с примерами артефактов, которые получаются в результате работы.
Я бы добавила еще пункт:
- Не применяйте outline stroke без реальной на то необходимости. Иначе у иконки станет в несколько раз больше точек, что сильно удлинит ее путь в коде (а это дороже и разработчики могут поругать и придется переделывать 😁 )
Если бы Вертгеймер и Коффка знали, что их исследования лягут в основу работы с композицией в дизайне и в основу юикс-законов, а потом дизайнеры ещё будут интерпретировать гештальт-принципы группировки в интерфейсы — они бы просто офигели 😄
Читать полностью…
Может, есть какая-то конкретная проблема, с которой нужно помочь разобраться? Про фильтры можно много чего сказать или найти, как кто-то что-то о них сказал, но суть у них в базе очень простая: взять большое количество информации и показать её срез по заданным параметрам. Остальное — нюансы, связанные с контекстом.
Читать полностью…
Есть бюджет. Можно и пять разных вариантов пяти разных дизайнеров/команд.
Нет бюджета — один вариант. Возможно с доработками, возможно нет.
Это да, как чел говорил какой-то, мол, когда метрика становится целью она перестаёт быть ценной метрикой, потому что, ну блин, вот вам три дизайна просто, чтобы что? Чтобы было.
Читать полностью…
Илона Арзуманян написала об онбординге новичков в команду.
— Онбординг нужен, чтобы погрузить во все аспекты работы как можно быстрее и не взорвать его мозг;
— Один документ, где всё описано, лучше отдельных ссылок в мессенджере или проговаривания большого объёма информации;
— Включите в него, что нужно сделать в первые дни: ссылки на программы, инструкции по настройке и получению доступов;
— Соберите ссылки на полезные материалы: редполитика, брендбук, гайды по проведению исследований, работе с дизайн-системой;
— Навигация по проектам поможет найти макет или сценарий, когда сотрудник ещё плохо знает принципы хранения макетов;
— Важно донести структуру компании: кто чем занимается в разных командах, к кому с какими вопросами обращаться;
— В каждой компании есть особенности взаимодействия между отделами. Опишите процесс работы от планирования до релиза. По каждому этапу укажите нужные ссылки, файлы, контакты коллег;
— Подробнее опишите этапы работы именно дизайнера: работа в таск-менеджере, получение (обсуждение и уточнение) задачи, исследование и анализ, работа с библиотекой паттернов, графикой, текстом, исследованиями и дизайн-системой, ревью с дизайн-командой, лидом, продактом и бизнес-заказчиками, ревью на соответствие дизайн-системе, передача макетов и дизайн-ревью;
— Также полезно донести, что вы ожидаете от сотрудника в ближайшие 3 месяца, но это больше относится к процессу прохождения испытательного срока.
#management
Если я правильно понял, этот подход для создания заданий и оценки решений в формате вайтборда тоже подходит
Читать полностью…
Ещё Юля Кондратьева пишет о результатах исследований интерфейсов: @chem_dokazhesh
Читать полностью…
Так хотелось удержаться и похвалить Машу, которая потратила свое время, чтобы научить коммьюнити пользоваться пипеткой. Но все факты настолько банальные и избитые, неужели ничего нового не наисследовали в последние годы?
Читать полностью…
Поправлю: здесь речь не про собеседования, а именно про тестовые задания и обратную связь по результатам их выполнения.
По поводу контекста автора. Что даст ответ на вопрос, что это за компания, к какому рынку относится, было ли это связано с экономической ситуацией в компании?
По поводу роли. Кажется вполне очевидным, что такого рода задачами занимаются руководители, так как HR не оценивает результат выполнения тестового. И что это не основатель, так как когда компания становится достаточно большой для периодического найма продуктовых дизайнеров, основатели уже успевают нанять для этого руководителей.
Про количество нанятых дизайнеров — хороший вопрос, можно понять, насколько этот подход апробирован. Но причём тут пиковое количество собеседований? Подход не увеличивает и не уменьшает время, необходимое для того, чтобы изучить результат выполнения тестового задания. Он просто структурирует то, что руководители делают и так и позволяет прозрачно оценивать результаты соискателей.
«Среди компетенций, которыми должен владеть руководитель, есть такие» — как мне кажется, любой руководитель. Для этого не нужен контекст конкретно автора.
По остальным пунктам согласен, можно добавить конкретики и примеров, чтобы проиллюстрировать выводы.