карта экранов мобильного приложения
Карта навигации
Часто начинающие дизайнеры вместо того чтобы рассматривать страницы сайта, или экраны мобильного приложения, в одной связке, как целостный сценарий, рисуют набор картинок и потом кидают его клиенту и разработчикам. Это приводит к двум основным проблемам:
В таких случаях помогает инструмент который я называю Карта навигации (по-буржуйски User flow). Конечно, можно запилить крутой интерактивный прототип который можно протестировать сразу на устройстве, но он не позволяет увидеть сразу общую логику работы и пройтись по основным сценариям. Прийдется долго-долго клацать, особенно если это мобильное приложение, а потом все равно нужно рисовать схему…
Карта навигации составляется когда уже есть четкое понимание общей логики, проработаны все основные экраны в виде прототипа. Я делаю карты двух видов, в зависимости от ситуации: общая карта и карта по сценариям. Их так же можно комбинировать, все зависит от сложности проекта.
Общая карта
Такая карта показывает как общую логику так связи всех экранов, используется когда проект не сильно большой и можно уместить все на одном условном листе.
Повторюсь, показываются все экраны и все связи чтобы любому члену команды была понятна логика работы и связи всех экранов, чтобы потом не доставали вопросами.
Карта по сценариям
Такая карта используется когда проект большой и сложный, в нем много-много-много экранов и много-много-много сценариев. В основном это характерно для мобильных приложений у которых нет четкой структуры а одни и те же экраны могут встречаться в разных сценариях.
Инструменты
Сначала я использовал Adobe Illustrator в котором создавал детализированный прототип основных экранов, потом сохранял все экраны в отдельные джипеги и собирал карту в отдельном документы. Это очень удобно потому, что когда вносишь изменения в в прототипе и потом сохраняешь этот экран Illustrator автоматически обновляет файлы в карте.
Сейчас я использую Sketch и на момент написания статьи я думал, что в нем нельзя апдейтить растровую графику. Ниже в комментарии указан плагин с помощью которого можно обойти это ограничение. И еще, для тех кто еще не знаком с этим инструментом вот тут много всего по Sketch.
Еще можно использовать Axure RP по такой же схеме как с Иллюстратором, только прийдется делать руками скриншоты страниц и собирать в отдельном доке, в том же Illustrator или Sketch. В общем, для создания карты навигации лучше использовать тот же инструмент что и для разработки прототипа.
Советы
1. Используй хорошо проработанный прототип, подписывай все экраны и добавляй комментарии которые помогут лучше понять логику всем участникам команды (менеджерам и программистам).
2. Если сценариев много, и они сложные, лучше их объединять в отдельные блоки, или размещать на отдельных листах (если потом документ со сценариями будет сохраняться как PDF).
3. Карту можно делать комбинированной (все экраны плюс основной сценарий) и отдельно показывать экраны с более детальным описанием взаимодействия.
4. Карту лучше составлять параллельно с разработкой прототипа, то есть сразу выкладывать экраны в сценарии, тогда сразу видны все косяки и недоработки. В этом отношении лучше использовать софт в котором можно отрисованные экраны составлять вместе и объединять в сценарии (в Illustrator и Sketch для этого есть артборды) или использовать другой инструмент, например InVision (совсем недавно я делал прототип в Sketch и создавал параллельно интерактивный прототип в InVision, что позволяло мне тестировать его и вносить правки).
Проектирование экранов приложения: от планирования до дизайн-макета
Примечание переводчика: сегодня мы публикуем перевод статьи шестнадцатилетней индийской разработчицы Харшиты Арора. Харшита начала изучать графический дизайн с 13 лет. Сейчас она занимается созданием мобильных приложений. В статье Арора делится нюансами разработки дизайна приложений с нуля на примере создания собственного криптовалютного аппа — Crypto Price Tracker.
Статья посвящена первичному проектированию — необходимости анализа функций и возможностей создаваемой программы еще до начала работы над ней, с тем, чтобы учесть все необходимые моменты при создании приложения. Стоит отметить, что этот материал будет особенно полезен начинающим разработчикам (совсем новичкам), поскольку автор сама занимается этим сравнительно недавно.
Skillbox рекомендует: Практический двухмесячный курс «UX-дизайн».
Напоминаем: для всех читателей Хабра — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
В целом работа над дизайном приложения разделяется на следующие шаги:
Диаграммы потока задач
Первый шаг при разработке — определение списка функций, которые вы хотите добавить в свое приложение. Как только у вас появляется четко оформленная идея, стоит начать работать над созданием диаграммы потока задач. Она позволяет наглядно увидеть, как будет работать апп.
В ходе работы обычно используется 3 элемента:
Собственно, речь идет об обычной блок-схеме, демонстрирующей принятие решения пользователем при попадании на разные экраны приложения.
Вайрфреймы
Как только вы закончили с user-flow, пора приниматься за вайрфреймы. Они показывают (с определенным приближением), что будет представлять собой приложение и как оно будет выглядеть. Это черновой эскиз с указанием основных элементов для каждого экрана.
Для того, чтобы каждый раз не чертить границы корпуса телефона, я использую сервис UI Stencils.
Вот пример вайрфрейма.
После того как эти скетчи готовы, вы можете использовать приложение Pop для объединения отдельных эскизов в единую схему, элементы которой связаны друг с другом.
Дизайн и цветовая палитра
Это мой любимый этап. Вы можете выбирать все, что угодно, после чего начинаем эксперименты над отдельными цветовыми решениями. Для меня лучшие репозитории примеров дизайна и палитр — Mobile Patterns и Pttrns, а также Color Hunt.
Макеты
Да, наконец-то мы можем приступить к проектированию, созданию макетов приложения. Макет в дизайнерском смысле — это наглядное представление вашего дизайна. На этом этапе макет должен быть максимально приближен к реальности, чтобы можно было понять, как приложение выглядит и работает.
Есть различные средства разработки, инструменты для создания макетов. Я использую Affinity. Создавая приложения для iOS, я чаще всего работаю со Sketch.
Вот пример некоторых ранних макетов моего собственного приложения.
Вот работа с цветовой палитрой.
В процессе стоит показывать свои макеты коллегам и знакомым — так вы сможете получить фидбэк, не имея прямого доступа к потенциальным пользователям. В моем случае большинству людей, кому я показывала макеты, понравился черно-золотой вариант.
К слову, в процессе обсуждения вашей работы будьте готовы встретиться с новыми идеями — вам могут предложить что-нибудь очень интересное! — и предложениями. Вы можете получить весьма интересные идеи, когда общаетесь с потенциальными пользователями приложения.
В моем случае я получила несколько идей, которые затем использовала в новом макете.
Дизайн приложения получился лаконичным, на панели задач есть иконки и все элементы управления. Далее я проработала все остальные экраны приложения, взяв это оформление экрана за основу.
Карта экранов в разработке игрового интерфейса
Как упростить работу при создании UI.
При создании интерфейса игры даже опытные разработчики могут запутаться в обилии кнопок и окон. При этом, у каждой команды есть свои способы облегчения этой части работы.
Борис Киселев, ведущий дизайнер интерфейсов студии Rocket Jump, написал для DTF колонку о картах экранов — удобном инструменте для упрощения разработки интерфейса игры.
В этом материале я поделюсь опытом использования карты экранов — инструмента, крайне полезного в разработке игрового UI. Он помогает сохранить целостность интерфейса, структурирует работу, делает её более прозрачной и прогнозируемой. Сам по себе этот приём не нов и весьма распространён среди разработчиков мобильных приложений, но при этом на удивление редко встречается в игровой сфере.
Карта экранов — это схематичное отображение всех экранов проекта и связей между ними. Выглядеть она может по-разному. Например, вот так.
Обычно хранение и просмотр файлов организованы иначе — дизайнеры ограничиваются набором поэкранных превью, названных по определённой системе. То есть, скорее всего, многие привыкли к примерно такой картинке.
Это простая, проверенная, рабочая система организации, и я не призываю от неё отказываться. Без поэкранных превью всё равно не обойтись — они понадобятся для отсмотра на устройствах, для вёрстки, для презентаций. Но не стоит ограничиваться только ими.
При таком подходе происходит неприятная вещь: интерфейс, будучи по сути своей целостной, связной системой, многократно дробится на отдельные экраны. Таким образом, теряется важная информация, находящаяся между элементами этой системы. Например, связи и переходы — на поэкранных превью увидеть их невозможно. И здесь нам помогают карты экранов.
Вкратце перечислю основные преимущества их использования.
С картой становятся понятны связи и переходы между экранами. Никаких вопросов по поводу того, что, откуда и куда ведет. Это особенно актуально для вложенных друг в друга экранов или частей игры, до которых игроку трудно добраться (например, интерфейс лидера клана или окно повышения N-го уровня).
На карте с первого взгляда становится понятно, в каком состоянии находится интерфейс в целом, каких экранов не хватает, а какие уже закончены. Project-менеджерам легче отслеживать и контролировать прогресс разработки интерфейса. Карта экранов — одновременно и превью, и отчёт по проделанной работе, и задел на будущее.
Новым людям на проекте (или тем, кто раньше работал с другой его частью) легче понять и удержать в голове общую структуру игры. Также становится проще ориентироваться на экранах и быстро находить интересующую часть интерфейса.
На карте можно оставлять любые пометки, стикеры и комментарии, видимые всем. Например, указание об особых условиях появления экрана, или о том, какие у него есть вариации, и где их найти.
Дизайнеру интерфейсов нужно держать в голове меньше информации, что также снимает некоторые риски в ситуациях, когда другой специалист заболел или ушёл с проекта. Карта экранов может ответить на большинство базовых вопросов, возникающих у разных отделов. Сколько слотов в магазине? Как посмотреть дерево навыков? Как перейти в этот режим? Какие макеты уже нарисованы и утверждены? Все ответы — в одном месте.
Отдельно хочу отметить один момент, важный для фрилансеров: карта экранов может заменить вам десятки писем и файлов при общении с заказчиком. Вы просто пересылаете одну большую картинку со своими отметками, а заказчик делает поверх них свои. Такой формат воспринимается лучше — заказчик принимает не конкретный визуал конкретного экрана, а как бы промежуточную итерацию интерфейса в целом, видя общий прогресс.
Пару слов о минусах подхода.
Составление и поддержание карты в актуальном виде требует дополнительного времени и усилий.
При работе с особо большими проектами карта экранов становится громоздкой и теряет в эффективности. В таком случае её приходится дробить на несколько более мелких карт, отвечающих за определённые логически связанные разделы.
Поначалу нужно будет учить команду работать с картой — не оставляйте её «в столе» только для себя. Активно оперируйте ею и всячески продвигайте использование инструмента, только так карта экранов станет неотъемлемой и полезной частью вашего производственного цикла.
Смысл карты экранов заключается в том, чтобы облегчить работу с интерфейсом проекта всем, кто с ним связан. Если чувствуете, что она съедает много времени, но при этом никому особо не помогает, смело отказывайтесь от инструмента. В конце концов, это лишь один из приёмов работы с игровым интерфейсом в арсенале дизайнера, а не «серебряная пуля».
Теперь несколько практических советов, которые помогут получить удобную для работы карту экранов.
На карту, доступную для просмотра всей команде, попадают только утвержденные превью, для которых уже есть готовые к вёрстке макеты. Это правило позволит избежать различных неприятных ситуаций и недопонимания между отделами.
Экраны на карте должны быть подписаны. Папки, исходники и файлы-превью должны иметь те же названия. Если на схеме вы назвали экран «inventory», папку с макетами на сервере «storage screen», а сам макет «items_finalVER12», то вы на верном пути в бездну.
На карте отражены все основные переходы и связи между экранами (кроме повторяющихся и очевидных, вроде кнопки «назад»).
Для поддержания читабельности на карту не стоит выносить все состояния одного экрана, если в них нет принципиальных различий и дополнительных переходов. Достаточно делать рядом пометку в стиле «у экрана N вариаций, посмотреть их можно в таком-то месте».
Карта должна быть читабельна в крупном масштабе. Стрелки, переходы, названия экранов должны быть видны издалека. Используйте для этого яркие, контрастные к фону цвета. При этом не стоит злоупотреблять цветокодированием — слишком пёстрые схемы сложнее воспринимать. Вводите дополнительные цвета только когда понимаете, что без них не обойтись.
Близкие по смыслу экраны на карте должны по возможности располагаться рядом. Если между экраном подготовки к бою и самим экраном боя находятся тысячи пикселей, это сильно усложняет их общее восприятие.
Старайтесь без жёсткой необходимости не менять расположение экранов на схеме с каждой итерацией — это запутывает. Лучше оставляйте плейсхолдеры под те экраны и разделы, которые пока находятся в разработке.
Карта должна обновляться регулярно, но без фанатизма. Цените своё время. Если вы на каком-то экране поменяли размер шрифта в колонке с 30 на 24 pt, то обновлять всю схему необходимости нет. Только не забудьте отследить, чтобы эта информация не потерялась по пути до верстальщика.
Вообще, составление и обновление карты не должно отнимать много времени. Если каждая итерация карты занимает час, подумайте, подходящий ли инструмент вы используете для ее создания.
Старые варианты карты лучше сразу удалять или хранить их там, где на них никто не наткнется случайно.
На карте должны быть чётко и однозначно отмечены точки входа и перехода на другие карты (если они есть). У человека, впервые в жизни открывшего этот файл, не должно возникать вопросов, откуда начинать движение по карте. Не стесняйтесь помечать стартовый экран крупной стрелкой или надписью.
Напоследок, пара слов об инструментарии. По сути, карта экранов — просто большая картинка, и принципиального значения, в какой программе вы её создаете, нет. Требования тут очень простые: программа должна позволять работать с картинками больших размеров, иметь возможность работать с текстом и стрелками, а также позволять без проблем двигать и выравнивать все элементы.
Сам я для составления карт экранов обычно использую Adobe Illustrator. Люблю его за удобную реализацию работы со стрелками, а также за возможность автоматического обновления вложенных картинок и различные плюшки вроде автозамены стилей.
Однако это вопрос привычки. Photoshop также прекрасно справляется с подобными задачами. Кроме того, есть ряд весьма неплохих онлайн-сервисов вроде realtimeboard, conceptboard или mural.co, позволяющих составлять карты экранов онлайн, а кто-то вообще работает с ними в Google Docs. Попробуйте разные варианты, чтобы понять, что лучше подходит именно вам и вашей команде.
В общем-то, на этом всё. Ещё раз повторю мысль о том, что карта экранов — не волшебное лекарство, способное в момент решить все проблемы проекта, связанные с интерфейсами. Тем не менее, это достаточно полезный и эффективный инструмент, позволяющий, при должном применении значительно упростить и структурировать работу, сделать её более осмысленной и понятной, а значит улучшить финальное качество интерфейса в целом.