Алита Джойс написала о всплывающих подсказках (tooltips).

Всплывающая подсказка — это краткое сообщение, которое отображается при наведении курсора на элемент интерфейса (или фокусировке на нём с помощью клавиатуры).

1. Не стоит прятать в подсказки важную информацию, без которой пользователю не выполнить нужное действие. Например, длинный список требований к паролю.

2. Подсказка должна быть краткой.

3. Подсказка должна быть полезной. Если на кнопке написано «Add new line», в подсказке к ней нет смысла писать «Add new line».

4. Всплывающая подсказка должна отображаться и при наведении курсора, и при фокусировке на элементе интерфейса с помощью клавиатуры.

5. Чтобы было ясно, с каким элементом связана подсказка, у неё должна быть стрелка, указывающая на этот элемент.

6. Будьте последовательны. Если всплывающая подсказка есть у одной иконки, она должна быть и у другой.

7. У иконок без подписей должны быть всплывающие подсказки.

8. Подсказка не должна перекрывать информацию, связанную с текущей целью пользователя.

https://ux.pub/rukovodstvo-po-vsplyvayushhim-podskazkam-tooltips/

Игорь Васильев написал о проектировании страниц-заглушек.

Пользователь видит пустой экран, когда:

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

2. Содержимое должен создать сам пользователь. Надо объяснить пользователю, что от него зависит наполнение этой страницы, и предложить ему сделать первый шаг. Например, перейти в список ресторанов, чтобы добавить что-то в избранное. Можно предложить ему подборку лучших ресторанов в городе.

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

4. Поиск ничего не нашёл. Если причина в опечатке, стоит попробовать её исправить. Также можно показать похожие товары из заданной категории, предложить ослабить фильтры или вернуться к полному списку товаров.

Общие рекомендации:
1. Предложите действие: наполнить страницу, посмотреть аналоги, сообщить о проблеме.
2. Добавьте иллюстрацию, чтобы разрядить обстановку.
3. Будьте краткими.
4. Текст сообщения начинайте с цели: «Чтобы найти любимые места, перейдите в список ресторанов».
5. Говорите по-человечески: пишите «На сегодня ещё нет планов» вместо «13.02.2019 ничего нет».
6. Добавьте немного юмора или жаргона, если продукт нацелен на узкую аудиторию.
7. Язык должен соответствовать платформе. В мобильном приложении — tap, в десктопном — click.

https://vc.ru/design/58918

В «Сибириксе» написали о Турбостраницах Яндекса и технологии Accelerated Mobile Pages, которую поддерживает Гугл. Это отдельные версии страниц, которые моментально открываются из результатов поиска.

Плюсы: быстрая загрузка, высокие позиции в поиске, место в «карусели» в гугловом поиске.

Минусы: отдельная вёрстка, упрощённый внешний вид (сложно брендировать), обрезанная функциональность, сложности с аналитикой, сокращение трафика (пользователи просматривают контент фактически с серверов поисковых систем).

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

https://blog.sibirix.ru/2019/02/19/amp-pages/

Ольга Шаврина продолжила рассказ об использовании Google Optimize для проведения а/б-тестов.

Как тестировать:
— Всплывающие блоки вроде по умолчанию скрытой плашки с календарём (режим Interactive mode);
— Сразу все типовые элементы на странице, например, карточки товаров в каталоге (кнопка Select similar);
— Совершенно новые элементы интерфейса ↓

Экспериментальный дизайн отображается после полной загрузки страницы, поэтому пользователь может заметить исчезновение новых элементов. Это снижает доверие. Скрытие всего содержимого страницы до загрузки эксперимента замедляет продукт. Чтобы избежать этого, новые элементы следует добавлять в скрытом виде (display: none), а в рамках эксперимента включать их. Тогда пользователь может заметить не исчезновение, а появление элементов, что вполне нормально для современных сайтов.

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

Как проверять экспериментальный дизайн на мобильных устройствах: Preview → Share preview → Открытие полученной ссылки в любом браузере.

#ab_testing

Эдуард Файзуллин написал о том, как способ отображения цены влияет на конверсию. Чтобы конверсия была выше:

1. Цена должна быть. В b2b её часто не указывают, так как:
— В этой сфере не принято. Контрпример: на сайте SpaceX есть цены на ракеты.
— Нет стандартных расценок. Можно указать минимальную стоимость.
— Конкуренты будут в курсе. Они и без сайта будут в курсе.

2. Пишите $2,99 или $2,90 вместо $3,00.

3. Цифры после запятой (99 или 90) уменьшайте визуально.

4. Показывайте зачёркнутую старую цену. Для усиления эффекта можно написать, сколько покупатель экономит в процентах и в абсолютном значении.

5. Разделяйте базовую стоимость заказа, стоимость платной доставки и другие дополнительные платежи вроде НДС.

6. Можно показать размер ежемесячного платежа, но акцент должен быть на базовой цене, чтобы не было ощущения обмана. Усилить эффект можно сравнением месячного платёжа с обычными мелкими расходами, например, со стоимостью чашки кофе. (Примечание редактора: сравнение с кофе всех уже достало.)

https://spark.ru/startup/conversant/blog/45663/

На «Меле» написали о канцеляризмах в тексте.

1. Слово «являться» почти всегда можно удалить. «Я являюсь писателем» → «Я писатель».
2. «Ввиду» → «Из-за».
3. «В настоящее время» → «Сейчас».
4. «В связи с этим», «в силу этого» → «Поэтому».
5. «Имеет место быть», «имеется» → «Есть».
6. «Данный» → «Этот». Иногда без указательных слов можно обойтись: «В данном тексте допущена ошибка» → «В тексте допущена ошибка».
7. Расщепление сказуемого — использование существительного с глаголом вместо глагола. «Производить проверку» → «Проверять»; «Выполнить доставку» → «Доставить»; «Озвучить возражение» → «Возразить».
8. Расщепление подлежащего или существительного: «Денежные средства» → «Деньги»; «Заработная плата» → «Зарплата».
9. «Осветить вопрос», «поставить вопрос», «поднять вопрос» → «Рассказать».
10. «В процессе чтения книги я узнал» → «Из книги я узнал».

https://mel.fm/gramotnost/2841970-officialese_phrases

Видео с петербургского Design Prosmotr 2018 года:

1. Дмитрий Пёрышков — Дизайн как социальный инструмент
youtube.com/watch?v=Eix4JHKWkuI

2. Юрий Гордон — Композиция как образ жизни
youtube.com/watch?v=-0VIaXfImGI

3. Денис Машаров — Парадигмы типографики
youtube.com/watch?v=LJJXYgMMbUc

4. Покрас Лампас — Дизайн и искусство будущего
youtube.com/watch?v=MY9xLfGHpnA

5. Денис Шлесберг — Зачем дизайнеру оба полушария
youtube.com/watch?v=ODNlOZLcri0

6. Александр Ратасеп — Инструменты дизайна будущего
youtube.com/watch?v=Tf5CcqBdn-0

7. Максим Пономарёв — Ловушки креативного мозга
youtube.com/watch?v=pbPQAMUzkPM

8. Андрей Курпатов — Мозг: инструкция по применению
youtube.com/watch?v=953uZgYNj9g

9. Артур Арсёнов — Как превратиться из дизайнера в компанию
youtube.com/watch?v=hSlHG0IldhU

10. Данила Шорох — Медиа-дизайн сейчас
youtube.com/watch?v=VdyiVkxhfZg

Александр Овчаренко рассказал о красном цвете в ночном режиме интерфейса.

Приборные панели в автомобилях часто подсвечиваются красным или переключаются на красную подсветку ночью. Красными лампами освещаются судовые мосты на ночной вахте. У судовых радаров некоторых производителей — красный интерфейс.

За ночное зрение отвечают рецепторы-палочки. Химические процессы, повышающие чувствительность палочек, занимают от 10 до 20 минут. Рецепторам-колбочкам, которые отвечают за дневное зрение, для активации надо около 15 секунд.

Если перевести взгляд с тёмного объекта на яркую приборную панель, адаптация ко тьме займёт некоторое время. Яркая приборная панель отключает ночные рецепторы, если просто находится в поле зрения.

Самые чувствительные дневные рецепторы — колбочки L-типа. Они воспринимают жёлто-красную часть спектра.

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

Красные очки использовались для адаптации лаборантов, которым надо было выходить из тёмной лаборатории на свет и возвращаться в неё обратно.

#dark_theme

Хосе Торре написал, как проектировать быстрее.

Проектирование — итеративный процесс. Чем быстрее вы работаете, тем больше вариантов можете попробовать, чтобы понять, что не работает, и улучшить решение.

1. Определите свою цель.

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

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

4. Поделитесь своим прогрессом и получите обратную связь. Лучше раньше, чем позже. Члены вашей команды могут что-то добавить, и это будет уже ваша общая идея, защищать и продвигать её будет проще.

5. Слушайте. Не стоит полагаться исключительно на своё мнение, если вы проектируете не только для себя.

6. Проектируйте поэтапно. Разделите проект на контрольные точки:
— Общая идея в виде грубых набросков, несколько вайрфреймов, которые показывают сценарий взаимодействия;
— Расширение идеи в виде грубого прототипа;
— Завершение в виде прототипа высокой точности или финальной анимации.

Так вы избежите комментариев о цвете на этапе, когда вы пытаетесь увидеть, как работает общая идея.

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

https://ux.pub/7-sovetov-kotorye-pomogut-proektirovat-bystree/

Лев Соломадин написал об особенностях подхода к дизайну в реальном производственном секторе на примере компании «Сибур».

«Тобольск, −40, темно, видимость не особо, ты ходишь брать пробы. К тебе приходят ребята из цифрового подразделения и радостно сообщают: „Всё, порешали мы твою проблему с бумажками, на тебе, мужик, смартфон“. А ты сидишь и думаешь — ну офигеть теперь, на 20 метров забираться, а там ещё смартфон этот доставать и тыкать чего-то».

«Мы гораздо ближе к пользователю нашего продукта. Это же касается и онбординга — никаких непоняток и разночтений. Собираем ребят, показываем им, как именно порешали их проблему, чего и где изменилось, как пользоваться всем этим».

https://habr.com/ru/company/sibur_official/blog/439818/

Антон Жиянов неделю вёл коллективный твиттер продактов и по итогам составил статью с мыслями (и ссылками на материалы, которые эти мысли развивают) про продукт и фичи, B2B и кровавый энтерпрайз, API и документацию, техподдержку, разработку, интерфейс и людей.

«Главная проблема „долгоживущих“ продакт-менеджеров и вообще любых сотрудников: со временем у человека замыливается глаз. Команда перестаёт видеть очевидные извне проблемы продукта и упускает возможности.

Знаю один сервис, где нельзя зарегистрировать двух пользователей с одинаковым именем (то есть не может быть две „Анны“, например). Основатель мне на полном серьёзе объяснял, что это фича и так и должно быть».

«Самое „весёлое“ в российском B2B — это документооборот, так же известный как „счета и акты“. Если вы прискакали из мира мобилок на розовом пони, эта штука срежет вас как наточенный серп».

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

https://antonz.ru/productology/

Появились первые видео с ProfsoUX 2019 года:

1. Иван Бакаидов — Пандус для интерфейса
https://vimeo.com/324745869

2. Михаил Правдин — Собираем все UX-находки в одном месте. Как обработать и не потерять результаты исследований
https://vimeo.com/324745961

3. Нелли Кам — Образовательное выгорание
https://vimeo.com/324745915

4. Алёна Кирдина — Работа над ошибками
https://vimeo.com/324745933

5. Scott Sullivan — Machine Learning for Designers
https://vimeo.com/324745884

6. Hyacinthe Briand — Designing with Data
https://vimeo.com/324745892

7. Наталья Мануйлова — UX-стратегия — ценность продукта
https://vimeo.com/324745835

8. Тамара Кулинкович — Долина страданий. Как продавать исследования и продавать с помощью исследований
https://vimeo.com/324745949

9. Диана Вайнберг — Эвристики как база знаний по UX
https://vimeo.com/324745907

Станислав Хрусталёв описал идеальный customer journey посетителя ресторана.

«Отвечая на негативный отзыв, стоит также писать контакты заведения и предлагать выйти на связь. Ряд платформ поддерживает только ответ заведения на отзыв без возможности дальнейшего обсуждения. Связь с клиентом может потребоваться для уточнения информации и более глубокого расследования ситуации».

«Все телефоны ресторана должны поддерживать функцию определения номера, чтобы не спрашивать номер клиента при бронировании, а просто подтверждать: „Записать номер, с которого звоните?“»

https://hardclient.com/restaurants

Интервью с Денисом Башевым, основателем дизайн-агентства DILETTANT.

«Большинство дизайнеров не понимают, в чём заключается их работа. Начинаются сравнения в духе „Лебедев или кто-то ещё нарисовал логотип, он похож на…“. Люди не понимают, что уникальности в проекте может вообще не быть.

Когда клиенты говорят, что им нужен логотип, не похожий вообще ни на что, то я за это не берусь. Я не смогу его сделать. Слишком долго уже люди занимаются дизайном, и образов похожих очень много. Гораздо важнее быть уместным, чем уникальным».

«— Ты работаешь над проектом у клиента, просишь выделить себе место в его офисе. Делаешь так сейчас? Как тебе такой формат?

— Я так работаю до сих пор. Потому что это интереснее, проще, быстрее, тебе не надо делать варианты. Меньше правок. И это опыт, сидеть в разных конторах гораздо круче, чем дома. Надо многим фрилансерам перейти на такой режим».

«— Ты не считаешь, что дизайн спасёт мир. Почему для тебя он важен?

— Мне удовольствие доставляет. То, что я навожу порядок в комнате по сути тоже бесполезно. Кому какое дело, чисто у меня или нет. Но испачкается, тебе приходится наводить порядок. В дизайне то же самое. Ты наводишь порядок в определённом визуальном куске. Мне комфортно быть дворником в этом плане. Оно моё».

https://designpub.ru/a5e7c1124203

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

«Мы дали респондентам задание: „Вот ваш чай, представьте, что вы пришли с работы домой, и у вас есть 20−30 минут свободного времени. Перед вами портал Mail.Ru, просто проведите время с интересом, читайте и смотрите, что хочется, а что не хочется — не читайте“. После чего исследователь перешёл в наблюдательную комнату.

Мы видим, как одна из девушек читает статьи про селебрити одну за другой. Когда исследователь вернулся в тестовую комнату, он спросил: „Расскажите, что вам больше всего запомнилось из того, что вы прочитали?“.

Та самая респондентка ответила: „Ну я тут почитала РБК…“

Люди врут. Цели у этого могут быть разные. В данном случае ей просто хотелось показаться лучше, чем она есть. Это называется „социально-желательное поведение“. При изучении темы нельзя ограничиваться только интервью, иначе вы узнаете, что все читают РБК, каждый день занимаются спортом и много зарабатывают».

https://www.sternina.com/notes/users-lie/

Тим Шеинер написал о «цифровой машине» — схеме, которая описывает цифровой продукт как совокупность 5 моделей: пользователя, ценности, взаимодействия, объекта, данных.

Они всегда существуют в виде неосознанных допущений в головах участников проекта. Такие допущения — основной источник неразберихи.

1. Модель пользователя описывает того, кто использует цифровую машину, и определяет цели, действия и эмоции. Для проекта это вымышленный персонаж с определёнными характеристиками.

2. Модель ценности определяет, каким должно быть первое впечатление о продукте. Её можно представить в виде высказывания:

[Название продукта] — это [категория пользовательского опыта], которая приносит мне [такую-то пользу] и лучше альтернативных решений [по таким-то причинам].

Если эта категория продуктов интересует персонажа, он изучит остальную часть модели ценности, если нет — не станет тратить время.

3. Модель взаимодействия определяет, как человек меняет состояние цифровой машины: какие данные вводит и какие сигналы обратной связи получает.

Это история о том, что пользователь делает с софтом. Участникам проекта проще всего обсуждать именно эту модель. Опасность в том, что команда слишком рано и безоглядно сосредотачивается на модели взаимодействия, не описав должным образом другие модели, от которых та зависит.

4. Модель объекта — самая важная, потому что она определяет детали машины и их взаимосвязь.

Чем подробнее история в модели взаимодействия, тем выше детализация и точность описания объектов, вступающих во взаимоотношения. Верно и обратное: если разбить объекты на подобъекты, история их взаимодействия становится более подробной.

5. Модель данных строится на основе простого принципа — пара имя/значение.

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

https://sobakapav.ru/publications/designing-digital-mental-models

Андрей Клёц написал о популярных проблемах форм в банковских приложениях.

1. Отсутствие маски при вводе номера телефона. Используйте маску вида +7 ( ) _-__-. Автоматически исправляйте ошибки ввода.

2. Неинформативные сообщения об ошибках. Плохо, если сообщение содержит технические термины, написано латиницей, находится над или под формой, так что пользователю не ясно, с каким полем оно связано. Хорошо, если указана причина ошибки и способ её устранения.

3. Неинформативные подсказки. Не стоит повторять в них название поля, писать очевидные вещи и использовать непонятные термины. Полезно объяснить, что означает название поля, в каком формате вводятся данные, сколько символов надо ввести, откуда брать информацию для ввода.

4. Подсказки и названия полей, которые исчезают после начала ввода. Располагайте подсказки над полем, выносите их в заголовок после начала ввода или показывайте маску ввода.

5. Отсутствие возможности посмотреть введённый пароль. Его можно показывать временно при нажатии на специальный значок.

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

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

8. Активная кнопка отправки формы при незаполненных полях. Пользователь считает, что форма заполнена верно, и в итоге сталкивается с сообщением об ошибке.

9. Перегруженная форма (характерно для платежей по квитанциям). Выделите главные поля, ненужные скройте.

10. Буквенная клавиатура вместо цифровой при заполнении числовых полей (вроде поля «Сумма»).

http://usabilitylab.ru/blog/usability-form-vvoda/

Раз уж у нас суббота, расскажу еще одну историю. Я ее очень часто рассказываю на своих выступлениях, так что если вы меня и так неплохо знаете, подкидываю годную идею: промотать этот пост и вместо этого пойти пить березовый сок, есть чашушули, смотреть на Фудзияму, пожирать сладкий картофель батат, сажать саженцы на даче, плясать гопак, ну или что вы там обычно делаете по субботам.

А история в следующем. Жила-была одна страховая компания, которая решила сделать себе личный кабинет пользователя: всякое там оформление страховок, просмотр полисов, туда-сюда. Нет, так-то у них личный кабинет уже был, но он был таким, что, честно говоря, лучше бы его никакого не было.

И вот решила эта страховая компания сделать все по уму в наш век Человекоориентированного Дизайна, Юикса-Сиикса и прочего Хуикса, и отправилась она с заказом в Специализированную Юзабилистическую Контору. Специальная Юзабилистическая контора была клевая: она носила какой-то красивый термин в названии (типа, НИИ ЮИКС или, там, АРТ ОФ ИНТЕРФЭЙС), штат ее сплошняком состоял из специально обученных психологических людей, издали похожих на хипстеров, а в клиентах числился весь белый свет вплоть до ФГУП «ГУСЬ-ХРУСТАЛЬНЫЙ АЛМАЗВНЕШТОРГЭКСПОРТОБЪЕДИНЕНИЕ».

Эти серьезные ребята сходу включились в работу, подняли на крыло целый безумный аэроплан UX-процессов, исследований, групповых фасилитаций, кастдев-оргий и всего такого - и уже через два месяца с лишним принесли заказчику результат: нарисованные интерфейсы лучшего в мире ЛК. Интерфейсы были и правда клевые: от картинок веяло эстетической мощью, за каждой кнопкой скрывалась какая-нибудь UX-премудрость, а на любой вопрос «А почему здесь так?» творцы подпускали нервическую дрожащую ноту в голос и заявляли «ВЫ БЫ ВИДЕЛИ КАКОЙ ТАМ СИДЖЭЭМ» - после чего от них сразу отставали.

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

Заказчик был не против, так что все ударили по рукам, и работа над ТЗ закипела. Впрочем, «закипела» - это громко сказано, потому что она по факту и закипеть не успела: практически сразу же, с главного же экрана ЛК, стало ясно, что в интерфейсе творится что-то поганое.

Нет, поймите меня правильно: интерфейсы сами по себе и правда были клевые, но при попытке описать их логику и привязать ее к существующим системам заказчика оказалось, что интерфейс нарисован как будто в параллельной реальности: например, в интерфейс было заложено редактирование детальной информации по полисам (чего система категорически не позволяла), но при этом не было никаких намеков на заказ нового полиса (как раз эта штука была в системе и без нареканий работала в предыдущей версии ЛК). Интерфейсом предполагалось, что какие-то данные будут подтягиваться в реальном времени - тогда как в реальности они получаются очень долго и раз в сутки. В реальности заявка на определенную справку составляла, по законодательству, 20 полей - а тут их было 3. Ну и тому подобная порнография.

Разработчик изрядно удивился, поднял брови и пошел к заказчику - выяснять, а с хера ли такая радуга в небе возникла. Заказчик, справедливости ради сказать, быстро въехал в тему, быстро забеспокоился и пригласил к себе ребят-юзабилистов - разобраться, как так-то.

И вот тут настает мой любимый момент. Юзабилистические ребята, представшие перед судом Ее Величества Логики, и глазом не моргнули и заявили следующее: «МЫ НЕ ИНЖЕНЕРЫ МЫ КОНСАЛТЕРЫ И ПСИХОЛОГИ И СДЕЛАЛИ УДОБНО А РАЗРАБОТКА ПУСТЬ ПОДТЯГИВАЕТСЯ ОНА ВСЕГДА ВОЗЬМЕТ СВОЕ ПУСТЬ РАЗРАБОТЧИКИ ПОСИДЯТ ПОДУМАЮТ И СДЕЛАЮТ ЭТО УЖЕ ИХ ЗОНА ОТВЕТСТВЕННОСТИ».

В общем, улавливаете, да? Ребята, которые занимаются интерфейсами, вертеть хотели какие-то там технические ограничения и сработали как настоящие Творцы в Сфере Чистого Разума, сделав Хорошо и Удобно. А уж что какие-то черти-разработчики не могут это сделать - это уже их проблемы, пусть учатся.

И вот тут, котаны, на белый свет выползла невообразимая херня: этим хуикс-гуру было невдомек, что доработки по их психологическим капризам потребуют столько денег и отнимут столько времени, что проще будет разогнать страховую компанию и организовать какую-нибудь новую. Под удар был поставлен весь продукт, потому что 3 месяца работы были потрачены впустую, деньги были съедены зря, и руководство страховой было готово махнуть рукой и сказать «ДАВАЙТЕ ЖИТЬ СО СТАРОЙ СИСТЕМОЙ А ЭТИХ UX ПИДАРАСОВ БОЛЬШЕ НЕ БУДЕМ ЗВАТЬ ОТ НИХ ВРЕД ОДИН» - и, что характерно, они были бы не так уж неправы.

В итоге все кончилось хорошо и интерфейс перерисовали под корень (и уже вместе с разработчиками), но вот эту фразу «МЫ НЕ ИНЖЕНЕРЫ МЫ ПСИХОЛОГИ», к сожалению, я сам слышал миллион раз, чтобы понимать - эта ебалайка будет играть вновь и вновь, пока все не поймут, что психология и инженерия - не космически разные явления, а стороны одной монеты под названием UX.

Впрочем, про это мы с вами еще поговорим - и не раз.

Николай Бабич составил правила написания интерфейсного текста. Наименее очевидные рекомендации:

3. Инструкции начинайте с пользовательской цели. «Нажмите на элемент, чтобы увидеть его свойства» → «Чтобы увидеть свойства элемента, нажмите на него».

5. Будьте последовательны. Если в одной части интерфейса вы назвали процесс «бронированием», не называйте его «резервированием» в других частях.

7. Убирайте лишние глаголы. «Видео было загружено» → «Видео загружено».

8. Пишите в активном залоге. «Кнопку „Поиск“ следует нажать, когда вы будете готовы искать статью» → «Чтобы найти статью, нажмите на кнопку „Поиск“».

9. Пишите числительные цифрами. «У вас два пропущенных звонка» → «У вас 2 пропущенных звонка».

10. Раскрывайте информацию постепенно (особенно в мобильных интерфейсах). Если пользователь заинтересовался одним из тезисов, пусть нажмёт кнопку, чтобы узнать больше.

14. Если речь о сегодняшнем, вчерашнем или завтрашнем дне, пишите «сегодня», «вчера» и «завтра» вместо даты.

https://contented.cd/media/text_ux