Войти в систему
Войти с помощью соц. сетей:
Информация, ведущая к обязательному изменению проекта, поступит к автору этого проекта тогда и только тогда, когда чертежи уже выполнены.
Артур Блох, Законы Мерфи
Создание нового мобильного приложения в каждой компании начинается по-разному. У всех компаний, серьезно относящихся к своим обязательствам перед заказчиком, есть одно общее правило при разработке приложений: вначале оно проектируется. Это обязательный этап создания любого мобильного приложения сложнее калькулятора.
В рамках этого этапа создается проект конкретного приложения, по которому происходит вся работа над ним в компании-разработчике. Проект дает ответы на все вопросы, которые могут возникнуть у разработчика (какую технологию использовать, как взаимодействуют разные части приложения, сколько времени потратить, в каком порядке выполнять работу). К примеру, если приложение будет многоязычным, то необходимо детально разобрать механизм реализации многоязычности именно на стадии проектирования, чтобы можно было заложить весь необходимый функционал.
Техническое задание описывает только то, как должно выглядеть приложение и что оно должно делать, но не объясняет разработчику, как необходимо разрабатывать приложение — это объясняет описание проекта.
У каждой компании собственный подход к проектированию. Некоторые ограничиваются только макетом интерфейса, другие детально описывают все что смогут, третьи ко всему вышеуказанному создают прототип. Поскольку проектирование может занимать довольно много времени и не может выполняться бесплатно, то в каждом отдельном случае все решается индивидуально.
Сделать приложение сегодня не проблема, проблема заключается в том, чтобы сделать все, как хочет заказчик и в оговоренные сроки. Если приложение — это простой калькулятор, то его может сделать один студент или даже школьник. Если приложение требует вовлеченности нескольких специалистов, то правильно организовать работу не так легко.
Как организовать сотрудников так, чтобы они одновременно работали над приложением и после этого не приходилось все переделывать заново? Нужно ясное видение того, что должен делать каждый из них, когда, в каком объеме и как совместить затем работу с работой другого специалиста. Для этого необходимо управление проектами.
Вы ведь не думаете, что компания-разработчик будет заниматься только одним вашим приложением? Они откажутся от всех существующих клиентов, всех доработок и подработок, а также от всех новых клиентов в вашу пользу? Нет, так не бывает. Компания обычно ведет несколько проектов разной сложности. Каждый из сотрудников компании должен иметь возможность с легкостью переключаться между совершенно разными задачами и выполнять их в срок. Для этого компании нанимают отдельного сотрудника, менеджера по проектам, который только тем и занимается, что организовывает совместную работу.
Без проекта разработчики не будут точно знать, что им и как делать. Если вам встретится разработчик, утверждающий, что «им это не нужно» или «это пустая трата денег», сразу с ним прощайтесь. Можно ли создать автомобиль, самолет или даже смартфон без проекта и продумывания всех этапов работы и взаимодействия специалистов? Конечно, нельзя. В этом плане разработка мобильного приложения не исключение.
Обратите внимание на то, что говорит разработчик, чтобы понять его профессиональный уровень. Нельзя путать проектирование с созданием макета интерфейса или прототипированием. Некоторые разработчики полагают, что это одно и то же. На самом деле макет может быть частью проектирования, но не может быть самим проектированием. Проектирование — более широкое понятие, включающее в себя детальное описание будущего мобильного приложения, зарисовки интерфейса и другую информацию, помогающую в работе над приложением.
С точки зрения заказчика, логично все детально описать, упорядочить и продумать в виде проекта и только после этого приступать к работе. Например, как это делают при постройке дома: нужно заранее утрясти все проблемы и обговорить все с заказчиком и только после этого начинать что-то делать. В материальном мире такой подход действительно всегда срабатывает. С разработкой мобильного приложения так не получится. Она скорее напоминает квантовую механику, где один электрон одновременно может быть в двух местах. Я хочу сказать, что при разработке приложений невозможно наперед все предсказать и описать. Это и есть основной камень преткновения между заказчиками и разработчиками.
Создание практически любого приложения начинается с чистого листа. Разработчик может использовать готовые элементы из прошлых работ, но их очень мало и они редко подходят для других типов проектов (если только речь не идет о сотнях похожих приложений, как у нас было с салонами красоты). Весь программный код, дизайн, звуки — все создается заново. Отчасти поэтому сложно не только определить сроки выполнения заказа, но и установить цены за работу. Разработчик, даже несмотря на детальное ТЗ, все еще плохо представляет, какими способами получится все это реализовать и что получится на выходе. Многие из пунктов ТЗ и договора заказчик обязательно будет трактовать так, как ему выгодно или захочется, что в результате приведет к изменениям в приложении.
Использовать чужой код или изображения для упрощения работы можно только с разрешения автора, и хотя во многих случаях его легко получить, лучше этого не делать. Достаточно посмотреть в интернете, сколько сайтов выглядят слишком похоже, используя одинаковые изображения. Экономия копеечная, поэтому лучше дизайн делать полностью уникальным.
«А как же фреймворки, библиотеки и готовые куски кода из прошлых работ?» — спросит опытный заказчик. А так, что это все равно придется приспосабливать под нужды нового проекта. Да, готовый код облегчает разработку, но вы не сможете использовать фреймворк без тщательной подгонки под проект, то есть разработчику все равно придется изрядно потрудиться.
Разработка мобильного приложения не линейный процесс. Часто приходится возвращаться к предыдущим этапам работы, что-то доделывать и переделывать. Иногда потому, что так захотел заказчик, иногда потому, что так лучше, иногда из-за найденных ошибок. Все это неотъемлемая часть процесса разработки любого программного обеспечения. Это значит, что, если вы заставите разработчика предсказывать все нюансы и тонкости будущего приложения на бумаге в виде проекта, это выльется в пустую потерю времени и денег и растянет проектирование на неопределенный срок.
Другая крайность — описание проекта слишком обобщенно. С одной стороны, как уже было сказано, это позволяет разработчику гибко подходить к разработке, а заказчику постоянно вносить предложения по ее улучшению, с другой — это сильно затягивает процесс работы, потому что все постоянно будет переделываться, а затем будет переделываться переделанное. Не будет никаких границ, никакой ясности, что негативно отразится на результате. С точки зрения многих разработчиков, это рай, потому что можно хоть до смерти программировать одно приложение, зарабатывая деньги, а с точки зрения заказчиков, это ад, потому что приложение никогда не появится на свет.
Избежать обеих крайностей помогает следование гибкой методологии разработки (Agile), позволяющей подстраиваться под проект, сохраняя его целостность и имея явные ограничения в виде сроков и сложности кода. Обычно проект разбивается на этапы, каждый из которых является самодостаточным и законченным проектом, в то же время оставаясь частью большего проекта.
В самом начале достаточно подробно, как отдельный проект, описывается только первый этап разработки приложения. После этого начинается разработка. Результат показывается заказчику, а затем обсуждается дальнейшая работа и корректируются как второй этап разработки приложения, так и проект разработки приложения в целом. Таким образом, проект имеет явные и четкие ограничения. Разработчик может довольно точно определить стоимость и срок реализации каждого отдельного этапа, что значительно облегчает его сотрудничество с заказчиком, да и заказчику так спокойнее.
На этапе проектирования разработчику важно понимать и учесть в договоре, что заказчик наверняка захочет что-то усовершенствовать. Нужно предусмотреть возможность улучшений в некоторых местах реализации проекта, потому что для разработчика это дополнительный расход времени, а для заказчика — денег. Даже если разработчик об этом ничего не говорит, имейте в виду, что при вашем желании что-то существенно доделать или переделать срок работы может растянутся, а стоимость — вырасти.
Многие используют user story, тщательно разбирая поведение пользователя, порядок его действий, перемещений и функции, которыми он будет пользоваться. Для этого создаются несколько выдуманных пользователей, каждый из которых хочет решить конкретные проблемы. Разработчики продумывают весь путь пользователя от загрузки приложения до решения своих проблем и пытаются понять, как его можно улучшить с точки зрения простоты для пользователя и реализации целей заказчика. Лучше сразу подключать к работе заказчика или его представителя, отлично знающего целевую аудиторию и результат, которого заказчик ожидает от выпуска приложения. Также необходимо подключать разных специалистов, в том числе программиста и дизайнера.
В результате описания проекта должна появиться навигационная карта, из которой будет понятно, как пользователь будет перемещаться в приложении и, возможно, за его границами, используя другие приложения. В результате пользователь должен добраться куда хочет, но управлять этим процессом и ненавязчиво подталкивать его в нужном направлении должны вы. С этой целью можно одни элементы делать большими и видимыми, другие — менее видимыми, а третьи — вообще прятать.
Придумать удачное название — не пара пустяков: это адский труд.
Нейл Тейлор, креативный директор, экс-неймер
Правильно назвать приложение важнее, чем правильно назвать ребенка. Ребенок в любое время может изменить свое имя, причем не один раз, и это только поможет ему эффективнее достигать поставленных целей. Смена названия приложения — это гарантированная «смерть». Его нужно с самого начала правильно назвать, ведь другой попытки не будет. Отчасти из-за этого создание любого продукта сегодня часто начинается с выбора названия.
До момента установки люди видят только название и краткое описание мобильного приложения. Название они видят в первую очередь, что в значительной мере влияет на их первое впечатление о программе, которое, как известно, крайне трудно изменить. Название приложения можно услышать от знакомого, прочитать в новостях, найти в магазине приложений. Именно по названию люди идентифицируют программы и отличают приложение от остальных.
Так почему практически все заказчики халатно относятся к процессу выбора названия приложения? Думаю, причины две. Первая причина: они уверены, что уже придумали самое лучшее название на свете. Ведь оно им очень нравится — так почему бы не считать его самым лучшим? Вторая причина: им кажется, что название никогда не поздно придумать — подумать денек, и найдется. Уверен, что если бы такие заказчики хоть раз имели дело с профессионалами нейминга, они бы относились к поиску названия более серьезно.
Конечно, вы можете самостоятельно придумать название для своего приложения, при условии, что сможете выделить этому процессу достаточно времени. Для начала купите хорошую книгу по неймингу и внимательно ее почитайте. Книг о нейминге мало, все они написаны специалистами, выбрать легко. Статьи из интернета мало чем помогут — их как раз пишут неспециалисты, а в этом вопросе доверять любителям не стоит.
Лучше всего подобрать название совместно со своей целевой аудиторией. Это одновременно и способ выбрать название, которое гарантированно нравится людям, и способ попиарить приложение на этапе разработки. Объявите о конкурсе с призом, который ценен для будущих пользователей приложения. Установите правила конкурса, сроки и требования к названию. Чем больше людей из целевой аудитории примут участие, тем большее количество вариантов названий вы получите. Останется только выбрать самое подходящее.
Одной из проблем с подбором названий для мобильных приложений является ограниченное количество символов, видимых на экранах пользователей. Так как экраны смартфонов небольшого размера, то длинные названия при показе в магазине приложений попросту обрезаются. Перед поиском названия для своего приложения посмотрите на названия приложений конкурентов и то, как они обрезаются в магазине приложений, обратите внимание на короткие названия, узнайте, как их придумали и что они значат. Ваше название должно быть коротким, но понятным для пользователя.
Естественно, название должно иметь прямое отношение к ценности, которую от него получает пользователь. Например, это может быть основная функция или проблема, которую решает приложение. Названием может служить краткое описание того, что делает приложение или образ, с которым оно ассоциируется. Понятное, но уникальное и выделяющееся в ряду названий других приложений — вот ваша цель.
Желательно, но не обязательно, чтобы название включало одно из популярных ключевых слов, которое пользователи используют при поиске в поисковых системах. Так оно будет лучше отображаться в поисковых системах и магазине приложений.
Не используйте бессмысленный набор букв для названия или же аббревиатуры. Такое себе могут позволить те, у кого есть миллионные инвестиции. Они с легкостью раскручивают узнаваемость своего бренда за счет огромной рекламы. Если вы не можете себе этого позволить, то подбирайте название так, чтобы оно рекламировало приложение, а не звучало для людей как абракадабра.
Хорошо, если название будет с капелькой юмора, но он должен быть понятен целевой аудитории. Смешное название выбрать очень трудно, поэтому неудивительно, что таких названий мало.
Не стоит называть приложение тем же именем, что и ваша компания или давать ему свою фамилию, если вы частный предприниматель. Так делают только те, кто уже очень известен, и раскрученное имя помогает продавать. Если же вы мало известны, то придумайте интересное название, привлекающее внимание больше, чем «Иванов» или «Попов».
Варианты названия сразу же ищите в поисковой системе: может быть, кто-то их уже использует? Также ищите его в магазинах приложений. Если название свободно — можно использовать. Если приложение станет популярным, рано или поздно вы задумаетесь о регистрации торгового знака, тогда придется проверять, не зарегистрировал ли кто-то такое же или очень похожее имя официально. Желательно проверить это как можно быстрее.
Источниками идеи для названия могут стать приложения конкурентов, сайты и книги по тематике приложения, обсуждения целевой аудитории на форумах и блогах.
Записывайте идеи. Сделайте список всех идей, оставьте его на неделю-другую, а потом просмотрите свежим взглядом. Я уверен, вы удивитесь тому, как сразу не увидели, что некоторые названия абсолютно бессмысленны или глупы. Отбросьте их, обдумайте оставшиеся названия еще раз и удалите те, которые посчитаете бесперспективными. В результате у вас останется мало подходящих названий, из которых вы выберете лучшее.
Обязательно проверьте, что означает ваше название на других языках. Может быть, это что-то отвратительное, противоположное по смыслу или может вызывать неприятные ассоциации у части людей? Проверять все названия таким образом нет смысла, поэтому проверяйте только самые лучшие варианты, которые вышли в финал отбора. Как и в случае с доменными именами, название мобильного приложения нужно проверить на уникальность и наличие, ведь если то, которое вам подходит, занято, то второе такое же точно дать нельзя.
Мы сделали иконки на экране такими хорошенькими, что вам захочется их лизнуть.
Стив Джобс, сооснователь Apple
Афоризмы — это интерфейсы, по которым передается оценка и понимание.
Алан Перлис, ученый в области информатики
Непосредственная разработка мобильного приложения обычно начинается с создания интерфейса. Интерфейс пользователя (User Interface) — это все, что вы видите в своем приложении, все элементы управления приложением, а также все способы уведомления о происходящем в приложении. Некоторые могут называть интерфейс дизайном, но это неверно, так как дизайн слишком обширное понятие. А вот интерфейс — это как раз все то, что позволяет вам получать информацию из приложения и передавать ее в приложение. Сюда относятся все «кнопочки» на экране, клавиатура, голосовое управление, управление жестами, вывод информации на экран, вибрирование, звуки и голосовые уведомления.
Интерфейс — то, чем пользуется абсолютно каждый пользователь приложения. Помните, что приложение может иметь невероятный потенциал и огромные возможности, но если пользователь не разберется, как пользоваться интерфейсом, то он не будет к нему обращаться.
Многие заказчики, да и разработчики также, делают интерфейс понятным в первую очередь для самих себя. То есть оценка качества интерфейса строится исключительно на том, насколько он понятен для самого заказчика и разработчика, вообще не беря во внимание пользователей приложения. Многие считают, что, если это понятно им, значит, будет понятно кому угодно. Это совсем не так.
Нужно учитывать пользовательский опыт. Когда сотрудники компании Visualead создавали рисунки для сканирования в качестве кода, они поняли, что в обычной картинке пользователь не распознает код для сканирования, в результате чего родилась идея объединить картинку с QR-кодом. Так появился визуализированный QR-код. По-другому сделать было невозможно, ведь без QR-кода даже сам разработчик не догадается, какая картинка содержит код, а какая нет.
Прежде всего, еще на стадии проектирования, разработчики должны были понять две самые важные вещи:
В каждом приложении все вертится вокруг одной самой главной задачи — той, которую оно должно решать: и внешний вид, и режим управления; второстепенные задачи при этом отодвигаются на второй план. Только так можно сделать популярное приложение, выполняющее свои функции.
Часто приходится видеть разработчиков, не делающих акцент на чем-то одном, а просто сбрасывающих все возможности приложения в одну кучу. С таким подходом они не могут довести до ума ни одну функцию, постоянно доделывая все и сразу. Пользователь, запустивший такое приложение, тратит много времени и сил, чтобы понять, где находится основная функция, ради которой он его установил, что вызывает только разочарование.
Если с основной задачей обычно все понятно еще на стадии разработки технического задания, то целевую аудиторию многие понимают неправильно. В этом вопросе очень легко ошибиться, потому что понять людей сложнее всего. Вы должны быть уверены, что точно знаете, вашего идеального клиента — кто будет пользоваться мобильным приложением и в каких условиях.
Если потенциальные пользователи — это люди старшего возраста, им будет сложно делать точные движения. Обычно они плохо видят, следовательно, все должно быть несколько большего размера и учитывать ложные касания и жесты. Если пользователи молодые, значит, они отлично разбираются в мобайле и им можно немного усложнить интерфейс. Если приложением будут пользоваться в шумном месте, то звука слышно не будет. Если на улице — то все должно отлично выглядеть даже при ярком солнце.
Если не учесть такие детали, то целевая аудитория не сможет пользоваться приложением, поэтому в ИТ появилось понятие «юзабилити» — оценка удобства использования программы. Весь смысл приложения заключается в том, насколько оно удобнее, чем другой способ решения задачи. Например, если будет проще поручить дело помощнику, то вы не будете пользоваться приложением, а привлечете помощника.
Создание интерфейса начинается с разработки внешнего вида управления приложением (визуальный интерфейс), потому что большую часть времени пользователь использует именно его, и с ним всегда связаны наибольшие проблемы. Кроме того, визуальный интерфейс проще сделать в виде прототипа, чтобы протестировать и показать заказчику.
Вначале визуальный интерфейс создается в виде каркаса, без оформления (wireframes). Все, что должно быть в приложении, рисуется в виде прямоугольных областей и подписывается. Таким образом становится понятно, какие элементы и где лучше всего разместить. Это можно делать как в специальных веб-сервисах, специально для этого предназначенных, так и просто на бумаге. Существуют даже специальные трафареты для упрощения рисования элементов интерфейса. Можно использовать готовый макет смартфона и специальные листочки, на которых рисуется интерфейс, а затем вставляется в макет, чтобы лучше понять, как все будет выглядеть.
Создание визуального интерфейса начинают с первого экрана, то есть того, что увидит пользователь сразу после запуска мобильного приложения. Делайте его привлекательным и информативным. С первого взгляда он должен просто нравиться, со второго — быть понятным. В противном случае дальше первого экрана пользователь не пойдет, выйдет из приложения и удалит его. Оценка полезности приложений происходит очень быстро, иногда в течение считаных секунд.
На первом экране разместите все самое важное и полезное для пользователя. Если самое важное будет размещаться на других экранах, после нажатия нескольких кнопок, то количество пользователей, пытающихся найти то, что они ожидают получить от приложения, катастрофически уменьшится. Чем быстрее пользователь получит то, что хочет, тем большему количеству пользователей понравится ваше приложение.
Не стоит при первом запуске приложения предлагать пользователю зарегистрироваться или уходить прочь. Это очень плохая практика. Крупные и известные компании могут себе позволить так поступать, потому что, если пользователь скачивает их приложение, он точно начнет им пользоваться. Они напомнят ему об этом. Можете ли вы себе это позволить?
В Creators большинству заказчиков мы советовали сделать все возможное, чтобы пользователь мог работать с приложением без необходимости регистрироваться или хотя бы имел возможность опробовать его, а затем уже зарегистрироваться — это помогает удержать пользователей. Хотя процесс регистрации выглядит простым, на самом деле он требует от пользователя дополнительных действий. Пользователь как минимум должен заполнить два поля: имя пользователя и пароль. И тут начинаются проблемы, потому что пользователи вообще не хотят ничего делать. Они хотят получить все и сразу, ничего не заполняя, не нажимая, даже не скачивая. Также типичный пользователь очень не любит, когда от него чего-то требуют и указывают, что он должен делать и как. Он считает себя владельцем смартфона, не обязанным выполнять требования какого-то очередного приложения. При первом запуске на первом экране ваше приложение должно быть готово к использованию без необходимости дополнительных манипуляций со стороны пользователя.
Несмотря на то что важность удобства первого экрана сложно переоценить, не думайте, что только он может быть сделан на совесть, а все остальное — «как получится». Визуальный интерфейс должен быть единым для всех экранов приложения, то есть иметь одинаковое оформление и находиться в одинаковых местах экрана. Иначе при переходе на другой экран пользователю придется долго привыкать к новому размещению кнопок или внешнему виду визуального интерфейса, что мало кому понравится.
У многих заказчиков возникает желание просто натыкать больше кнопок на один экран, чтобы пользователь одновременно получил доступ ко всему и сразу. Однако это сделает приложение некрасивым и неприятным. Всегда должен быть баланс между количеством кнопок и эстетической составляющей дизайна. Также не стоит делать красивые приложения во вред удобству использования. Всегда ищите золотую середину, чтобы результат понравился пользователю во всех смыслах.
Большое количество функций всегда усложняет интерфейс приложения. Приходится либо отказываться от части функций, либо скрывать их. Минимализм и большое количество свободного пространства всегда позитивно воспринимаются пользователями в отличие от нагромождения элементов управления и перегруженности визуальной составляющей.
Лучше спрятать менее востребованные функции куда-нибудь подальше, чтобы, с одной стороны, они были, к ним можно было добраться и было понятно, где они расположены, с другой — чтобы они не мешали пользователю получить доступ к самым важным функциям приложения. С этой целью их чаще всего размещают на других экранах приложения или показывают только после определенных манипуляций. Многие даже добавляют отдельную настройку в приложение, которая включает расширенные функции приложения и делает его более сложным, а до этого показывает только необходимый минимум функций.
Если картинка лучше тысячи слов, то прототип лучше десяти тысяч.
Тодд Варфел, основатель Messagefirst
Определившись с размещением элементов в приложении, можно приступить к их «оживлению», сделав прототип мобильного приложения с минимумом функций и практически без оформления. На данном этапе нужно как можно быстрее сделать нечто, отдалено похожее на будущее приложение, чтобы проверить его в работе. Используются любые способы заставить работать прототип, даже в урон производительности, безопасности и правильности работы всех элементов. К примеру, проекты https://www.invisionapp.com/ и http://www.concept.ly
Прототип жизненно необходим при разработке любого приложения по нескольким причинам:
Основная задача прототипа — показать, как будет выглядеть и работать приложение, чтобы можно было подробнее обсудить техническое задание и договор в целом, покритиковать первую задумку и улучшить ее. Иногда после создания первого прототипа и его обсуждения идея меняется настолько, что необходимо создавать второй прототип, чтобы обсудить все изменения. Хотя, конечно, чаще всего небольшие изменения вносятся в существующий прототип.
Вначале прототип видят только сами разработчики. Они все пробуют в работе и обсуждают. Далее показывают заказчику, и если он остается доволен результатом, то показывают целевой аудитории пользователей приложения. Важно организовать не просто просмотр прототипа, а тестирование. Продумайте этот процесс заранее, чтобы качественно проанализировать поведение пользователей, учесть все нюансы и сделать хорошее приложение.
Иногда прототип создается только в виде рабочего интерфейса, но без каких-либо функций. В других случаях добавляются самые важные функции. Все зависит от сложности задачи и договоренностей с заказчиком. Если задача сложная и незнакомая, то обычно необходимо реализовать важные функции, чтобы лучше понять, как дальше их воплотить в полноценном приложении.
Очень редко прототип создается с полностью готовым дизайном, а не в виде каркаса. Такой прототип очень удобен, потому что можно увидеть, как будет выглядеть и работать приложение. Мелкие детали дизайна обычно упускаются, также присутствуют небольшие ошибки в части оформления. Единственный недостаток такого прототипа — излишние затраты времени и денег на его изготовление, ведь после тестирования прототип будет уничтожен, так как создавался не для дальнейшего улучшения, а только чтобы опробовать приложение в работе.
Прототип запускается непосредственно на устройстве, чтобы можно было увидеть его в реальной работе.
Если ваша компания не заинтересована в дизайне, она бессмысленна. Все имеет форму. И если что-то имеет форму, значит, оно имеет смысл. Вы вынуждены создавать дизайн. Но дизайн — это не только форма. Дизайн — это также функциональность, себестоимость, стиль жизни и ее продолжительность.
Кьелл Нордстрем и Йонас Риддерстрале, Стокгольмская Школа Экономики
Разобравшись со структурой интерфейса, можно приступать к разработке дизайна, то есть к внешнему оформлению мобильного приложения. Очень часто именно дизайн становится камнем преткновения между заказчиками и разработчиками. Оценить качество программного кода заказчик обычно не может, а специалистами в дизайне себя считают почти все люди. Каждый думает, что может точно оценить, чего стоит тот или иной внешний вид мобильного приложения.
В понимании заказчика, главная цель дизайна — нравиться ему. Это кажется естественным как для заказчика, так и для пользователя, и даже для разработчика. Но подход к реализации «сделайте мне красиво» у всех свой, ведь все по-разному понимают красоту. Пользователь приложения вообще не задумывается о том, насколько привлекательно выглядит приложение или какой у него должен быть дизайн. Оно ему или нравится, или нет. Разработчик одновременно оценивает красоту и удобство приложения с точки зрения пользователя, пытается не выйти за рамки требований заказчика, а также обдумывает, как можно реализовать задуманное с технической точки зрения, насколько это финансово выгодно и сколько займет времени. Другими словами, разработчик видит и тоннель, и свет в конце тоннеля, и поезд, мчащийся из него, но этого ни заказчик, ни пользователь не понимают. Каждому разработчику приходится довольно серьезно работать с заказчиком по вопросам его возражений и требований к внешнему оформлению приложения. Если у разработчика нет для этого подходящего человека, который сможет доступным и понятным языком объяснить заказчику, как лучше всего сделать дизайн приложения, то заказчик всегда будет чем-то недоволен.
Заказчику важно помнить, зачем он создает приложение и почему не делает этого сам. Ответ очевиден: приложение должно приносить прибыль и лучше, если его будут делать профессионалы с опытом работы. Помня об этом, умный заказчик не будет мешать разработчикам создавать приложение правильно, в том числе — правильно оформить его внешний вид.
Каждый дизайн должен создаваться под конкретную целевую аудиторию и конкретные задачи мобильного приложения. Нельзя делать весь дизайн или отдельные его элементы только с целью сделать его красивым. Дизайн приложения — это неотъемлемая составляющая всего приложения, и если вы сделаете что-то красиво, но в ущерб функциональной составляющей или удобству использования, это негативно отразится на приложении.
Оценивайте внешний вид приложения, учитывая его влияние на приложение в целом. Если, увеличивая эстетическую составляющую дизайна, вы тем самым уменьшаете удобство пользования приложением, то, с точки зрения пользователя, приложение будет более сложным. Сложное приложение отталкивает пользователей, несмотря на всю его красоту.
Понять, как должно выглядеть ваше приложение, вам поможет анализ приложений конкурентов. Изучите все, что сделали они, попытайтесь понять, чем они аргументировали свои решения, к примеру, что заставило их выбрать именно такой цвет, именно такие иконки, именно такое оформление кнопок. Поймите это, а потом сделайте свое приложение лучше.
Анализ приложений конкурентов покажет, что во многих из них оформление некоторых частей абсолютно однотипно. Дело не в том, что конкуренты копируют друг друга. Причина похожести элементов приложения заключается в том, что так делать лучше всего, и разработчики едины в своем мнении. Приложения так же похожи, как автомобили, имеющие четыре колеса, двери, руль — все потому, что это оптимальный вариант как с точки зрения создателя автомобиля, так и потребителя. Не нужно придумывать что-то, чтобы кардинально отличаться от остальных, потому что в таком случае потребитель вас не поймет и не станет пользоваться этими «инновациями».
Если мобильное приложение принадлежит вашей компании, его можно создать в ее фирменном стиле. Однако его придется адаптировать под требования мобильных приложений. Дело в том, что большинство компаний имеют фирменный стиль, созданный под веб-сайт и полиграфию. Используя его без изменений, на выходе вы получите уродливое или красивое, но неудобное приложение. Дизайн для каждой сферы деятельности отличается, потому что невозможно сделать оформление на маленьком экране точь-в-точь как на листе А4.
Если собственного фирменного стиля у вас еще нет, то рекомендую вначале сделать его, а затем уже приступать к дизайну приложения. Часто приходится видеть, что у компаний униформа одного цвета и стиля, сайт другого, приложение третьего и все эти цвета и оформление совершенно разные, по ним никак не догадаешься, что это одна и та же компания. А ведь клиенты, однажды получившие позитивный опыт сотрудничества с вашей компанией, зайдя в магазин приложений и увидев знакомый стиль, с большей охотой скачают ваше приложение, потому что уже сталкивались с вашей продукцией и остались довольны. Я уже не говорю об эстетической стороне вопроса: для нашего мозга удобнее и красивее то, что привычнее.
Дизайн лучше всего начинать с создания иконки. Она так же важна, как и название, потому что показывается в магазине приложений и на самом устройстве. Перед разработкой ознакомьтесь с материалами для дизайнеров с официального сайта Material Design для Android и с Руководством по iOS Human Interface.
Иконка запуска приложения в магазине приложений должна отличаться от иконок приложений-конкурентов — это выделит ее на их фоне и увеличит количество загрузок. Она должна отличаться от стандартных приложений, установленных целевой аудиторией, чтобы привлекать больше внимание пользователя — так он будет чаще запускать приложение. Кроме этого, иконка должна быть создана в соответствии с требованиями разработчика и операционной системы, для которой она создается.
Делайте иконку максимально просто. Желательно, чтобы изображение объясняло главную функцию приложения (к примеру, телефонная трубка говорит о том, что перед нами мессенджер, а ноты — что перед нами плеер). Посмотрите, как сделали конкуренты, они ведь первым делом тоже попытаются использовать для иконки интуитивно понятное изображение, а повторяться нельзя.
Помните о размере: иконка очень маленькая, и в дизайне изначально должно это учитываться. Проблема с иконкой похожа на проблему с названием — нужен маленький размер. У иконки много схожего и с логотипом, но не стоит использовать логотип вашей компании, если она не такая же известная, как Apple. Ваш логотип в виде иконки скорее всего не только не сможет сказать ничего полезного о приложении, но и будет непривлекательно смотреться на экране смартфонов из-за их небольшого размера. Если уж вы решили во что бы то ни стало использовать существующий логотип, то переделайте его специально под мобильное устройство.
Разобравшись с иконкой можно приступить к выбору цветовой палитры приложения. Цветовая палитра — это набор цветов и их оттенков, которые гармонично сочетаются между собой. В интернете есть большое количество уже готовых цветовых палитр, подобранных другими людьми. Каждый цвет по-своему влияет на человека, и порой влияние сочетания цветов очень сложно предсказать.
Лучше делать приложение в цветах вашего фирменного стиля, уже знакомого потребителю. Есть и другой подход — выбор цветовой палитры на основе тех цветов, которые больше всего ассоциируется с вашим видом деятельности или полностью ему противоположны. К примеру, если ваша сфера деятельности — производство мебели, то вашей цветовой гаммой будет коричневый цвет и его оттенки, а полностью ему противоположный — синий цвет. Используйте только один подход к выбору цвета, то есть или только те цвета, которые ассоциируются с вашей деятельностью, или только те, которые противоположны вашей деятельности. Если смешать оба подхода, результат будет непредвиденным.
Ограничьте количество цветов. Все цвета радуги хороши только на небе, в приложении лучше использовать не более трех-четырех цветов. Если цветов будет много, это усложнит восприятие приложения, что негативно скажется на удобстве его использования.
После выбора цвета пора переходить к типографике, то есть выбору шрифтов для приложения и их оформлению. В первую очередь обратите внимание на размер текста: он должен быть комфортным для чтения даже на небольших экранах. Часто пытаются разместить как можно больше информации, ради чего уменьшают размер текста так, что даже человек с хорошим зрением ничего не видит. А теперь представьте, как читать тому, у кого есть проблемы со зрением, при плохом освещении, в транспорте и других не особо комфортных условиях. Мелкий шрифт не добавляет приложению пользователей.
Второй фактор, влияющий на читабельность, — контраст цвета текста и фона. Цвет текста должен сильно отличаться от фона текста. Если будете использовать похожие цвета, текст станет трудночитаемым. При выборе шрифта обращайте внимание на его вид на маленьких и больших экранах. Есть шрифты, отлично выглядящие на больших экранах и плохо — на маленьких.
Дизайн для каждой операционной системы должен быть уникальным и делаться специально под платформу. Это связано с разным подходом к оформлению на разных платформах и разными привычками пользователей. Можете не беспокоиться о том, что у кого-то будет два смартфона с разными платформами — это редкость, но если это случится, то пользователь, привыкший ими пользоваться, не будет испытывать от этого дискомфорт.
Когда разработчик покажет вам дизайн приложения, естественно, что вам нужно видеть его на самом устройстве. Никогда не соглашайтесь на просмотр дизайна в виде картинки — так вы не поймете, на что смотрите. Рекомендую смотреть дизайн на реальном смартфоне, с реальным контентом, чтобы все было предельно понятно. Только реальный контент, который будет использоваться в приложении, даст вам возможность увидеть, насколько хорош или плох дизайн вашего будущего приложения.
Большинство хороших программистов делают свою работу не потому, что ожидают оплаты или признания, а потому, что получают удовольствие от программирования.
Линус Торвальдс, главный архитектор Linus
После создания дизайна у вас будет все необходимое для добавления функций в приложение. Все, что умеет делать приложение, реализуется с помощью программирования, то есть написания кода программы на одном из языков программирования.
При разработке мобильных приложений чаще всего используется только несколько языков программирования. Важно определиться, на каком языке лучше всего писать код, ведь от этого будет зависеть как производительность, так и возможность реализовать поставленные задачи. Если приложение создается на основе языков веб-программирования, то на выходе вы получите веб-приложение. Если будут использованы другие языки, то вы получите нативное приложение. Каждая операционная система имеет рекомендуемые языки для создания нативных приложений: для Андроид — это Java, а для iOS — ObjectiveC и Swift.
Многие разработчики советуют использовать веб-приложения. Они работают на принципах клиент-серверной архитектуры и запускаются через веб-браузер. На самом устройстве запускается небольшое приложение, которое отправляет всю информацию на сервер, а тот занимается обработкой информации. Единственный плюс таких приложений — простота и дешевизна создания каждой платформы. Одним из основных недостатков является невозможность использовать все возможности, предоставляемые операционной системой и аппаратной частью мобильного устройства. Еще один минус — для обмена информацией между клиентом и сервером необходим постоянный доступ или в локальную сеть, или в интернет. Еще один существенный недостаток — сложность реализации безопасного обмена информацией между клиентом и сервером (это требует реализации дополнительных инструментов, и не каждый разработчик это умеет делать).
Лучший выбор, по моему мнению, — создание нативного приложения, которое разрабатывается специально под конкретную операционную систему. У нативных приложений огромное количество преимуществ:
Единственный недостаток нативных приложений — необходимость более высокой квалификации разработчика. Если разработчик начинает выдумывать недостатки нативных приложений, это означает только одно: он не способен их создавать.
Каждое приложение можно написать по-разному, используя для этого разные инструкции и получая при этом одинаковый результат. Опытные программисты пишут меньше кода и знают, что необходимо сделать, чтобы ускорить обработку инструкций. Неопытные пишут «лишь бы работало» и часто оставляют ошибки в коде. У опытных программистов легко читаемый код, что позволяет быстро понять его другому программисту, а также самому разработчику через несколько лет, а неопытные через некоторое время сами не могут разобрать, что написали.
Ошибки программиста именуют «багами». Каждая такая ошибка может привести к абсолютно непредсказуемым последствиям. К примеру, вместо того чтобы записать информацию, баг может привести к потере новой информации, а также удалению той информации, что сохранялась ранее. Самые худшие баги — это баги, связанные с безопасностью приложения, из-за которых его легко взломать, получив несанкционированный доступ к его содержимому и даже содержимому мобильного устройства. Баги не так просто найти, так как они проявляются только при сочетании определенных условий. Долгое время вы можете о них даже не подозревать.
Как говорит Джанел Гарвин, директор Evans Data: «Ошибки — это часть жизни с программным обеспечением. Иметь мало ошибок большое достижение, но реальная победа — это постоянное обновление приложения и исправление багов или добавление новых функций». Согласно исследованию Evans Data, «три четверти приложений содержит до 10 ошибок при выпуске».
Единственное, что сразу может оценить любой заказчик, — оформление исходного кода приложения. Опытные программисты всегда сохраняют определенный стиль на протяжении всего кода. Например, отступы у них одинакового размера, а сам код выглядит аккуратно отформатированным. Также изредка у них встречаются комментарии к коду, написанные на русском или английском языках.
Если тестирование (также известное как контроль качества) рассматривать как нечто, обеспечивающее поддержку программного проекта, оно должно служить цели получения прибыли.
Грэхем Ли, программист
После того как будет создан почти весь необходимый функционал, на свет появляется альфа-версия мобильного приложения (первая версия). Это работающее приложение, имеющее множество багов, а также недоделанные мелочи в дизайне и функционале. Заказчику лучше такое приложение не видеть, чтобы не разочароваться раньше времени.
Где-то на этом этапе разработчики добавляют эффекты, звуки, анимацию и локализацию. Немного остановлюсь на украшательствах. Каждый эффект, добавленный в приложение, делает его более ресурсоемким и может усложнить использование. Никогда не добавляйте что-то только ради красоты и чтобы «выглядело круто». Эффекты добавляются для решения конкретных задач пользователя, никак иначе. К примеру, эффекты анимации. Если добавляется анимация выдвижения, то она должна появляться и убираться в характерную для нее сторону: вправо, если хотим увидеть, что будет далее или влево, если хотим увидеть, что было ранее. Обратная анимация желательна в ту же сторону, откуда что-то появилось на экране.
Анимация необходима: только так пользователь может понять, что в приложении что-то произошло, например, после его действия. В противном случае будет непонятно, откуда взялось новое окошко. Когда оно появится без предупреждения, это будет как если в нашем физическом мире прямо перед вами из ниоткуда возникнет попугай. От такого можно и со стула грохнуться. А вот если вы увидите, как попугай залетел в окно, это не вызовет у вас неприятных эмоций из-за неожиданности его появления и отсутствия взаимосвязи между тем, что вы видели за секунду до его появления. Также попугай должен улететь с эффектом анимации, то есть постепенно удалиться от вас, а не просто исчезнуть. Анимация помогает пользователю понимать, что приложение работает, а не зависло или «заглючило». Кстати, анимировать можно что угодно, главное, чтобы анимация не просто «делала красиво», а добавляла смысл и помогала пользователю. По своей сути анимация имитирует материальный мир с последовательностью происходящего и законами физики.
Бета-версия выпускается вслед за альфа-версией и содержит небольшое количество ошибок. Все критические ошибки были исправлены в альфа-версии, и теперь приложение стабильно работает, но изредка «глючит». Такое приложение уже можно увидеть и опробовать в работе как заказчику, так и потребителям. С появлением бета-версии начинается активное тестирование приложения. Для этого есть специалисты — тестировщики, основная работа которых — выявление и документирование ошибок.
Такие сервисы, как AppsFlyer, App Annie, Tune, AppMetrika, дают возможность тестировать приложения без их загрузки в магазине приложений.
Довольно часто можно увидеть, как кто-то запускает в массы бета-версию приложения, чтобы ускорить выявление ошибок за счет пользователей. Иногда приложение делают доступным только для ограниченного числа знакомых, которым доверяют. Поступив так, вы можете быть уверены, что ваши пользователи не разочаруются в приложении со множеством мелких ошибок, так как основные ошибки исправятся до выхода программы на публику.
Если выпустите приложение с большим количеством ошибок или с несколькими, но критическими, вам гарантированы плохие отзывы о приложении и его проблемный запуск в массы. Многие пользователи настолько сильно разочаровываются, что навсегда перестают пользоваться не только приложением, но и услугами вашей компании. Ошибки есть почти в каждом приложении, даже в том, которое было тщательно протестировано, поэтому ваша задача состоит не в том, чтобы полностью их исключить, а в том, чтобы свести их к минимуму и сделать так, чтобы большинство пользователей на большинстве устройств не сталкивались с ними. Те несколько пользователей, у которых возникнут ошибки, не сделают погоды.
Проблема тестирования заключается в том, что разработчику необходимо опробовать приложение в самых разных условиях при выполнении приложением всех функций. Необходима команда опытных тестировщиков (один человек не справится) и много устройств от разных производителей, с разными экранами и разными версиями операционной системы. Обычным фрилансерам и командам, состоящим из нескольких человек, такое тестирование недоступно. Максимум, что вы можете от них ожидать, это установку приложения на несколько мобильных устройств и беглый осмотр их работы. Поэтому приложения, выпущенные ими, всегда содержат большое количество ошибок, проявляющихся в самых неожиданных ситуациях. Необходимость качественного тестирования — одна из причин, по которой я советую заказывать разработку мобильного приложения в компании, имеющей в штате тестировщиков.
Опробование приложения в работе — единственный способ, доступный заказчику для проверки качества созданного приложения. Хоть это и не полноценное тестирование, но поможет вам убедиться в качестве приложения. Итак, вот на что вы должны обратить внимание:
Вынужден предупредить, что вы можете опробовать приложение в работе, но не можете проверить его на уязвимости, то есть безопасность. Что делать? Доверять обещаниям разработчика, что приложение не имеет ошибок, влияющих на безопасность, не стоит. У вас есть два варианта.
Первый вариант — вы нанимаете специальную компанию, и она проводит тестирование приложения и ищет ошибки в безопасности. Это довольно дорого, сложно найти ответственную компанию, а при частом обновлении приложения вам это придется делать регулярно.
Второй вариант, который использует большинство компаний, — bag-bounty программа, то есть поиск ошибок за счет сторонних специалистов по безопасности, которых в народе называют «хакерами». Пообещайте вознаграждение за поиск ошибок, и хакеры начнут их искать, чтобы в случае нахождения получить награду. Чем более серьезна ошибка, тем больше сумма вознаграждения. Стоит ли это делать? Однозначно — да! Ваше приложение все равно будут пытаться взломать и всячески проверять на уязвимости. Но в случае наличия bag-bounty хакеры не будут выкладывать взломанную программу в паблик и не будут создавать проблем вашим клиентам, потому что иначе не получат от вас денег. Таким образом, через bag-bounty вы сможете экономить затраты на поиск уязвимостей: за мелкие «дыры» в безопасности платить меньше, за большие — больше.
Ошибки в приложении — это то, что можно увидеть и «пощупать», но есть еще и недостаточно проработанные элементы приложения, которые можно и нужно улучшать в будущем. Советую сразу же после выпуска приложения запустить круг постоянного улучшения и доработки приложения. Чем дольше будет существовать ваше приложение, тем больше полезных изменений и новшеств вы захотите внедрить, поэтому не откладывайте этот процесс, а, наоборот, собирайте и записывайте все, что считаете нужным изменить в будущем и начинайте постепенно внедрять улучшения. Маленькими, но постоянными усилиями вы достигнете гораздо большего, чем одиночными силовыми рывками.
И последнее. После устранения ошибок, но перед запуском приложения в массы проводится внедрение мобильного приложения в компанию. Вам нужно ознакомить персонал с работой приложения, при необходимости обучить сотрудников правилам и процедурам, проработать варианты реакции в нестандартных ситуациях и внедрить приложение в существующую ИТ-инфраструктуру. Человеческий фактор уничтожил не одну компанию, поэтому крайне важно позаботиться о том, чтобы никто не мешал приложению продвигать ваш бизнес и приносить прибыль.
Безопасность удобной не бывает.
Андрей Брызгин, Group-IB
Мобильные приложения, которым доверяют финансовые операции или хранение персональных данных, нуждаются в безупречной защите. При этом часто разработчики игнорируют техники безопасного написания кода и пренебрегают тщательным аудитом перед релизом. Отлично понимая это, киберпреступники исследуют обновления популярных корпоративных и e-commerce приложений, ищут уязвимости, развивают функционал вредоносного ПО для их использования.
Да, чтобы противостоять хакерским угрозам, нужно частично пожертвовать удобством пользователя. Появятся пароли, подтверждения, проверки. Но, как говорит Андрей Брызгин, руководитель направления аудита и консалтинга безопасности Group-IB, безопасность удобной не бывает. Это значит, что между функциональными бизнес-требованиями и защищенностью нужно найти адекватный баланс.
Далеко не всегда разработчик, ориентированный в первую очередь на функционал приложения, способен сам разобраться в угрозах и уязвимостях. Поэтому лучший способ проверить защищенность создаваемого продукта — привлечь независимого аудитора. Уж Group-IB точно можно доверять в этом вопросе, ведь они анализируют уязвимости более 10 лет, понимают слабости инфраструктур любого масштаба и к каждой компании находят индивидуальный подход.
Аудит позволяет смоделировать угрозы, которым подвержено мобильное приложение и разработать модель потенциального злоумышленника, нарисовать его портрет. Вы определите, как и с какой целью он может попытаться взломать вашу программу, а также сколько денег и времени потратит взломщик, чтобы добиться своего.
Существуют три базовых модели аудита безопасности:
Black box — самая распространенная модель аудита. Аудитор получает в буквальном смысле черный ящик с неизвестным содержимым и должен найти способ его вскрыть, достать содержимое, а затем еще и закрыть так, чтобы никто ничего не заподозрил. Именно по схеме «скачать приложение из магазина и взломать» происходит типичный взлом, поэтому Black box — рекомендуемый вид аудита для большинства приложений.
White box, с одной стороны, значительно увеличивает глубину теста, а с другой, сулит заказчику дополнительные затраты. Процесс длится дольше, а некоторые из уязвимостей, проявляющихся в рамках такого исследования, слишком сложны для обнаружения сторонним злоумышленником или не эксплуатируются в текущем виде в силу внутреннего характера. Аудитор в рамках теста по данной модели получает доступ ко всем данным, включая интеллектуальную собственность. Приложение и компания для него — как прозрачный и открытый ящик.
Аудит мобильного приложения может проводиться автоматически с использованием специального программного обеспечения или вручную при помощи подготовленных тестовых устройств. Ручная проверка более гибкая и точная, она занимает больше времени, стоит дороже, но позволяет лучше оценить защищенность приложения от злонамеренных воздействий.
Надо понимать, что злоумышленники могут добраться до чувствительной информации не только из-за уязвимостей самого приложения. Так, ОС Android от компании Google дает пользователям большие права по настройке и внесению изменений и поэтому считается менее защищенной, чем, например, iOS. Кроме того, политика обновления Android для каждого производителя своя. Некоторые из ходовых смартфонов несут на борту устаревшую версию этой ОС с давно известными уязвимостями, но владельцы не могут обновиться до официальных безопасных сборок — производитель прекратил поддержку устройства. Это накладывает на разработчиков дополнительные обязанности. Мобильное приложение должно контролировать версию операционной системы и не запускаться под теми версиями платформы, в которых выявлены критические уязвимости. Как вариант, при запуске в недовыверенной среде оно может ограничивать свой функционал.
Защита приложений, которые оперируют деньгами или персональными данными (сведениями о здоровье, контактами, локациями), должна быть усиленной. В противном случае вы рискуете потерять клиентов и репутацию, а также потратить на восстановление доверия много денег и времени.
Для платежных приложений в обязательном порядке рекомендуется обфускация кода — один из приемов противодействия изучению логики приложения. Перед компиляцией исходного кода в исполняемый файл имена методов и классов шифруются или кодируются, в логические конструкции языка добавляются ложные переходы, тупиковые ветви… Ломать такое приложение злоумышленнику будет слишком долго и дорого, он вряд ли за это возьмется.
С экономической целесообразностью не поспоришь: хорошо защищены те приложения, попытки взлома которых не окупаются. Приложений много, злоумышленник не станет тратить свое время понапрасну, а отправится на поиски более легкой добычи.
Обратите внимание, что следует проводить не только аудит безопасности мобильного приложения, но и аудит информационной безопасности компании в целом. Если приложение достаточно хорошо защищено, то злоумышленники могут достичь цели, подкупив сотрудника или проникнув в слабо защищенную локальную сеть. Нельзя проверить только одну составляющую системы информационной безопасности и считать, что дело выполнено, — вопрос безопасности нужно решать комплексно.
Войти с помощью соц. сетей: