зачем нужна карта экранов
Карта навигации
Часто начинающие дизайнеры вместо того чтобы рассматривать страницы сайта, или экраны мобильного приложения, в одной связке, как целостный сценарий, рисуют набор картинок и потом кидают его клиенту и разработчикам. Это приводит к двум основным проблемам:
В таких случаях помогает инструмент который я называю Карта навигации (по-буржуйски 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-разработчиков, так что, если читатели будут заинтересованы — обязательно опубликуем в недалеком будущем.
Разработка мобильного приложения: как создать прототип и зачем нужен MVP
руководитель направления мобильной разработки компании Neti
Практически каждый современный бизнес хочет обзавестись мобильным приложением. Одни используют его для связи с клиентами, другие — для автоматизации внутренних процессов и повышения эффективности сотрудников. При этом сегодня все больше компаний разрабатывают мобильные приложения для доставки в условиях самоизоляции.
О том, как создается прототип и зачем нужен MVP мобильного приложения, рассказывает Наби Ибатулин, руководитель направления мобильной разработки компании Neti.
Преимущество мобильного приложения заключается в том, что оно нативно работает на смартфоне или планшете пользователя. Однажды установленное на устройство, мобильное приложение потребляет минимум трафика, может работать в автономном режиме и потенциально создает обширные возможности для персонализации.
Но для этого нужно тщательно проработать как логику функционирования приложения, так и его интерфейс.
Прототип мобильного приложения
В мобильной разработке прототипом обычно называют проработку пользовательского интерфейса. Основная задача на стадии прототипа заключается в том, чтобы нарисовать внешний вид экранов, а также продумать логику перехода между ними. Прототип может создаваться как самим заказчиком, так и дизайнерами подрядчика.
Получить цифровую карту за 40 секунд — легко!
Прототип приложения — пример набора экранов
Для простых приложений, таких как мобильная версия интернет-магазина или форма заказа блюд из ресторана, прототип выглядит достаточно просто. В нем должен содержаться каталог, корзина и форма отправки заказа.
Для более сложных приложений, содержащих чаты, интегрированных с картой или платежными шлюзами, поддерживающих программы лояльности, прототип будет выглядеть сложнее. Поэтому на его разработку уходит больше сил и времени.
Запуск в формате MVP
Хорошо, когда вы понимаете, каким должно быть приложение, четко формулируете спектр его функций и возможностей и предоставляете исполнителю исчерпывающее техническое задание. Однако в 90% случаев ситуация складывается иначе, и менеджеры разработчика участвуют в создании концепции мобильного приложения вместе с заказчиком.
На большинстве проектов используется подход MVP (Minimum Viable Product). В состав MVP обычно входят только самые базовые элементы мобильного приложения.
Например, если речь идет о заказе товаров на дом, MVP будет включать в себя каталог и форму заказа. Такие функции, как оплата в приложении, встроенный чат и поддержка push-уведомлений, как правило, реализуются на следующих этапах.
Белые — часть MVP, серые — для последующей реализации
Запуск MVP позволяет предложить пользователям первую версию своего мобильного приложения намного раньше, чем если бы разработка велась сразу по всем предполагаемым функциям.
В зависимости от проекта, MVP приводит к значительному сокращению time-to-market — иногда даже до 10 раз!
Возможность получить первичный фидбек от своих пользователей помогает скорректировать или сформулировать стратегию развития приложения. Например, может оказаться, что вам вовсе не нужна геолокация или интеграция платежного шлюза. Это позволит сэкономить время и средства, которые ушли бы на реализацию этой функции.
Использование кросс-платформенных фреймворков
Разработка мобильного приложения начиная с MVP может происходить нативно для конкретных платформ — например, iOS и Android, — либо на базе универсального фреймворка.
Используя Flutter или React Native можно создать одно приложение, которое будет работать сразу на всех платформах. Таким образом, время разработки уменьшается как минимум вдвое, а любые изменения и доработки отражаются на версиях для всех платформ.
Минусы такого подхода — это увеличенный размер приложения и незаметное для пользователя снижение производительности. Но для бизнес-проектов зачастую гораздо критичнее оказывается time-to-market.
Интеграции мобильного приложения
Еще один важный момент, о котором нужно помнить при разработке мобильного приложения, — это наличие серверной части. Даже когда запускается первая, упрощенная версия MVP, приложение с мобильного устройства клиента должно обращаться к серверу, получать и отправлять данные.
Если речь идет о мобильном приложении для бизнеса, то на серверной стороне бывает полезно сразу провести интеграцию с другими системами.
Например, у многих уже есть каталог в 1С, используется CRM для приема заказов либо уже подключена система лояльности, которую логично использовать в мобильном приложении. Вместо разработки дублирующих решений логично настроить интеграцию и использовать имеющиеся системы.
Дальнейшее развитие
После успешного прохождения стадии MVP мобильное приложение продолжает развиваться и обрастать функциональностью. Дальнейшая разработка может происходить в самых разных форматах, с использованием фреймворков или без них.
Но самое главное — тщательно проработать стадию прототипа и MVP, потому что вносить изменения в уже реализованные элементы дольше и дороже, чем планировать постепенное развитие продукта и на каждом этапе адаптировать свое видение мобильного приложения к запросам реальных пользователей.
Как достичь максимума
Если вы решили создавать мобильное приложение, перед стартом проекта следует выполнить следующие шаги: