Андрей Маркелов написал о дизайне сложных таблиц.

— Шрифты с моноширинными цифрами можно использовать, если в таблице числа не смешаны с буквами (рядом с числом может стоять единица измерения);
— Но лучше использовать полностью моноширинные шрифты, например, очень компактный Ubuntu Mono;
— Числа выравнивайте по правому краю, но текстовые заголовки столбцов с числами — по левому;
— Чтобы повысить читаемость, можно выделить визуальные границы колонок, разорвав разделительную линию;
— Если колонки стоят очень плотно, для отделения разрядов вместо обычного пробела лучше использовать тонкий («thin space», U+2009);
— Единицы измерения обычно пишут в названиях колонок через запятую, но тогда колонка становится шире. Можно располагать их под названием на отдельной строке и выделять цветом;
— Иногда группы колонок полезно сворачивать: для экономии места, для показа результирующей колонки;
— Базовую числовую таблицу можно обогатить инфографикой, цветами и диаграммами. Например, в дополнение к начальной и конечной цене можно показать график её колебания. Вклад каждой облигации в стоимость портфеля можно подсветить градацией зеленого и красного;
— Стоит ввести двойные строки. Например, полезно видеть не только стоимость облигации, но и процент, который она занимает в портфеле.

#table

Даниил Видишев написал, как работать с мелкими багами, появляющимися при реализации дизайна.

— Они бывают визуальными (не те цвета, отступы, анимация) и функциональными (у кнопки нет тултипа). Они не мешают пользователям достигать целей, поэтому получают низкий приоритет;
— В итоге их становится слишком много, чтобы можно было легко исправить, продукт начинает отличаться от макетов, растёт поток обратной связи от пользователей;
— Оформляйте баги правильно: пишите конкретно, что и где надо исправить (карточка пользователя, изменить стиль заголовка с 24 на 28 px), группируйте их с помощью тегов или папок, прикладывайте скриншот проблемы и ссылку на макет;
— Объясняйте команде ценность дизайна;
— Документируйте дизайн: подробно описывайте работу элементов (здесь стоит упомянуть мою статью о функциональной спецификации), прикладывайте референсы анимаций, показывайте в макетах пошаговые сценарии;
— Проводите ревью вёрстки, когда она уже почти готова (вряд ли получится выделить для этого отдельный статус задачи в Джире). Фронтендер может показать наработки на коротком созвоне;
— Если перечисленные выше процессы работают, можно внедрить автотесты на pixel perfect UI.

Смотрите также статьи Алисии Суски и Сэма Айронса о дизайн-долге. #process

Андрей Кононов написал о проектировании сложной функциональности на примере заказа товаров в сетевом магазине.

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

#process

В tubik написали о единообразии в интерфейсе.

— Чтобы справляться с быстрым темпом современного мира и большим объёмом информации, люди стремятся снизить когнитивную нагрузку и выбирают простоту. В этом помогает единообразие (одна из эвристик Якоба Нильсена);
— Единообразие — способность вести себя или действовать одинаково;
— Единообразие одинаковых элементов интерфейса помогает быстрее освоиться новым пользователям, меньше путаться и ошибаться, снижает когнитивную нагрузку, работает на силу бренда;
— Визуальное единообразие — похожие элементы выглядят одинаково. Посты с разными типами контента всё равно должны быть похожи на посты;
— Функциональное единообразие — похожие элементы ведут себя одинаково. На любой пост можно нажать, чтобы его прочитать;
— Внутренняя согласованность — различные части интерфейса или бренда выглядят и работают как единая система. Ключевые кнопки раскрашены в цвет бренда;
— Внешняя согласованность — элементы интерфейса ведут себя так же как и в других продуктах такого типа. Подчёркнутый синий текст ведёт себя как ссылка;
— Как сделать дизайн единообразным и согласованным: придерживайтесь узнаваемых шаблонов (обычно красный цвет показывает что-то негативное, зелёный — позитивное), системно подходите к использованию шрифтов, цветов и изображений, придерживайтесь фирменного стиля во всех каналах коммуникации, не забывайте о единообразии в тексте (терминология, стиль, tone of voice);
— Даже непоследовательное использование регистра (написание с заглавной только первого слова в кнопке или каждого слова) может вызывать дискомфорт.

In English. #heuristic

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

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

#metrics

Евгений Паршин написал о Riskiest Assumption Test (RAT).

— Это быстрая проверка идей, провал которых может похоронить весь продукт целиком;
— Для проверки идеи не обязательно нужен MVP. Проверить спрос можно с помощью лендинга с рассказом о продукте и формой заявки;
— Надо 1) выделить рискованные гипотезы — предположения, из-за которых с высокой вероятностью продукт не выживет, 2) оценить степень их значимости, 3) протестировать самые опасные;
— С помощью RAT можно проверить спрос, ценность продукта для пользователя, юнит-экономику и правильность выбранного сегмента;
— Найти рискованные гипотезы можно через исследования, брейнштормы, самостоятельные рассуждения. Например, можно посмотреть на Lean Canvas и спросить себя: что может пойти не так, что мы ошибочно приняли за истину?
— Каждую гипотезу можно оценить по способности похоронить продукт, количеству ресурсов, необходимых для проверки гипотезы, сложности тестирования, времени проверки.

#product #research

Алиса Шефер и Саша Липатова написали, как UX-редакторам встроиться в дизайн-процесс.

— Знакомьтесь с командами не только дизайнеров, но и аналитиков, тестировщиков и маркетологов, которые работают над вашим продуктом. Повторять знакомство можно раз в квартал: люди приходят и уходят, меняются зоны ответственности редакторов;
— Задачи на текст надо ставить одновременно с задачами на дизайн, а если задача небольшая, то хотя бы за неделю до дедлайна. Так можно успеть погрузиться в контекст и собрать вводные, а не просто поправить формулировки;
— Чем полнее задача описана, тем лучше. Смотрите в статье шаблоны с вопросами, что писать в задачах на текст а) целого сценария, б) экрана или попапа, в) письма, пуша или смс;
— Создайте таблицу ответственности (например, в виде модифицированной матрицы RACI), чтобы коллеги легко могли понять, к кому из редакторов обратиться с конкретным вопросом или задачей;
— Разработайте и обновляйте гайды, глоссарии и редполитику. Опишите процесс работы над задачами и отличия разных редакторских ролей: основатель проекта, партнёр, ревьюер. Чтобы эти документы оставались актуальными, бронируйте на них 1 час в день;
— Чтобы новые продакты или тимлиды не забывали подключать редакторов к задачам, проводите 15-минутные онбординги с рассказом о процессе, базе знаний и гайдах;
— Соберите всех пишущих (и UX-редакторов, и копирайтеров из отдела маркетинга) в один чат, чтобы всегда можно было обсудить какие-то изменения в тексте и не копить недопонимание.

#process #writing

Андрей Маркелов написал о шкалах в дизайне графиков.

— Построение графика начинается с выбора осей. Чаще всего это 2 оси. В основе оси — шкала (линия с делениями);
— Вертикальная ось не всегда должна быть слева. В финансовых системах её располагают справа (ближе к более актуальной части графика). А ещё текущую цену выделяют цветом и пунктирной линией от края графика;
— Легче всего читается толщина графика от 1,3 до 1,6 пикселей;
— Вертикальную шкалу нужно подстраивать под значения графика в видимой области. Нижняя точка должна быть чуть ниже минимума на графике, а верхняя точка — чуть выше максимума;
— Шаг вертикальной шкалы выбирается делением на несколько равных частей, чтобы расстояние между делениями было не слишком широким и не слишком узким (от 40 до 90 пикселей). В идеале должны получаться круглые числа;
— Двухсекционная шкала, в которой используется сразу два масштаба, помогает видеть, например, какой отображается год на месячной шкале (используется в терминале Блумберга);
— Шорткаты позволяют быстро посмотреть график за конкретный период. Например, W — за неделю, YTD — от начала года до сегодня. Обычно они размещаются над графиком;
— В финансовых системах графики часто смотрят в процентах. За 100% принимается самая левая точка графика в зоне видимости. Остальные деления пересчитываются в проценты относительно этой отметки;
— Логарифмическая шкала строится так, что рост в N раз будет занимать одинаковую высоту в любом месте графика. Можно сравнивать рост цены в 2 раза полвека назад и в прошлом году, и видеть одинаковое изменение.

Смотрите также, как делать подписи для таймсерий. #data_visualization

Сеара Кроушоу написала о перетаскивании: первая, вторая часть перевода.

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

In English. #drag_and_drop

20 самых популярных постов UX Notes в 2022 году в Телеграме.

Перед прошлым Новым годом я включил реакции, и теперь могу составить топ по обратной связи от читателей в Телеграме. Будет интересно потом сравнить его с аналогичным топом в ВК. Указанное количество лайков = лайки минус дизлайки.

1. Сергей Шандарин написал о поиске работы дизайнером за рубежом (после 24 февраля). 52 лайка

2. Иван Звяхин поделился чеклистом для самостоятельной проверки интерфейса. 52 лайка

3. В Heads and Hands написали о приоритизации фич по модели Кано. 46 лайков

4. Маргарита Романова написала о поиске работы продуктовым дизайнером в Европе. 43 лайка

5. Брайан Миллар написал об экстремальных пользователях. 40 лайков

6. Читатели рассказали в комментариях о своих телеграм-каналах. 39 лайков

7. Эдвард Скотт написал о хлебных крошках в мобильных версиях интернет-магазинов. 39 лайков

8. Игорь Штанг написал о современной русской пунктуации на примере упаковки умной розетки Яндекса. 38 лайков

9. В Purrweb написали об адаптации интерфейса для стран Ближнего Востока. 38 лайков

10. Илья Бирман написал о кнопке «Подробнее» в карточках. 38 лайков

11. Ксения Беляева написала о дизайн-ревью, когда дизайнер проверяет, как разработчик воплотил его дизайн. 37 лайков

12. Энтони Ценг написал, на что можно заменить большое меню, состоящее из нескольких колонок. 37 лайков

13. В «Собаке Павловой» написали о специфике проектирования медицинских интерфейсов. 36 лайков

14. Чем отличаются униширинные и моноширинные шрифты. 35 лайков

15. Игорь Штанг написал, что делать с текстом в скобках (например). 35 лайков

16. Станислав Хрусталёв написал о лучших практиках работы с корзиной. 34 лайка

17. Андрей Насонов написал о модальных окнах. 34 лайка

18. Наталья Стурза написала о чек-листе проектирования, который помогает не упускать детали, создавая сложные продукты. 33 лайка

19. Эдвард Скотт написал о частых ошибках в дизайне интернет-магазинов одежды. 33 лайка

20. Барт Гиссенс написал, почему курсор в операционных системах наклонён. 33 лайка

А вот 20 самых популярных постов, если считать по лайкам в ВК.

Только 5 статей попали и в вкшный и в телеграмный топ:
— Чеклист для самостоятельной проверки интерфейса Ивана Звяхина;
— Heads and Hands о приоритизации фич по модели Кано;
— Ксения Беляева о дизайн-ревью;
— «Собака Павлова» о специфике проектирования медицинских интерфейсов;
— Чеклист проектирования сложных продуктов Натальи Стурза.

2 автора оказались в обоих топах, но с разными материалами:
— Илья Бирман а) о дизайн-системах, б) кнопке «Подробнее» в карточках;
— Энтони Ценг а) об адаптивных таблицах, б) замене большого меню.

А Игорь Штанг оказался единственным автором с двумя материалами в телеграмном топе:
— О современной русской пунктуации;
— Что делать с текстом в скобках.

Интересный феномен, когда кто-то прилагает дополнительные усилия, чтобы сделать хуже.

Например, в телевизоре миллион способов «обработать» (ухудшить) изображение, хотя все, что от него требуется — просто показать цифровой сигнал ровно в том виде, в котором он поступает на порт. Все, лучше уже не сделаешь.

Или Твиттер, они пыжились, придумывали алгоритм «умного» кропа изображения. А в итоге лучший кроп — это не кропать картинку вообще. Если я прикладываю изображение, наверное, я хочу, чтобы его увидели целиком, а не какую-то часть? Если бы мне нужен был кроп, я бы кропнул.

«Алгоритмические» ленты в ту же степь. Лучшая алгоритмическая лента — обратная сортировка по дате. Если бы мне был не интересен какой-то контент, я бы от него отписался, не? А если я подписался, значит я хочу его видеть, епт.

Иногда, чтобы сделать хорошо, достаточно просто ничего не делать.

Андрей Маркелов написал о линиях в дизайне графиков.

— Важно правильно выбрать толщину линии. Толщина в 1,3 пикселя даёт лёгкую воздушность. Стоит добавить скругление изломов;
— Если отображаются 2 графика, для облегчения восприятия к первому добавляют градиент: 15% прозрачность в верхней точке и 0% у горизонтальной оси;
— Линиям добавляют обводку, равную толщине линии, чтобы избежать шума на стыках;
— Сканер позволяет узнать значение параметра в любой точке графика. Это вертикальная линия, накладывающаяся поверх графика и следующая за курсором. В месте пересечения с графиком ставится точка и отображается значение параметра. Под сканером отображается дата (или то, что находится на горизонтальной оси). Сканер хорошо работает для нескольких графиков;
— В финансовых системах используются индикаторы — миниграфики под основным графиком. Например, столбчатая диаграмма, показывающая спред или объём торгов, или график RSI;
— Японские свечи — особая столбчатая диаграмма. Прямоугольник показывает изменение цены (её значение при открытии и закрытии торгового дня), а линия показывает минимальное и максимальное значение, которого достигала цена в течение дня.

#data_visualization

Александра Савельева написала об обновлении устаревших таблиц в большом продукте.

— Проведите презентацию, какие проблемы можно решить обновлением. Подсветите несуразности в текущей работе элемента. Покажите красивый макет, каким всё станет. Заручитесь поддержкой руководства;
— Конкретные дизайн-решения могут сделать таблицы удобнее (ссылки на материалы с рекомендациями есть в статье и здесь: #table). Перевод их на компоненты повысит консистентность и увеличит скорость разработки новых таблиц;
— Сделайте хорошую новую таблицу на какой-нибудь одной странице (например, при создании новой функции);
— Итерационно, небольшими шагами замените старые таблицы на новые во всём продукте. Это позволит сильно не задерживать выпуск новой функциональности;
— В начале не будет никакого результата. Чтобы не сдаться, ищите поддержки у других дизайнеров;
— Если говорят «работает — не трогай» (в новом дизайне можно не учесть все нюансы предыдущего решения), можно предложить чисто визуальное обновление (фейслифтинг).

#table #process

Олег Королев написал о количественных исследованиях с помощью опросов.

— Их можно разделить на разовые (статистическая проверка гипотез) и регулярные (отслеживание динамики оценки);
— Регулярные: NPS, CSAT, CSI (помогает понять, насколько клиентам важны характеристики используемого продукта), CES (насколько сложно было взаимодействовать с компанией при решении своей задачи);
— Опросы наиболее эффективны на этапе исследования, тестирования и сбора обратной связи после разработки;
— С ними нельзя выявить глубинные мотивы и проверить сложные гипотезы и сценарии. Опросы не будут 100% истиной, так как люди лгут, забывают о своём опыте и часто только предполагают, как могли бы поступить;
— Чтобы провести разовый опрос, надо обозначить проблему и определить цели. На этапе исследования: проверить гипотезы о целевой аудитории, узнать её характеристики (в том числе, какими конкурирующими продуктами пользуются), отношение к услуге;
— Для расчёта размера выборки есть калькуляторы. По опыту, почти никогда не нужно больше 400 ответов на сегмент;
— От целевой аудитории зависит канал общения, а от него — формат вопросов. В почте допустимы длинные заходы, 5–7 вопросов (в том числе открытые), пояснения в скобках. В чате лучше использовать шкалы и вопросы с вариантами ответов;
— Закрытые вопросы лучше задавать в начале опроса. Они помогают быстро сегментировать респондентов. Но не спрашивайте, условно, про семейное положение, если эта информация не повлияет на продукт;
— Вопросы могут отличаться для разных категорий клиентов. Пользователей, которые зарегистрировались, но не используют продукт, можно спросить о целях, актуальности продукта для них и почему они его не используют;
— И для разных ситуаций. При раннем оттоке можно спросить о самой большой проблеме при взаимодействии, что компания может сделать, чтобы исправить ситуацию;
— При анализе ответов можно посмотреть сочетание ответов на несколько вопросов, чтобы понять зависимость одних ответов от других;
— Если вы можете узнать что-то о клиентах из аналитики или CRM, не спрашивайте об этом в опросе.

#research #survey

Маргарита Романова показала, как без больших трудозатрат повысить интерактивность прототипов в Фигме.

— Выделение строки таблицы, отображение раскрывающегося списка действий со строкой, изменение статуса строки — с помощью интерактивных компонентов;
— Для раскрывающегося списка настройка Absolute position позволяет игнорировать Auto layout компонента, в котором он находится;
— Для Auto layout таблицы настройте Canvas stacking: First on top. Так верхние строки расположатся в слоях выше, и нижние строки не будут перекрывать раскрывающиеся списки действий;
— Отображение в таблице большого количества тултипов;
— Component properties позволяет работать с текстом, не переходя на конкретный слой с текстом. Функция Expose properties from Nested instances позволяет редактировать текст тултипа прямо в свойствах инстанса родительского компонента;
— Чтобы редактировать текст тултипов, которые отображаются с помощью интерактивного компонента, для состояния компонента без тултипа надо добавить тултип с нулевой прозрачностью.

#figma #prototype #table

Кирилл Улитин написал о цвете в интерфейсе: о контрасте и конфликте разных информационных слоёв цвета.

— Цветовые пространства RGB и производные от него HSB и HSL не адаптированы для человеческого восприятия. Изменение оттенка даёт цвета, неравномерные по контрасту. Цветовые модели LCH и HSLuv призваны это исправить;
— Контраст зависит от способа воспроизведения: на электронно-лучевых экранах контрастнее жёлтый на чёрном, на светодиодных — чёрный на белом;
— Алгоритм расчёта контраста в WCAG 2.1 иногда ошибается. В новую версию стандарта доступности вошёл алгоритм APCA. Можно использовать инструменты Huetone и Accessible Palette;
— Алгоритмы проверяют цвета в идеальных условиях и не учитывают пользовательский контекст: тип матрицы экрана, яркость, режимы вроде Night Shift или корректирующие очки;
— Цвет может обеспечивать узнаваемость бренда;
— Apple в руководстве по интерфейсному дизайну говорит о том, что конфликт разных информационных слоёв цвета нежелателен: красное сообщение о критической проблеме будет менее эффективным, если красный используется в приложении для некритичных ситуаций;
— При этом в новой версии macOS Big Sur разработчикам дана возможность настраивать основной цвет интерфейса приложения;
— Когда цвет бренда (например, красный) совпадает со статусными цветами в интерфейсе (сообщения об ошибках) надо вводить дополнительный цвет для элементов интерфейса, отличающийся от брендового (например, Microsoft Office 365), или добиваться цветовой разницы от 30 до 40 единиц (например, МойОфис).

#color #accessibility

Фейфей Лиу написала о переводе пользовательского контента.

— Если продуктом пользуются люди из разных стран и пользовательский контент важен (например, это могут быть отзывы), дайте пользователям возможность перевода всех или отдельных записей или заранее переводите весь контент;
— Если отзывов мало, пригодится кнопка перевода отдельного отзыва, чтобы дополнить их мнениями иностранных покупателей (Etsy);
— Не отображайте кнопку перевода, если язык отзыва совпадает с языком пользователя;
— Если преобладают отзывы от иностранцев, пригодится кнопка «Перевести все», чтобы не переводить каждый отдельный отзыв (Amazon). Особенно актуально для развлекательного контента, когда пользователям проще уйти на другой ресурс, чем переводить вручную или прокручивать недоступный контент;
— В таком случае можно переводить контент заранее и отображать отметку о переводе и кнопку для просмотра оригинального текста;
— Стоит учесть, что сервисы для такого автоматического перевода не бесплатны;
— Если отзывов на разных языках достаточно много, дайте возможность отфильтровать их по языку (Booking, Weverse).

In English. #localization #ecommerce

Александр Аникеев написал о позициях восприятия.

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

#psychology

Алина Ермакова написала, что делать, когда от команды осталась половина.

— «Когда ты смотришь на свою команду шире, чем на отдел в компании, отпускать становится проще»;
— Это повод пересмотреть процессы, от чего-то отказаться, перераспределить нагрузку;
— Попросите руководителей оценить значимость каждого проекта. Оцените планы по самым важным проектам и вложитесь в критичные задачи;
— Сверьтесь с приоритетами компании на год: создавать инновации, удерживать и повышать качество, оптимизировать ресурсы? Это поможет понять, какие задачи можно брать в работу;
— Оставьте место концептам: новым продуктам и процессам. Если заниматься только операционными задачами, можно превратиться в завод, из которого рано или поздно захочется сбежать;
— Обучайте людей вокруг, чтобы они помогали решать ваши задачи. Например, чтобы повысить уровень запросов на исследования, обработки полученных данных;
— «Только честно прожив опыт отпускания несколько раз, вы научитесь перезапуску команды и процессов».

#management