Апарекиум: в поисках невидимых особенностей дизайна

Коротко

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

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

Что разработчик не должен искать в макете

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

1. Учтите разные размеры экранов

Мобильные устройства различаются размером, пропорциями и платформенными требованиями. В практике автора в 2018 году базовыми макетами служили 375×667 для iOS и 360×640 для Android. Эти размеры были рабочей отправной точкой, а не универсальным стандартом для всех устройств. На более высоких экранах видно больше контента, но критические состояния нужно отдельно проверять на компактных и нестандартных устройствах. В некоторых случаях стоит учитывать смартфоны с меньшим разрешением или другими пропорциями, например iPhone 4. Для него может потребоваться отрисовать отдельные версии экранов, если контент не помещается на экран.

2. Опишите ошибки и пустые состояния

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

Если сервер возвращает три варианта ошибки, а в макете описан один, дизайн вернётся на доработку и задержит реализацию.

Заранее уточните у аналитика и разработчика, какие состояния поддерживает форма.

3. Активная клавиатура

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

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

4. Карта экранов

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

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

В 2018 году автор использовал для карт переходов Realtimeboard, Axure, Figma, Sketch и Overflow; выбор инструмента был частью личного рабочего процесса.

5. Текст в контейнере

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

6. Нет указания типа навигации

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

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

7. Удобный экспорт

Вы нарисовали макет, утвердили его у заказчика, выложили все макеты для верстки и вроде выдохнули. Но вот откуда ни возьмись прибегает разработчик и говорит вам о том, что иконка выгружается коряво. о_О И тут вы понимаете, что забыли сгруппировать и/или объединить иконки. Поэтому всегда при завершении работы по дизайну проверяйте все элементы, которые могут понадобиться разработчику. Размещайте на отдельном артборде элементы, которые разработчик не сможет воспроизвести кодом. Иконки и элементы должны быть сгруппированы для удобства экспорта, иначе все будет коряво выгружено и также заверстано.

8. Не всегда то, что нарисовано легко реализуемо

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

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

9. 50 оттенков серого

Если у вас большой макет сайта или приложения и цвет используется 2-3 раза на разных элементах, то уверенно создавайте стиль. Стили ускорят не только вашу работу и не дадут применить к элементу похожий, но не идентичный цвет. Но и разработчику будет потом намного проще, поскольку стили можно выгрузить в Zeplin. Главное не забывать о том, что при индивидуальном изменении элемента с привязанным стилем есть возможность того, что вы случайно можете изменить стиль. Лучше заранее отвязать от стиля элемент и редактировать его под свои нужды.

10. Кратности в макетах

Говорить на тему сеток можно бесконечно. Но в данном контексте хочется рассказать о личном опыте построения интерфейса. Недавно читал пост в facebook и там разгорелась очень интересная дискуссия. Кто-то настаивал на том, что все интерфейсы должны быть построены по определенному формату, то есть никакой индивидуальности. И тут же спрашивают о том, что делать если экран имеет нечетные параметры? Например iPhone 8 имеет разрешение 375×667, что же делать в таком случае? Если отталкиваться от построения на четных количествах столбцов, то здесь едет вся логика. Google же предлагает использовать сетку основанную на 8 единицах.

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

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

11. Нестандартный кернинг

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

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

Потренироваться в кернинге можно в игре: https://type.method.ac

12. Своевременная актуализация

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

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

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

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

13. Тени картинками

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

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

Чёткий макет экономит время всей команды: фиксируйте состояния, переходы, ограничения и правила экспорта до передачи в разработку.

Впервые опубликовано: 29 ноября 2018 года.