UX Notes

А вы смотрите сторис в приложениях? Кажется, что это просто привычный формат из соцсетей. Но на самом деле сторис могут решать вполне конкретные продуктовые задачи. Кирилл из команды t2.digital разобрал, как с помощью этого инструмента закрывать 5 ключевых задач мобильного приложения. Листайте карточки, чтобы узнать больше. В своем канале ребята рассказывают о новых фичах, делятся внутренней экспертизой и публикуют вакансии.

Эрик Чанг написал о навигации с помощью табов (вкладок). — Вкладки упрощают навигацию, экономят место на странице, группируют контент и обеспечивают быстрый доступ к нему; — Табы хорошо работают, когда их немного, все они видны на экране и нет горизонтальной прокрутки; — На мобильных устройствах может появиться горизонтальный скрол в блоке табов или кнопки для его прокрутки влево и вправо. Также переключаться между табами иногда можно свайпами влево и вправо; — Их лучше не использовать для сложного иерархического контента (табы внутри табов внутри табов); — Они хорошо подходят для навигации второго уровня, когда основная навигация находится в боковом меню; — Также лучше от них отказаться, если нельзя каждой вкладке дать короткое и понятное название, из-за чего текст может обрезаться или переноситься на несколько строк; — Минус табов: для доступа к контенту вкладок, не открытых по умолчанию, пользователю надо на табы нажимать. Если находящийся там контент имеет решающее значение для пользовательских целей, лучше его там не размещать; — Не забывайте выделять активную вкладку, а также реагировать на наведение курсора на десктопе; — Чем отличаются от аккордеонов: обычно вкладки расположены горизонтально, а аккордеоны — вертикально, в аккордеонах часто возможно одновременное раскрытие нескольких панелей. In English. #tab

Маргарита Попова написала об итеративном процессе в дизайне. — Полезен новым продуктам (MVP и R&D-проекты), в условиях неопределённости, без готовой дизайн-системы, для ускорения поставок функциональности пользователям; — В каскадной модели разработка следует за дизайном. Минусы: этап дизайна кажется бесконечным, разработчики приходят с вопросами, когда дизайнеры уже заняты другим; — Дизайн блока функциональности (запланированного в USM) можно разделить, чтобы идти от общих вопросов к частным и чаще получать обратную связь; — 1. Формирование общей картины: работа с PO и PM, создание User flow, схем работы и прототипов от руки, которые легко выбрасывать при переборе идей; — 2. Детализация прототипов, добавление отдельных интерактивных элементов, чтобы провести простые пользовательские тесты сценариев использования и обсудить с разработчиками функциональность. Последние могут приступать к проектированию архитектуры; — 3. Подробный интерактивный прототип со всеми состояниями, дающий возможность провести полноценное тестирование с пользователями. После тестов — внесение правок, запись идей на следующие итерации; — 4. Дальнейший дизайн идёт параллельно разработке: макеты, состояния компонентов, подготовка к вёрстке, UI-кит; — Плюсы: вся команда вовлечена в проектирование и принятие решений, решения тестируются, технические вопросы решаются раньше; — Минусы: сложнее тестировать не финальные макеты, разработка стартует после проработки всего блока функциональности, обсуждения переключают контекст разработчиков; — Если брать не блок, а небольшой кусочек, можно спроектировать его за спринт (хотя бы простой вариант для начала); — Плюсы: у разработчиков и дизайнеров общий контекст, пользователи получат фичу и дадут обратную связь, видны метрики, может оказаться, что цель достигнута и дальше полировать дизайн смысла нет; — Минусы: более сырой интерфейс, большие сценарии не умещаются в спринт, сложнее управлять, больше техдолг; — Чтобы потом вспомнить, какие дизайн-решения были приняты и почему, можно использовать аналог ADR (пример); — Когда останавливаться в полировке прототипа: покрыты все сценарии, улучшения не приносят заметной пользы, у команды не осталось вопросов, появилось желание выровнять отступы; — Итеративный подход снижает тревогу по поводу идеальности результата, а также предлагает задуматься, что считать идеальным результатом (приносит пользу клиентам уже сейчас). #process #prototype

Макс Фёдоров рассказал, как выигрывать борьбу за внимание. — Важно постоянно быть в медиапространстве, поэтому современный бизнес всё больше превращается в медиа; — Бизнесы соревнуются за ограниченное внимание потребителей; — Лучший продукт и дизайн проигрывают тем, кто ярче и кто может создать лучшее событие; — Хайпономика: использование инфоповодов, мемов и провокаций для привлечения краткосрочного внимания и (при системном подходе) создания долгосрочной лояльности; — Надо понимать своих пользователей и их потребности. 43% людей указывают, что ходят в кофейни ради кофе. Чаще — чтобы встретиться с друзьями или поработать; — В коммуникации надо рассказывать, как именно будет решена задача клиента. Не «скорость 100 мегабит», а «сколько устройств смогут работать» и «можно ли стримить»; — Люди покупают только одно — гарантию выживания (сохранение денег, экономия времени, накопление других ресурсов, социальные связи, статус, покровительство, смысл существования); — Говорите на понятном человеческом языке, минимизируйте термины; — Есть разные стратегии позиционирования, например, лидерство (первое место в категории), отстройка от лидера (учёт его ошибок и слабых сторон), решение проблемы (решаем её лучше остальных) и так далее. Чтобы отличаться от конкурентов, надо выбрать одну-две стратегии и их придерживаться (может со временем меняться); — Лонгриды → минимализм; сложные схемы или просто текст → инфографика; апелляция к опыту (часто негативному) → воображение (как может быть); многозадачность → однозадачность; академизм → геймификация; — Логика (обосновывает уже принятые на эмоциях решения) → эмоции; однообразие → контраст; скука → развлечение (провал, если на презентации не было шуточки); — Главное — не бояться.

«Передумал», «Не буду оплачивать», «Давайте добавим ещё задач» — такие ситуации проще обсуждать, когда условия заказа зафиксированы заранее. На Авито Услугах развивается более безопасный и защищённый сценарий взаимодействия между заказчиками и исполнителями. По их данным, 48% клиентов называют защиту условий сделки своим приоритетом. Для дизайнеров, бухгалтеров, финансистов, копирайтеров, маркетологов (от SMM до работы с блогерам) и других специалистов из сферы деловых услуг доступен сервис «Защита сделки» при поддержке Авито Услуг. Он помогает заранее договориться об объёме, сроках и стоимости заказа, а оплату – зарезервировать до подтверждения результата со стороны клиента. Что даёт «Защита сделки» исполнителю: *️⃣Фиксирование условий: клиент не сможет потребовать больше, чем обсуждалось на старте *️⃣Полная оплата: вы получите оплату, если выполнили всё в рамках зафиксированных условий *️⃣Защита от риска отказа в последний момент: заказчик уже внёс деньги на спецсчёт и заинтересован в том, чтобы довести дело до конца *️⃣Независимые арбитры: в спорных ситуациях подключатся арбитры, которые могут помочь разрешить ситуацию Подключить «Защиту сделки» можно при создании нового объявления на Авито Услугах или редактировании существующего. Подробности о сервисе можно узнать по ссылке. От себя ставим ❤️ за инициативу!

Евгения Шамрай написала, что профессия дизайнера интерфейсов в привычном нам виде скоро исчезнет. — Экраны в Фигме — удобные, приятные визуально, с адаптивными состояниями, собирающиеся в сценарий — раньше сами по себе представляли ценность; — Клиенты приходили за ними к дизайнерам, потому что других вариантов особо не было. Сейчас альтернативы предлагает ИИ; — За последние 1,5 года клиенты не покупают дизайн интерфейса; — Приходят за аудитом, аналитикой, исследованием, пониманием пользователей, поиском проблем в продукте, разбором сценариев, редизайном бизнес-процессов, стратегией развития продукта; — Интерфейс появляется где-то в конце такой работы и не является основной её ценностью; — Основная ценность — в ответах на вопросы вроде: «Почему пользователи не доходят до целевого действия?», «Почему сотрудники обходят систему с помощью Экселя?», «Почему заявки есть, а продажи не растут?», «Почему люди не доверяют продукту?», «Почему новые пользователи не понимают, что делать дальше?»; — Главное — понять, какой интерфейс вообще нужен. Может оказаться, что проблему вообще не решить новым дизайном; — Будет падать спрос на дизайнеров интерфейсов и расти спрос на тех, кто умеет понимать клиентский опыт целиком; — UX, UI, исследования, аналитика и AI сольются в одну роль. #definition

Yandex for TechnoCreative — канал для дизайнеров, продюсеров, маркетологов, бренд-менеджеров и всех, кто использует технологии для креативов и оптимизации. Что внутри: 〰️ Кейсы яндексоидов — как в Yango сделали натуралистичный ролик про Эфиопию с помощью AI 〰️ Механики и лайфхаки по избавлению от рутины – как CTO Яндекс Карт Толя Панов систематизирует личную базу знаний 〰️ Истории и мнения экспертов из мира креативных технологий — статья Арсения Попова о креативном мышлении в эпоху AI 〰️ Вакансии Яндекса для креативных специалистов. Подписывайтесь, будет еще интереснее! Реклама. ООО "Яндекс". ИНН 7736207543 erid: 2VtzqvfBhrR

Знаете, от чего прям противно? Вот эти вот прогрессбары, которые движутся не от настоящего прогресса, а с предзаданной скоростью. Типа, чтобы пользователь не пугался. В чем вообще идея прогрессбара? Вот у тебя есть N файлов, ты скопировал M из них, и показал на прогрессбаре M / N × 100%. Ну и ты видишь, сколько работы сделано, а сколько осталось. Некоторые прогрессбары даже время примерное до конца показывали! Потом люди заметили, что иногда прогресс неравномерен. Например, с теми же файлами, большой файл копируется дольше, а прогресс мы считаем по количеству. Тогда на большом файле 1% прогресса будет продвигаться дольше, чем на маленьких. Или скачивание из интренета, там вообще непредсказуемо. Если ты начнешь тут считать время, оставшееся до конца, оно у тебя будет плясать — 30 секунд, полдня, неделя, о, снова 30! Пошли сразу шутки, про 99%, про квантовую природу прогрессбаров и так далее. Но — что важно — отображаемый прогресс был связан хоть с чем-то реальным! Можно было поставить курсор мыши на текущее положение, и если оно через 15 минут сдвинулось, значит программа еще что-то делает, а не зависла. Понятно, что прогресс можно предсказать не всегда. Какая-нибудь установка софта, или, не знаю, обработка фотки плагином, короче, какая-то операция, которая не бьется так легко на N шагов, и в которой не всегда понятно, что такое прогресс. Для таких случаев придумали крутилки и недетерминированные прогресс-бары — это такие, в которых полосы нет, а просто все закрашено паттерном и крутится бесконечно по циклу. Типа, идея та же, операция делается, но сколько там прошло и сколько осталось мы фиг его знает. Это все нормальные идеи. Пока что все хорошо. Элементы используются по назначению, коммуникация честная, претензий нет. А потом какой-то маркетолог, или, может, таролог или астролог, в общем, человек с выдуманной профессией, подумал: смотрите. Допустим, мы логиним пользователя. Это сколько-то времени займет. Сколько? Никто не знает. Может, секунду. Может, десять. Вряд ли больше десяти. Но и не мнгновенно. То есть подождать придется. Так? Так. Это значит что? Что пользователь будет переживать. Надо ему что-то показать. Давайте покажем ему детерминированный прогресс-бар! Программисты сразу такие: ну нет, мы прогресс не посчитаем, там сложно, или еще какое-то му-хрю, расписались в беспомощности. И тут мораль/сила воли/система ценностей, которой ни у кого из присуствующих и не было, дала слабину. «Давайте рисовать прогресс от балды!» — сказали они. За первую секунду закрасим 25%. Равномерно, будем добавлять 1% каждые 40 мс. За вторую закрасим, условно, 20%, за третью 15% и так далее. Как только загрузимся, то сразу дорисовываем до 100%, все же радуются, когда кажется, что куча времени еще осталась, а тут хоба и все сразу сделано! Ну а если не загрузимся за 10 секунд, то последние 5% будем тянуть сколько сможем, по какой-нибудь бесконечно приближающейся асимптоте (я уверен, что на том митинге, где это решили, прозвучало слово асимптота, мне нужно хоть что-то приятное про него представлять, иначе хана). Так родилось самое противное изобретение современного интерфейсостроения — лживый прогрессбар. По сути своей он недетерминированный. Но выглядит как детерминированный. Он намеренно лжет и о совершенном прогрессе, и об оставшемся времени. Лжет прямо вам в лицо и не стесняется этого. Еще и выдает это под соусом заботы о пользователе. А ничо тот факт, что мне, как пользователю, нравилось знать, что происходит? Что мне настоящий прогресс, сколь угодно неравновномерный, дороже любых лживых ваших мультфильмов? К настоящему можно было приспособиться, можно было выводы какие-то делать. Им можно было ПОЛЬЗОВАТЬСЯ. А со лживым можно только пить водку, грустно смотреть и плакать. Хватит прятать от меня компьютер! Хватит кормить меня пустыми обещаниями! Я взрослый человек, я хочу знать, что происходит! Я готов принять любой прогресс, пока он правдивый. А обещаниями своими в веб-интерфейсах друг друга кормите.

Новые материалы в @uxwork (кроме вакансий): — Как говорить с руководителем о повышении зарплаты; — Что делать, если не нравится новая работа; — Как проще фокусироваться на работе.

Антон Черногоров написал о будущем интерфейсов b2b-продуктов. — Раньше они отражали внутреннее устройство систем, состоявших из ролей, прав, справочников, статусов и прочего, что нужно для выполнения задач; — Экраны получались функциональными, но не помогали выполнять задачи или принимать решения; — Считалось, что с таким интерфейсом не будет работать случайный человек и непонятность можно компенсировать обучением; — В итоге люди запоминали, где что лежит, учились обходить неудобные сценарии, заводили рядом эксельку, писали себе инструкции; — Что изменилось: привыкнув пользоваться классными b2c-продуктами, сотрудники ещё сильнее страдают, SaaS стал доступнее и выросла конкуренция, бизнес стал внимательнее считать деньги (а плохой интерфейс снижает эффективность работы сотрудников); — Хороший b2b-интерфейс даёт чувство контроля: эксперту даёт скорость, а новичка не бросает без опор, объясняет, зачем нужны именно эти данные, о последствиях предупреждает до действия, помогает исправить ошибку, подсвечивает важное, говорит по-человечески там, где техническая точность бесполезна; — Чего ждать в будущих b2b-продуктах: таблицы станут функциональнее, формы из набора полей превратятся в сценарии, пустые, ошибочные и промежуточные состояния перестанут быть техническими заглушками, навигация будет строиться вокруг рабочих контуров, а не базы данных; — ИИ будет активно помогать. Например, выводить на дашборд не все данные, а только то, что требует внимания, объясняет причинно-следственные связи и помогает принять решение; — Метрики: Cognitive load, Error rate, Time to task, eLTV, eNPS, CSAT, Cost per hire; — Для этого надо разбираться в механике продукта: кто принимает решение и какие данные нужны, где возникает риск и какие ошибки стоят денег, где пользователь теряет контекст, какие операции повторяются ежедневно, какие роли видят систему по-разному, где пользователя надо ускорить и где затормозить. #b2b

Рауль Фламинцяну написал о четырёх паттернах выделения объектов в общем потоке. — Флажок — красная ленточка в картотеке. Нужен для привлечения внимания к объекту. Пример: флажок в почтовом клиенте Outlook позволяет не терять важные сообщения в папке «Входящие»; — Закрепление — булавка на пробковой доске. Полезно, чтобы объект был под рукой, пока в этом есть необходимость. Пример: закрепление сообщений в групповых чатах (с адресом, где пройдёт вечеринка); — Сохранение на потом — тумбочка. Позволяет отложить заинтересовавший объект, чтобы уделить ему время потом, когда будет возможность. Пример: плейлист «Смотреть позже» на Ютубе; — Ничто на тумбочке не остаётся навсегда, а если долго там лежит, начинает восприниматься как долг. Отдельный вызов: проектировать сохранение на потом так, чтобы этот долг со временем закрывать; — Избранное — книжная полка. Позволяет отметить какой-то объект как значимый, чтобы проще обратиться к нему в будущем и даже просто для того, чтобы коллекция вас характеризовала. In English.

⚪ Британка выходит за пределы московского кампуса! Долгожданный апдейт: программы Британки по дизайну теперь доступны в онлайн-формате. Семь самых востребованных направлений: от декорирования и дизайна интерьера до моды и современной живописи теперь можно пройти в любой точке мира, в нашем виртуальном кампусе.

В онлайн-программы мы заложили все, что помогает выпускникам Британки стать востребованными в индустрии: работу над реальными задачами и постоянную обратную связь от преподавателей-практиков, живые вебинары и комьюнити, где легко найти своих.

✔ За полгода обучения вы соберете портфолио с проектами по реальным брифам, которое можно отправить в студию, приложить к отклику или показать первому клиенту. Узнать подробнее о программах, которые доступны в новом формате, можно на сайте в разделе Онлайн-программы

Ира Туманова написала об автоматизации подготовки перевода интерфейса в многоязычном продукте. — Каждая текстовая строка в коде заменяется ключом. Основные решения: 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

Илья Бирман рассказал об адаптивных сайтах без брейкпоинтов. — Кирпичная вёрстка — когда сайт свёрстан под определённую ширину и не реагирует на изменение ширины окна браузера; — Благодаря резиновой вёрстке сайт выглядел хорошо на популярных размерах экранов, но потом появились очень большие ширины (2560px) и очень маленькие (320px); — На большие экраны всем было плевать. Пользователей у них было мало, да и зачем открывать браузер на весь экран на таком экране; — Появилось много инструментов, например, медиазапросы позволяют узнать, что у пользователя тач-устройство и адаптировать дизайн; — Проблема адаптивного дизайна с брейкпоинтами: надо делать несколько версий дизайна, как когда-то делали отдельные мобайл-версии; — Дизайн, адаптированный под определённый диапазон ширины, часто выглядит не очень ближе к границам этого диапазона; — Илья предлагает прорабатывать адаптивные состояния для разной ширины отдельных элементов, из которых состоит страница; — За любым этажом можно закрепить поведение: перенос строк, изменение числа колонок, прокрутка, масштабирование; — Высший пилотаж, когда переключение между состояниями элементов происходит из-за контента, а не произвольных чисел ширины; — Может потребоваться отдельный мобильный дизайн кусочка как исключение (предусмотреть тач), когда остальные части сайта не меняются драматически; — Не будет такого момента, когда сайт при какой-то ширине ломается; — Адаптивность должна быть частью дизайн-системы, а не шагом по разработке конкретных экранов; — Минус подхода Mobile-first: упрощать десктопный дизайн до мобильного проще, чем обогащать выхолощенный мобильный, плюс дизайнеры теряют навыки вёрстки. Копия в ВК Видео. #adaptive

Кирилл Улитин и Стася Кабанова написали о контекстном интервью. — Обычное интервью даёт изменённую версию реальности: люди не на всё обращают внимание, забывают неинтересные детали, часть опыта вообще не осознают, совершая действия автоматически; — А ещё могут не хотеть честно обо всём рассказывать, чтобы выглядеть компетентнее в глазах собеседника; — В контекстном интервью исследователь сначала разговаривает с респондентом о его опыте, контексте, задачах и привычных сценариях; — Затем наблюдает, как тот выполняет задачи, и задаёт уточняющие вопросы, чтобы лучше понять происходящее и ничего не додумывать; — Респондент как учитель показывает устройство своей работы, исследователь как ученик пытается понять его логику, не притворяясь экспертом; — Контекст подсказывает, что спрашивать дальше, не нужно целиком полагаться на заранее подготовленный гайд; — Так виден не только формальный порядок работы, но и реальные паттерны поведения: где человек срезает путь, перепроверяет себя, компенсирует неудобство интерфейса; — Если нет возможности наблюдать весь день, можно дать задание в рамках исследовательского фокуса. Но так не увидеть моменты прокрастинации и отвлечения; — Не всегда есть задачи, готовые для выполнения. В этом случае попросите респондента пройтись по недавним задачам и артефактам и воспроизвести ход своих действий; — Предупреждайте о формате и ожиданиях заранее, чтобы респондент мог подготовиться, например, скрыть какие-то сенситивные данные; — В отдельных ситуациях можно отключать видеозапись, оставляя только аудио; — Обрабатывать наблюдения можно с помощью диаграммы сходства: вынести наблюдения на стикеры и сгруппировать по темам, паттернам и повторяющимся мотивам; — Исследовать можно хоть MVP, но чтобы с его помощью уже решались реальные задачи; — Метод исследования лучше работает там, где есть повторяющаяся деятельность, полезен в выездных исследованиях в естественной среде, b2b-сценариях, когда нельзя регулярно созваниваться с пользователями и глубоко погружаться в их рабочую практику удалённо; — Читайте также: книга Contextual Design, материалы Nielsen Norman Group и «Собаки Павловой». #research #interview

Разговор про трансформацию профессии, инструментов и личные вызовы, с которыми сталкивается дизайнер. Разберём: — как меняется роль дизайнера и какое мышление помогает проходить через изменения — как применять искусственный интеллект в реальной работе, а не в теории — как не теряться в потоке инструментов и сохранять фокус — какие навыки остаются опорой независимо от технологий — как трансформация инструментов становится частью повседневного процесса В программе — 6 выступлений от спикеров из Сбера, СберМаркетинга, Pragmatica, RDMI, Skillbox и СберАвто. Боремся со «страшилками» и тревожным ожиданием будущего практическим опытом и рабочими подходами, которые уже используются в командах. 📆 15 июня, 18:00 📍 Москва, офис Сбера и онлайн ⚡️ Бесплатно, нужна регистрация по ссылке ⚡️

Дмитрий Ваницкий написал об опыте тестирования вайбкод-прототипа с фронтендом и бекендом. — Вероятность получить ТЗ не в виде длинной спецификации, а в виде вайбкод-прототипа с каждым днём становится всё больше; — Надо учиться их запускать, а также тестировать с пользователями; — Потребуется редактор кода. К 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

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

Напоминание: Сегодня в 19:00 (по московскому времени) — круглый стол от UX Feedback. Зарегистрироваться можно тут.

Никита написал об особенностях создания транспортных схем на иностранных языках (тоже победитель «Технотекста 8» в категории «Дизайн»). — Их никогда не переводят полностью. Перевод топологических имён вроде «Красносельская» навигацию только усложняет; — Названия большинства объектов транслитерируют или транскрибируют, чтобы передать звучание, не передавая смысл; — Полная транслитерация со всеми составными частями (Ленинградский вокзал → Leningradskiy Vokzal) основана на идее, что главная задача схемы — навигация в пределах транспортной системы; — Чтобы понять, где он и куда ему идти, пассажир может сопоставить голосовое объявление остановки с надписью или спросить у местного жителя; — Альтернатива: переводить слова «вокзал», «улица», «площадь». Упрощает навигацию за пределами транспортной системы: можно увидеть объект в окно и сопоставить место со схемой. Но усложняет восприятие аудиосообщений; — Такой подход зафиксирован, например, в правилах оформления Народной карты Яндекса; — Компромисс: транскрибировать всё, а важным для навигации объектам добавлять перевод. Минус: больше надписей, хуже читаемость; — На китайском звуки передаются иероглифами (одному звуку могут соответствовать разные). Но так как каждый иероглиф — слово, может появляться дополнительный смысл; — Имя «Юлия» можно написать: а) 朱莉娅 (Zhū​lì​yà) — красный, жасмин, шурин; б) 猪厉亚 (Zhū​lì​yà) — свинья, злой, ущербный; — Переводчик отвечает за уместность возникающих ассоциаций. Обычно используют словари официальных транскрипций, а если нужного топонима там нет — правила китайско-русской практической транскрипции; — В схеме Московского метро на китайском и арабском совмещены 3 подхода; — В арабской версии в названии станции «Аэропорт Внуково» перевели «аэропорт», так как станция находится в аэропорту. А название станции «Аэропорт» транскрибировали, так как там аэропорта нет; — Вместо китайских и восточных арабских цифр на схемах используют привычные цифры, так как они служат обычно идентификаторами. Они должны совпадать с тем, что встречается на указателях и табло; — Если цифры должны передать именно числа (например, время работы), то можно использовать восточные арабские цифры. Для китайской версии сойдут обычные, так как в Китае их тоже используют; — Станция «Улица 1905 года» записана с цифрами. Сложнее распознать по звучанию, зато надпись занимает меньше места и её легче заметить на табличках, экранах и бегущих строках. #localization #writing #transport