Продуманные макеты или как предугадать вопросы коллег (+ чек-лист)

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

Часто при подготовке концептов мы не задумываемся о том, что с приложением может быть что-то не так — пользователь находился в зоне слишком слабого сигнала Wi-Fi, на сервере произошел сбой… Например, при плохом интернете, данные могут долго не отображаться, что будет раздражать пользователей.

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

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

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

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

Получаем, что глобально у экрана могут быть следующие состояния:

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

Посмотрите, как ваш макет будет выглядеть и для «Ивана Иванова», и «Константина Константинопольского». Комфортно должно быть всем.

Это касается и заполняемости содержимого экрана. Что, если пользователь напишет в строке с отзывом «Классно»? А что, если он сильно расстроился и хочет вылить душу в этом маленьком инпуте?

Всегда думайте и про «маленьких», и про «больших».

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

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

Если приложение загружает какой-то контент (изображения, видео…) стоит предусмотреть заглушку для него. Это поможет избежать белых дыр в интерфейсе.

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

Есть еще один момент, который я бы назвала не правилом, а особым случаем, который стоит держать в уме. Мы с коллегами всегда готовим макеты для каждой платформы в одном размере. Например, сейчас для iOS мы используем iPhone 11 Pro. У многих пользователей девайсы могут оказаться меньше. Поэтому при подготовке макета представьте, что увидит человек с iPhone 8 или SE. В «особо тяжелых случаях» подготовьте дополнительный макет. Вам не сложно, а разработчику будет намного проще.

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

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

Сейчас чек-лист успешно применяется на одном из проектов e-Legion при работе с дизайнерами из сторонней компании.

#дизайн #полезныесоветы #макеты #мобильныеприложения #чеклисты