Usability *

Из разговора с потенциальным клиентом…

Клиент: Сколько страниц будет входить в аудит?
Я: Неизвестно. Почему неизвестно? Потому что у меня нет цели написать определённый объём правок и замечаний. Сколько их увижу — столько и зафиксирую. Если бы я проаудировал систему и не нашёл в ней ни одной проблемы — размер документа не превышал бы одной страницы.

Тут сразу пара моментов, которые хотел бы подсветить.

Я раньше, когда работал над документацией, считал, что «чем объёмнее — тем лучше». Это ещё со школы и универа. Реферат должен быть на пять листов. Эссе на семь. Доклад на три.

Акцент был на форме, а не на содержании. И это ужасно. В начале двухтысячных, когда работал в компании Webmaster.Spb проектировщиком, клиентам нравились толстые ТЗ. Точнее, представителям клиентов. Менеджерам. Сами-то клиенты эти ТЗ не читали, насколько мне известно.

Из строительной тематики тоже была клёвая байка, которую мне рассказал один из клиентов: «Я однажды сдаю своему шефу пачку документации высотой в два сантиметра. А он смотрит на неё и пальцами показывает три сантиметра. Вот столько, говорит, надо. Возвращайся, когда будет пачка высотой в три сантиметра».

Это первый момент. А второй — если во главе стоит форма, а не содержание, то это сродни проектированию главной страницы сайта, когда всё остальное ещё не готово. Спроектировал главную за час, а потом пятьдесят часов подгоняешь остальные сто страниц под неё. Вместо того, чтобы сделать всё без ограничений, а главную рисовать уже в самом конце, когда весь проект будет понятен. В виде вишенки на торте.

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

Прикиньте, кто-то сначала бы придумал тематику: пять начал (законов) термодинамики. И после четвёртого сидел бы и страдал.

Возвращаясь к моим аудитам: у меня нет задачи найти конкретное количество косяков. Задача — проверить, достигают ли пользователи интерфейса своих целей. Если достигают — и отлично! Радоваться надо, что в моём документе будет одна строчка текста («Всё идеально, красавчики»). Это как на чек-ап пойти ко врачу и переживать, что ничего не нашли.

К сожалению, на практике такого ещё ни разу не было. Всегда что-то нахожу.

П.С.
Представляете, я бы сказал, например: «Четыре страницы». Сделал бы аудит и нашёл бы ошибок на две страницы. И что бы делал? То же, что в школе и универе? (здесь должна быть какая-нибудь эмодзи с льющейся бессмысленной водой)

МойОфис Frontend&UX Talks уже начался!

Самое время смотреть и задавать вопросы спикерам в чате митапа!

Митап посвящен главным вызовам и проблемам в сложных интерфейсах. Спикеры расскажут о самых разных аспектах фротенда в 2025 году: от айтрекинга и других методов исследований до реактивного программирования и СSS-спецификаций.

Сам митап разделен на две категории: JavaScript и UX. В каждой из них, помимо наших специалистов, есть ребята и из других компаний: Лаборатория Касперского, Контур, Alpha Research Center. Всего на встрече будет семь докладов – их расписание можно посмотреть здесь.

Смотрите митап прямо здесь:

Также трансляцию можно смотреть на Youtube и ВК.

Заинтересовало? Тогда скорее переходите в чат митапа. Здесь можно задать вопросы спикерам, и получить раньше остальных доступ к записи выступлений :)

Как студенты с айтрекером изучали наш текстовый редактор

Июнь стал месяцем айтрекинга в UX-команде МойОфис. Сначала у нас прошло совместное исследование со студентами ВШЭ, а в ближайшие дни мы проведем крупный митап, где поговорим о создании и анализе сложных интерфейсов, в том числе с помощью технологий отслеживания взгляда.

Важный анонс: 26 июня пройдет онлайн-митап МойОфис Frontend&UX Talks, на котором JS-еры, дизайнеры, продакты и аналитики соберутся, чтобы обсудить все насущные проблемы и нюансы современного фронтенда. Кроме наших экспертов, на митапе будут ребята из Лаборатории Касперского, Контура и Alfa Research Center!

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

Еще немного о совместном исследовании со студентами:

4 июня в нашем петербургском офисе прошла презентация результатов совместного исследования с лабораторией социальной и когнитивной информатики ВШЭ в рамках учебного сотрудничества. Студенты курса «Айтрекинг в UX-аналитике» провели глубокое тестирование текстового редактора МойОфис 3.4 с обновлённым интерфейсом.

Методология:

• Определили самые востребованные задачи у студентов и на их основе составили задания.

• Использовали носимый open-source айтрекер PupilLabs.

• Провели психологические опросы до и после заданий (спойлер: уровень стресса участников не изменился) и когнитивное интервью после.

Ключевые результаты:

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

2. Получили оценки пользователей: лёгкость и чёткость интерфейса.

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

4. Выявлены новые точки роста для развития продукта

P.S. Большая благодарность Елене Артёменко из лаборатории социальной и когнитивной информатики ВШЭ за эту коллаборацию! А если хотите узнать больше о фронтенде и UX-исследованиях — ждем вас 26 июня на Frontend&UXTalks!

Тест на собеседовании на должность проектировщика интерфейсов

Ставим перед соискателем большую коробку с конструктором типа Лего. Задача: собрать его за час. А дальше наблюдать.

1. В коробке должно быть шесть пакетов и инструкция по сборке. В инструкции должно быть указано, что для успешной сборки понадобится семь пакетов. Если соискатель заметит это перед тем, как распечатает первый пакет, и укажет на невыполнимость задачи — он молодец.

2. Конструктор должно быть физически невозможно собрать за час. Первый пакет должен занимать в среднем пятнадцать минут, а остальные пакеты должны быть примерно такого же объёма и сложности и это должно быть заметно. Если соискатель, собрав первый пакет за пятнадцать минут, укажет на невыполнимость задачи — он молодец.

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

К сожалению, этот тест — плод моей фантазии развлекательного характера. Представляете, сколько это мороки — подготавливать и упаковывать в пакеты подобные наборы для каждого нового соискателя? Не, проще пообщаться. Но идея не даёт мне покоя :)

А вот ещё один теоретический способ, с помощью которого я бы проверял квалификацию соискателей. Там про цепляние к мелочам.

TUI Rust, это Хабр. Хабр, я нашёл тебе годноту.

По этой ссылке https://www.youtube.com/watch?v=rWMQ-g2QDsI обнаружилось видео (11:16) с тучей прелюбопытнейших отсылок объединённых идеей использования Rust для написания консольных приложений.

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

• не плоди сущности без необходимости

• используй меньше чтобы сделать больше

• велик C и Rust наследует ему

• всё преходяще, кроме вечного

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

Конкретика: Uutils, Fish, Nushell, Ripgrep, Fd, Bat, Eza, Zoxide, Xh, Zellij, Gitui, du-dust, dua, starship, yazi, hyperfine, evil-helix, bacon, cargo-info, fselect, ncspot, rusty-man, delta, ripgrep-all, tokei, wiki-tui, just, mask, mprocs, presenterm, kondo, bob-nvim, rtx, espanso.

Конкуренты есть у любого продукта

Даже если вы делаете супер инновационный продукт, в нём наверняка есть какие-то элементы, которые уже используются у других (ручки, кнопки, формы, функционал). Когда пользователь будет «вертеть в руках» ваш продукт, он будет интуитивно искать знакомые вещи. Гениальность команды и состоит в том, чтобы добиться вау-эффекта, используя привычные элементы.

«Знакомые» детали дают пользователю ощущение комфорта, «новое» — драйвит интерес и создает вау-эффект (iPhone, AirPods).

Люди не готовы полностью к тому, что кардинально ломает их привычный опыт. Если продукт не даёт точки опоры, то пользователи теряются. Например, Google Glass пока так и не взлетели, хотя потенциал до сих пор кажется огромным.

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

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

Конкуренты — это не только вызов, но и инструмент, с помощью которого можно направить продукт в нужное русло, сохранив баланс между знакомым и новым.

Путь UX-исследователя. Новый выпуск Sravni Podcast

Зачем компаниям нужны UX-исследователи? А как ими становятся? И из чего состоят сами исследования?

Поговорили об этом с UX-исследователями Сравни, Светланой Юдиной и Анной Борзовой. Гости рассказали о нюансах карьерного пути в UX и поделились практическими советами по улучшению опыта пользователей.

Также в выпуске:

• Почему исследователи — это «глаза» компании

• Виды UX-исследований и когда их использовать

• Поиск респондентов и происшествия на интервью

• Как сочетать эмпатию с аналитикой

Посмотреть новый выпуск Sravni Podcast можно здесь:

✅VK
✅YouTube
✅RUTUBE

А послушать — здесь:

✅Яндекс Музыка

Наш тг-канал: Sravni Tech

Развивать отношения с клиентом

Есть несколько архетипов общения сайтов со своими пользователями.

Наставник. Уважительное экспертное общение с уклоном в менторство и обучение.

Друг. Всегда на ты, переход на личности, подарки, близость.

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

Партнёр. Просто профессионально делают свою работу без лишних слов.

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

Ну и ещё есть. Они по-разному называются, но суть примерно одинаковая. Ещё это всё можно назвать Tone of Voice (голос продукта).

К чему это я? Многие сайты, один раз выбрав стиль общения, уже не отходят от него, как бы долго юзер ни пользовался сервисом. И получается эффект примерно как в жизни. Когда мы маленькие дети — нам нравится, что мама о нас заботится. Чем взрослее, тем всё больше эта забота нам кажется навязчивой и даже бесит.

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

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

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

Привет, Хабр! 👋 Сегодня говорим про

WCAG и подбор цветов: когда можно сделать исключения и как это влияет на доступность проекта

При проектировании интерфейсов важно учитывать доступность (a11y) и следовать Web Content Accessibility Guidelines (WCAG). Однако иногда возникают ситуации, когда строгие требования контрастности могут мешать эстетике или логике интерфейса. Сегодня разберём, когда можно делать исключения и как это влияет на UX.

Как WCAG регулирует цвет и контраст

WCAG (Web Content Accessibility Guidelines) — набор рекомендаций, который делает цифровые продукты доступными для людей с ограничениями зрения. Основные требования:

✅ Минимальный контраст текста к фону: 4.5:1 для обычного текста и 3:1 для крупного (AAA — 7:1 и 4.5:1 соответственно).

✅ Элементы интерфейса должны иметь контраст 3:1 относительно фона.

✅ Информация не должна передаваться только через цвет (например, ошибки должны сопровождаться иконкой или текстом).

Но есть ситуации, когда эти правила можно гибко адаптировать.

Когда можно отступить от строгих требований?

1. Дизайн под слабовидящих пользователей Если аудитория вашего продукта — пользователи с нарушениями зрения, они часто используют персонализированные настройки контраста и цвета. В таком случае важно дать им возможность адаптировать интерфейс (например, смена темы, поддержка high contrast mode в OS).

2. Декоративные элементы Если текст является неинтерактивным и несёт лишь декоративную нагрузку, требования к контрасту могут быть мягче. Например, логотипы брендов или фоновые иллюстрации не обязаны соответствовать 4.5:1.

3. Темные интерфейсы (Dark Mode) В тёмных темах контрастность воспринимается иначе. Чрезмерный контраст (белый текст на чёрном фоне) может быть утомительным. В таких случаях допускается снижение контраста для улучшения читабельности.

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

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

Как сделать интерфейс доступным даже при отклонениях от WCAG

💡 Добавьте альтернативные способы восприятия информации — используйте иконки, текстовые метки, контуры для важных элементов.

🎨 Тестируйте цвета на симуляторах дальтонизма — инструменты вроде Stark или встроенные в Figma помогают оценить восприятие цветов разными группами пользователей.

🔄 Позвольте пользователю выбрать контрастную тему — динамические настройки темы решают множество проблем.

📊 Проводите тестирование с реальными пользователями — иногда теоретически допустимый цвет в реальности оказывается плохо читаемым.

Итоги

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

Где почитать:
Самый полный гайд по контрастности интерфейсов от DSGNERS
Про инклюзивность и доступность от AGIMA на Хабре
Руководство по доступности контента от WCAG

До связи 🤝

Привет, Хабр! 👋 Сегодня говорим про

UX‑аудит, как найти и устранить проблемы интерфейса с помощью UX‑законов

Создание удобного интерфейса — сложная задача, где даже мелкие недочёты могут вызвать недовольство пользователей. Если метрики падают, а отзывы оставляют желать лучшего, вам нужен UX‑аудит. Сегодня расскажу как провести аудит, какие методы использовать и как помочь себе с помощью UX‑законов.

Что такое UX‑аудит и зачем он нужен?

UX‑аудит — это проверка интерфейса на удобство использования. Его цель — выявить проблемные точки, которые мешают пользователям выполнять задачи.

Когда проводить UX‑аудит?

📉 Низкая конверсия или высокий показатель отказов.

👿 Пользователи жалуются на сложности.

👨‍🎨 Вы готовитесь к редизайну.

Методы UX-аудита

1. Использование UX-законов

UX-законы — принципы, объясняющие поведение пользователей. Примеры:

Закон Миллера: Человек удерживает в памяти 5–9 элементов. Убедитесь, что ваш интерфейс не перегружен информацией.

Закон Фиттса: Чем дальше и меньше элемент, тем сложнее на него нажать. Проверьте размеры кнопок.

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

2. Анализ данных

Инструменты аналитики помогут найти проблемные места:

Карта кликов: показывает, какие элементы привлекают внимание, а какие игнорируются.

Сессии пользователей: дают понять, где пользователи застревают.

Конверсия и отказы: указывают на слабые места в пути пользователя.

3. Пользовательские исследования

Юзабилити‑тесты: наблюдайте, как пользователи выполняют ключевые задачи.

Опросы: выясните, что нравится или раздражает.

Интервью: погружайтесь в опыт реальных людей, чтобы понять их мотивацию.

4. Хейтерская сессия

Попробуйте сами быть самым критичным пользователем: что мешает вам дойти до цели? Этот метод помогает выявить очевидные проблемы. Не переусердствуйте!

Как провести UX‑аудит?

1. Сбор данных

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

2. Проверка по UX‑законам

Проанализируйте интерфейс: Не перегружен ли он информацией? Удобно ли пользоваться навигацией? Интуитивно ли расположены кнопки?

3. Тестирование с пользователями

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

4. Составление рекомендаций

После сбора данных подготовьте список аргументированных доработок.

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

Зачем учитывать UX‑законы?

Применение UX‑законов помогает избежать распространенных ошибок. Например:

Проблема: высокая отказоустойчивость в онлайн‑магазине.

Решение: сократили количество фильтров (закон Миллера), упростили поиск. Конверсия выросла на 20%.

Итоги UX‑аудита

После UX‑аудита ваш продукт станет:

Понятным: пользователи быстрее осваивают интерфейс.

Интуитивным: меньше ошибок и сложностей.

Эффективным: выше конверсии, меньше отказов.

Где почитать:
Подробно про аудит и как его делать от Fuse8
Руководство по улучшению интерфейса от Pixcap
Чек-лист по юзабилити в e-commerce от TexTerra

Помните: UX‑аудит — это не разовая акция, а постоянный процесс. Всегда найдётся, что улучшить! До связи 🤝

Хабр, привет!

Сегодня поговорим о UX-тестировании и глубинных интервью.

Как сделать так, чтобы тесты выявляли настоящие проблемы, а интервью давали ценную обратную связь? Разбираем степ бай степ!

Что такое UX-тестирование?

Это процесс, в котором вы наблюдаете за тем, как пользователь выполняет определённые задачи в вашем продукте. Цель - понять, что работает, а что вызывает сложности.

Как провести эффективное тестирование?

1. Сценарии вместо вопросов.
Давайте пользователям конкретные задачи, а не абстрактные вопросы. Вместо «Что вы думаете об этом экране?» скажите: «Попробуйте найти ближайший магазин на карте». Это помогает увидеть реальное взаимодействие.

2. Тестируйте с целевой аудиторией.
Если ваш продукт для бухгалтеров, тестируйте на бухгалтерах, а не на друзьях или коллегах. Только реальные пользователи покажут настоящие проблемы.

3. Молчите и наблюдайте.
Когда пользователь запутался, не спешите подсказывать. Вместо этого спросите: «Что бы вы сделали дальше?» или «Почему вы решили нажать сюда?». Молчание помогает понять, где интерфейс недоработан.

4. Фиксируйте факты.
Записывайте то, что пользователь делает, а не то, что вам кажется важным. Например, вместо «он ошарашен и запутался» напишите: «трижды нажал на кнопку “Назад”, чтобы найти меню».

Что такое глубинные интервью?

Это формат, где вы задаёте пользователю вопросы, чтобы узнать его опыт, мотивацию и проблемы. Главное здесь - не задавать наводящих вопросов.

Как провести глубинное интервью?

1. Открытые вопросы — наше всё.
Спрашивайте так, чтобы человек мог подробно ответить. Например: «Как вы обычно ищете билеты на концерт?», а не «Вам нравится искать билеты в приложении?».

2. Спрашивайте о прошлом опыте.
Пользователи не всегда знают, чего они хотят, но помнят, что им не нравилось раньше. Вместо «Что вы хотите от новой функции?» лучше спросить: «С какими проблемами вы сталкивались, когда пользовались похожими продуктами?».

3. Уточняйте детали.
Если человек сказал что-то важное, не бойтесь уточнить: «Почему это для вас важно?», «Что именно было неудобным?». Это раскроет проблему глубже.

4. Не оценивайте ответы.
Сохраняйте нейтральность. Например, не говорите «Это интересное мнение». Пользователь может начать говорить только то, что, как ему кажется, вам нужно услышать.

5. Всегда спрашивайте: «Что я забыл спросить?»
Этот вопрос открывает новые инсайты. Пользователь может вспомнить то, о чём вы даже не подумали.

Зачем это всё?

Тестирование и интервью - это ваш главный инструмент, чтобы понять, что действительно мешает пользователям. Но самое важное - превращать эти знания в действия.

Итог:
Тестируйте сценарии на реальных людях, слушайте их истории и задавайте правильные вопросы. Всё это поможет вам сделать продукт, который не только «работает», но и действительно нравится людям.

Где почитать:
Про виды и методы UX-тестирования на Яндекс.Практикум
9 методов UX-тестирования на UX Journal от Рината Шайхутдинова
Про глубинные интервью от UPROCK

Ребята, привет! Давайте поговорим про:

Анализ конкурентов

Это одна из самых интересных и полезных практик, которая помогает нам делать продукты лучше. Но, как и во всём, тут есть тонкости. Цель анализа - не копировать чужие решения, а понять, что работает, что нет, и придумать что-то своё, уникальное. Как это сделать? Сейчас разберём!

Зачем анализировать конкурентов?

Анализ конкурентов - это не только про то, чтобы узнать, что делают другие. Это про то, чтобы:

Определить рыночные стандарты. Узнать, чего пользователи ожидают от продуктов в вашей нише.

Найти сильные стороны конкурентов. Какие фишки у них особенно популярны? Может, это что-то, что вы можете адаптировать?

Выявить слабые места. У каждого продукта есть недостатки. Их можно превратить в ваши преимущества.

Собрать идеи. Хорошие решения конкурентов могут вдохновить на создание собственных инноваций.

Как правильно анализировать конкурентов?

Вот пошаговый план:

1. Определите, кого анализировать.

Составьте список конкурентов. Это могут быть:

- Прямые конкуренты (продукты с такими же функциями).
- Косвенные конкуренты (решают схожие задачи, но по-другому).
- Лидеры рынка (даже если они не из вашей ниши, у них всегда есть чему поучиться).

2. Изучите продукт.

- Зарегистрируйтесь и попробуйте продукт как пользователь.
- Изучите весь пользовательский путь: от первых экранов до глубины функционала.
- Проверьте их мобильные и веб-версии, если они есть.

3. Проанализируйте интерфейс и UX.

Какие паттерны и подходы они используют?

- Легко ли понять их продукт? Какие элементы интерфейса кажутся удачными?
- Какие моменты вызывают вопросы или трудности?

4. Оцените визуальный стиль.

- Как выглядит их дизайн? Современный, минималистичный, классический?
- Есть ли в нём что-то, что может выделять их среди других?

5. Соберите отзывы пользователей.

Отзывы - это кладезь информации. Люди часто рассказывают, что им нравится и что не устраивает. Загляните в:

App Store, Google Play.
Соцсети и форумы.
Обзоры на профильных сайтах.

6. Проанализируйте метрики.

Если есть доступные данные, изучите их:

- Количество скачиваний.
- Рейтинг приложения.
- Активность в соцсетях.

Как не копировать, а адаптировать?

Вот несколько советов:

Понимайте контекст. Если у конкурента что-то работает, это не значит, что оно сработает у вас. Понять, почему решение эффективно, - уже половина успеха.

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

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

Объединяйте подходы. Если видите классные идеи у разных конкурентов, подумайте, как их можно объединить в рамках вашей концепции.

Маленький лайфхак:

Сделайте себе простую таблицу для анализа конкурентов. Например:

Зачем это всё?

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

И помните: лучший продукт - это не тот, который делает всё как у других, а тот, который делает это лучше.

Где почитать:
Руководство по конкурентному анализу от Андрея Шилова на Medium (идти с прокси)
Конкурентный анализ от UPROCK
Статья на Хабре от Никиты Колюгина

До скорого!

Привет, Хабр!

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

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

Что планирую рассмотреть:

1. Генерация гипотез. Как строить гипотезы, чтобы они не просто висели в воздухе, а стали основой для тестирования и улучшения продукта.

2. UX-аналитика и Бизнес-аналитика. Как связать анализ пользовательского опыта с бизнес-позициями и почему важно не забывать про оба аспекта.

3. Анализ конкурентов. Зачем и как правильно проводить анализ конкурентов, чтобы не копировать, а интегрировать самые крутые практики в свой продукт.

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

5. User Flow и Персоны. Как создавать User Flow и прорабатывать персоны для детального понимания того, как пользователи себя ведут.

6. UX-тестирование и Глубинное интервью. Как сделать тестирование таким, чтобы оно реально выявляло проблемы, а глубинные интервью давали ценную обратную связь.

7. Создание дизайн-концепции. Как развить свою дизайн-концепцию, составить UI-kit и начать работать с дизайн-системами.

8. Android и iOS гайдлайны. Как различия в дизайне для Android и iOS могут повлиять на взаимодействие с продуктом и что стоит учитывать при проектировании.

9. UX-законы и UX-аудит. Как с помощью UX-аудита найти и устранить проблемы в интерфейсе, а какие методы исследования лучше всего для этого использовать.

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

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

12. WCAG и подбор цветов. Когда и почему можно сделать исключения по WCAG, и как это влияет на доступность проекта.

Надеюсь, эти посты будут полезны всем, кто работает с интерфейсами и UX. Пишите в комментариях, что вас интересует в первую очередь, какие темы стоит обсудить подробнее, и что бы вы добавили.

До скорого в следующих постах!

Моё главное разочарование в 2024: bluetooth клавиатуры с подсветкой и мышки

Для программирования на удаленке в позе полулёжа на диване нужны блютуз клавиатура и мышка. Клавиатура должна быть с подсветкой. Но... именно блютуз в таком применении жестко разочаровал. Тормоза, зависания и засыпания. Быстрое отключение подсветки. Несколько лучше мышки и клавиатуры с радио каналом. Но на мини ПС под Windows 11 постепенно нарастали тормоза по мере обновления Windows и в конце года уже стали нестерпимо раздражать. Перешел на 2 кабеля USB по 7 метров и обычные мышку и клавиатуру с подсветкой. Теперь не тормозит. Подсветка не гаснет. Ничто не засыпает. Но провода все же не так уж и удобно, к сожалению. Добавлю, на Mac OS на m1 мышка с радио каналом работает идеально, плавно, не тормозит, не засыпает. (Но радио - это не блютуз)

Как наклейки на серверах делают обслуживание проще и безопаснее

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

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

Все элементы обозначены яркими синими метками. Например, Riser «B» выделен яркой маркировкой, благодаря чему его легко отличить. Такая система упрощает обслуживание и снижает вероятность ошибок.

Другие примеры serviceability читайте в статье Александра Чурикова, технического эксперта по продукту в YADRO.

Почему сайты говорят как роботы

Только ли SEO продолжает превращать сайты в поле битвы алгоритмов? Часто это выглядит, как будто контент пишут для поисковых роботов, которые вроде как и «умные», но всё ещё реагируют на шаблонные фразы, ключевые слова и лонгриды. «Больше ключевых фраз — больше клиентов».

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

«Раковина может перестать работать, и вам нужно её починить. Чтобы починить раковину, следуйте этим шагам: найдите проблему, подготовьте инструменты и почините раковину.»

Бизнес: «Ну а чо, сайт в топе, посещаемость высокая, кассу делают, так о чём речь?».
Клиент: «Мне нужно быстро получить услугу/товар здесь и сейчас, дёшево и с гарантией». Побоку все эти «финтифлюшки и расшаркивания».

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

Наверно только крупный бизнес позволяет себе разговаривать со своими клиентами на человеческом языке. И мы делаем скрины и обучающие программы «Смотрите как надо». А всех остальных (без SEO и лонгридов), поисковики выкидывают из индекса по причине: «Малоценная или маловостребованная …»

Если у бизнеса цель только быстро заработать, то и нет смысла заниматься каким-то там юзабилити и тем более текстами. Стандартные библиотеки и грамотное SEO — «всего и делов».

А вот когда SEO сделало своё дело, а вы всё ещё любите своих клиентов и хотите взаимности на долгие годы — займитесь уже юзабилити и текстами.

• Подумайте, что чувствует человек, когда открывает ваш сайт. Понятен ли текст? Логична ли структура?

• Экспериментируйте, проверяйте разные подходы: более человечный язык, больше визуального контента, меньше шаблонов. Ваши SEO-тексты — не догма и не исключают экспериментов.

• Посмотрите на поведение пользователей: как они перемещаются по сайту, где застревают, где уходят. За метриками отказов стоят реальные люди, которые ищут решения, а не SEO-фразы. SEO — это инструмент, и проблема не в нём, а как бизнес интерпретирует его задачи.

• Локальные бренды и нишевые проекты часто привлекают аудиторию именно за счёт живого общения и уникального стиля.
  

Люди вернутся на сайт, где их понимают, а не туда, где их «оптимизировали».

—------------------

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

UX-редактору: Правило «Хочу…». Что писать в кнопке

Например, кнопка в результатах поиска. Что написать, «Показать все» или «Посмотреть все»?

Считается, что на кнопках надо писать действие (фраза с глаголом), чаще всего, от лица юзера или что произойдёт дальше (а не просто «OK» или «Далее»). Зависит от контекста, флоу и, даже, от голоса продукта.

Давайте применим правило «Хочу». Мысленно добавляем слово «хочу» в начале текста кнопки и «что делать» (текст кнопки).

• Хочу … «Читать далее»

• Хочу … «Отправить сообщение»

• Хочу … «Отменить»

• Хочу … «Посмотреть все»

А вот так уже не очень:

• Хочу … «Загрузка»

• Хочу … «Отмена»

• Хочу … «Показать все» — не юзер же показывает, а система

• плохо работает аккуратнее с глаголами на -тся/-ться (загружается, обновляется)

• не работает с глаголами в страдательном залоге (потеряно, зависла)

Правило «Хочу» хорошо работает с глаголами, которые обозначают действия, поддающиеся контролю человека: отправить, скачать, завершить, обновить, поделиться и т.д.

Можете привести пример кнопок (с глаголами), где правило «Хочу» не работает, но всё равно надо использовать глагол?

--------------------------------------------

В телеграм-канале Заметки о юзабилити практические задания по юзабилити и интерфейсным текстам. Развиваем внимание к деталям, насмотренность и разбираем User Flow.
Ещё на канале: исследования, мнения, полезные ссылки и много на тему юзабилити. Присоединяйтесь, присылайте свои кейсы, разберём ))

UX-редактору: «Отправить» или «Получить»?

Есть мнение, что в подобных формах, в кнопке лучше писать «Отправить код» вместо «Получить код».

В этом скрине проблема ещё в том, что пример немного абстрактный. Название формы может сильно повлиять на текст в кнопке.

Одно из правил для кнопок гласит: подпись должна четко сообщать, что именно произойдет, когда пользователь нажмет на кнопку.

«Получить код» вроде бы подходит, НО т.к. сайт не может гарантировать доставку СМС (т.е. юзер может не «получить»), потому, дескать, и надо писать «Отправить».

Как по мне, так странное объяснение, т.к. «отправку» сайт тоже не может гарантировать. Кроме того, «отправить» — это промежуточное действие, юзер же не отправку просит, а хочет видеть (получить) код.
«Получить» мне больше нравится, сообщает именно о том, что должно произойти после нажатия.

-----------------

В телеграм-канале «Заметки о юзабилити» публикуются практические задания по анализу юзабилити и интерфейсных текстов. Развиваем внимание к деталям, насмотренность и разбираем пользовательские сценарии.

Ещё на канале есть: исследования, мнения, полезные ссылки и много всего на тему юзабилити.

Дал последний шанс Evernote...
Почему - потому что найти решение куда перескочить - не удалось, а к кнопке веб-клиппера я уже привык на уровне подкорки за эти ... да лет за 10 точно.

В общем потихоньку все равно продолжал клипить заметки. При этом я даже удалил (как писал недавно) толстого клиента и пользовался только веб-клиентом и веб-клиентом.

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

В итоге - я для себя принял решение экспортировать заметки из проги в локальный файл(ы) enex и искать замену - а с Evernote прощаться.

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

Ну и по ходу поймал ряд глюков и дырок:

• при удалении блокнот пропадает, но окно висит, приходится отменять и выходит ошибка удаления;

• ребята ввели ограничение на кол-во заметок в месяц (50), но из клипера их можно продолжать клепать;

• в целом клиент висит и жрет ресурсы бессовестно (особливо при открытии).

В общем кризис Evernote продолжается, халява кончается... и даже платить нет смысла - потому что падает качество программы и сервиса. В общем все по тренду рилсов - "bye bye bye".

Когда встает задача запустить Windows приложениях в Linux, то неизменно на ум приходят с десяток приложений основанных на WINEhq. Однако есть одна разработка, WinApps, которая не идет этим путем и представляет собой попытку творческого переосмысления WSL, но наоборот, т.е. у нас есть виртуальная машина с MS Windows/Docker контейнер с Windows/Podman контейнер с Windows в которые мы устанавливаем необходимый софт, а дальше, мы получаем, через консоль или через ярлыки в системе, доступ посредством протокола RDP через утилиту FreeRDP. Однако удобство, по сравнению, с обычным RDP, заключается в том что каждое такое приложение будет в отдельном окне, словно нативное приложение Linux.

Плюсы метода:

• OpenSource решение

• Пользователь может безболезненно запускать привычные Windows приложения как если бы они были частью Linux

Минусы метода:

• протокол RDP - в котором мне не удалось завести аппаратное ускорение Direct Draw и AGP, работает только Direct3D со всеми вытекающими. Различные манипуляции с реестром виртуальной машины, ее групповых политик и консольными параметрами freerdp ни к чему не привели. Приложения в которых работа Direct Draw и AGP жизненно необходима, например в Adobe Photoshop, Autodesk AutoCAD и т.п., работаю плохо или никак.

• иногда происходят ложные срабатывания, например: когда пытаешься перемещаться по документу мышью удерживая полосу прокрутки - это, чаще всего не работает или работают не так как ожидаешь