Как сделать дизайн приложения самому
Этапы создания мобильного приложения: проектирование, дизайн и разработка
Практическое руководство от команды студии мобильной разработки Winfox для тех, кто начинает делать свое приложение.
Что именно входит в создание приложения? Вопрос, который нам чаще всего задают клиенты. Они хотят знать, сколько денег и времени от них потребуется, как строится работа, с чего начать и как в результате заработать, а не потерять.
Этот важный вопрос, на который нельзя ответить в двух словах, вдохновил нас на публикацию этого цикла статей. В них не будет туманных советов из серии «как сделать приложение: три простых шага». Зато будет опыт, накопленный нами за пять с лишним лет работы на рынке мобильной разработки, примеры из практики и руководство к действию.
В предыдущих материалах мы рассказывали:
Сейчас поговорим о том, что включают в себя три следующих этапа разработки приложения: проектирование, дизайн и разработка.
Здесь наша работа делится на два направления: UX-дизайн, то есть проектирование, и UI-дизайн, то есть дизайн привычном понимании.
UX-дизайн направлен на повышение уровня удовлетворенности клиентов. На этом этапе мы упаковываем сложные процессы в максимально простое, понятное и полезное приложение, которое работает без глюков и багов.
UI-дизайн определяет то, как будет выглядеть приложение, каким будет его пользовательский интерфейс.
Иногда заказчик говорит: «А давайте не будем тратить время на проектирование и сразу займемся дизайном?». Не делайте так. Допустим, мы исключили проектирование и сделали дизайн. Посмотрели его, и у вас появилась куча идей, как все улучшить. Мы вносим правки и перерисовываем дизайн. Трудозатраты и стоимость проекта вырастают в два раза, а скорость работы вдвое снижается. Дизайнер выгорает, а вы как заказчик недовольны, что проект стал дороже. Все в минусе.
UX-дизайнер продумывает взаимодействие между элементами дизайна, чтобы увидеть, как приложение работает при всех распространенных пользовательских сценариях. Как проходит регистрация и авторизация, как выглядит начальный экран и личный кабинет, как происходит оформление заказа и оплата покупки. Мы проверяем логику приложения и корректируем ее, чтобы сделать пользовательский опыт максимально положительным. В результате получаем прототип — схематичную модель будущего приложения.
Проектирование особенно важно для проектов с большой долей неопределенности. Например, для стартапов.
UX-дизайн — это непрерывный процесс. При выпуске каждого обновления вы должны помнить, как люди используют ваше приложение. Если после обновления пользователям стало не так удобно совершать покупки или им надо сделать больше кликов, чтобы попасть в личный кабинет, значит, вы отклоняетесь от курса и пора поработать над UX-дизайном.
Лучше делать интерактивный прототип, например, в Figma. Перейдя по ссылке, можно пользоваться приложением так, будто оно уже готово и установлено на ваш смартфон. Вы можете перемещаться по разделам, нажимать на кнопки и выполнять различные действия.
Такой прототип полезен как на этапе проектирования, так и для заказчика. В первом случае он помогает выявить несоответствия в сценариях и быстро их исправить. Во втором случае заказчику не придется на словах объяснять, для чего нужен сервис и как он будет работать. Можно просто показать все на интерактивном прототипе, благодаря чему шансы быстро найти инвестора и реализовать проект возрастают.
UI-дизайнер отвечает за внешний вид будущего приложения. Он подбирает шрифты, выбирает цветовое решение, отрисовывает элементы интерфейса: кнопки, иконки, слайдеры, пуш-уведомления.
Если у заказчика есть корпоративный стиль, мы берем гайдлайн и делаем дизайн по нему. Если стиля нет, предлагаем свое видение с учетом трендов, специфики бизнеса и аудитории. В любом случае мы всегда рекомендуем работать по гайдлайнам от Apple и Google.
В зависимости от масштаба проекта дизайн может занять одну неделю или несколько месяцев.
Программирование — один из главных этапов. Написание кода любого приложения делится на фронтенд и бэкенд.
На этапе фронтенда разрабатывают клиентскую часть сервиса, то есть интерфейс пользователя и бизнес-логику приложения.
На этапе бэкенда разрабатывают серверную часть приложения — она отвечает за передачу данных между пользователями или ресурсами.
Что в результате: первый релиз приложения.
Есть множество подходов к разработке интерфейса. Но вам как заказчику не нужно в них углубляться. Достаточно знать два основных.
Нативные приложения написаны для конкретной мобильной платформы: iOS, Android, Windows. Язык программирования, который используется для написания таких сервисов, поддерживается только одной платформой. Например, Swift и Objective-C понимает только iOS, а Java или Kotlin — только Android.
Делайте нативное приложение, если оно должно стать важной частью бизнеса и влиять на продажи.
Нативное приложение может максимально использовать аппаратные и функциональные возможности смартфона или планшета, благодаря чему им очень удобно пользоваться. Но вместе с тем можно использовать оригинальные компоненты и шаблоны.
Плюсы нативных приложений:
Минусы нативных приложений:
При создании таких приложений используются общие наборы средств разработки (SDK). Из-за этого кроссплатформенные сервисы не используют все нативные преимущества каждой платформы. Зато сделать такое приложение дешевле — это оптимальный вариант для проектов с ограниченным бюджетом.
Делайте кроссплатформенное приложение, если нужно быстро проверить гипотезу или протестировать новый продукт.
Плюсы кроссплатформенных приложений:
Минусы кроссплатформенных приложений:
Исходите из своих бизнес-целей и ответьте на следующие вопросы:
Главное отличие между нативным и кроссплатформенным приложением — в скорости и отзывчивости работы. Это как проехаться на Porsche Cayenne и Hyundai Solaris. Оба авто едут по дороге, разгоняются, маневрируют и входят в повороты. Но разница чувствуется сразу.
После того, как вы определились, какое приложение будете делать — нативное или кроссплатформенное — надо разобраться с серверной частью.
Любое приложение отображает данные: показывает, какие товары есть в наличии в интернет-магазине, сколько запасов лежит на складе и кто из контрагентов должен вам денег. Все эти данные хранятся на сервере. Чтобы создать сервер, который эффективно обменивается данными с внешним интерфейсом приложения, надо его тщательно продумать.
На этапе бэкенда участие заказчика минимальное. Вам не надо думать, где хранить данные и нужно ли использовать бессерверную архитектуру — это решают разработчики. Мы в WINFOX всегда выбираем оптимальные для клиента решения. Единственное исключение — это когда надо вписать приложение в уже существующую среду. Тогда вы можете сказать: «Делайте на PHP, а не на Java».
UX-дизайн направлен на повышение уровня удовлетворенности клиентов. На этом этапе мы упаковываем сложные процессы в максимально простое, понятное и полезное приложение, которое работает без глюков и багов.
UI-дизайн определяет то, как будет выглядеть приложение, каким будет его пользовательский интерфейс.На этапе фронтенда разрабатывают клиентскую часть сервиса, то есть интерфейс пользователя и бизнес-логику приложения.
На этапе бэкенда разрабатывают серверную часть приложения — она отвечает за передачу данных между пользователями или ресурсами.
Делайте нативное приложение, если оно должно стать важной частью бизнеса и влиять на продажи.
Делайте кроссплатформенное приложение, если нужно быстро проверить гипотезу или протестировать новый продукт.
В следующий раз мы расскажем, что вам нужно знать про тестирование, стабилизацию и публикацию приложения в сторах.
Этот цикл статей основан на книге, которую мы недавно сделали для своих клиентов. В этой книге мы постарались ответить на основные вопросы, которые у них возникают:
Остались вопросы? Не согласны с нами? Хотите высказать свою точку зрения или поделиться опытом? Пишите в комментариях. Давайте обсуждать!
Стилизация Android-приложений и дизайн-система: как это сделать и подружить одно с другим
В какой-то момент любое крупное приложение разрастается так, что сложно везде поддерживать однотипный дизайн и динамично реагировать на любые изменения и тенденции в дизайне и UX-требованиях.
Поэтому решили внедрить в наше приложение дизайн-систему и добавить поддержку нескольких тем оформления.
Изучив различные способы, выработали свой подход к решению такой задачи. Хотелось сделать так, чтобы дизайн-систему и поддержку стилей можно было повторно использовать в других своих проектах. В соответствии с этой идеей разрабатывались компоненты и темы.
Компоненты дизайн-системы
Дизайн-система и её компоненты предназначены для унификации дизайна и стилевого единства во всем приложении.
Компонентами дизайн-системы в нашем случае будем называть custom view с возможностью адаптации к нескольким стилям приложения. Компоненты могут применяться в любом месте приложения (кнопки, элементы списка, заголовки и т.д.).
Проектирование, отладка и доработка компонентов дизайн-системы
Заказчиками компонентов дизайн-системы являются дизайнеры. С ними на первом этапе согласовываем надобность элемента (оценка переиспользуемости) и его функциональность.
После согласования должно быть понятно, какие опции нужно вынести в атрибуты custom view (цвет текста, текст, иконочку, цвет тинта иконочки и т.д.), а какие скрыть от изменений извне (это позволяет уберечь элемент от неправильного использования разработчиками).
Далее дизайнеры отрисовывают компонент в своих средах и отдают на разработку.
При реализации компонента нужно добавить поддержку тем (светлая или темная тема и т.д.) О том, как компонент поддерживает несколько тем, я расскажу ниже.
Лучшие методики
Способы внедрения темы в приложение
Мне известно два способа поддержки стилей в Android:
Программный способ
Перекрашивать можно как перед отображением экрана (например, в onStart() у Activity ), так и при работе с ним.
Недостатки
Достоинства
Не требует пересоздания Activity (это важно! Нет морганий при смене темы).
Я внедрил этот подход в одном известном всем продукте (см. скриншоты). Работает довольно быстро при простой однотипной вёрстке(в данном случае она была простая).
Стандартный механизм стилей в Android
Стиль — локальная стилизация экрана или view, затрагивающая только отдельный экран или view. Часто такую стилизацию называют «ThemeOverlay», или «легковесная» тема, которая позволяет переопределить атрибуты основной темы).
Тема — глобальная стилизация экранов приложения, затрагивающая подмену стилей, цветов и т.д. у всего, что мы видим на экранах приложения.
Темой можно считать множество стилизаций, которые можно переключать.
Примеры
В теме могут содержаться как стили конкретных view элементов, так и конкретные цвета.
Здесь объявлен стиль для конкретной view:
Стили поддерживают явное и неявное наследование:
Множественного наследования темы не поддерживают. Вероятно, из-за конфликтов одноименных атрибутов.
Стилизация компонентов дизайн системы. Архитектура компонентов. Поддержка нескольких тем
Стандартный конструктор view
Рассмотрим стандартный конструктор view на примере H1Component (задаёт крупный текст в шапке экранов):
defStyleAttr — стиль view по умолчанию.
context — контекст view, при помощи которого она создана.
ВАЖНО: чтобы view успешно переключала тему, необходимо чтобы она была создана при помощи контекста, унаследованного от android.view.ContextThemeWrapper (то есть контекст activity подходит, а applicationContext — не подходит (применится тема, которая подтянется из стиля, указанного в Manifest экрана).
Интеграция стиля в компоненты дизайн системы и его связь с темой
Для поддержки темы компонентами дизайн-системы мы определяем в компонентах defStyleAttr и переключаем его в соответствии с темой, в которой он определен.
Реализация темы в приложении
Компоненты дизайн системы системы будут тянуть этот стиль в таком ключе:
Тут определены стили каждой темы для этого элемента:
Применяем тему через стандартный механизм Android.
При создании Activity указываем нужную тему. Тогда MyBestText подтянет нужный стиль и окрасит свой текст в белый или черный в зависимости от темы (см. выше описание темы MyBestText ).
ВАЖНО: начиная с Android 5.0 допускается отовсюду динамически разрешать android:background=»?attr/primary_background» (селекторы, shape, vector drawables и т.д.) В Android 4.4 есть ограничение на селекторы, при попытке динамически разрешить итоговый цвет из селекторов система упадёт.
При всех достоинствах такой реализации компоненты дизайн-системы не могут в preview Android Studio полноценно работать со стилизованными темами (к элементам не будут применяться стили).
Пока тема официально не использована нашими экранами, а только подключается программно (то есть стили наших activity не подгружают явным образом тему из Manifest ), мы не можем комфортно работать с элементами, поддерживающими темы в preview (их даже не будет в списке).
Тестирование компонентов дизайн-системы
Для тестирования и анализа степени покрытия приложения дизайнеры предложили разработать отладочную панель с настройками стилей компонентов, цветов и т.д.
Программно изменять атрибут темы без отсылок к объявленным стилям, к сожалению, нельзя. По крайней мере, я не нашёл способа.
Если знаете, как подсунуть свой цвет в атрибут темы (не объявленный в ресурсах как style ), то напишите мне. Тогда мы сможем прямо из коробки манипулировать цветами с бэка на уровне стилизации всего приложения!
Делаем рабочее preview компонентов дизайн-системы в Android Studio
Темы экранов приложения должны наследоваться от темы дизайн-системы.
При некорректно установленной теме экрана компоненты дизайн-системы тоже не будут отображаться корректно (не применятся стили и цвета):
При установке темы, унаследованной от темы дизайн-системы, мы получим вот что:
Видно, как разрешились все атрибуты темы и правильно подтянулись стили компонента.
Проверка поведения компонентов в другой теме в Preview без пересборки приложения
Чтобы проверить отображение в другой теме достаточно переключить тему в Preview light/dark.
Переключение тем в приложении
Переключение тем в приложении может быть завязано на системное переключение dark-mode. В таком случае темы должны быть определены в директориях values и values-night.
Процесс разработки дизайна мобильного приложения с нуля
Новичок дизайнер и разработчик рассказывает об опыте в дизайне мобильных приложений.
Продуктовый дизайнер (UX/UI) и исследователь. Преподаватель курса «Проектирование интерфейсов» в Институте программных систем.
Сен 21, 2018 · 5 мин читать
Привет. Я изучаю графический дизайн с 13 лет. Опыт в веб-дизайне я по крупицам собирала из онлайн-курсов, а еще целыми днями играла с Photoshop и Affinity Designer. Вот, собственно, кратко о моих первых шагах в прокачке дизайна.
В проектировании и разработке приложений я уже год. И уже успела поработать над мобильным приложением Universeaty. А два месяца назад начала работать над новым приложением Crypto Price Tracker, которое выложили 28 января в App Store.
В этой статье я поделюсь с вами этапами процесса проектирования, который использую каждый раз при работе над приложениями. Мне кажется, мой подход поможет новичкам, и тем, кто хочет прокачаться в дизайне.
Интересуетесь свежими статьями по дизайну? Вступайте в группу на Facebook.
Не секрет, что дизайн — это не только работа в графических редакторах или инструментах для проектирования, поэтому в этой статье не будет туториалов по софту. На эту тему уже есть сотни качественных обучающих роликов. Дизайн – это про понимание сути вашего продукта, его функциональности, а также про проектирование полезных продуктов для людей.
Вот мой чек-лист по дизайну приложений:
User-Flow
Первым делом нужно выяснить, какие функции нужны в приложении. Как только вы определились, создайте user-flow – блок-схему работы вашего приложения.
Обычно user-flow состоит из трех типов фигур:
User-flow очень полезны, потому что они дают логическое представление о том, как приложение должно работать и решать задачу.
Вот диаграмма user-flow, которую я нарисовала, когда начала работать над дизайном моего приложения.
User-flow для основного интерфейса.
Эскизы экранов (Wireframes)
После того, как вы завершили проектировать user-flow для всех сценариев, вы начинаете работать с эскизами всех экранов. Wireframes — это, по сути, быстрые наброски вашего приложение. Эскиз, схема того, где будут располагаться изображения, ярлыки, кнопки и прочее. Это грубый эскиз того, как ваше приложение должно работать.
Я использую печатные шаблоны из UI Stencils для рисования эскизов. Это экономит время и к тому же, там есть пространство для заметок.
Вот пример прототипа.
Прототип интерфейса мобильного приложения.
После создания Wireframes вы можете использовать приложение под названием Pop, сделать снимок всех своих рисунков и получить кликабельный прототип, соединив все экраны с помощью кнопок.
Паттерны и цветовые палитры
Это моя любимая часть. Это похоже на разглядывание витрины в магазине. Множество паттернов и цветовых палитр на выбор. Я выбираю те, которые мне нравятся, и экспериментирую с ними.
Кстати, лучшие платформы для поиска паттернов — это Mobile Patterns и Pttrns. Чтобы найти хорошие цветовые палитры, попробуйте зайти на Color Hunt.
Прототипы и дизайн
Наконец мы добрались до софта. То, что получится в итоге – это как если бы мы вошли в свое будущее приложение и сделали серию скриншотов, пока шли до цели, экран за экраном. Все должно быть по-настоящему, приложение уже должно быть как живое.
Хорошо что есть софт, который позволяет делать так, как надо. Я использую Affinity Designer. А на iOS мой основной инструмент – Sketch.
Вот так выглядят мои первые дизайны.
Перенесение рисунка в пиксели!
Я больше экспериментировала с различными цветовыми палитрами.
Я поделилась первыми макетами с друзьями, и собрала с них отзывы. Кажется, многим понравилась схема с золотым градиентом и черным.
Подготовьтесь получить отзывы и поэкспериментировать с новыми предложениями! Вы почерпнете невероятно много идей, просто поговорив с ними, намного больше чем просто скролля Dribbble или Behance.
После интервью я переработала дизайн и удалила фоновую графику, потому что такое оказалось сложно запрограммировать, а еще они снижали читабельность. Вот что в итоге вышло:
Золотой градиент с черным на удивление хорошо выглядит!
Я довольна цветовой схемой, значками на панели вкладок и общей компоновкой. Следующим шагом я задизайнила остальные экраны, по тем же гайдлайнам. Это заняло время, но было безумно увлекательно!
Когда все мои экраны были готовы, я сделала прототип в Adobe XD и попросила нескольких друзей поэкспериментировать и оставить отзыв.
После последних штрихов получилось финальная версия дизайна.
Финальная версия дизайна
После того, как все экраны были завершены, я импортнула их в Xcode и начала разработку приложения.
Вот и все! Надеюсь, что эта статья поможет вам начать работу над дизайном приложения или поможет стать лучшим дизайнером. Кстати, если вам приглянулось мое приложение, вы можете скачать его здесь.
Напоследок добавлю мою любимую цитату.
«Дизайн — это не только, то как что-то выглядит и ощущается. Дизайн — это то, как оно работает»
(с) Стив Джобс
Если у вас есть на примете какая-нибудь классная статья по UX и не только — скиньте нам ссылку, и мы будем рады над ней поработать.