12 плохих ошибок UX/UI, которые нельзя допускать в дизайне приложений

Текст слишком мелкий для чтения.

Мелкий светлый шрифт на белом фоне.

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

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

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

1. Отклонение от ожиданий пользователя

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

Рассмотрим простой пример: вы всю жизнь слушаете новости BBC. Внезапно кто-то из вашей семьи решает вместо этого слушать CNN, и у вас возникает чувство «рыбы из воды». Это именно то, что почувствуют пользователи, когда вы вносите серьезные изменения в виджеты графического интерфейса.

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

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

2. Незнание того, что на самом деле нужно пользователю

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

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

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

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

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

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

3. Плохие сенсорные цели

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

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

4. Ужас свитка

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

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

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

5. Кнопки, имитирующие внешний вид кнопок управления графическим интерфейсом

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

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

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

6. Несогласованные элементы управления графическим интерфейсом

Элементы управления GUI должны быть согласованными. Если вы используете определенные слова для призыва к действию и подобных действий, используйте одни и те же слова во всем приложении. Использование разных слов для одного и того же действия может создать путаницу.

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

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

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

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

8. Не учитывать «мнимые возможности»

С точки зрения непрофессионала, аффорданс означает все действия, которые физически возможны в зависимости от свойств объекта/среды. Лестница позволяет подниматься или спускаться, крышка бутылки позволяет завинчивать или отвинчивать.

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

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

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

9. Отсутствие правильных диалоговых окон

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

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

Например, когда пользователь решает закрыть определенную страницу после ввода информации, диалоговое окно может появиться с окном подтверждения, говорящим «Отменить черновик? Отменить или отказаться».

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

10. Распространенные ошибки с сообщениями об ошибках

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

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

1. Неоднозначность — неясность ошибки, допущенной пользователем.
2. Обвинение пользователя. Лучше быть скромным, даже когда пользователь совершает ошибку. Аккуратно укажите на ошибку, чтобы им было предложено повторить попытку.
3. Плохое размещение сообщений об ошибках — рекомендуется не размещать ошибки в маркированном списке, потому что это действительно отключает их. Поместите сообщения об ошибках прямо над ошибками, чтобы пользователи могли сразу увидеть, что не так.
4. Не использовать микрокопию для предотвращения ошибок. Небольшие фрагменты пояснительного текста рядом с пробелами могут на самом деле указывать пользователю, что заполнять, чтобы он мог получить его с первого раза.

11. Отсутствие умных значений по умолчанию

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

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

12. Игнорирование акцентных цветов для кнопок призыва к действию

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

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

Вывод

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

Дизайн приложений — это залог успеха, и каждый день выпускаются тысячи приложений, но лишь немногие из них получают одобрение. Плохая практика может привести к смертельным ошибкам в дизайне UX/UI, и все усилия многих людей пропадут даром.

Последнее напоминание:

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