Дизайн мобильных приложений уроки – Курс «Дизайн мобильных приложений»: обучение дизайну приложений
Процесс создания дизайна мобильного приложения с нуля
Я начала изучать графический дизайн, когда мне было 13 лет. Я научилась проектировать веб-сайты по онлайн-курсам и целыми днями игрался с Photoshop и Affinity Designer. Этот опыт научил меня мыслить, как дизайнер.
Я занимаюсь проектированием и разработкой приложений уже почти год. Я приняла участие в программе Массачусетского технологического института, где я работала в команде по разработке приложения Universeaty. Два месяца назад я начала работать над новым приложением Crypto Price Tracker, которое вышло недавно, 28 января.
В этой статье я поделюсь поэтапным процессом проектирования, которому я следую при работе над приложениями. Это должно помочь тем, кто хочет научиться или улучшить свои навыки цифрового дизайна. Дизайн – это не только то, как использовать программное обеспечение для проектирования, и эта статья не научит вас, как его использовать. Есть сотни качественных обучающих программ в Интернете. Дизайн также касается понимания сути вашего продукта, его функциональности, а также проектирования, не забывая о конечных пользователях. Вот чему вас научит эта статья.
Процесс проектирования:
- Создайте юзерфлоу для каждого экрана.
- Создайте / нарисуйте прототипы.
- Выберите шаблоны дизайна и цветовые палитры.
- Создайте дизайн.
- Создайте анимированный прототип приложения и попросите людей проверить его и оставить отзыв.
- Сделайте финальную ретушь макетов, чтобы все финальные экраны были готовы к разработке.
Давайте начнем!
Юзерфлоу
Первый шаг – выяснить, какие функции вы хотите видеть в своем приложении. После того, как у вас появились идеи, создайте юзерфлоу. Это блок-схема работы вашего приложения.
Обычно юзерфлоу состоит из трех типов фигур.
- Прямоугольники используются для представления экранов.
- Ромбы используются для условий (например, нажатие кнопки входа в систему, свайп влево, увеличение).
- Стрелки соединяют экраны и условия вместе.
Юзерфлоу очень полезны, потому что они дают хорошее логическое представление о том, как приложение будет функционировать.
Вот диаграмма юзерфлоу, которую я нарисовала, когда начала работать над дизайном моего приложения.
Юзерфлоу для основного интерфейса.Прототипы
После того, как вы завершили делать юзерфлоу для каждого экрана, вы начнете работать с протопипами всех экранов. Прототипы – это, по сути, низко детализированные наброски ваше приложение. По сути, эскиз или схема того, где будут располагаться изображения, ярлыки, кнопки и прочее. Грубый эскиз того, как ваше приложение будет работать.
Я использую печатные шаблоны из UI Stencils для рисования каркасов. Это экономит время и дает хорошую рабочую область для рисования и заметок.
Вот пример прототипа.
Прототип интерфейса мобильного приложенияПосле создания прототипов вы можете использовать приложение под названием Pop и сделать снимок всех своих рисунков с помощью приложения и получить кликабельный прототип, связав все экраны с помощью кнопок.
Наброски дизайна и цветовые палитры
Это моя любимая часть. Это похоже на разглядывание витрин. Множество паттернов дизайна и цветовых палитр на выбор. Я выберу те, которые мне нравятся, и буду экспериментировать с ними.
Лучшие платформы для поиска паттернов – это Mobile Patterns и Pttrns. И чтобы найти хорошие цветовые палитры, посетите сайт Color Hunt.
Дизайн
Наконец вы переходите к использованию программного обеспечения для создания дизайна. Это похоже на то, что вы вошли в свое приложение в будущем, и сделали несколько скриншотов. Это должно выглядеть реалистично и в значительной степени похоже на реальную вещь.
Существуют программные средства разработки и инструменты для создания дизайна. Я использую Affinity Designer. Наиболее часто используемым инструментом для дизайна iOS является Sketch.
Вот пример некоторых ранних дизайнов моего приложения.
Перенесение рисунка в пиксели!Я больше экспериментировала с различными цветовыми палитрами.
Я поделилась первоначальными макетами с друзьями, чтобы получить их отзывы. Кажется, многим понравилась схема с золотым градиентом и черным.
Будьте готовы получить отзывы и поэкспериментировать с новыми предложениями! Вы получите удивительные отзывы от своих пользователей, когда разговариваете с ними, а не когда лихорадочно просматриваете Dribbble или Behance.
Поэтому я переработала макет и удалила фоновые графики, потому что их генерация была технически трудоемким процессом, и они снижали читабельность. Что в итоге вышло:
Золотой градиент с черным на удивление хорошо выглядит!Я была довольна цветовой схемой, значками на панели вкладок и общей компоновкой. Я пошла дальше и разработала остальные экраны, следуя тем же принципам дизайна. Это был долгий, но безумно увлекательный процесс!
Когда все мои экраны были готовы, я собрала прототип в Adobe XD и попросила нескольких друзей поэкспериментировать и дать свой отзыв.
После последних штрихов именно так выглядит финальная версия моего дизайна.
Финальная версия дизайнаПосле того, как все экраны были завершены, я импортировала их в Xcode и начала разработку приложения.
Вот и все! Я надеюсь, что эта статья поможет вам начать работу над дизайном приложения или поможет стать лучшим дизайнером. И если вам нравится мое приложение, вы можете скачать его здесь.
Я заканчиваю статью одной из моих любимых цитат о дизайне
«Дизайн – это не только, как предмет выглядит и ощущается. Дизайн – это то, как он работает»
– Стив Джобс
ux.pub
Общие принципы в создании мобильных приложений для начинающего UX/UI-дизайнера / e-Legion corporate blog / Habr
Привет! После предыдущих моих постов мне часто писали ребята, которые начинают изучать тему UI/UX. Это так классно, спасибо вам! И в этой статье я делюсь принципами, которые будут интересны и полезны новичку.
Начинать знакомство с приложением через onboarding — хорошо. Для чего это нужно? Когда пользователь скачивает приложение, он «примерно» представляет себе функционал. При старте удобно показать основные функции приложения, чтобы пользователь не путался и начал им пользоваться.
Ещё они нужны, когда выходит классное обновление в приложении, и грех его не выделить.
Яндекс.Транспорт рассказывает о новых фишках.
Среднее количество слайдов 3-4, больше читать неинтересно.
iOS , Android , Windows — у каждой оси есть своя «модель поведения», т.е. все пользовательские сценарии зачастую отличаются друг от друга, и чтобы лучше понимать логику каждой платформы, необходимо смотреть гайды и приложения на устройствах.
Пример отображения экрана на iOS и Android.
Итак, прежде чем делать приложение одной компании, стоит посмотреть, как оно реализовано у других.
9-ая операционная система поддерживается не на всех устройствах, т.е. рисуя макеты для iPhone 6, используя шрифт SF, необходимо понимать, что у некоторых пользователей будет старая добрая гельветика. (Это нестрашно, разве что, может помешать в максимальном значении символов в одной строке)
В принципе, разница не раздражает, а кому-то и совсем не видна.
Использовать прилипающую кнопку в дизайне не стоит. Это связано с тем, что она хорошо смотрится на продуманном (прорисованном) макете, но на других экранах перекрывает большую часть вместе с клавиатурой. Тут есть два выхода:
— продумать решение для всех разрешений, нарисовать и передать разработчику все спецификации;
— использовать другую кнопку.
Красота в деталях. Особенно приятно, когда в приложении продуманы все мелочи: что делать, если контента пока нет? Не загрузился? Загрузилась часть? Отвалился интернет? Всё это необходимо отрисовать и отдать разработчику, иначе он всё сделает за вас.
Удобно выработать эти принципы для себя, вынести их на отдельный файл и при случае всегда отдавать разработчику.
Шрифт (android)
Недавно я столкнулась с тем, что в Аndroid каждая компания задает свой шрифт, т.е. может получиться такая ситуация, что в модели нет шрифта roboto. Или пользователь установил свой шрифт в смартфоне (рукописный или др.). Что делать в этом случае? Идеальная картина на nexus, это слишком маленький процент, чтобы ориентироваться только на него.
Разработчики зашивают функцию «использовать дефолтный шрифт», и я с этим согласна. Если же загрузить шрифт в библиотеку приложения, вы лишаете пользователя привычного для него экрана, и я не думаю, что пользователь обрадуется.
А ещё можно встретить вот такие баги.
Здесь ситуация ещё интереснее, чем в iOS. Размеров смартфонов даже в одной ветке (XH, например) много, и сделать на всех устройствах идеально невозможно. Но может помочь выработка принципа отображения элементов. Как вариант, выяснить для себя, что отображение функций на экране девайса 2:1 и передать эту информацию разработчику.
Тут стоит не забывать проработать момент с клавиатурой и набором текста.
Пожалуйста, любите детали!
Вы знали, что клавиатуру в iOS по-хорошему сворачивать нельзя, если она появляется по умолчанию, а в Android можно? И тогда остается пустое, незаполненное пространство.
Если у вас остались вопросы или вы считаете иначе, то я буду рада пообщаться с вами! И спасибо вам за ваши комментарии!
Мой e-mail: [email protected]
Вклад дизайнера в разработку мобильных приложений / Habr
Дизайнер и его роль в разработке мобильных приложений
Все мы знаем, что дизайн играет очень важную роль в проектировании и разработке мобильных приложений. У каждого дизайнера свои подход, методы и инструменты для работы над приложениями. От того, на каких платформах будет работать дизайнер и как он преподнесет готовый материал проектной команде зависит темп дальнейшей разработки.
Не секрет, что проектные команды часто меняются. Сегодня над проектом работает один, а завтра уже абсолютно другой человек. Поэтому дизайн мобильного приложения — это не просто хорошо нарисованные картинки, но и качественно переданный материал, показывающий другим людям, как должно работать приложение.
В этой статье я хочу рассказать о взаимодействии разработчика с дизайнером, основываясь на собственном опыте разработки мобильного приложения, о своих ожиданиях от проекта и жестокой реальности. Надеюсь, эта статья заставит многих дизайнеров-новичков призадуматься над своей работой, а также поможет разработчикам справится с некоторыми сложными ситуациями.
Как дизайнер может облегчить жизнь разработчику?
Итак, у дизайнера, независимо от его профиля и направленности, существует множество инструментов, с помощью которых он может отрисовать то, что от него требуют. Только вот просто отрисовать экраны мобильного приложения недостаточно. Это не веб-сайт и не веб-приложение. У этой категории цифровых продуктов более строгие правила, которым нужно подчиняться. Под платформы IOS и Android созданы отдельные гайдлайны (см. раздел «Полезные ссылки»).
В настоящее время ситуация складывается так, что у разработчиков, как и у дизайнеров, очень много специфических инструментов и гайдов. Им не то что не хочется вникать в инструменты дизайна — им просто некогда. Дизайнер только сдал свою работу, а от разработчика уже требуют результаты менеджер проекта и клиент. Чем же в этом случае может помочь дизайнер? Как он может сэкономить время разработчику? Все довольно просто — нужно правильно подобрать инструменты не только для отрисовки проекта, но и для последующей работы с командой разработчиков.
После нескольких лет работы во многих непохожих друг на друга командах, я понял, как влияет дизайн на скорость разработки и комфортную работу в коллективе. Поэтому теперь, перед тем, как принять дизайн в разработку, я проверяю его на соответствие некоторым стандартам и правилам.
Дизайнер — часть команды
Это не просто пафосные слова. Дизайнер должен быть частью команды до сдачи приложения в магазин, постоянно общаться с коллегами, уточнять вопросы и быстро реагировать на запросы разработчиков. Минимальный срок его нахождения в команде — до первой сдачи MVP.
Дизайнеру приходится доделывать свою работу, и хорошо, если он будет в это время в команде, чтобы можно было быстро внести изменения. Или он должен быть на связи для того, чтобы у проекта и команды не было проблем с оперативным изменением UI/UX.
Разработчик не должен разбираться, в каких программах был нарисован проект. Файлы должны открываться легко
Как уже было сказано выше, разработчику сейчас приходится столько всего изучать, что времени разбираться в графических редакторах просто нет. Поэтому дизайнер не должен отрисовывать элементы в Photoshop / Illustrator и сдавать макет в *.psd / *.ai файлах. Такие файлы довольно много весят и требуют установки пакета Adobe. Даже если это не играет особой роли, на изучение этих редакторов просто нет времени.
Разработчик хочет просто выбирать элементы и видеть, как их верстать, а не разбираться в структуре слоев одного огромного файла. Сейчас существует много графических редакторов для отрисовки мобильных приложений: Sketch, Figma и другие. В общем, есть из чего выбрать. От выбранного редактора будет зависеть то, как дизайнер представит кликабельный прототип и “живые экраны” для фронтенда.
Если дизайнер выбрал Figma, то “живые” экраны, кликабельный прототип, юзер стори, переходы экранов, семейства шрифтов и колористика, ресурсы можно скачивать самостоятельно — все находится в одном месте. Изменения дизайна видны сразу. Как и у многих сервисов, у Figma есть свои минусы. Но это довольно удачный выбор, хотя бы потому, что данный редактор не требует установки специального ПО. Нужен просто переход по ссылке на проект. Главное, чтобы был интернет.
Sketch — тоже неплохой выбор. Дизайнер в пару к этому редактору может использовать такие инструменты прототипирования как Zeplin или InVision, если с ними уже работает команда разработчиков. Это программы не требуют углубленного изучения инструментария.
Дизайнер должен знать гайдлайны под разные платформы и их отличия
Довольно часто дизайнеры рисуют проекты, не разбираясь в гайдлайнах, смешивают стили или создают нестандартные элементы, думая о красоте экрана. Таких примеров довольно много на Dribbble и Behance. Клиенты, не зная об этих нюансах, одобряют макеты. Когда дело доходит до разработки, дело стопорится. Дизайнер не хочет переделывать неправильно выполненную работу. Заказчик требует именно такой экран или эффект, который он одобрил, но его невозможно сделать.
Поэтому очень важно, чтобы дизайнер разбирался в том, что и как можно отрисовывать.
Ресурсы
Это самый больной вопрос при взаимодействии с дизайнером. Обычно дизайнеры не нарезают ресурсы. В большинстве своем они считают, что: не обязаны это делать; это долго и монотонно, и если разработчику надо, он сам все нарежет или можно сбросить *.svg; не знают, что именно нужно нарезать и в каких размерах.
Тем не менее, если взглянуть со стороны разработчика, решение этого вопроса очень сильно сокращает время работы. Ему достаточно взглянуть на название ресурса на прототипе и найти в папке ресурсов такое же — и все, он продолжает верстку. А если представить, что разработчику нужно самому нарезать ресурсы? Он должен полностью выделить нужный элемент на экране, найти экспорт, указать размеры и путь.
Только кажется, что это быстрая работа. Но элементов много, и времени тратится масса. Опять же, макеты не всегда сдаются в идеальном состоянии. Дизайнер не всегда всё учитывает. Также инструмент прототипирования может неправильно сработать при экспорте.
Пытаясь выделить элементы для нарезки, разработчики иногда выделяют только часть элемента или цепляют фон (который должен быть прозрачным). Поэтому хорошо, когда дизайнер не только нарезает ресурсы, но еще и использует правильные размеры.
ТЗ с описанием работы экранов
Хорошо, когда приложение состоит из небольшого количества экранов и с первого взгляда понятно, как оно работает. Если в приложении большое количество экранов и прототип не дает полной картины его работы либо приложение разрослось после внесения изменений по желанию заказчика, техническое описание всех экранов, каждого элемента на этом экране и его состояния может спасти ситуацию.
Как говорилось выше, члены проектных команд часто меняются. Никто не хочет возиться с новичками. Возможно, коллеги сделают краткий обзор, скинут ссылки на все выданные дизайнером ресурсы — и все. От разработчика ждут, что он начнет работать с полным понимаем, как функционирует приложение. Чаще всего ТЗ, разъясняющего это, нет, поскольку дизайнер не знал о том, что оно требуется, или не захотел его делать. И что же выходит? Работа стопорится. Новый член команды не понимает, что и как функционирует, работает в полсилы, тратя при этом время команды.
Что делать, если ничего из вышеперечисленного нет, а работать нужно?
Так получилось, что все вышеперечисленные требования стали обязательными в одном из моих проектов.
Проект был связан с арендой недвижимости и разрабатывался под две платформы: IOS и Android. Процесс разработки начинался как любой другой. Позже оказалось, что дизайнер не полностью разбирался в мобильных приложениях. Что такое гайды он не знал. На дизайне присутствовали прозрачные элементы, шрифты использовались только под одну платформу. Колористику можно было описать как использование “50 оттенков серого”.
Мне дали *.psd файл. Вроде бы ничего плохого. Такие файлы сдают многие дизайнеры. Но мне пришлось установить пакет Adobe, чтобы взглянуть на макет. Файл был очень “тяжелым” и открывался минут 10. Не все экраны были отрисованы отдельно на рабочей области. Они находились один поверх другого как слои, и чтобы посмотреть один экран, нужно было отключить все остальные. Так как у меня не было значительного опыта работы с пакетом, я подумал об Avocode как об инструменте для обработки дизайн-материала. Конечно, эта программа не идеальна, но она меня буквально спасла.
Кликабельный прототип мне передали в InVision. Замечу, просто кликабельный прототип без живых экранов.
Выводы:
Что я ожидал получить от дизайнера:
- кликабельный прототип и живые экраны (InVision, Zeplin или Figma)
- переработанное ТЗ с описанием работы экранов
- карту экранов с переходами
- пользовательскую историю
- нарезанные ресурсы в размерах @1, @2, @3
- шрифты
Из всего перечисленного я получил только кликабельный прототип и *psd файл.
Проект доведен до конца и выложен в магазин. Но чтобы добиться этого результата, моя команда прошла семь кругов Ада или, как говорится, столкнулась с определенными трудностями.
Многие не согласятся и скажут, что предоставленных материалов достаточно. Но мы говорим о профессионализме и о том, как ситуация выглядит со стороны разработчиков. В конце концов, дизайнер мобильного приложения — это не просто художник. Это член команды, работающей над сложным проектом. Свою работу он должен делать хорошо, ведь для него это еще не конец работы над проектом, а для команды — только начало.
Всем спасибо за внимание и успешных проектов!
Полезные ссылки:
IOS guidelines
Android guidelines
Problems of development the legacy mobile project
Figma
Sketch
habr.com
Комплексное руководство по дизайну мобильных приложений
При разработке дизайна для мобильных устройств необходимо учитывать множество факторов. Мы уверены, что это подробное руководство избавит вас от головной боли при создании приложений.
Сегодня более чем когда-либо люди взаимодействуют со своими телефонами в критические моменты. Средний пользователь из США проводит 5 часов в день за мобильным телефоном. Подавляющее большинство этого времени тратится на приложения и на веб-сайты.
Разница между хорошим и плохим приложением обычно заключается в качестве пользовательского опыта (UX). Хороший UX – это то, что отличает успешные приложения от неудачных. Сегодня мобильные пользователи много ожидают от приложения: быстрое время загрузки, простота использования и удовольствие от взаимодействия. Если вы хотите, чтобы ваше приложение было успешным, вы должны считать UX не просто второстепенным аспектом дизайна, но важным компонентом стратегии продукта.
Есть много вещей, которые следует учитывать при разработке мобильных приложений. В этой статье я обобщил множество практических рекомендаций, которые вы можете применить к своему дизайну.
Минимизируйте когнитивную нагрузку
Когнитивная нагрузка относится к количеству умственных способностей, необходимых для использования приложения. Человеческий мозг имеет ограниченную вычислительную мощность, и когда приложение одновременно предоставляет слишком много информации, оно может ошеломить пользователя и заставить его отказаться от выполнения этой задачи.
Наведение порядка
Избавление от беспорядка – одна из главных рекомендаций статьи «10 Do’s and Don’ts of Mobile UX Design». Беспорядок – один из худших врагов хорошего дизайна. Загромождая интерфейс, вы перегружаете пользователей слишком большим объемом информации: каждая добавленная кнопка, изображение и иконка усложняют экран.
Беспорядок на ПК ужасен, но на мобильном устройстве он намного хуже (просто потому, что у нас не так много полезного пространства экрана, как на ПК и ноутбуках). В мобильном дизайне важно избавиться от всего, что не является абсолютно необходимым, потому что уменьшение беспорядка улучшит понимание. Техника функционального минимализма может помочь вам решить проблему загроможденного пользовательского интерфейса:
- Сократите контент до минимума (предоставьте пользователю только то, что ему нужно знать).
- Сохраняйте минимум элементов интерфейса. С простым дизайном пользователю легче взаимодействовать с продуктом.
- Используйте метод прогрессивного раскрытия, чтобы показать больше вариантов.
Упрощайте задачи
Ищите в дизайне все, что требует усилий пользователя (это может быть ввод данных, принятие решения и т. д.), и ищите альтернативные пути. Например, в некоторых случаях вы можете повторно использовать ранее введенные данные вместо того, чтобы просить пользователя ввести их повторно, или использовать уже имеющуюся информацию для установки умного значения по умолчанию.
Разбивайте задачи на небольшие куски
Если задача содержит много шагов и действий, требуемых от пользователя, лучше разделить ее на несколько подзадач. Этот принцип чрезвычайно важен в мобильном дизайне, потому что вы не хотите создавать слишком много сложности для пользователя за один раз. Хороший пример – пошаговый процесс оформления заказа в приложении электронной коммерции, когда дизайнер разбивает сложную задачу оформления заказа на куски, каждый из которых требует действий пользователя.
Разбивка задачи делает форму менее загруженной, особенно когда вы запрашиваете у пользователя много информации. (Изображение: Murat Mutlu)Разделение на блоки также может помочь соединить два разных действия (например, просмотр и покупка). Когда сценарий представлен в виде ряда шагов, логически связанных друг с другом, пользователю может быть легче его выполнить.
Поиск фильма и покупка билетов в кинотеатр. (Изображение: Anton Skvortsov)Используйте знакомые экраны
Знакомые экраны – это экраны, которые пользователи видят во многих приложениях. Такие экраны, как «Начало работы», «Что нового» и «Результаты поиска», де-факто стали стандартами для мобильных приложений. Они не требуют дополнительных объяснений, потому что пользователи уже знакомы с ними. Это позволяет пользователям использовать предыдущий опыт взаимодействия с приложением без необходимости обучения.
Экран профиля пользователя в приложении QuoraДля получения дополнительной информации о знакомых экранах. Прочтите статью «11 экранов, которые вы найдете во многих самых успешных мобильных приложениях».
Минимизируйте ввод информации пользователем
Набор текста на маленьком мобильном экране – не самое удобное занятие. На самом деле, оно часто подвержено ошибкам. И наиболее распространенным случаем ввода данных пользователем является заполнение формы. Вот несколько практических рекомендаций по упрощению этого процесса:
- Делайте формы максимально короткими, удаляя ненужные поля. Приложение должно запрашивать у пользователя только минимальный объем информации.
- Предоставьте маски ввода. Маски полей – это метод, который помогает пользователям форматировать введенный текст. Маска появляется, когда пользователь фокусируется на поле, и автоматически форматирует текст по мере заполнения поля, помогая пользователям сосредоточиться на необходимых данных и легче заметить ошибки.
- Используйте такие интеллектуальные функции, как автозаполнение. Например, заполнение поля адреса часто является наиболее проблемной частью любой регистрационной формы. Использование таких инструментов, как Place Autocomplete Address Form(который использует как географическое местоположение, так и предварительное заполнение адреса для предоставления точных предложений, основанных на точном местоположении пользователя), позволяет пользователям вводить свой адрес с меньшим количеством нажатий клавиш, чем при обычном поле ввода.
- Динамическая проверка значения полей. Это печально, когда после отправки данных вам приходится возвращаться и исправлять ошибки. По возможности, проверяйте значения полей сразу после ввода данных, чтобы пользователи могли их мгновенно исправить.
- Кастомизируйте клавиатуру для типа запроса. При запросе номера телефона отобразите цифровую клавиатуру и добавьте кнопку @ при запросе адреса электронной почты. Убедитесь, что эта функция реализована последовательно во всем приложении, а не только для определенных форм.
Предвосхищайте потребности пользователя
Проактивно ищите шаги в путешествии пользователя, где ему может понадобиться помощь. Например, на снимке экрана ниже показана часть, где пользователям необходимо предоставить конкретную информацию.
Не очевидно, где пользователь может найти штрих-код. Краткая справка рядом с полем ввода будет очень полезной. (Изображение: Hotjar)Используйте визуальный вес, чтобы подчеркнуть важность
Самый важный элемент на экране должен иметь наибольший визуальный вес. Добавление большего веса к элементу возможно посредством изменения веса, размера и цвета шрифта.
Большие предметы привлекают внимание и кажутся более важными, чем мелкие. Кнопка «Request Lyft» привлечет внимание пользователяИзбегайте жаргона
Четкое общение всегда должно быть главным приоритетом в любом мобильном приложении. Используйте то, что вы знаете о своей целевой аудитории, чтобы определить, подходят ли определенные слова или фразы.
Неизвестные термины или фразы увеличат когнитивную нагрузку на пользователя. (Изображение: ThinkWithGoogle)Сделайте дизайн последовательным
Последовательность является основополагающим принципом дизайна. Она устраняет путаницу. Поддержание общего согласованного внешнего вида во всем приложении имеет важное значение. Что касается мобильного приложения, последовательность означает следующее:
- Визуальная согласованность
Шрифты, кнопки и метки должны быть последовательными во всем приложении. - Функциональная последовательность
Интерактивные элементы должны работать одинаково во всех частях вашего приложения. - Внешняя согласованность
Дизайн должен быть последовательным для нескольких продуктов. Таким образом, пользователь может применить ранее полученные знания при использовании другого продукта.
Вот несколько практических рекомендаций по созданию последовательного дизайна:
- Соблюдайте стандарты платформы.
Каждая мобильная ОС имеет стандартные
ux.pub
Онлайн-курс «Дизайн мобильных приложений» Redmadrobot / Skillbox / Тэглайн: tema — LiveJournal
Открыта регистрация на курс дизайна мобильных приложений Redmadrobot — первую комплексную образовательную программу по мобильному дизайну на русском языке.
Старт первого потока — 31 октября. Скидка первым 20 участникам — 40%.
Вас ждут 50+ видеоуроков, разбор успешных кейсов, 12 домашних заданий, бонусные модули и дипломный проект с реальным заказчиком.
Вопросы, на которые ответит этот курс:
Что эффективнее — нативное приложение или «обертка» к сайту?
Нужно ли покупать тысячу устройств, чтобы все протестировать?
В чем специфика дизайна под Smart Watch и Smart TV и нужно ли гнаться за этими трендами?
Как получить фичеринг App Store и внимание обзоров?
Как создавать UI-киты, карты экранов и интерактивные прототипы и разбираться в паттернах навигации?
Как добиться того, чтобы вашим приложением продолжали пользоваться после первого раза, а не забывали про него навсегда?
В чем отличия платформ и как безболезненно адаптировать дизайн iOS-приложения под Android и наоборот?
Как проводить коридорное тестирование и защищать идеи перед клиентом?
Подробнее о курсеПочему этот курс достоин вашего внимания?
Преподаватели курса — практикующие специалисты Redmadrobot, арт-директора и ведущие дизайнеры, аналитики, программисты и менеджеры — люди разных специализаций, которые рассказывают о дизайне с разных сторон.
Знания, которыми они делятся, получены на реальных проектах компании.
В курсе охвачен широкий спектр инструментов мобильного дизайна — Sketch, Figma, Photoshop, Principle, After Effects, Framer, Flinto, Marvel и Zeplin.
В процессе выполнения домашних заданий вы создадите прототип, презентацию и собственный кейс дизайна мобильного приложения для портфолио на Behance.
Курс идеально подойдет для дизайнеров, арт-директоров, проектировщиков и разработчиков.
Чему вы научитесь
Понимать специфику платформ iOS и Android
Использовать основные инструменты мобильной разработки
Проводить предпроектные исследования, анализировать и задавать вопросы
Прорабатывать логику работы мобильного приложения на бумаге
Думать про customer experience вообще и про user experience в частности
Делать красивый и гармоничный дизайн, который нравится людям
Выдвигать гипотезы и проверять их в ходе разных видов тестирования
Понимать, как ваш дизайн будет реализован в коде
Оформлять мобильные приложения в красивые кейсы
Скидка 40% первым 20 участникам
при регистрации на странице tagline.ru/redmadrobot-mobile-design.
Скидки при участии 2+ человек от компании также предусмотрены, для получения более подробной информации заполните форму и дождитесь звонка менеджера.
Забронировать место со скидкойКурс рассчитан на 12 недель, обучение занимает 3–5 часов в неделю
50+ видеоуроков в 12 модулях по основным темам мобильного дизайна
Списки полезных книг, подкастов, YouTube- и Telegram-каналов
Отработка домашних заданий на кейсе реального клиента Redmadrobot
Индивидуальная проверка каждого задания преподавателем
2 дипломных работы: результат выполнения всех домашних заданий и экзаменационный проект
Публичный сертификат о прохождении курса (может быть присвоен компании, а не конкретному сотруднику)
Программа курса
1. Мобильная среда
— О курсе
— Особенности мобильных интерфейсов
— Платформа iOS
— Платформа Android
— Полезности
2. Процесс работы над дизайном
— Этапы создания продукта
— Этапы работы над дизайном
— Инструментарий
— Принципы успешного процесса
3. Инструменты дизайнера мобильных интерфейсов
— Sketch / Figma / Photoshop
— Principle / After Effects
— Framer
— Flinto / Marvel
— Zeplin
4. Старт проекта
— Цели и задачи продукта
— Процесс и артефакты аналитики
— Исследование рынка
— Критерии успешности продукта
5. Проектирование и UI/UX
— UI, UX, CX
— Информационный, навигационный и композиционный дизайн
— Прототипирование и проверка идеи
6. Создание визуальной концепции
— Необходимость визуальной составляющей
— Сетка и модульность
— Типографика и цвета
— Иллюстрации и иконографика
— Анимация
— Методология создания визуальной концепции
7. Принципы хороших интерфейсов
— Методики оценки интерфейса
— Функциональная доступность
— Очевидность возможностей
— Работоспособность в неидеальных условиях
— Бесшовный пере
tema.livejournal.com
Интеграция дизайна мобильных приложений. Часть 1: Android / Habr
Этот доклад я прочитал на Dribbble Meetup 2013, который прошел в Москве в День космонавтики. В нём описан мой процесс интеграции дизайна — то есть в каком виде передавать приложение от дизайнера к разработчику мобильных приложений. Выбор интсрументов, которые я использую в работе, и сам процесс сформировались опытным путём, методом проб и ошибок. Надеюсь, он поможет сохранить вам немного времени и избавит хотя бы от части рутинной работы. Так как презентация содержит достаточно большое количество слайдов, я решил разбить материал на две части. Первая часть — интеграция дизайна под платформу Android. Вторая — под iOS и Windows Phone, а также упомяну про Samsung Bada. Дальше — много картинок.
Проблематика
А начну я свой рассказ с момента, когда мы уже нарисовали макеты нашего приложения. Всё выглядит идеально, всё выверено до пикселя.
Мы отдаем макеты в разработку, а на выходе получаем ЭТО.
Почему?! Ответ очевиден. Виноваты программисты, которые криво всё запрогали… На самом деле, НЕТ! Еще до начала работы программистов, дизайнер должен передать им спецификацию дизайна (ТЗ), которую дизайнер обычно делает спустя рукава, или что еще хуже, вообще не делает. Поэтому программист и вынужден делать всё на своё усмотрение, раз нету четкой инструкции.
Специфкация дизайна (ТЗ)
Итак, под спецификацией дизайна я понимаю набор файлов, которые дизайнер передает программистам. По сути, их создание и есть процесс интеграции дизайна. У Microsoft и Google это называется blue, red, green lines. У меня это три папки: Metrics, Fonts, Res.
Составлению ТЗ надо уделить должное внимание, т.к. именно это видит конечный пользователь вашего продукта, а не макеты дизайнера.
Android
Рассмотрим интеграцию дизайна на примере 4-х основных в России мобильных платформ. И начну я с самого тяжелого для понимания… Android
Краткая теоретическая часть
Немного теории для понимания дальнейшего процесса. Ни для кого не секрет, что экраны телефонов имеют разные разрешения и разные диагонали, то есть экраны характеризуются разной плотностью. Она измеряется в точках на дюйм. Выделяют 4 основных категории плотности экрана для Android-устройств: LDPI, MDPI, HDPI, XHDPI, XXHDPI (пока не берём в расчёт). Поэтому, чтобы элементы интерфейса имели одинаковый физический размер на экранах разных устройств, компания Google ввела абстрактную единицу измерения — DP.
Не будем вдаваться в подробности откуда появляются эти цифры, а для себя запомним, что один dp равен одному физическому пикселю для экранов с плотностью MDPI. Соответственно, для XHDPI-экранов, 1 dp будет равен 2 px (такая плотность, например, у Google Nexus 4).
Практическая реализация
Теперь приступаем к практической реализации. Дальше будет описан мой процесс работы, который сформировался опытным путем. Надеюсь, он будет вам полезен.
Metrics
Итак, папка Metrics должна содержать файлы с размерами элементов, отступами между ними и от края экрана, цвета однотонных элементов — то, что делается программно (например, разделители).
Все размеры для разработчиков должны быть указаны в DP.
Я делаю макеты для XHDPI-экранов (768×1280, Nexus 4). А как мы помним, для XHDPI 1 dp = 2 px. Но так как Photoshop, естественно, не понимает dp, а работает с пикселями, то сначала я делаю так, чтобы 1 dp ровнялся 1 px. Заходим в Image, жмём Image Size, и выставляем значение 50%. Готово, теперь 1 dp = 1 px.
Можно приступить, так сказать, к «образмериванию» макета. Делать это вручную было очень утомительно, и недавно мне попалось на глаза очень полезное раcширение для Photoshop.
PNG EXPRESS — платное расширение, стоит 29 баксов. Но оно реально того стоит. Для Photoshop, начиная с версии CS5. Оно позволяет делать много полезных вещей, но я использую его, именно, для «образмеривания».
Пример
Шаг 1. Допустим, нам надо указать размер между иконкой X (удалить) и текстом Discard.
Шаг 2. Просто выделяем эти два слоя в Photoshop и в PNG EXPRESS жмем Margins.
Шаг 3. Расширение само нарисует размеры. Если размер получился неверным, наш дизайнерский косяк, редактируем его как обычный текстовый слой Photoshop.
Хоть мы получаем не полностью автоматизированный процесс, всё же это расширение экономит кучу времени.
Fonts
Папка Fonts должна содержать файлы со всем, что касается шрифтов: размер, цвет, начертание, Photoshop-стили и т.д. Я вынес ее отдельно от размеров, чтобы программистам было легче разобраться в таком большом обилии выносок, тем самым сократив количество ошибок.
Все размеры шрифтов должны быть указаны в SP
1 SP = 1 DP, если в настройках размер шрифта операционной системы установлен по умолчанию. Если у пользователя проблема со зрением, он может в настройках системы увеличить шрифт. Если вы задали размер шрифта в SP, то ваше приложение подстроится под пользователя и также увеличит шрифт. Если в других единицах, то шрифт останется неизменным.
Пример
Шаг 1. Если нам надо указать шрифт у кнопки Done, то
Шаг 2. Выделяем этот слой в Photoshop и в PNG EXPRESS жмем Spec Font Features.
Шаг 3. Получили полное описание шрифта.
Опять сэкономили кучу времени.
Resources
Папка Res должна содержать ресурсы графики для вашего приложения. Это 4 подпапки для каждой плотности экрана.
Для этого я использую другое расширение.
Cut & Slice me — бесплатное расширение для Photoshop. Только для CS6. Оно позволяет делать всю эту работу в один клик.
Изначально наш PSD-макет должен быть для XHDPI.
Пример
Шаг 1. Нам надо нарезать иконки для нашего приложения.
Шаг 2. Каждую иконку помещаем в папку, в конец названия которой добавляем @. Таким образом, скрипт определяет, что эту папку надо нарезать.
Шаг 3. Переходим во вкладку Android, жмем Cut all assets.
Шаг 4. Расширение автоматом нарезает наши иконки для 4-х нужных плотностей экрана и помещает их в соответствующие папки.
Оставшиеся две кнопки в Cut & Slice me для нарезки из выбранном подпапки и текущего выбранного слоя.
Иногда возникает проблема «мыльных» пикселей, то есть когда иконка не попадает в пиксельную сетку при ресайзе. Поэтому надо пройтись по папкам, просмотреть качество выполненной скриптом работы. Если необходимо, поправить вручную. Опять сэкономили кучу времени.
9.PNG
И еще про графику. Все кнопки и плашки для Android нарезаются не фиксированного размера, а делаются «резиновыми».
Для этого используется формат 9.png. Делаюся такие файлы из обычных png в NinePatchEditor. По сути, к исходной картинке добавляется с каждой стороны еще один пиксель, залитый черным цветом. Черный пиксель слева отвечает за то, как будет «тянуться» ваша картинка по вертикали, сверху — за горизонталь. Пиксель справа и снизу — за размещение контетна внутри кнопки.
Всё!
Продолжение: Интеграция дизайна мобильных приложений. Часть 2: iOS, Windows Phone
habr.com
Дизайн мобильного приложения. Как добиться оптимального результата?
О дизайне мобильных приложений написано уже много всего. Тем не менее в этой сфере есть огромное количество нюансов. Некоторые известны не всем, другие быстро забываются. В этом посте мы постараемся описать несколько приемов работы с дизайном приложения, которые можно назвать эффективными и проверенными.
В идеале приложение для мобильного устройства должно работать со скоростью мысли. Более того, интерфейс приложения должен быть понятен даже новичку.
1. Правила, которые всегда работают
Стоит выделить пять основных факторов, имеющих важное значение при проектировании взаимодействия с приложением.
Целеориентированность. Вы создаете дизайн для конкретного пользователя. Сейчас в Сети большое количество данных о различных категориях пользователей, причем многие материалы — исследования, обзоры — доступны бесплатно. Изучение этой информации поможет вам создать приложение, которое полностью соответствует потребностям целевой аудитории.
Юзабилити. Ваше приложение должно быть удобным и интуитивно понятным. К примеру, если вы хотите указать ссылку для перехода на сторонний ресурс, то оформляйте ее привычным образом — с помощью подчеркнутого голубого текста. Удобство и практичность — это первый шаг на пути к тому, чтобы ваша программа стала желанной для пользователя.
Возможность (аффо́рданс) и символичность. Аффо́рданс — это функция. Для простоты снова воспользуемся приемом со ссылкой. Так, голубой подчеркнутый текст указывает на то, что клик по нему переведет пользователя по какому-то адресу. Подобные символы нужно использовать таким образом, чтобы пользователь не размышлял о том, что может означать тот или иной элемент интерфейса. Практичность и рациональность — наше все.
Обучаемость. В идеале пользователь должен без труда догадываться, как работать с программой. Здесь приходят на помощь знакомые и привычные схемы оформления приложения. Они должны помочь человеку без проблем привыкнуть к программе.
Фидбек и время ответа. Отклик приложения должен давать пользователю представление о том, выполнена задача или нет. Это может быть обычный звуковой сигнал или нечто более сложное — например, модальное окно. Убедитесь в том, что фидбек приложения соответствует положениям, установленным Nielsen Norman Group.
Как верно заметил Эндрю Майер (Andrew Maier) в своей статье, эти пять правил должны стать основой, определяющей проектирование любого типа взаимодействия.
2. Знать своих пользователей
Первым шагом при создании целеориентированного интерфейса является изучение своей аудитории. Размер дисплея — это не единственное ограничение при разработке мобильного приложения. Пользователи также формируют требования к интерфейсу и необходимо их учитывать.
В этом вопросе есть четкая тактика, состоящая из трех положений:
Personas: помогает понять, что будет побуждать пользователя выполнить то или иное действие внутри приложения. Это формальные, теоретические модели реальных пользователей.
User Scenarios: обеспечивает моделирование различных ситуаций, помогает предсказать действия пользователя. Благодаря этому можно разработать интерфейс, который оптимально подходит для смоделированных пользователей и задач, которые они хотят выполнить.
Experience maps: здесь изучаются все возможные условия отдельного взаимодействия. Схема поможет описать каждый шаг пользователя, который будет выполнен с высокой вероятностью на определенном этапе работы с приложением. Такая схема поможет понять эмоции и обстоятельства, которые приводят к выполнению каждого действия.
Самым простым способом выполнения этих пунктов может быть, например, удаленное тестирование юзабилити при помощи сервиса вроде UserTesting, что помогает изучить поведение пользователей в естественных условиях. Чтобы еще лучше изучить этот вопрос (например, учитывать жесты и даже положение тела), стоит провести работу с реальными пользователями (минимум — пять человек).
Отличные советы по этому вопросу дает Джефф Саурос (Jeff Sauros).
3. Контент и поведение пользователей
Этот пункт позволяет параллельно проводить разработку приложения и изучать возможное поведение пользователей. Идеальным вариантом является набросок, по которому изучается взаимодействие пользователей с контентом. И в этом нет ничего глупого — работу человека с содержимым программы можно проиллюстрировать на бумаге. Это поможет понять, как примерно будут вести себя пользователи внутри приложения.
К примеру, вы создаете банковское приложение. Предполагаемый сценарий: пользователь хочет включить функцию автоматического внесения средств на счет:
Автодепозит выкл.
[Настройки автодепозита]
Выбираем период
[Раз в месяц][Дважды в месяц]
[Через неделю][Каждую неделю]
Депозит
Раз в месяц
[Выбрать календарный день]
Установка суммы
[Ввести сумму]
[Настройки автодепозита]
Прежде чем сделать прототип, рукописная схема поможет изучить наиболее важную часть приложения — контент. Понимание возможной схемы взаимодействия пользователя с контентом поможет дать более точную оценку числа страниц/экранов, необходимых в программе.
Следующий шаг — создание схемы для каждой страницы перехода (в нашем случае это четыре схемы). И здесь уже можно продолжать итерации, постепенно переходя от бумажных схем к цифровому прототипированию (в этом может помочь инструмент вроде UXPin).
Схема поможет быстро изучить возможные переходы на страницы / со страниц приложения. Скетчи позволят «оживить» приложение и понять большее количество деталей и структуры программы. А уже цифровой прототип поможет протестировать поведение реальных пользователей.
4. Улучшение юзабилити с использованием знакомых пользователю схем
Дизайн мобильного приложения стоит сделать «знакомым» для пользователя. К примеру, практически все картографические сервисы используют прием навигации slide-out. Это позволяет пользователю чувствовать себя «как дома». Приложение незнакомо, но схема работы с ним общеизвестна и понятна.
Стоит уточнить, что мы не предлагаем вам копировать дизайн приложений других разработчиков. Речь идет именно об использовании общедоступных элементов интерфейса. Если вы воспользуетесь этим советом, стоит убедиться, что дизайн вашего приложения соответствует ожиданиям пользователя.
Рекомендуем использовать две категории схемы взаимодействия пользователей с интерфейсом приложения:
Жесты: Тап, свайп, двойной тап, щипок, масштабирование — все это давно стало привычным для пользователя. Подробно о жестах можно узнать вот здесь.
Оживление: здесь имеется в виду анимация, которая сделает приложение более живым. Рекомендуем объединить анимацию с жестовым управлением.
Схемы взаимодействия пользователей с интерфейсом приложения предопределяют его структуру и отдельные элементы. К примеру, кнопки навигации в нижней части приложения более привычны для пользователей, чем кнопки, вынесенные в верхнюю часть программы.
Yelp — отличный пример приложения с интуитивно понятным интерфейсом.
5. Учитываем размер пальцев пользователя
Да, пальцы многих пользователей гораздо больше, чем могли бы представить любители утонченного дизайна. Поэтому обязательно нужно адаптировать свою программу к пальцам разного размера.
Им просто нужно оставлять достаточно места. Если ваши кнопки слишком малы или расположены слишком близко друг к другу, некоторые люди просто не смогут попадать по ним. Как следствие, пользователи будут раздражаться и, может быть, прекращать работу с такой программой.
Вот что стоит учитывать, проектируя кнопки и другие сенсорные элементы:
Все мы держим телефон или планшет по-разному. Даже один и тот же человек в различных ситуациях держит устройство разными способами.
Наши пальцы действительно большие. Их ширина составляет около 45–57 пикселей, что больше, чем рекомендует большинство руководств для тестовых устройств. Apple, например, рекомендует цель квадратной формы с размером стороны в 44 пикселя. А этого далеко не всегда достаточно.
6. Не отказывайтесь от градиента и теней
Да, плоский дизайн уже стал новым стандартом, но это вовсе не значит, что тени и градиент — далекое прошлое и от такого варианта оформления нужно отказаться. Вовсе нет, просто подход к дизайну несколько изменился.
Тень обычно очень актуальна при проектировании кнопок, переключателей и подобных элементов.
Тени и градиент отдельных элементов делают интерфейс более понятным пользователю. Эти приемы оформления можно использовать для создания объемных кнопок и полей ввода.
7. Убираем хаос
Правило трех кликов актуально и сейчас, и его стоит использовать при проектировании дизайна приложений. Почему? Да потому, что оно позволяет понять, что именно действительно необходимо для страниц приложения.
В идеале пользователь должен выполнить все задачи быстро и за как можно меньшее количество действий. СЕО Yahoo Марисса Майер даже предлагает использовать правило двух тапов. Если этот принцип не соблюдается, Марисса предлагает работать над приложением дальше, совершенствуя его дизайн.
Старайтесь сделать так, чтобы пользователю приходилось выполнять минимальное количество действий. Чем меньше пользователю придется прилагать усилий при взаимодействии с программой, тем выше вероятность того, что ваше приложение станет успешным.
habr.com