UX Notes
В соцсетях: vk.com/ux_notes и fb.com/uxnotes Чат читателей: @uxnoteschat О карьере в UX-дизайне и вакансии: @uxwork Рекламодателям: uxnotes.ru/ads · В перечне РКН: gosuslugi.ru/snet/67a9a56970de7b4d761a81ae Est. 2016 · Автор: @zGrav
Show more📈 Analytical overview of Telegram channel UX Notes
Channel UX Notes (@uxnotes) in the Russian language segment is an active participant. Currently, the community unites 24 074 subscribers, ranking 1 221 in the Art & Design category and 27 669 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 24 074 subscribers.
According to the latest data from 02 July, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -63 over the last 30 days and by -6 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 11.03%. Within the first 24 hours after publication, content typically collects 5.33% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 655 views. Within the first day, a publication typically gains 1 284 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 13.
- Thematic interests: Content is focused on key topics such as интерфейс, макет, ревью, строка, артефакт.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“В соцсетях: vk.com/ux_notes и fb.com/uxnotes
Чат читателей: @uxnoteschat
О карьере в UX-дизайне и вакансии: @uxwork
Рекламодателям: uxnotes.ru/ads · В перечне РКН: gosuslugi.ru/snet/67a9a56970de7b4d761a81ae
Est. 2016 · Автор: @zGrav”
Thanks to the high frequency of updates (latest data received on 03 July, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Art & Design category.
Data loading in progress...
| Date | Subscriber Growth | Mentions | Channels | |
| 03 July | +4 | |||
| 02 July | +3 | |||
| 01 July | +8 |
| 2 | «Передумал», «Не буду оплачивать», «Давайте добавим ещё задач» — такие ситуации проще обсуждать, когда условия заказа зафиксированы заранее.
На Авито Услугах развивается более безопасный и защищённый сценарий взаимодействия между заказчиками и исполнителями. По их данным, 48% клиентов называют защиту условий сделки своим приоритетом.
Для дизайнеров, бухгалтеров, финансистов, копирайтеров, маркетологов (от SMM до работы с блогерам) и других специалистов из сферы деловых услуг доступен сервис «Защита сделки» при поддержке Авито Услуг. Он помогает заранее договориться об объёме, сроках и стоимости заказа, а оплату – зарезервировать до подтверждения результата со стороны клиента.
Что даёт «Защита сделки» исполнителю:
*️⃣Фиксирование условий: клиент не сможет потребовать больше, чем обсуждалось на старте
*️⃣Полная оплата: вы получите оплату, если выполнили всё в рамках зафиксированных условий
*️⃣Защита от риска отказа в последний момент: заказчик уже внёс деньги на спецсчёт и заинтересован в том, чтобы довести дело до конца
*️⃣Независимые арбитры: в спорных ситуациях подключатся арбитры, которые могут помочь разрешить ситуацию
Подключить «Защиту сделки» можно при создании нового объявления на Авито Услугах или редактировании существующего. Подробности о сервисе можно узнать по ссылке.
От себя ставим ❤️ за инициативу! | 1 518 |
| 3 | Евгения Шамрай написала, что профессия дизайнера интерфейсов в привычном нам виде скоро исчезнет.
— Экраны в Фигме — удобные, приятные визуально, с адаптивными состояниями, собирающиеся в сценарий — раньше сами по себе представляли ценность;
— Клиенты приходили за ними к дизайнерам, потому что других вариантов особо не было. Сейчас альтернативы предлагает ИИ;
— За последние 1,5 года клиенты не покупают дизайн интерфейса;
— Приходят за аудитом, аналитикой, исследованием, пониманием пользователей, поиском проблем в продукте, разбором сценариев, редизайном бизнес-процессов, стратегией развития продукта;
— Интерфейс появляется где-то в конце такой работы и не является основной её ценностью;
— Основная ценность — в ответах на вопросы вроде: «Почему пользователи не доходят до целевого действия?», «Почему сотрудники обходят систему с помощью Экселя?», «Почему заявки есть, а продажи не растут?», «Почему люди не доверяют продукту?», «Почему новые пользователи не понимают, что делать дальше?»;
— Главное — понять, какой интерфейс вообще нужен. Может оказаться, что проблему вообще не решить новым дизайном;
— Будет падать спрос на дизайнеров интерфейсов и расти спрос на тех, кто умеет понимать клиентский опыт целиком;
— UX, UI, исследования, аналитика и AI сольются в одну роль.
#definition | 1 691 |
| 4 | Yandex for TechnoCreative — канал для дизайнеров, продюсеров, маркетологов, бренд-менеджеров и всех, кто использует технологии для креативов и оптимизации.
Что внутри:
〰️ Кейсы яндексоидов — как в Yango сделали натуралистичный ролик про Эфиопию с помощью AI
〰️ Механики и лайфхаки по избавлению от рутины – как CTO Яндекс Карт Толя Панов систематизирует личную базу знаний
〰️ Истории и мнения экспертов из мира креативных технологий — статья Арсения Попова о креативном мышлении в эпоху AI
〰️ Вакансии Яндекса для креативных специалистов.
Подписывайтесь, будет еще интереснее!
Реклама. ООО "Яндекс". ИНН 7736207543 erid: 2VtzqvfBhrR | 1 855 |
| 5 | Знаете, от чего прям противно? Вот эти вот прогрессбары, которые движутся не от настоящего прогресса, а с предзаданной скоростью. Типа, чтобы пользователь не пугался.
В чем вообще идея прогрессбара? Вот у тебя есть N файлов, ты скопировал M из них, и показал на прогрессбаре M / N × 100%. Ну и ты видишь, сколько работы сделано, а сколько осталось. Некоторые прогрессбары даже время примерное до конца показывали!
Потом люди заметили, что иногда прогресс неравномерен. Например, с теми же файлами, большой файл копируется дольше, а прогресс мы считаем по количеству. Тогда на большом файле 1% прогресса будет продвигаться дольше, чем на маленьких. Или скачивание из интренета, там вообще непредсказуемо. Если ты начнешь тут считать время, оставшееся до конца, оно у тебя будет плясать — 30 секунд, полдня, неделя, о, снова 30! Пошли сразу шутки, про 99%, про квантовую природу прогрессбаров и так далее.
Но — что важно — отображаемый прогресс был связан хоть с чем-то реальным! Можно было поставить курсор мыши на текущее положение, и если оно через 15 минут сдвинулось, значит программа еще что-то делает, а не зависла.
Понятно, что прогресс можно предсказать не всегда. Какая-нибудь установка софта, или, не знаю, обработка фотки плагином, короче, какая-то операция, которая не бьется так легко на N шагов, и в которой не всегда понятно, что такое прогресс. Для таких случаев придумали крутилки и недетерминированные прогресс-бары — это такие, в которых полосы нет, а просто все закрашено паттерном и крутится бесконечно по циклу. Типа, идея та же, операция делается, но сколько там прошло и сколько осталось мы фиг его знает.
Это все нормальные идеи. Пока что все хорошо. Элементы используются по назначению, коммуникация честная, претензий нет.
А потом какой-то маркетолог, или, может, таролог или астролог, в общем, человек с выдуманной профессией, подумал: смотрите. Допустим, мы логиним пользователя. Это сколько-то времени займет. Сколько? Никто не знает. Может, секунду. Может, десять. Вряд ли больше десяти. Но и не мнгновенно. То есть подождать придется. Так? Так. Это значит что? Что пользователь будет переживать. Надо ему что-то показать. Давайте покажем ему детерминированный прогресс-бар! Программисты сразу такие: ну нет, мы прогресс не посчитаем, там сложно, или еще какое-то му-хрю, расписались в беспомощности.
И тут мораль/сила воли/система ценностей, которой ни у кого из присуствующих и не было, дала слабину. «Давайте рисовать прогресс от балды!» — сказали они. За первую секунду закрасим 25%. Равномерно, будем добавлять 1% каждые 40 мс. За вторую закрасим, условно, 20%, за третью 15% и так далее. Как только загрузимся, то сразу дорисовываем до 100%, все же радуются, когда кажется, что куча времени еще осталась, а тут хоба и все сразу сделано! Ну а если не загрузимся за 10 секунд, то последние 5% будем тянуть сколько сможем, по какой-нибудь бесконечно приближающейся асимптоте (я уверен, что на том митинге, где это решили, прозвучало слово асимптота, мне нужно хоть что-то приятное про него представлять, иначе хана).
Так родилось самое противное изобретение современного интерфейсостроения — лживый прогрессбар. По сути своей он недетерминированный. Но выглядит как детерминированный. Он намеренно лжет и о совершенном прогрессе, и об оставшемся времени. Лжет прямо вам в лицо и не стесняется этого. Еще и выдает это под соусом заботы о пользователе.
А ничо тот факт, что мне, как пользователю, нравилось знать, что происходит? Что мне настоящий прогресс, сколь угодно неравновномерный, дороже любых лживых ваших мультфильмов? К настоящему можно было приспособиться, можно было выводы какие-то делать. Им можно было ПОЛЬЗОВАТЬСЯ. А со лживым можно только пить водку, грустно смотреть и плакать.
Хватит прятать от меня компьютер! Хватит кормить меня пустыми обещаниями! Я взрослый человек, я хочу знать, что происходит! Я готов принять любой прогресс, пока он правдивый.
А обещаниями своими в веб-интерфейсах друг друга кормите. | 1 646 |
| 6 | Новые материалы в @uxwork (кроме вакансий):
— Как говорить с руководителем о повышении зарплаты;
— Что делать, если не нравится новая работа;
— Как проще фокусироваться на работе. | 1 745 |
| 7 | Антон Черногоров написал о будущем интерфейсов b2b-продуктов.
— Раньше они отражали внутреннее устройство систем, состоявших из ролей, прав, справочников, статусов и прочего, что нужно для выполнения задач;
— Экраны получались функциональными, но не помогали выполнять задачи или принимать решения;
— Считалось, что с таким интерфейсом не будет работать случайный человек и непонятность можно компенсировать обучением;
— В итоге люди запоминали, где что лежит, учились обходить неудобные сценарии, заводили рядом эксельку, писали себе инструкции;
— Что изменилось: привыкнув пользоваться классными b2c-продуктами, сотрудники ещё сильнее страдают, SaaS стал доступнее и выросла конкуренция, бизнес стал внимательнее считать деньги (а плохой интерфейс снижает эффективность работы сотрудников);
— Хороший b2b-интерфейс даёт чувство контроля: эксперту даёт скорость, а новичка не бросает без опор, объясняет, зачем нужны именно эти данные, о последствиях предупреждает до действия, помогает исправить ошибку, подсвечивает важное, говорит по-человечески там, где техническая точность бесполезна;
— Чего ждать в будущих b2b-продуктах: таблицы станут функциональнее, формы из набора полей превратятся в сценарии, пустые, ошибочные и промежуточные состояния перестанут быть техническими заглушками, навигация будет строиться вокруг рабочих контуров, а не базы данных;
— ИИ будет активно помогать. Например, выводить на дашборд не все данные, а только то, что требует внимания, объясняет причинно-следственные связи и помогает принять решение;
— Метрики: Cognitive load, Error rate, Time to task, eLTV, eNPS, CSAT, Cost per hire;
— Для этого надо разбираться в механике продукта: кто принимает решение и какие данные нужны, где возникает риск и какие ошибки стоят денег, где пользователь теряет контекст, какие операции повторяются ежедневно, какие роли видят систему по-разному, где пользователя надо ускорить и где затормозить.
#b2b | 2 780 |
| 8 | Рауль Фламинцяну написал о четырёх паттернах выделения объектов в общем потоке.
— Флажок — красная ленточка в картотеке. Нужен для привлечения внимания к объекту. Пример: флажок в почтовом клиенте Outlook позволяет не терять важные сообщения в папке «Входящие»;
— Закрепление — булавка на пробковой доске. Полезно, чтобы объект был под рукой, пока в этом есть необходимость. Пример: закрепление сообщений в групповых чатах (с адресом, где пройдёт вечеринка);
— Сохранение на потом — тумбочка. Позволяет отложить заинтересовавший объект, чтобы уделить ему время потом, когда будет возможность. Пример: плейлист «Смотреть позже» на Ютубе;
— Ничто на тумбочке не остаётся навсегда, а если долго там лежит, начинает восприниматься как долг. Отдельный вызов: проектировать сохранение на потом так, чтобы этот долг со временем закрывать;
— Избранное — книжная полка. Позволяет отметить какой-то объект как значимый, чтобы проще обратиться к нему в будущем и даже просто для того, чтобы коллекция вас характеризовала.
In English. | 2 492 |
| 9 | ⚪ Британка выходит за пределы московского кампуса!
Долгожданный апдейт: программы Британки по дизайну теперь доступны в онлайн-формате.
Семь самых востребованных направлений: от декорирования и дизайна интерьера до моды и современной живописи теперь можно пройти в любой точке мира, в нашем виртуальном кампусе.
В онлайн-программы мы заложили все, что помогает выпускникам Британки стать востребованными в индустрии: работу над реальными задачами и постоянную обратную связь от преподавателей-практиков, живые вебинары и комьюнити, где легко найти своих.
✔ За полгода обучения вы соберете портфолио с проектами по реальным брифам, которое можно отправить в студию, приложить к отклику или показать первому клиенту.
Узнать подробнее о программах, которые доступны в новом формате, можно на сайте в разделе Онлайн-программы | 2 948 |
| 10 | Ира Туманова написала об автоматизации подготовки перевода интерфейса в многоязычном продукте.
— Каждая текстовая строка в коде заменяется ключом. Основные решения: i18next, Lingui и FormatJS;
— ICU MessageFormat — синтаксис для форматирования сообщений, который позволяет разработчикам учитывать сложности человеческого языка;
— Значения ключей (текстовые строки на разных языках) хранятся в специальных файлах, откуда система берёт текст для заданного языка;
— Translation management system позволяет управлять переводами: смотреть статус ключа, на какие языки он уже переведён. Интересные TMS: Lokalise, Phrase, Crowdin, POEditor;
— Доделав фичу, разработчик запускает скрипт экстракции ключей из кода в TMS и создаёт задачу для переводчиков (со ссылками на ключи);
— Чтобы минимизировать человеческий фактор, в Яндекс Go процесс запускается сам при Pull Request в основную ветку;
— После того, как переводчики подготовят переводы, надо забрать их из TMS обратно в файлы локализации;
— В Яндекс Go это происходит автоматически по крону каждый день в 5 утра: скрипт по TMS API запрашивает все новые переводы, раскладывает данные по файлам, создаёт Pull Request с изменениями;
— Плюс добавили проверку на дубликаты, чтобы случайно не слить два Pull Request с одинаковыми ключами;
— Разработчики в среднем заводили 2,5 задачи в день на переводы. Это порядка 20 минут на задачи и последующее обновление файлов переводов. Немного, но выбивало из рабочего потока.
#localization | 2 327 |
| 11 | Илья Бирман рассказал об адаптивных сайтах без брейкпоинтов.
— Кирпичная вёрстка — когда сайт свёрстан под определённую ширину и не реагирует на изменение ширины окна браузера;
— Благодаря резиновой вёрстке сайт выглядел хорошо на популярных размерах экранов, но потом появились очень большие ширины (2560px) и очень маленькие (320px);
— На большие экраны всем было плевать. Пользователей у них было мало, да и зачем открывать браузер на весь экран на таком экране;
— Появилось много инструментов, например, медиазапросы позволяют узнать, что у пользователя тач-устройство и адаптировать дизайн;
— Проблема адаптивного дизайна с брейкпоинтами: надо делать несколько версий дизайна, как когда-то делали отдельные мобайл-версии;
— Дизайн, адаптированный под определённый диапазон ширины, часто выглядит не очень ближе к границам этого диапазона;
— Илья предлагает прорабатывать адаптивные состояния для разной ширины отдельных элементов, из которых состоит страница;
— За любым этажом можно закрепить поведение: перенос строк, изменение числа колонок, прокрутка, масштабирование;
— Высший пилотаж, когда переключение между состояниями элементов происходит из-за контента, а не произвольных чисел ширины;
— Может потребоваться отдельный мобильный дизайн кусочка как исключение (предусмотреть тач), когда остальные части сайта не меняются драматически;
— Не будет такого момента, когда сайт при какой-то ширине ломается;
— Адаптивность должна быть частью дизайн-системы, а не шагом по разработке конкретных экранов;
— Минус подхода Mobile-first: упрощать десктопный дизайн до мобильного проще, чем обогащать выхолощенный мобильный, плюс дизайнеры теряют навыки вёрстки.
Копия в ВК Видео. #adaptive | 2 415 |
| 12 | Кирилл Улитин и Стася Кабанова написали о контекстном интервью.
— Обычное интервью даёт изменённую версию реальности: люди не на всё обращают внимание, забывают неинтересные детали, часть опыта вообще не осознают, совершая действия автоматически;
— А ещё могут не хотеть честно обо всём рассказывать, чтобы выглядеть компетентнее в глазах собеседника;
— В контекстном интервью исследователь сначала разговаривает с респондентом о его опыте, контексте, задачах и привычных сценариях;
— Затем наблюдает, как тот выполняет задачи, и задаёт уточняющие вопросы, чтобы лучше понять происходящее и ничего не додумывать;
— Респондент как учитель показывает устройство своей работы, исследователь как ученик пытается понять его логику, не притворяясь экспертом;
— Контекст подсказывает, что спрашивать дальше, не нужно целиком полагаться на заранее подготовленный гайд;
— Так виден не только формальный порядок работы, но и реальные паттерны поведения: где человек срезает путь, перепроверяет себя, компенсирует неудобство интерфейса;
— Если нет возможности наблюдать весь день, можно дать задание в рамках исследовательского фокуса. Но так не увидеть моменты прокрастинации и отвлечения;
— Не всегда есть задачи, готовые для выполнения. В этом случае попросите респондента пройтись по недавним задачам и артефактам и воспроизвести ход своих действий;
— Предупреждайте о формате и ожиданиях заранее, чтобы респондент мог подготовиться, например, скрыть какие-то сенситивные данные;
— В отдельных ситуациях можно отключать видеозапись, оставляя только аудио;
— Обрабатывать наблюдения можно с помощью диаграммы сходства: вынести наблюдения на стикеры и сгруппировать по темам, паттернам и повторяющимся мотивам;
— Исследовать можно хоть MVP, но чтобы с его помощью уже решались реальные задачи;
— Метод исследования лучше работает там, где есть повторяющаяся деятельность, полезен в выездных исследованиях в естественной среде, b2b-сценариях, когда нельзя регулярно созваниваться с пользователями и глубоко погружаться в их рабочую практику удалённо;
— Читайте также: книга Contextual Design, материалы Nielsen Norman Group и «Собаки Павловой».
#research #interview | 2 741 |
| 13 | Разговор про трансформацию профессии, инструментов и личные вызовы, с которыми сталкивается дизайнер.
Разберём:
— как меняется роль дизайнера и какое мышление помогает проходить через изменения
— как применять искусственный интеллект в реальной работе, а не в теории
— как не теряться в потоке инструментов и сохранять фокус
— какие навыки остаются опорой независимо от технологий
— как трансформация инструментов становится частью повседневного процесса
В программе — 6 выступлений от спикеров из Сбера, СберМаркетинга, Pragmatica, RDMI, Skillbox и СберАвто.
Боремся со «страшилками» и тревожным ожиданием будущего практическим опытом и рабочими подходами, которые уже используются в командах.
📆 15 июня, 18:00
📍 Москва, офис Сбера и онлайн
⚡️ Бесплатно, нужна регистрация по ссылке ⚡️ | 2 536 |
| 14 | Дмитрий Ваницкий написал об опыте тестирования вайбкод-прототипа с фронтендом и бекендом.
— Вероятность получить ТЗ не в виде длинной спецификации, а в виде вайбкод-прототипа с каждым днём становится всё больше;
— Надо учиться их запускать, а также тестировать с пользователями;
— Потребуется редактор кода. К VS Code можно подключить любой ИИ. Дмитрий остановился на Antigravity благодаря агентному подходу и продвинутому планированию при решении задач;
— Прототип без бекенда (React app, который сам считает и хранит данные в локальном хранилище) можно легко посмотреть на своём компьютере;
— Для пользовательского тестирования такие прототипы можно сделать доступными в интернете через Netlify или Vercel;
— Зачем нужен прототип с бекендом: использовать реальные данные (дамп базы), обрабатывать запросы не на фронте ради безопасности, тестировать более длинные сессии;
— Чаще всего придётся иметь дело с Vite-проектом. Достаточно попросить ИИ проанализировать проект и запустить его;
— Чтобы всё работало не только у вас на компьютере, регистрируйтесь в GitHub и публикуйте проект там;
— Коммитьте чаще, чтобы не сильно откатываться назад, когда всё сломается;
— Проекты, требующие только фронта, можно публиковать в GitHub Pages, а можно в Vercel или Netlify через интеграцию с Гитхабом (указать его как вендора);
— Если нужен бекенд, репозиторий в GitHub можно подключить к Railway. Надо прописать в конфиге Vite нужный URL, чтобы не ссылаться на локалхост;
— При тестировании на реалистичных данных может потребоваться подменить данные из дампа базы выдуманными, сохранив логику и связи. Дмитрий поделился ИИ-скилом для этого;
— Для немодерируемых тестов таких прототипов подойдут Maze, Useberry, бесплатная платформа Display;
— Чтобы система понимала, когда заканчивать тест, открытие целевого экрана должно сопровождаться изменением URL;
— Если у вас React-приложение, которое работает на стейтах, попросите ИИ добавить подмену URL на финальные экраны.
#prototype #user_testing #ai #tool | 2 948 |
| 15 | Опубликован отрывок из книги Юрия Ветрова «Паттерны дизайн-менеджмента», посвящённый Т-образным специалистам.
— У них глубокая экспертиза в ключевых навыках и поверхностная — в широком наборе смежных;
— Если не вовлекаться в формирование требований, могут приходить задачи, которые сложно сделать хорошо;
— При разработке выявляются технические ограничения, мешающие сделать как задумано. При эксплуатации появляется пользовательская обратная связь;
— Сейчас все делают неплохие интерфейсы. Чтобы выделиться, надо прорабатывать вовлечение пользователя, строить кросс-канальное взаимодействие, проектировать всю цепочку оказания услуги;
— Объём нужных знаний ведёт к узкой специализации, что усложняет коммуникацию (каждый создаёт и передаёт дальше свои артефакты), удлиняет производственный цикл, размывает ответственность;
— Это подходит дизайн-студиям и аутсорсерам, которым важна формализация и предсказуемость, так как их клиенты покупают заранее оговоренный результат;
— Но не подходит стартапам (дорого нанимать столько специалистов) и продуктовым компаниям (важна скорость);
— Главный навык продуктового дизайнера — брать на себя ответственность за продукт. Чем именно он поможет команде — вопрос её специфики;
— Лучшие практики и здравый смысл — хорошо, но что если пользователям в конкретном продукте удобно по-другому?
— Важно применять эмпатию и к пользователям, и к коллегам, чтобы принимать дизайн-решения с учётом их болей и задач;
— Дизайнер работает в связке с продактом: помогает формировать продуктовое решение, снабжать продакта знаниями о пользователях, нужными для успешного запуска;
— Собираются ситуативные рабочие группы, где каждый дизайнер силён в своей теме и помогает в ней остальным. Автор дизайна в этом случае — ответственный, кто всё свёл воедино и довёл до результата;
— Лучшая спецификация продукта — работающий продукт. Лучше потратить время на его полировку, чем на эстетичные сопроводительные документы. Артефакты быстро устаревают;
— Важно не просто обрабатывать входящие запросы, а систематизировать наработки, переиспользовать паттерны, автоматизировать часть работы, не пытаться решить все проблемы одним рывком;
— Уровень владения смежными навыками: от осведомлённости (понимание того, как работает специалист в этой области) до умения (способность решать базовые задачи в области, доделывать за специалистом работу, вносить осмысленные правки);
— Есть разница между ролью и специалистом. В разных проектах один специалист может выполнять несколько ролей. Либо одну роль могут закрывать несколько человек;
— Уровни зрелости компании: возникла потребность в Т-образных дизайнерах → часть команды → все дизайнеры Т-образные.
#management | 2 940 |
| 16 | Напоминание:
Сегодня в 19:00 (по московскому времени) — круглый стол от UX Feedback. Зарегистрироваться можно тут. | 1 539 |
| 17 | Никита написал об особенностях создания транспортных схем на иностранных языках (тоже победитель «Технотекста 8» в категории «Дизайн»).
— Их никогда не переводят полностью. Перевод топологических имён вроде «Красносельская» навигацию только усложняет;
— Названия большинства объектов транслитерируют или транскрибируют, чтобы передать звучание, не передавая смысл;
— Полная транслитерация со всеми составными частями (Ленинградский вокзал → Leningradskiy Vokzal) основана на идее, что главная задача схемы — навигация в пределах транспортной системы;
— Чтобы понять, где он и куда ему идти, пассажир может сопоставить голосовое объявление остановки с надписью или спросить у местного жителя;
— Альтернатива: переводить слова «вокзал», «улица», «площадь». Упрощает навигацию за пределами транспортной системы: можно увидеть объект в окно и сопоставить место со схемой. Но усложняет восприятие аудиосообщений;
— Такой подход зафиксирован, например, в правилах оформления Народной карты Яндекса;
— Компромисс: транскрибировать всё, а важным для навигации объектам добавлять перевод. Минус: больше надписей, хуже читаемость;
— На китайском звуки передаются иероглифами (одному звуку могут соответствовать разные). Но так как каждый иероглиф — слово, может появляться дополнительный смысл;
— Имя «Юлия» можно написать: а) 朱莉娅 (Zhūlìyà) — красный, жасмин, шурин; б) 猪厉亚 (Zhūlìyà) — свинья, злой, ущербный;
— Переводчик отвечает за уместность возникающих ассоциаций. Обычно используют словари официальных транскрипций, а если нужного топонима там нет — правила китайско-русской практической транскрипции;
— В схеме Московского метро на китайском и арабском совмещены 3 подхода;
— В арабской версии в названии станции «Аэропорт Внуково» перевели «аэропорт», так как станция находится в аэропорту. А название станции «Аэропорт» транскрибировали, так как там аэропорта нет;
— Вместо китайских и восточных арабских цифр на схемах используют привычные цифры, так как они служат обычно идентификаторами. Они должны совпадать с тем, что встречается на указателях и табло;
— Если цифры должны передать именно числа (например, время работы), то можно использовать восточные арабские цифры. Для китайской версии сойдут обычные, так как в Китае их тоже используют;
— Станция «Улица 1905 года» записана с цифрами. Сложнее распознать по звучанию, зато надпись занимает меньше места и её легче заметить на табличках, экранах и бегущих строках.
#localization #writing #transport | 2 868 |
| 18 | 🎬 Люди говорили о важном и было хорошо (с)
23 мая в Москве прошла третья конференция «Просто Сложно» про дизайн и исследования инженерных продуктов. Записи, материалы и дискуссии доступны в канале конференции.
Спикеры — из Сбера, NAVIO, Бюро Горбунова, AVITO, YADRO, Бюро 1440 — поделились опытом о том, как делать сложные инженерные продукты простыми и удобными.
Доклады были практичными и вдохновляющими:
✔️ Илья Бирман из Бюро Горбунова посадил зал в машину времени и отправил на 20 лет назад, чтобы задать неудобный вопрос: почему мы до сих пор не научились делать адаптивный дизайн правильно? Один из самых дискуссионных докладов конференции.
✔️ Команда NAVIO показала на реальном кейсе, с какими задачами сталкивается дизайнер беспилотных тягачей.
✔️ Мария Копачевская из компании YADRO увлекла историей про исследования в hardware-разработке: как изучать пользователя там, где продукт буквально железный.
✔️ Отдельное удовольствие было слушать доклады про AI-агентов и то, как они меняют UX в инженерных продуктах.
Смотрите записи выступлений, задавайте вопросы спикерам в комментариях и узнайте первыми о следующей конференции в канале ПРОСТО СЛОЖНО | 2 303 |
| 19 | Ольга Петроченко написала, как уменьшить вероятность расхождения макетов и их реализации в мобильном приложении.
— Вёрстка — финальный макет, передаваемый в разработку, и его реализация в коде, которую разработчик передаёт дизайнеру на проверку;
— iOS, Android, WebView, десктопный и мобильный веб (плюс горизонтальная ориентация и планшеты) имеют особенности и технические ограничения, которые надо учитывать;
— Есть платформенные паттерны, но их могут игнорировать, пытаясь сформировать общий паттерн использования приложения, не зависящий от платформы;
— Технически на макете не всё собирается через таблицу или стек. Применять только Auto layout невозможно, так как элементы могут настраиваться через констрейнты, закрепляться на экране поверх остального контента, оставаясь его частью;
— Изображение не должно искажаться при изменении ширины контейнера. Как оно должно вести себя при увеличении ширины вьюпорта?
— Учитывайте это, и один макет будет работать с любой вёрсткой: широкой и узкой, горизонтальной и вертикальной;
— Паттерны навигации в iOS: Push (линейная со стрелочкой «Назад») и Present (модальная с крестиком). Можно комбинировать: внутри модальной использовать линейную (но пользователь может ошибочно закрыть весь флоу, по которому двигался в модальности);
— Чтобы не путаться, заведите под эти паттерны шаблоны в дизайн-системе. И вообще фиксируйте все правила, о которых договорились с разработчиками;
— Определяйте типы элементов в макете. От типа зависят их свойства: какие есть состояния, могут ли отображать загрузку и ошибку, нативные или кастомные это элементы, должны ли нажиматься;
— Передать информацию о типе можно, использовав определённые компоненты дизайн-системы (по крайней мере так реализовано в Альфа-Банке);
— Если этого не делать, разработчики будут возвращаться с вопросами или даже делать так, как сами (неправильно) поняли;
— Экран может быть реализован с помощью разных технологий: фронтовая вёрстка, серверная (например, BDUI), комбинированная;
— Технология определяет допустимый набор элементов и возможности их кастомизации. Например, весь экран — это модуль, и его можно только переиспользовать;
— Макеты — это техническое задание. Качественное ТЗ — залог лёгкого последующего дизайн-ревью. Но чтобы делать качественно, надо общаться с разработчиками (не стесняясь задавать глупые вопросы) и понимать технические нюансы.
#mobile #handoff | 2 720 |
| 20 | Хабр подвёл итоги конкурса «Технотекст 8», и моя статья оказалась одной из трёх победительниц в категории «Дизайн». Поэтому сегодня — повторная публикация её анонса в UX Notes.
Я написал, какими бывают адреса электронной почты и как это может повлиять на опыт регистрации и входа по имейлу.
— Когда человек заводит электронную почту, его имя пользователя и домен почтового сервиса становятся уникальным адресом;
— Но его не обязательно указывать в точности, чтобы получать письма;
— Все почтовые сервисы игнорируют регистр букв. Gmail — точки в имени пользователя. Почти все игнорируют то, что в имени пользователя указано после «+»;
— Фишка с «+» описана в одном из стандартов работы электронной почты и может использоваться для борьбы со спамом и сортировки почты;
— Плюс тестировщики могут так зарегистрировать несколько аккаунтов в тестируемых продуктах, не заводя множества почтовых ящиков;
— Некоторые почтовики работают на нескольких доменах. Например, gmail.com и googlemail.com, yandex.ru и ya.ru;
— По хорошему, сделав исключение для тестировщиков, всё это стоит учитывать при регистрации, входе и восстановлении пароля (в статье в общих чертах описан механизм), чтобы пользователи не создавали несколько аккаунтов, фактически связанных с одним ящиком;
— Пользователь может забыть, с каким адресом регистрировался ранее, и по ошибке завести ещё один аккаунт;
— Если посмотреть на крупные и популярные сервисы вроде ChatGPT, Notion, Amazon, они отрабатывают только кейс с регистром букв.
#login #signup | 2 531 |
Available now! Telegram Research 2025 — the year's key insights 
