Любое программное обеспечение создается командой людей, а где есть человек, есть и вероятность ошибки. Дизайнер забыл прорисовать мелкую деталь, разработчик не заметил этого при реализации, тестировщик не продумал, отвлекшись на другие моменты. В итоге до пользователя доходит не до конца дружелюбное ПО.
Очень и очень многое можно предотвратить на этапе программирования, если разработчик достаточно опытный, или если ему повезло с тестировщиком, и QA-инженер сразу “подсветил” нуждающиеся в проработке моменты.
Навигация должна быть логичной
Любая разработка должна быть логичной и удобной в работе. Навигация – один из главных ключей к успеху. Глядя на главный экран приложения или первую страницу сайта, мы должны понимать, что задумал пользователь и каким будет его следующий порыв.
При продуманном UX интерфейс предвидит желания пользователя и оправдывает их. При некачественном UX пользователь злится, раздражается и больше с нашей разработкой не взаимодействует.
Картинку придумали, а вариативность забыли
Баги могут появиться из-за плохой коммуникация в команде. Дизайнер создает красивую картинку, отправляет ее разработчику, но тот картинку не видит, а видит варианты реализации. Если кто-то не додумал, здравствуй баг.
Проектированием приложения обычно занимаются дизайнер и продакт-менеджер, они продумывают навигацию и расположение элементов. Иногда за важными и приоритетными задачами теряется что-то незаметное, но не менее важное. Например, с какой буквы начинать ввод текста. Что происходит с кнопкой при нажатии? Какое сообщение выводить, если страница не грузится?
Бывает, что дизайнерские штучки – помеха разработке. Когда желание создать яркий и запоминающийся дизайн идет в ущерб архитектуре и логике. Это тот случай, когда у создателей приложения и пользователя разные цели: красиво и дружелюбно. Поэтому сначала нужно разработать архитектуру и только потом на ее основе создавать дизайн. Наоборот не работает.
Разработка – это не только логичный код, но еще и дружелюбный
Реализовали какой-то код – протестируйте. Все ли удобно нажимать, все ли реагирует так, как заложено в ТЗ, соответствует ли результат ожиданиям? Вот чек-лист для разработчика, по которому сразу можно провести проверку:
- Есть реакция на нажатие у кликабельных элементов, приложение адекватно реагирует на действия пользователя и все идет по плану.
- Нет реакции у тех элементов, где нажатие не предусмотрено.
- Скролл работает.
- Экранная клавиатура появляется и исчезает в соответствии с заложенной логикой.
- Ввод текста начинается с заглавной буквы.
- Есть фокус на следующем поле ввода при нажатии Enter, т.е. когда вы ввели текст в одном поле и нажали “Готово”, приложение автоматически переходит на другое.
- Программная отправка формы работает, никаких дополнительных действией не требуется.
- Если нужно показать какой-то прогресс, есть специальный индикатор .
Чтобы сделать что-то нужное для пользователя, нужно думать как пользователь.
Еще на моменте формирования документации важно продумать, все ли возможные варианты учтены. Что будет, если все рухнет? Важно всегда ставить себя на место пользователя. Невозможно создать в проекте интерфейс для кого-то абстрактного, такое приложение не решает задач и не имеет успеха.
Для этого существует подход Jobs To Be Done (Работа, которая должна быть выполнена): ваше приложение помогает выполнить работу? Если нет, нужно поработать ещё. Понимая задачу пользователя, гораздо проще сделать эффективное решение.
Правильно выстроенные приоритеты – залог успеха
Самый шикарный интерфейс чаще всего приводит к разочарованию, если он нарисован из головы, без аналитической базы. Важно провести анализ конкурентов, выделить главные элементы. Потом проработать логику действий пользователя, продумать несколько возможных сценариев и на этой основе создать требуемую базу.
Правила успешных “не”:
- Не добавлять иллюстрации ради иллюстраций.
- Не разрабатывать ненужную функциональность.
- Не встраивать регистрационные формы на каждый клик, не предложив что-то существенное взамен.
- Не прятать строку поиска.
- Не игнорировать оптимизацию.
- Не терять связи с пользователями.
Когда ошибки в UI/UX допустимы?
Вариант только один: когда вы создаете тестовый продукт для оценки идеи в целом. В этом случае нет ясности, окупается проект или нет, потому на мелких погрешностях можно не заострять внимание. Однако не стоит лениться: всегда исправляйте то, что исправляется за минуту и делает вашу разработку лучше.
Как избежать ошибок?
- Создавайте чек-листы.
- Используйте элементы визуального тестирования.
- Соберите свой тестовый стенд.
- Тестируйте свои разработки внутри компании.
- Развивайтесь и создавайте собственную базу знаний.
Подробнее об инструментах тестировщика мы уже писали.
Хочу научиться программировать с нуля, но не знаю, с чего начать. Что делать?
Можно учиться самостоятельно (долго) или пойти на курсы с преподавателями (быстро). Плюс нужно учитывать, что джунов много, конкуренция выше и работодатели повышают порог вхождения при найме на работу. Чтобы получить актуальные знания, мы в proglib.academy запустили курсы:
- Основы программирования на Python.
- Профессия Python-разработчик.
- Алгоритмы и структуры данных.
- Математика для Data Science.
- Профессия Data Science.
- Frontend Basic: принцип работы современного веба.
- Профессия Фронтенд-разработчик.
- Обработка естественного языка. Полный курс.
На подходе еще больше 10 курсов для взрослых и детей.
Комментарии