карта экранов что это
Карта навигации
Часто начинающие дизайнеры вместо того чтобы рассматривать страницы сайта, или экраны мобильного приложения, в одной связке, как целостный сценарий, рисуют набор картинок и потом кидают его клиенту и разработчикам. Это приводит к двум основным проблемам:
В таких случаях помогает инструмент который я называю Карта навигации (по-буржуйски 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.
Вот пример некоторых ранних макетов моего собственного приложения.
Вот работа с цветовой палитрой.
В процессе стоит показывать свои макеты коллегам и знакомым — так вы сможете получить фидбэк, не имея прямого доступа к потенциальным пользователям. В моем случае большинству людей, кому я показывала макеты, понравился черно-золотой вариант.
К слову, в процессе обсуждения вашей работы будьте готовы встретиться с новыми идеями — вам могут предложить что-нибудь очень интересное! — и предложениями. Вы можете получить весьма интересные идеи, когда общаетесь с потенциальными пользователями приложения.
В моем случае я получила несколько идей, которые затем использовала в новом макете.
Дизайн приложения получился лаконичным, на панели задач есть иконки и все элементы управления. Далее я проработала все остальные экраны приложения, взяв это оформление экрана за основу.
Карта навигации
Карта навигации составляется когда уже есть четкое понимание общей логики и проработаны прототипы основных экранов.
Александр Волошин (UX CLAN) рассказывает о том, как правильно делать карту навигации для приложения.
Часто начинающие дизайнеры вместо того, чтобы рассматривать страницы сайта или экраны мобильного приложения в одной связке, как целостный сценарий, рисуют набор картинок и потом кидают его клиенту и разработчикам. Это приводит к двум основным проблемам:
В таких случаях помогает инструмент, который я называю Карта навигации (по-буржуйски User flow). Конечно, можно запилить крутой интерактивный прототип который можно протестировать сразу на устройстве, но он не позволяет увидеть сразу общую логику работы и пройтись по основным сценариям. Придется долго-долго клацать, особенно если это мобильное приложение, а потом все равно нужно рисовать схему…
Карта навигации составляется когда уже есть четкое понимание общей логики и проработаны прототипы основных экранов. Я делаю карты двух видов: общая карта и карта по сценариям. Их так же можно комбинировать, все зависит от сложности проекта.
Общая карта
Такая карта показывает как общую логику так связи всех экранов, используется когда проект не сильно большой и можно уместить все на одном условном листе.
Повторюсь, показываются все экраны и все связи чтобы любому члену команды была понятна логика работы и связи всех экранов, чтобы потом не доставали вопросами.
Карта по сценариям
Такая карта используется когда проект большой и сложный, в нем много-много-много экранов и много-много-много сценариев. В основном это характерно для мобильных приложений у которых нет четкой структуры а одни и те же экраны могут встречаться в разных сценариях.
Инструменты
Сначала я использовал Adobe Illustrator, в котором создавал детализированный прототип основных экранов, потом сохранял все экраны в отдельные джипеги и собирал карту в отдельном документе. Это очень удобно, так как когда вносишь изменения в прототип и потом сохраняешь этот экран, Illustrator автоматически обновляет файлы в карте.
Сейчас я использую Sketch и в нем нельзя апдейтить растровую графику, по крайней мере я не нашел как это сделать, и это чуть расстраивает.
Растровые картинки в скетче можно обновлять через несколько плагинов, например, https://github.com/frankko/Place-Linked-Bitmap. Если не менять название файла, то при изменении, он будет обновляться автоматически.
На днях вышло большое обновление плагина UserFlows и теперь он стал (или претендует на это) удобным инструментом для создания карт без дополнительных плясок https://abynim.github.io/UserFlows/.
Еще можно использовать Axure по такой же схеме, как с Illustrator. В общем, для создания карты навигации лучше использовать тот же инструмент, что и для разработки прототипа.
Советы
1. Используй хорошо проработанный прототип, подписывай все экраны и добавляй комментарии которые помогают лучше понять логику.
2. Если сценариев много и они большие, лучше их показывать на отдельных листах.
3. Карту можно делать комбинированной (все экраны + основной сценарий) и отдельно показывать экраны с более детальным описанием взаимодействия.
4. Карту лучше составлять параллельно с разработкой прототипа, то есть сразу выкладывать экраны в сценарии, тогда сразу видны все косяки и недоработки.
Передача проекта от дизайнеров iOS разработчикам
Карта экранов содержит в себе все экраны приложения и все возможные переходы между ними. Для каждого из переходов должно быть строго обозначено действие, инициирующее его (к примеру, нажатие кнопки или определенный жест пользователя). Каждый из экранов должен быть определенным образом обозначен (порядковый номер, название, код). В дальнейшем именно это обозначение используется в качестве ссылки на этот экран (к примеру, при наименовании папок, содержащих нарезку ресурсов).
2. Карта цветов приложения
Карта цветов — это изображение, содержащее список всех цветов, используемых в приложении (как многократно, так и единоразово).
3. Список шрифтов приложения
Список шрифтов представляет собой текстовый документ, в котором перечислены все использующиеся в приложении шрифты. Указывается только название шрифта; размер в данном случае писать не нужно.
Если предполагается использовать нестандартный шрифт, он должен быть приложен к набору предоставляемых документов.
Список стандартных шрифтов представлен здесь.
Формат: txt, doc, pdf (для списка шрифтов). ttf/otf для нестандартных шрифтов.
4. Разметка состояний экранов
В большинстве случаев каждый из экранов может находиться в различных состояниях. Каждое из таких состояний, в том числе и основное, должно быть представлено в отдельном файле.
Про отличия пойнтов от пикселей и размеры экранов различных устройств хорошо написано здесь. Также, чтобы иметь представление об адаптивной верстке, стоит прочитать эту статью.
Формат: png.
Если одна и та же иконка используется на нескольких экранах, то нарезается она только один раз и кладется в папку common. Важно следить за тем, чтобы у разных иконок (даже находящихся в разных папках) не было одинаковых названий.
6. Видео нестандартных анимаций
Так как выделить в общем виде набор стандартных анимаций не представляется возможным, то все планируемые анимации нужно обсуждать с командой разработчиков.
Для всех нестандартных анимаций должны прилагаться пояснительные видео или gif. Кроме этого, нужно подготовить и текстовое описание происходящего: какой параметр анимируется, за какое время, у какого объекта. Например: »заголовок увеличивается в 2 раза за 1 секунду с линейной скоростью», «изображение поворачивается на 90 градусов за 2 секунды с функцией плавности easeInOutQuart».
7. Иконки приложения
Иконки приложения должны быть квадратными (без скругленных углов) и предоставлены во всех необходимых размерах. Список размеров можно посмотреть здесь.
Автоматически нарезать иконки в нужных размерах поможет этот psd.
Формат: png.
Неплохой набор psd-шаблонов для генерации скриншотов всех размеров.
Формат: png.
Некоторые из перечисленных требований могут показаться излишними, но опыт показывает, что следование этим гайдлайнам экономит время не только разработчикам, но и самим дизайнерам.
Похожие гайдлайны в настоящий момент формируются и командой Android-разработчиков, так что, если читатели будут заинтересованы — обязательно опубликуем в недалеком будущем.
Как подготовить макет интерфейса мобильного приложения к передаче в разработку?
Или «как сделать вашего разработчика счастливым, а финальное приложение точно сверстанным по макету».
Каждому, кто так или иначе связан с мобильной разработкой, знакомы проблемы и разногласия, возникающие на стыке интересов программиста и дизайнера мобильного приложения, когда речь заходит о том, как правильно подготовить и передать дизайн в разработку.
Проанализировав свой многолетний опыт работы, я с уверенностью могу сказать, что:
Дизайн мобильного приложения считается законченным только тогда, когда разработчику переданы все необходимые для его верстки материалы, а это далеко не только один макет.
Основное, что должен получить от вас разработчик:
Немного расскажу поподробней про каждый пункт.
Непосредственно сам макет
Дизайн-макет приложения может быть выполнен в любом удобном вам и вашей команде инструменте. Как правило, это Sketch, XD, Figma, Photoshop или Illustrator. Другие инструменты are fine as well, но лучше использовать что-то популярное.
В чём бы вы ни работали, ещё раз проверьте, всё ли внутри макета в порядке, а именно:
👉 Зачем это? Это просто контроль качества. Если макет сделан некорректно, то это так или иначе приведет к конфликту или правкам. Лучше сделать хорошо сразу.
Макет для «просмотра глазами разработчика»
Макет нужно загрузить в Zeplin или Sympli. Ну или сгенерировать ссылку для разработчика, если вы работаете в Figma или Sketch.
👉 Зачем это? Это делается для того, чтобы разработчик мог посмотреть все спецификации (отступы, размеры, цвета, названия шрифтов и пр.) и при этом не открывать оригинальный файл с дизайн-макетом в редакторе, которого, к слову, у него может и не быть.
Карта экранов
Карта экранов — это изображение, которое отражает в себе все экраны приложения и все возможные переходы между ними.
Для каждого из переходов желательно обозначить действие, инициирующее его (к примеру, нажатие кнопки или определенный жест пользователя). Каждый из экранов должен быть определенным образом обозначен (например, номер или название).
Карту экранов лучше всего рисовать в инструментах для составления mindmap’ов. Мои любимые, например, XMind и MS Visio.
👉 Зачем это? Карта экранов поможет разработчику разобраться с логикой приложения. Из нее он сразу получит ответы в стиле «что будет, если нажать на это?».
Кликабельный прототип
Кликабельный прототип — это интерактивный макет, цель которого в данном случае также показать разработчику, как должно работать приложение, согласно вашей задумке.
👉 Зачем это? По тем же соображениям, что и карта экранов. Одно можно заменить другим. Но, как правило, кликабельный прототип более нагляден для разработчика и для клиента.
Экспорт иконок и иллюстраций
Нужно экспортировать и разложить по соответствующим папкам все использованные в макете иконки и иллюстрации в формате PNG для всех 6-ти плотностей экранов (mdpi, hdpi, xhdpi, xxhpdi, xxxhdpi) для Android и в формате PNG или PDF для всех 3-х плотностей экранов (@1x, @2x, @3x) для iOS. Также можно использовать SVG, тогда достаточно по одному файлу.
Обязательно все иконки и иллюстрации должны быть адекватно проименованы в соответствии с принципами:
Итого, у вас должна получиться следующая структура:
👉 Зачем это? Если разработчик будет сам экспортировать иконки, то что-то обязательно пойдет не так. Поедет цвет, иконки станут мыльными и так далее. К тому же, он будет вынужден потратить время на то, чтобы разобраться с тем, как их экспортировать и как назвать, вместо того, чтобы кодить. Лучше избежать этого и сделать всё самому. Тогда разработчик просто скопирует всё в Android Studio или XCode и будет счастлив.
Шрифты
Нужно сложить в отдельную папку все шрифты, использованные в макете. Если это платный шрифт, то ссылку на место, где его можно купить. Но лучше не использовать платные шрифты.
👉 Зачем это? Если разработчик будет искать использованные вами шрифты сам, то есть вероятность того, что он найдет не тот шрифт или, например, устаревшую версию шрифта. Лучше всего будет просто потратить 2 минуты и сохранить шрифты отдельно.
Видео с анимациями
Если вы сделали очень клевую нестандартную анимацию интерфейса в After Effects или Principle и хотите её реализовать, то её тоже нужно экспортировать и передать разработчику. Можно как в видео-формате, так и в формате GIF.
Если же вы просто хотите сделать «как вот в этом приложении», то не забудьте положить ссылки на примеры таких анимаций.
👉 Зачем это? Если разработчик не увидит вашей анимации, он просто её не реализует и ваша задумка окажется лишь задумкой.
Итого
Таким образом, финальный идеальный ZIP-архив, который отдается счастливому разработчику должен иметь примерно такую структуру:
Кроме этого в файле ReadMe.TXT или в сопроводительном письме не забудьте добавить ссылки на:
Буду рад вашим комментариям 💬 и аплодисментам 👏.