Мобильное приложение как инструмент бизнеса - Вячеслав Семенчук

Большое количество функций всегда усложняет интерфейс приложения. Приходится либо отказываться от части функций, либо скрывать их. Минимализм и большое количество свободного пространства всегда позитивно воспринимаются пользователями в отличие от нагромождения элементов управления и перегруженности визуальной составляющей.

Лучше спрятать менее востребованные функции куда-нибудь подальше, чтобы, с одной стороны, они были, к ним можно было добраться и было понятно, где они расположены, с другой – чтобы они не мешали пользователю получить доступ к самым важным функциям приложения. С этой целью их чаще всего размещают на других экранах приложения или показывают только после определенных манипуляций. Многие даже добавляют отдельную настройку в приложение, которая включает расширенные функции приложения и делает его более сложным, а до этого показывает только необходимый минимум функций.

Определившись с размещением элементов в приложении, можно приступить к их «оживлению», сделав прототип мобильного приложения с минимумом функций и практически без оформления. На данном этапе нужно как можно быстрее сделать нечто, отдалено похожее на будущее приложение, чтобы проверить его в работе. Используются любые способы заставить работать прототип, даже в урон производительности, безопасности и правильности работы всех элементов. К примеру, проекты https://www.invisionapp.com/ и http://www.concept.ly

Прототип жизненно необходим при разработке любого приложения по нескольким причинам:

• позволяет оценить существующие идеи, а также найти новые;

• заказчик очень быстро может увидеть и опробовать свое приложение в работе;

• разработчик и заказчик лучше понимают, что необходимо сделать;

• в разы уменьшается количество доработок или переделок;

• позволяет точнее оценить количество времени на разработку приложения и стоимость работы.

Основная задача прототипа – показать, как будет выглядеть и работать приложение, чтобы можно было подробнее обсудить техническое задание и договор в целом, покритиковать первую задумку и улучшить ее. Иногда после создания первого прототипа и его обсуждения идея меняется настолько, что необходимо создавать второй прототип, чтобы обсудить все изменения. Хотя, конечно, чаще всего небольшие изменения вносятся в существующий прототип.

Вначале прототип видят только сами разработчики. Они все пробуют в работе и обсуждают. Далее показывают заказчику, и если он остается доволен результатом, то показывают целевой аудитории пользователей приложения. Важно организовать не просто просмотр прототипа, а тестирование. Продумайте этот процесс заранее, чтобы качественно проанализировать поведение пользователей, учесть все нюансы и сделать хорошее приложение.

Иногда прототип создается только в виде рабочего интерфейса, но без каких-либо функций. В других случаях добавляются самые важные функции. Все зависит от сложности задачи и договоренностей с заказчиком. Если задача сложная и незнакомая, то обычно необходимо реализовать важные функции, чтобы лучше понять, как дальше их воплотить в полноценном приложении.

Очень редко прототип создается с полностью готовым дизайном, а не в виде каркаса. Такой прототип очень удобен, потому что можно увидеть, как будет выглядеть и работать приложение. Мелкие детали дизайна обычно упускаются, также присутствуют небольшие ошибки в части оформления. Единственный недостаток такого прототипа – излишние затраты времени и денег на его изготовление, ведь после тестирования прототип будет уничтожен, так как создавался не для дальнейшего улучшения, а только чтобы опробовать приложение в работе.

Прототип запускается непосредственно на устройстве, чтобы можно было увидеть его в реальной работе.

Разобравшись со структурой интерфейса, можно приступать к разработке дизайна, то есть к внешнему оформлению мобильного приложения. Очень часто именно дизайн становится камнем преткновения между заказчиками и разработчиками. Оценить качество программного кода заказчик обычно не может, а специалистами в дизайне себя считают почти все люди. Каждый думает, что может точно оценить, чего стоит тот или иной внешний вид мобильного приложения.

В понимании заказчика, главная цель дизайна – нравиться ему. Это кажется естественным как для заказчика, так и для пользователя, и даже для разработчика. Но подход к реализации «сделайте мне красиво» у всех свой, ведь все по-разному понимают красоту. Пользователь приложения вообще не задумывается о том, насколько привлекательно выглядит приложение или какой у него должен быть дизайн. Оно ему или нравится, или нет. Разработчик одновременно оценивает красоту и удобство приложения с точки зрения пользователя, пытается не выйти за рамки требований заказчика, а также обдумывает, как можно реализовать задуманное с технической точки зрения, насколько это финансово выгодно и сколько займет времени. Другими словами, разработчик видит и тоннель, и свет в конце тоннеля, и поезд, мчащийся из него, но этого ни заказчик, ни пользователь не понимают. Каждому разработчику приходится довольно серьезно работать с заказчиком по вопросам его возражений и требований к внешнему оформлению приложения. Если у разработчика нет для этого подходящего человека, который сможет доступным и понятным языком объяснить заказчику, как лучше всего сделать дизайн приложения, то заказчик всегда будет чем-то недоволен.

Заказчику важно помнить, зачем он создает приложение и почему не делает этого сам. Ответ очевиден: приложение должно приносить прибыль и лучше, если его будут делать профессионалы с опытом работы. Помня об этом, умный заказчик не будет мешать разработчикам создавать приложение правильно, в том числе – правильно оформить его внешний вид.

Каждый дизайн должен создаваться под конкретную целевую аудиторию и конкретные задачи мобильного приложения. Нельзя делать весь дизайн или отдельные его элементы только с целью сделать его красивым. Дизайн приложения – это неотъемлемая составляющая всего приложения, и если вы сделаете что-то красиво, но в ущерб функциональной составляющей или удобству использования, это негативно отразится на приложении.

Оценивайте внешний вид приложения, учитывая его влияние на приложение в целом. Если, увеличивая эстетическую составляющую дизайна, вы тем самым уменьшаете удобство пользования приложением, то, с точки зрения пользователя, приложение будет более сложным. Сложное приложение отталкивает пользователей, несмотря на всю его красоту.