Ищем Middle UX-редактора в команду Точки.

Точка Банк — финтех-компания, создаём онлайн-банк и другие сервисы для бизнеса.

📍От 150 000 ₽. Удалёнка или работа в офисе, мы есть в 20 городах по всей стране.

У нас комьюнити UX-редакторов, чётко прописанный TOV, гайды и библиотеки. Мы ждём, что редактор будет бороться за согласованность языка Точки в интерфейсах и всячески помогать в разработке сервисов.

Что делать:

— Писать тексты для продуктов: работать с интерфейсами, рассылками и сервисными сообщениями.
— Искать решения вместе с продактами, дизайнерами и UX-исследователями.
— Вместе с маркетологом создавать баннеры, рассылки, онбординги и другие промо-тексты для активации бизнес-карт.

Ты подойдёшь, если:

— Есть опыт работы UX-редактором от двух лет.
— Есть опыт работы с продуктами для предпринимателей.
— Понимаешь, как создаётся продукт, как решаются задачи продукта с помощью текста, как выстраивается работа с продакт-оунерами и дизайнерами.
— Знаешь, как следовать TOV в коммуникациях.

📝 Узнай больше и откликайся на сайте.

Читать полностью…

Егор Камелев написал, как минимизировать количество правок, подготовиться к оставшимся и работать с ними, чтобы легче сдавать проекты.

— Даже если вам стало предельно ясно, чего хочет заказчик, всё равно дослушайте до конца и выясните как можно больше деталей перед началом работы, чтобы максимально синхронизировать видение решения;
— Договоритесь о терминах. Сложные и неоднозначные понятия бывают и в вашей работе (что такое «прототип»?), и в специфике бизнеса заказчика («комплект» в интернет-магазине?);
— Сразу готовьтесь к правкам: осознанно и единообразно называйте страницы и разделы, повторяющиеся элементы превращайте в компоненты, пока не согласованы основы (например, состояния в статике), не уходите в детали (анимации и переходы);
— Покажите первые результаты как можно раньше, чтобы получить корректирующие комментарии к полуфабрикату и не переделывать потом «утку» в «кролика»;
— Показывайте столько, сколько можно изучить за один подход. Иначе заказчик будет присылать комментарии пачками, что растянет процесс и повысит вероятность противоречивой обратной связи. Такое допустимо в самом конце проекта;
— В этом случае заказчик или кто-то из команды может указать на что-то недоделанное: «Когда форма отправлена, надо показать сообщение об этом». Можно сказать, что вы так и собирались сделать, либо поблагодарить за идею. Так он станет причастным к финальному результату;
— Чтобы реже пересматривать собственные решения, сперва проработайте атомарные разделы, а потом то, что из них состоит. Карточка компании → список компаний (использует данные из карточки) → дашборд или главная;
— Конкретизируйте субъективную обратную связь, чтобы не проделывать напрасную работу. Задавайте уточняющие вопросы, показывайте референсы;
— Сохраняйте варианты, которые заказчик отмёл, чтобы было к чему вернуться, если концепция изменится и он передумает;
— Не бойтесь показывать рабочие варианты, которые вы сами отмели, чтобы заказчик увидел, что вы хорошо поработали. Иногда он может увидеть там что-то, что поможет быстрее прийти к нужному решению;
— Записывайте все комментарии, нумеруйте, показывайте, как каждый комментарий был отработан. Очень плохо, когда забытые комментарии замечает заказчик;
— Вам могут доверять как специалисту, вы можете быть убедительны, приводить цифры и факты, но ответственность за проект несёт заказчик. Хорошо, когда он чувствует, что получил именно то, что нужно.

#client

Читать полностью…

Сэм Либерти написал об ошибках внедрения геймификации.

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

In English. #gamification

Читать полностью…

У меня есть канал UX Work. Раньше там были вакансии, которые мне показались интересными. А теперь их будут разбавлять заметки с тезисами избранных материалов о карьере в UX-дизайне: поиск работы и найм (он же наём), прохождение собеседований и вайтбордов, грейды, прокачка, управление командой и так далее.

Уже вышли:
— Обзор возможных карьерных траекторий в дизайне;
— Рассказ в декорациях зомби-апокалипсиса о том, как дизайнеру организовать свою работу, чтобы развиваться и не выгореть;
— Как меньше ходить на созвоны;
— На что можно опереться при принятии решения о смене работы.

Подписывайтесь на @uxwork!

Читать полностью…

Картинка из UX Notes образца 2014 года, когда телеграм-канала ещё не было, а был паблик в ВК

Читать полностью…

В UX Feedback подготовили сборник кейсов по эффективной работе с метриками.

— Работать с метриками лояльности с одной стороны легко, так как есть правила, по которым можно настроить их сбор;
— С другой стороны, в разных ситуациях и отраслях есть своя специфика, которая требует креативности;
— Отдельная задача, если надо не только измерить, но и улучшить показатели;
— В сборник вошли истории, как команды Газпром Бонус, Aviasales, Fun&Sun, METRO и Вебзайм, с этим успешно справились;
— Кейсы: как поднять NPS на 29%, как эффективно запускать CSI и SUPR-Q, как визуализировать фидбек в виде тепловой карты, как сократить расходы на сбор обратной связи, почему клиентская лояльность напрямую влияет на выручку.

Реклама ООО «ФИДБЕК» ИНН 5030094661, erid 2VtzqxQc4YN

Читать полностью…

Виктория Друзенко написала о тексте плейсхолдера в поле поиска.

— Если это основная функция, можно написать призыв к действию: «Введите запрос»;
— Если лишь часть данных доступна для поиска, перечислите их: «Трек, альбом, исполнитель»;
— Если поиск ограничен определённым разделом, обозначьте его: «Поиск по каталогу»;
— Если к запросам в поле поиска нет жёстких требований, обозначьте направление: «Куда отправимся»;
— Если вариантов поиска много, и пользователь не знает, как можно сформулировать запрос, напишите примеры: «Искать от холестерина, омега 3, Витамин Д»;
— Если нужен минимализм или поиск не основная функция: «Поиск», «Найти».

#search #writing

Читать полностью…

Наталия Бажан написала, как дизайнеру улучшить взаимодействие с разработчиками.

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

#handoff

Читать полностью…

Женя Арутюнов, Аня Худякова и Света Светликова написали об особенностях восприятия и принципах гештальта с большим количеством примеров.

— При восприятии любой формы мы заполняем пробелы, достраиваем формы до целостного образа, стремимся «закрыть гештальт»;
— Цветовые пятна, регистрируемые сетчаткой глаза, мы воспринимаем как объекты и фон;
— Расположенные рядом объекты формируют группу и ощущаются связанными (Бирман о принципе близости в интерфейсах: раз и два);
— Совместное движение группирует объекты даже сильнее (активно используется в интерфейсах);
— Также мы группируем объекты по визуальному сходству (подобию). Близость и подобие могут конкурировать;
— Объекты в виде непрерывной цепочки образуют устойчивую целостность. Непрерывность сильнее близости;
— Если объекты расположены в форме замкнутой фигуры, это создаёт новую целостность. Разрывы в фигуре будут мысленно достроены. Фигура сильнее фона и частей, из которых она состоит;
— Сюда можно отнести и способность видеть объёмные объекты за счёт светотени и искажений перспективы;
— Как бы ни были сильны эти эффекты, наибольшую роль в интерпретации увиденного играет опыт. Например, способность увидеть мяч вместо 6 пятиугольников;
— Что-то мы научились узнавать не лично, а как вид. Например, видеть лица, живое в неживом (парейдолия). Это повышало шансы выжить;
— Принципы гештальта не получится использовать как композиционный инструмент или метод проектирования. Скорее это способ оценить, что получается.

#psychology

Читать полностью…

Юля Кондратьева написала, как снизить боль от расставания с деньгами во время оплаты (со ссылками на результаты экспериментов).

— Люди с большей вероятностью покупают нездоровую пищу, если платят картой, а не наличными;
— Чем больше человек обращает внимание на отдаваемые деньги, тем сильнее боль от расставания с ними;
— Если цена не является решающим фактором, её делают максимально незаметной в карточке товара. Пример: премиальные бренды одежды;
— Если цена является преимуществом, стоит сделать акцент на ней на этапе выбора, а на этапе покупки (в корзине) — не выпячивать (меньший размер и максимально привычный шрифт);
— Иногда цену крупно показывают после оформления заказа. Для повышения вероятности повторного заказа лучше сделать акцент на выгодах покупки;
— Если покупатели могут покрутить барабан и получить разные скидки с определённой вероятностью, они тратят на 54% больше, чем с обычными фиксированными скидками;
— Формулировка «20% шанс заплатить $40» работает намного лучше, чем «20% шанс на скидку $20»;
— Люди тратят больше (особенно на бесполезные штуки), если чувствуют поддержку социума. И деньги, и социальная поддержка — это безопасность. Можно потратить больше денег, если это компенсируется.

#price

Читать полностью…

Даша Почекуева написала, как дизайнеру влиять на продукт на стратегическом уровне.

— Проблема: постоянный поток небольших рутинных задач, закрывающих боли здесь и сейчас без долгосрочного плана, понимания, куда всё движется;
— Стратегическое мышление у дизайнера — это 1) видеть будущие задачи, 2) фокусироваться не на интерфейсе, а на незакрытых болях, масштабировании, адекватности продукта рынкам и целям, 3) подниматься от макета или сценария на уровень порождаемых рисков и возможностей, 4) не преувеличивать ценность дизайна там, где она невелика, 5) мыслить большими отрезками времени, чем спринт или даже квартал;
— Это надо, если вы долго работаете в продукте (2+ года), видите его системные боли, выходите за границы своей ответственности (делаете концепты, предлагаете что-то, что команда не планировала), думаете, что это надо только вам и качаете навыки презентации и убедительности, чтобы продавать своё видение;
— Не в этих навыках дело. В какой-то момент дизайн-карьеры даже самые классные презентации не так уж сильно повышают шансы продать идею;
— Не надо приносить идеальное решение проблемы (оно не будет идеальным, так как всего предусмотреть нельзя), надо делиться опытом, прикидывать риски и возможности, сильные и слабые стороны, предлагать варианты;
— «Вот наши проблемы, вот наша с тобой экспертиза, давай вместе придумаем, как быть»;
— Ищите партнёров, но не среди своих руководителей или подчинённых, у них о другом голова болит. Подойдут бизнес-заказчики, продакты, CPO (обогатят своим опытом), дизайнеры вашего уровня (облегчат ваш труд);
— Они должны быть заняты долгосрочным развитием продукта и иметь возможность решать, куда двигаться;
— Убедитесь, что у вас похожие устремления, предложите раз в 1–2 недели встречаться для обмена новостями и планами, помогайте своей экспертизой, устраивайте совместные брейнштормы, наблюдайте и впитывайте: какой у партнёра фокус, что ему важно, какими инструментами пользуется;
— Не торопитесь. На создание почвы для партнёрства может уйти и полгода, и год.

Читать полностью…

Андрей Шапиро написал о придуманной им Карте реализации историй.

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

Видео о карте: ВК, Рутуб, Ютуб. #user_story

Читать полностью…

Дмитрий Ваницкий написал, как проектировать, чтобы вызывать и сохранять у пользователей состояние потока.

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

Читать полностью…

Ваня Серебренников написал serebrennikov/IBEszUMLUJN">о применении фреймворков для решения сложных задач.

— Использование фреймворков и инструментов без понимания, зачем они нужны, — карго-культ (так можно легко опознать джуна);
— Вопросы, без ответов на которые задачу не решить: зачем, кто, что, как, когда;
— Отвечать на них можно в любом порядке. Лучше начинать с «Зачем», но Иван часто начинает с «Кто», чтобы понять, у кого спрашивать;
— Каждый фреймворк помогает частично или полностью ответить на один или несколько таких вопросов;
— Например, Mental models отвечает на «Кто наши пользователи?», а Stakeholder map — на «Кто наши стейкхолдеры и как с ними работать»;
— «Зачем» — фильтр для всего, что мы делаем. Аргументы на этом уровне хорошо понимает бизнес. User story map помогает увидеть, на каком этапе взаимодействия находится фича, и определить её приоритет;
— «Что» — что именно надо сделать и что получат пользователи: описания фичей, макеты, Userflows;
— «Кто» — важно не просто понимать, «Кто», но и «Какие они»;
— Карта стейкхолдеров показывает, на какие группы их разделить и как с ними работать: Inform, Show consideration, Keep satisfied, Work together;
— Возможно, артефакты JTBD потребуются только для того, чтобы конкретные участники увидели, что на этот раз всё по-науке, а не на коленке;
— «Как и когда» — в сложных задачах могут появиться вопросы вроде «Как собрать требования» и «Как вообще выстроить процесс». Здесь Scrum, Agile, Design Thinking и так далее;
— Полезные процессы стоит добавлять постепенно. К каким-то изменениям и практикам команда может быть ещё не готова;
— Внедрение идёт проще, если выделить проблему команды или бизнеса и принести одну из практик в качестве решения;
— Берите фреймворки как есть и пробуйте применять. Лучше в тепличных условиях, без дедлайнов и жёстких требований к результату — иначе трудно учиться, рефлексировать и делать выводы;
— Уже после максимального освоения и практического применения со стабильным результатом фреймворк можно переделывать под себя, скрещивать с другими подходами и так далее.

Читать полностью…

Роман Черных написал, почему роль бизнес-аналитика устарела.

— Раньше он переводил расплывчатые пожелания бизнеса в технические требования;
— Например, в ответ на запрос «автоматизировать отдел продаж» собирал требования, документировал процессы и создавал спецификации с диаграммами вариантов использования;
— Сейчас недостаточно переводить запросы (фиксировать требования), надо проектировать продукты, которые решают проблемы пользователей и приносят прибыль;
— Этим совместно занимаются разные специалисты от продакта (определяет, что именно делать, например, зачем автоматизировать отдел продаж?) до системного архитектора;
— Бизнес-аналитик может стать продакт-менеджером, если ему ближе рыночный анализ, формирование идеи продукта, стратегии и метрики;
— Либо UX-аналитиком, если ближе исследование поведения пользователей и тестирование гипотез;
— Либо системным аналитиком, если ближе технические детали и понимание того, как работает система.

Читать полностью…

Виктория Друзенко написала о прокачке UI.

— Навыки UI-дизайна могут просесть, если долго работать с дизайн-системой на одном продукте;
— UI Daily может не подойти, так как макеты там оторваны от контекста, и надо тратить время на его додумывание;
— Переделывайте макеты из своих старых проектов. Подойдут даже макеты с предыдущего спринта;
— Так вы увидите свой прогресс, можете пересмотреть решения и улучшить UX, не будет ограничений со стороны заказчиков и разработки, а результат можно положить в портфолио;
— Анализируйте чужой дизайн, выделяя удачные и неудачные решения, предлагайте альтернативы;
— Публикуйте свои наблюдения там, где другие дизайнеры могут их увидеть и обсудить, это даст обратную связь;
— Так вы научитесь давать обратную связь, прокачаете насмотренность;
— Вовлекайте коллег, знакомых дизайнеров, менторов;
— Помимо того, что так веселее, будет больше обратной связи, можно перенять чужой опыт, сложнее слиться с прокачки;
— Перерисовывайте понравившиеся макеты;
— Так ваша база UI-решений будет расти. Вы будете не только знать разные визуальные ходы, но и уметь их воспроизвести;
— Можно попробовать новые инструменты для оптимизации работы. Если надо перерисовать экран, стоит подумать, как сделать это быстрее и качественнее.

#visual #upskilling

Читать полностью…

Фёдор Миронов написал, как использует Crowdin для перевода текста в интерфейсе.

— Если передавать переводчикам просто текстовые строки без сведений, где они используются и как выглядят, будут ошибки и неестественные формулировки;
— Надо хорошо постараться, чтобы в процессе перевода не было бардака, особенно если работает несколько переводчиков;
— Crowdin хранит идентификаторы строк (ключи), все переводы, их статусы, теги принадлежности к платформам;
— При загрузке текста из Фигмы делает скриншоты и отмечает, где находится текстовая строка, что позволяет переводчику понимать контекст;
— Переводчики могут начинать работу сразу, не дожидаясь готовности макета и вёрстки;
— Плагин Crowdin в Фигме синхронизирует текст и позволяет дизайнеру просматривать переводы прямо в Фигме;
— Перед передачей макетов в разработку дизайнер запускает плагин и создаёт ключи;
— С помощью Select Matching Layers выделите повторяющиеся текстовые слои и переименуйте их, указав предполагаемые ключи. Плагин найдёт дубликаты и свяжет повторяющийся текст с одним ключом;
— Не используйте один ключ для заголовков и текста на кнопках. Они могут совпадать на английском (Transfer/Transfer), а на русском отличаться (Перевод/Перевести). У каждой текстовой роли в интерфейсе должна быть отдельная строка;
— Если в строке есть переменные данные (суммы, даты, имена), не разбивайте строку на части, а используйте переменные. Строка останется целостной и понятной для перевода. Это важно, если порядок слов в переводах может отличаться.

#localization #сrowdin

Читать полностью…

26 июня в 15.00 мск пройдет онлайн митап «МойОфис Frontend&UX Talks. Практические решения для сложных интерфейсов в 2025 году: от кода до дизайна».
Фронтенд и UX в 2025 году — какие подходы работают на практике? Разберём на реальных кейсах от МойОфис, Контур, Alfa Research Center, Лаборатории Касперского.
Разберем актуальные подходы к созданию сложных интерфейсов. На реальных кейсах расскажем, как решать современные задачи UX и фронтенда.

В программе:
- Михаил Проскурин покажет, как работать с темизацией на примере мультипродуктовой дизайн-системы МойОфис: сохранять единство при множестве продуктов и обходить ограничения Figma по количеству тем.
- Кнарик Джавадян и Светлана Самойленко из команды настольных редакторов МойОфис поделятся опытом безболезненного редизайна — как полностью обновить интерфейс редакторов документов, ничего не сломав.
- Антон Бессонов (Alfa Research Center) объяснит, зачем нужны сложные методики исследований и как их применять на практике.
- В начале митапа Павел Востриков из «Лаборатории Касперского» (соорганизатор MoscowJS) расскажет о новых возможностях CSS, которые влияют на современную разработку и дизайн.
Все темы докладов и спикеров можно посмотреть в расписании.

Для кого это?
✔️Дизайнеров, стремящихся глубже понимать технические аспекты реализации интерфейсов
✔️Фронтенд-разработчиков, которые создают не просто код, а удобные интерфейсы
✔️Продуктовых специалистов, следящих за развитием индустрии
Это не просто доклады — разбор реальных кейсов, живые обсуждения и ответы на вопросы. Присоединяйтесь, чтобы перенять практический опыт и найти новые идеи для своих проектов!

Регистрация здесь

Чат участников здесь — чтобы не пропустить новости и задавать вопросы спикерам

Реклама ООО "НОВЫЕ ОБЛАЧНЫЕ ТЕХНОЛОГИИ" ИНН: 7703807270 erid: 2W5zFGWK71i

Читать полностью…

Андрей написал, почему творчество нельзя подменять креативностью.

— Креативные методологии (фреймворки для быстрого создания новых идей) — узкий инструмент с кучей ограничений, и подменять им творчество нельзя;
— Все они работают примерно так: некий объект раскладывается на составляющие → проводится работа с этими частями (что-то убрать, поменять, добавить, набор операций ограничен) → собирается новый объект;
— Их подают как последовательность действий, переключающих мозг на дивергентное мышление, что даже полезно;
— Постфактум можно увидеть, как эти действия привели к созданию каждой успешной идеи, но просто выполняя эти действия нельзя быть уверенным, что они приведут к успешной идее. Успех зависит от кучи других факторов;
— Творчество начинается с повторения, выработки навыков;
— Затем действия складываются в системы: технологии и методологии. Уже не нужна директивность, задачи объединены в последовательности, которыми человек и оперирует;
— Владея несколькими методологиями, можно выбирать более подходящие и комбинировать их. Это профессиональный кругозор;
— Затем становится доступна творческая деятельность: изобретение новых инструментов, подходов, идей. Это работа уровня RnD-отделов компаний;
— Креативные методологии позволяют получить много поверхностных идей, не сильно в них погружаясь. Годится для маркетинга, но в других сферах работает плохо;
— Создаётся иллюзия, что творчество — это легко и быстро. Но это одна из самых тяжёлых деятельностей: на час брейншторма можно потратить больше сил, чем на полный рабочий день;
— Если заниматься этим постоянно в рамках операционной деятельности, можно выгореть;
— Ломается нормальный процесс набора опыта. Люди занимаются чем-то другим вместо расширения профессионального кругозора, изучения предметной области и системных вещей;
— А ведь только это может привести к прорывным идеям, когда большая часть из них уже сгенерирована и реализована, и требования к продуктам уже не такие, как раньше.

#process

Читать полностью…

Как начать работать с цветом осознанно — и перестать подбирать палитры наугад? 🎨

Цвет в интерфейсах — это не просто «вкус» или интуиция. Это инструмент: он управляет вниманием, помогает считывать структуру, задает настроение. И влияет на то, насколько «дорого» и профессионально выглядит ваш макет.

📅 19 и 20 июня пройдет бесплатный интенсив по цвету в UX/UI. За два вечера разложим все по полочкам — от теории до практики.

Что будет:

✔️ Как устроена логика цвета: контрасты, насыщенность, психология восприятия
✔️ Почему одни палитры смотрятся грязно, а другие — чисто и дорого
✔️ Приемы, которые помогут вам уверенно работать с цветом в любом проекте
✔️ Практика и обратная связь — чтобы закрепить результат

➡️ Зарегистрироваться на интенсив

Реклама. ИП Кузьмин Е.Л. ИНН: 634502641730, erid: 2VtzqwddEBQ

Читать полностью…

Рамазан Нурулаев написал о дизайне таблиц для цеха.

— Тонкие шрифты — мимо. Числа должны читаться даже в маске сварщика. Для цифр — моноширинный шрифт;
— Почти всегда нужна тёмная тема;
— Минимум цветов. Новый цвет — только чтобы привлечь внимание к критичным вещам;
— Системная цветовая индикация, которую нельзя изменить: зелёный — всё хорошо, жёлтый — обратить внимание, красный — что-то случилось;
— Есть дополнительные цвета, которые можно назначить выбранным статусам (или переназначить под себя);
— Рекомендации по выбору цвета есть в сторибуке: «фиолетовый для специальных режимов работы»;
— Пользователи попросили добавить легенду во все формы, где есть цветовая индикация;
— Заголовки столбцов были менее контрастными, чем их содержимое, но они плохо считывались. Сделали их контрастнее, а чтобы отделить от цифр, поменяли шрифт;
— Таблицы почти никогда не прокручивают (особенно, по горизонтали), поэтому они должны быть максимально компактными, но не сливаться в кашу;
— 40 px основная высота строки, 56 px — увеличенная, 32 px — компактная. Надо учитывать, что в них могут быть иконки и кнопки;
— Нужна возможность настраивать их под себя: скрывать столбцы, закреплять, менять их порядок;
— Иногда можно заменить заголовки столбцов на более компактные: «Положение плавки» → «Плавка»;
— Чтобы уменьшить визуальный шум, кнопки действий отображаются при наведении на строку. Пользователь примерно понимает, какие действия ему надо совершить;
— Чтобы было понятно, какие ячейки можно редактировать, в них есть кнопка редактирования. Ячейки с отредактированными данными подсвечиваются жёлтым.

#table #industrial

Читать полностью…

Павел Шерер написал о терминах 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

Читать полностью…

Виктор Теплов рассказал, как работать с иконками в Фигме. А я немного дополнил из других источников.

— Иконку преобразуйте в векторную форму (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

Читать полностью…

Игорь Штанг написал, почему разряжают слова, набранные прописными буквами.

— В металлическом наборе площадки букв могут максимально прижаться друг в другу, из-за чего буквы просто невозможно поставить ближе. Из-за этого пробел между Р и Д в слове СЕРДЦА может оказаться слишком большим;
— В цифровом наборе такого ограничения нет;
— Проблему с Р и Д можно решить настройкой межбуквенного пробела (этот процесс называется кернингом). Но в случае с Ц и А этому мешает форма букв;
— Из-за таких пар прописной набор принято разряжать, чтобы скрыть неравномерности в межбуквенных пробелах;
— Не всем шрифтам это подходит. Насыщенные и узкие шрифты с небольшими внутрибуквенными просветами выглядят лучше в плотном наборе (с небольшими межбуквенными пробелами).

Копия в Медиуме. #typography

Читать полностью…

В TypeType написали об OpenType-фичах шрифтов.

— В одной гарнитуре может быть несколько форм одной и той же буквы. Иногда их добавляют ради красоты, иногда с определённой целью. Например, вариант строчной буквы эль «l» с хвостиком полезен в навигации, чтобы её не путали с прописной ай «I»;
— Альтернативы отдельных букв со схожими стилистическими решениями объединяют в стилистические сеты. Применив сет можно, например, превратить нейтральный гротеск в мягкий или поменять форму точки с квадратной на круглую для всех знаков, где она есть;
— Лигатуры — знаки, образованные путём соединения нескольких глифов. Бывают стандартными (например, из практических соображений соединяют fi, fl, ff, ffi, ffl, ft) и дискреционными (могут быть самыми разными, если шрифтовик увидел в этом практический или эстетический смысл);
— Цифры часто бывают в виде дробей, числителей и знаменателей (из них составляются дроби), надстрочных и подстрочных индексов, табулярных цифр (одинаковая ширина у всех цифр), в залитых и пустых кружках, старостильные цифры;
— Почти во всех современных шрифтах есть базовые иконки и другие необычные символы, сочетающиеся со шрифтом. Иногда можно сэкономить на отрисовке нужной графики;
— Сеты локализации (иногда включаются через стилистические сеты). Например, болгарская локализация для кириллицы;
— В Фигме стилистические сеты можно включить через панель Text → Type Settings → Details;
— Список всех фич обычно публикуют в спесимене на сайте, где шрифт продаётся.

Лекция «Скрытые возможности шрифта». #font

Читать полностью…

Суббота, Питер, лучшее мероприятие для создателей инженерных продуктов! 😉

24 мая в Санкт-Петербурге состоится конференция «Просто Сложно», посвященная дизайну и исследованиям инженерных продуктов. Просто расскажем, как сложно дается разработка интерфейсов инженерных и промышленных систем. Присоединяйтесь!

✔️ Разберёмся, зачем дизайнеру понимать задачи инженера
✔️ Узнаем, как создаются удобные и эстетичные высоконагруженные интерфейсы
✔️ Обсудим, как ИИ меняет работу и пользовательский опыт инженеров

Выбирайте оптимальный вариант участия: очно в Технохабе Сбера или онлайн, и готовьтесь к встрече с экспертами Сбера, Т-банка, ВК, Wildberries и Газпромнефти!

Читать полностью…

Давайте поговорим о культе метрик и к чему он может привести.

Если на вопрос «а нахуя» вам отвечали «так показала аналитика» или в своих продуктах вы были вынуждены повышать какую-то нелепую (по вашему мнению) метрику, то этот пост для вас.

За последние 10-20 лет в IT аналитика стала решающим фактором в принятии продуктовых решений. Дашборды, отчёты, графики и схемы — это то, на чём мы строим свои продукты. Это не плохо, данные для того и нужны, чтобы их анализировать.

Но частенько мы даже в мыслях не допускаем, что наши дашборды могут врать. Что одна метрика, возведённая в ранг культа, может если и не похоронить всю компанию, то как минимум сделать противоположное своему назначению.

Давайте я приведу несколько примеров:

В 2015-2017 Facebook убеждал медиа «переходить на видео», показывая им астрономические показатели Average Watch Time и Video Views. Позже в суде оказалось, что ребятишки малость погорячились (до 900% по данным иска) и Facebook знал об этом больше года. Издатели уволили сотни текстовых редакторов, вложились в видеопродакшн, но получили только просадку по баблу. В итоге Facebook выплатил $40 млн компенсации рекламодателям, а понятие «pivot to video» стало мемом.



В 2010 году соц-новостник Digg решил угодить издателям: в четвёртой версии приоритет отдали автопостам медиа, а не голосам пользователей. Через неделю комьюнити устроило «Quit Digg Day» и дружно съебало на Reddit. Трафик Digg рухнул на 25% за месяц, а к 2012-му — на 90%. Команду урезали, компанию продали за копейки. Метрика «объём партнёрского контента» стала главенствовать, и комьюнити просто вышло из чата. 



В 2018 Snapchat решил поднять Time in App, и расхерачил интерфейс, как ты свой палец с заусенцем: разделили чаты и сторис, усложнили навигацию. Пользователи взбунтовались, петицию против редизайна подписали 1.2 млн человек, сервис впервые потерял 3 млн DAU. Акции просели на 20%, и компания врубила заднюю. Я прям вижу, как топы спускают «надо поднять минуты в приложении», а дизайнеры «хуйня вопрос, усложним UX»

Да, там было не всё так просто, но это — большие, публичные компании. Сколько таких проёбов было у компаний помельче?

Следование одной понятной и легко измеримой метрике — это классический пример туннельного зрения. Почти всегда продукт сильно шире одного показателя. Цифры должны служить, а не командовать.

Что делать на практике?

1. Держите пул из 3–5 метрик: рост, удержание, качество, выручка, удовлетворённость и тп. Не выделяйте одну, стройте иерархию. Если нижняя метрика растёт, а верхние нет, то должны возникнуть вопросики.

2. Валидируйте данные. Стройте контрольные отчёты, проверяйте формулы, смотрите срезы. Важно построить процессы таким образом, чтобы каждый показатель подтверждался другими.

3. Ставьте «гвардейцев» — вторые метрики, которые тормозят злоупотребления (например, NPS к Time in App). Это позволит вовремя очнуться, даже если «зависимые» метрики не ведут себя подозрительно.

4. Слушайте пользователей: юзтесты, саппорт, соцсети. Не только цифры в дашбордах, но и реальные отзывы.

Я для себя обычно разбиваю показатели на 3 слоя:

1. North Star (LTV/CAC, валовая маржа). Это то, к чему идёт продукт и компания. На короткой дистанции их толком не посчитаешь.

2. Здоровье продукта сегодня (конверсия оплаты, churn). А вот это как раз можно измерять если и не в моменте, то почти.

3. Пульс системы (5xx ошибки, latency, аптайм). Это чаще технические метрики, от которых зависит качество продукта.

Важно: все эти слои не изолированы, а связаны сквозной аналитикой. Потому что поклонение какой-то одной цифре — это как минимум глупо

Читать полностью…

Юля Кондратьева написала, как помочь пользователю ждать (со ссылками на результаты экспериментов).

— Во время загрузки даже незамысловатый контент повышает время, которое пользователь готов ждать. Загрузки экрана с логотипом ждали на 1 секунду дольше, чем пустого экрана;
— При 10-секундном ожидании анимированный персонаж вместо прогресс-бара уменьшает воспринимаемое время ожидания на 1 секунду, а люди оценивают опыт на 1 балл выше. Но для 5- и 2-секундного ожидания прогресс-бар лучше;
— В развлекательных приложениях лучше работает энергичная анимация (например, персонаж куда-то летит). В полезных — медленная (персонаж расслабленно крутит обруч);
— В цифровой среде ожидание обычно меньше минуты. Лишняя информация о процессе ожидания привлекает к нему ненужное внимание. Поэтому пустой экран может быть лучше лоадера: в тесте из первого абзаца загрузки пустого экрана ждали на 1,5 секунды дольше, чем экрана со спинером;
— Прогресс-бар, быстро заполняющийся до 70% и затем замедляющийся, уменьшает воспринимаемое время ожидания лучше тех, которые заполняются равномерно или ускоряются в конце;
— Attentional Gate Model: счётчик ожидания запускается тогда, когда мы обращаем на него внимание. Чем больше мы уделяем ему внимания, тем дольше кажется событие. Поэтому лучше отвлекать человека от идеи ожидания и не показывать связанные с ней прогресс-бары (если это не длительное ождание).

#loader

Читать полностью…

Открытый вебинар о новых границах ответственности CX/UX-исследователей 13 мая

В преддверии курса по CX/UX-исследованиям RADAR.Школа проводит еще один бесплатный вебинар, посвященный теме ответственности CX/UX-исследователей: в каких случаях исследователь может проявить инициативу и помочь дизайнеру, редактору, продакту. А когда сам лидер продукта должен взять на себя роль исследователя.

Юрий Шеваров, CX/UX Lead, Ex-СберБанк, и Дарья Сергеева, коммуникационный стратег Яндекс Недвижимость, подготовили два больших кейса из личного опыта в Сбере и Яндексе, чтобы обсудить, где и как могут проходить границы этой ответственности.

Спикеры:
Юрий Шеваров, CX/UX Lead. Ex-СберБанк, Хоум Кредит Банк, RADAR.
Дарья Сергеева, Коммуникационный стратег Яндекс Недвижимость. Ex-Lead UXW Сбер.
Формат: Zoom-вебинар
Дата и время: 13 мая 2025, 19:00 МСК
Учаcтие бесплатное, необходима регистрация

Реклама ООО «Исследовательская компания Радар», ИНН 7708651203, erid 2VtzqxRXCMh

Читать полностью…

Сана Бехнам и Ралука Будию написали uxteddy/WwujNzNrfQ3">о дополненной реальности.

— AR-функции должны добавлять ценности. В приложении Google Arts & Culture известные картины можно повесить в своей гостинной, но нельзя рассмотреть в деталях. Зачем?
— В электронной коммерции важны реалистичность товара и правильный масштаб. Если не можете их обеспечить, лучше отказаться от использования AR;
— Если в каталоге есть карточки товаров с AR-функциями, добавьте соответствующий индикатор в список товаров и параметр фильтрации;
— Отмечать товары с AR-функциями лучше не иконкой, а текстом. Пользователи чаще всего не понимают метафор, которыми дизайнеры обозначают AR;
— Учитывайте контекст: не предлагайте читать текст, если человек должен находиться на расстоянии от устройства. Используйте аудиоинструкции, взаимодействие жестами (взмах или поднятие руки для начала);
— Аудиоинструкции позволяют сосредоточиться на объекте, не перенося взгляд на текстовое описание;
— Подумайте, кому AR-опыт может не подойти, и предупредите таких пользователей. Например, для визуальной примерки теней для век надо снять очки. Некоторые пользователи не могут смотреть в экран без очков;
— Инструкции и варианты взаимодействия лучше давать последовательно, шаг за шагом;
— Убедитесь, что инструкции и элементы управления хорошо видны на разном фоне. Можно использовать плашки со сплошной заливкой;
— Предусмотрите возможность внесения корректировок в объект и получения полезной информации, не выходя из AR-режима. Например, смена цвета, замена на похожий объект, отображение размеров;
— Но всё это должно занимать как можно меньше места на экране, чтобы не мешать изучению объекта и перемещению его по сцене.

In English. #ar

Читать полностью…