Keep Warning разбивает процесс разработки приложений на четыре этапа: предварительный дизайн, дизайн, разработка и поддержка. Мы можем использовать модульный подход и обрабатывать эти этапы индивидуально, но самая большая ценность, которую мы можем предложить, - это осуществление проекта от начала до конца.
Имея это в виду, мы создали нижеприведенные рекомендации, которые помогут вам понять, что представляет собой каждый этап и что клиенты получают от него.
Этап 1: Предварительное проектирование
Предварительное проектирование — это первая стадия процесса разработки приложения, когда мы разрабатываем проект из первоначального описания - будь то одна строка или тридцать страниц - в работоспособную стратегию. Это означает проработку всего, от того, о чем идет речь и для кого он предназначен, каких технологий он должен использовать и как мы будем измерять успех.
Предварительное проектирование гарантирует вам правильное начало проектирования и разработки вашего приложения и обеспечивает отличный конечный продукт.
Что происходит на этапе предварительного проектирования?
Первая часть процесса предварительного проектирования - это определение основной концепции и цели проекта.
Для этого мы начнем с мастерской. Это одно- или двухдневное совместное занятие, на котором клиенты получают доступ к опыту всей нашей команды, среди специалистов UX и бизнес-аналитиков, а также нашей команды разработчиков, которые используют свой семилетний опыт работы в области мобильных приложений.
Мы советуем клиентам использовать аналогичный междисциплинарный подход на этом этапе и привлечь сотрудников из отдела маркетинга, юриспруденции ... любого отдела, который захочет высказать свое мнение позже в проекте. Если это внутреннее приложение, это также хорошая идея, чтобы взять с собой кого-то, кто действительно будет на месте, использовать приложение.
Это гарантирует, что все заинтересованные стороны имеют право голоса с самого начала, а не после начала процесса.
За этим следует этап исследований и анализа. В рамках этого мы создаем список задач, которые помогают нам понять цели и необходимости реальных людей, которые собираются использовать приложение.
Мы также смотрим на похожие приложения уже на рынке. Это сложнее для внутренних приложений, которых нет в магазинах, чем для приложений, ориентированных на потребителя, - но, глядя на разные отрасли приложений, , которые имеют очень похожие пользовательские цели, всегда можно найти применить.
Каковы результаты Предварительного проектирования?
В конце предпроектной стадии клиентам предоставляется пакет наших рекомендаций, технических соображений для проекта.
В рекомендациях изложено видение проекта и то, как мы нацеливаем его на пользователей, и каковы цели как с точки зрения пользователя, так и с точки зрения бизнеса.
Пакет-аудит содержимого включает все планы на будущее, с изложением того, что будет включено в первоначальный запуск, и планы развития последующих этапов.
Этот пакет содержит все, что нам, и клиенту необходимо знать о предстоящем проекте, чтобы мы могли обеспечить наилучшие конечные результаты.
Как узнать, нужна ли вам предварительное проектирование?
Люди часто думают, что могут сразу перейти к процессу проектирования, но это может привести к плохому конечному результату. Если все идеи исходят из одного источника, который не обязательно провел все исследования или рассмотрел все аспекты, то это может вызвать проблемы в дальнейшем развитии.
В конечном счете, все сводится к одному вопросу: достаточно ли подробны ваши краткие сведения, чтобы кто-то мог создать готовый продукт? Но это может быть трудно узнать самим. Подумайте, можете ли вы ответить на все эти вопросы:
· Что хотят мои пользователи?
· Какова основная цель проекта?
· Знаю ли я, какие технологии лучше всего использовать?
· Что проект пытается исправить, изменить или улучшить?
· Это должно быть приложение само по себе? Может ли это быть частью функциональности внутри чего-то еще?
· Рассматривал ли я всех своих конкурентов и подобные приложения в сопоставимых отраслях?
Если вы уже ответили на некоторые, но не на все эти вопросы, имейте в виду, что этап предварительного проектирования может увеличиваться или уменьшаться в соответствии с потребностями каждого клиента.
Что мне нужно знать перед началом предварительного проектирования?
Чтобы начать процесс, нам просто нужно знать, чего вы надеетесь достичь с помощью вашего мобильного приложения.
В идеале, ваше задание должно содержать, в чем заключается проблема, чем, по вашему мнению, может помочь мобильное приложение, и выработать приблизительное представление о цели - но минимум - просто знать, какую проблему вы хотите решить с помощью мобильного телефона.
Это то, что вы могли бы записать в одном абзаце. Это может быть так просто: «мы теряем кучу денег, используя бумажный процесс для этой вещи, мы хотим оцифровать его».
Мы можем помочь заполнить дыры, но нам нужно знать, где они находятся в первую очередь. Как только у нас возникнет эта проблема, мы можем приступить к ее решению.
Этап 2: Дизайн
После того, как вы завершили стадию предварительного проектирования и получили полную рекомендацию подхода, вы готовы перейти к дизайну.
Что произойдет, если я не прошел предварительную стадию разработки?
Некоторые из наших клиентов действительно начинают процесс разработки приложений на стадии проектирования, но, как правило, мы все равно включаем некоторую предварительную разработку.
Иногда, особенно в крупных компаниях, клиент мог бы провести все пользовательские исследования самостоятельно, но очень важно убедиться, что концепция была тщательно проверена. В противном случае проблемы могут возникнуть дальше. Обычно эти проблемы включают нереально длинные списки функций; и отсутствие исследований других приложений, уже имеющихся на рынке.
Самое главное, вам нужно убедиться, что конечный продукт будет не только тем, что вы хотите как владелец приложения, но и тем, что хочет конечный пользователь. После этого пришло время приступить к разработке вашего приложения.
Что происходит на этапе проектирования?
На этапе проектирования разрабатывается и повторяется дизайн UI (пользовательский интерфейс) и UX (пользовательский опыт) вашего приложения до тех пор, пока у вас не будет окончательного проекта для разработчиков, который затем будет создан.
Он немного более плавный, чем другие этапы, поскольку для ввода одного из последующих этапов может потребоваться возврат к чертежной доске для его реализации. Но в целом мы проходим пять этапов в следующем порядке: каркас, концепции, совместное проектирование, создание прототипов и тестирование пользователей.
Начнем с создания каркаса . Это чисто UX-представление о том, как приложение будет работать, фиксируя поток между экранами. Например, если у вас есть экран входа в систему, он также должен перейти к экранам регистрации и забытого пароля. Каркас покажет, как они соединяются, и все места, куда вы можете перейти с этих экранов.
Каркасы имеют тенденцию быть огромными. У них может быть сотня экранов или более, включая функции, которые не будут реализованы в первый день, чтобы мы знали, как они вписываются в общий поток.
Они действительно полезны, чтобы показать, сколько нажатий требуется, чтобы перейти из одного места в другое в приложении. Если, например, это новостное приложение, и для перехода к последней новостной статье требуется шесть нажатий - значит, что-то нужно изменить.
Как только мы завершили каркас - обычно через несколько циклов обратной связи с клиентом - мы переходим к визуальному дизайну, создавая первые концепции . Обычно мы берем два или три основных экрана приложения и исследуем различные способы визуального подхода к каждому из них.
Количество стилистического разнообразия на данный момент во многом зависит от клиента. Если у них есть четкие рекомендации по бренду, то речь идет не столько о цвете и шрифте, которые, скорее всего, будут исправлены, а о макете. Как только эти экраны отправляются клиенту, мы начинаем совместный процесс проектирования . Мы часто видим, что клиентам нравятся разные части каждой концепции - кнопка от этой, цвета в ней - поэтому мы попытаемся собрать их воедино и усовершенствовать в единый дизайн, а не монстра Франкенштейна различных дизайнов.
Это дает нам конечный визуальный дизайн, который можно объединить с потоком UX для создания рабочего прототипа . По сути, это набор изображений каждого экрана с горячими точками, которые позволяют перемещаться с экрана на экран, как будто вы используете настоящее приложение
Завершающим этапом проектирования является пользовательское тестирование . Прототип будет передан пользователям - если это внутреннее приложение, то, скорее всего, людям внутри компании, которые будут использовать его, когда оно появится, - чтобы получить их отзывы. В частности, мы стремимся, чтобы пользователи могли быстро понять, что делает приложение, и получить доступ к его основным функциям.
Мы используем результаты тестирования, чтобы сделать окончательный, более образованный набор изменений, прежде чем перейти к разработке.
Каковы результаты на стадии проектирования?
К концу стадии проектирования у вас будет полный UX-каркас; дизайн для всех экранов в приложении, возможно, отдельно для версий для iOS и Android
Что происходит дальше?
Этап проектирования заканчивается четким ТЗ, которую можно передать разработчикам, независимо от того, обрабатывается ли это нами или кем-то еще.
Важно, чтобы дизайн, который вы получили в итоге, был не просто привлекательным, а практичным, и который можно разработать. Поскольку наша команда дизайнеров является частью более крупного мобильного агентства, мы работаем с каждым проектом так, как будто собираемся его создать. Это означает, что нужно помнить о бюджете и о том, как его будет разрабатывать
Что я должен учитывать на этапе проектирования?
Вы можете быстро получить представление о том, что еще существует, с точки зрения аналогичных приложений от конкурентов и в других отраслях, с помощью нескольких поисковых запросов в Интернете. Это может помочь определить, чего ожидать от вашего собственного приложения, определить, что может быть возможным, и определить пробел на рынке, который вы пытаетесь заполнить.
Научитесь отделять свое мнение от ваших пользователей. На этапе проектирования клиенты часто получают наибольшую отдачу. В конце концов, даже если у вас нет опыта работы с технологиями, у каждого есть личное мнение о том, как должно выглядеть приложение, исходя из собственного опыта. Это поощряется - в конце концов, это совместный процесс - но также важно отделить ваши собственные чувства от того, что конечные пользователи захотят.
Например, если в приложении для социальных сетей есть функция, которая вам нравится, это не означает, что она подходит для внутреннего приложения управления запасами. Если вам нравится определенный цвет, но исследования показывают, что он не работает для целевой аудитории, тогда будьте готовы сделать шаг назад.
Рассмотрим мобильную версию дизайна вашего бренда. Крупные компании часто имеют твердые руководящие принципы бренда, но они, возможно, не задумывались о том, как они переводят на мобильные устройства. Существуют определенные элементы дизайна, которые могут отлично смотреться в печати или даже в Интернете, но когда вы помещаете их на меньший мобильный экран, они просто не работают.
В качестве простого примера: ваш логотип удобно расположен на верхней панели устройства или на значке приложения? Мы можем помочь разработать мобильную версию логотипа или совместно с командой вашего бренда, если она у вас есть, определить, как ваш бренд выглядит в мобильном пространстве.
Завершив этапы предпроектного проектирования и дизайна, теперь пришло время фактически его построить.
Что мне нужно, чтобы начать разработку?
Этап проектирования должен был предоставить вам каркас, показывающий все экраны приложения и как они соединяются, а также визуальный дизайн для каждого из этих экранов. Существует один последний жизненно важный компонент, который находится прямо на перекрестке между дизайном и разработкой: подробная техническая спецификация.
Что происходит на этапе разработки?
Довольно просто: разработка приложения. В нашем случае это делается так называемыми спринтами. Это является частью методологии Agile и разбивает разработку на периоды около двух недель в каждом, каждый из которых сосредоточен на определенной функциональности.
В конце этого спринта сборка выпускается - обычно для клиента, но, конечно, внутри - для проверки и тестирования. Команда обеспечения качества проверяет, работает ли новая функциональность, и что ее внедрение не сломало ничего, что уже было там.
Лучше всего работать прозрачно, чтобы клиенты могли иметь полную детализацию на каждом этапе процесса и знать, как все продвигается.
Как только все эти спринты разработки завершены - обычно их может быть семь в проекте - у вас есть так называемая версия UAT (User Acceptance Testing), которую клиент может протестировать и подписать.
В этот момент он переходит в состояние RC (Release Candidate), где вносятся все необходимые уточнения, чтобы его можно было разместить в магазинах приложений, на веб-сайте клиента или в любом другом выпуске, похожем на конкретный проект. Ожидайте увидеть несколько итераций этой версии.
Каковы результаты со стадии разработки?
К концу разработки у вас, разумеется, и самое главное, будет сам разработанный продукт. Но мы также даем клиентам полную функциональную спецификацию и полный исходный код проекта.
Мы твердо верим, что это проект клиента, а не наш проект. Хотя, естественно, предпочтительнее продолжать совместную работу, это позволяет вам делать все, что вы хотите, с приложением, а не быть привязанным к одному разработчику.
Сколько времени занимает разработка?
Полный процесс сборки, чтобы добраться до первой версии вашего приложения, обычно длится от трех до шести месяцев.
Более того, мы бы посоветовали разбить его и сделать раннюю версию с некоторой долей полной функциональности, чтобы вы могли начать обучение. И стоит помнить, что, даже если это не так, приложение первого дня не будет включать в себя все функции, запланированные во время проектирования. Мы собираем все идеи на этом этапе, но поскольку сборка обычно ограничена сроками и бюджетом, некоторые из них откладываются для будущих выпусков.
Это полезно, потому что, как только приложение заработает, аналитика может многому научиться. Возможно, люди используют одну часть приложения больше, чем вы ожидали, и то, что было задумано как основная функция, в значительной степени игнорируется.
Такое открытие может проинформировать ваши планы по мере развития приложения после первого дня. Вы можете добавить больше ресурсов в неожиданно популярную функцию. Возможно, стоит отказаться от дальнейшей разработки для недостаточно используемой функции - или работать, чтобы лучше обозначить ее в приложении. Это соображения для следующего этапа, поддержки и обслуживания.
Что я должен учитывать на этапе разработки?
Безопасность важна, но существует на всем спектре.
Нас часто спрашивают, насколько безопасным должно быть приложение. Ответ зависит от специфики вашего проекта. Не существует единого отраслевого уровня безопасности приложений, поэтому подумайте: насколько важны данные?
Если это приложение для рецептов, которое просто хранит список того, что пользователь имеет в своем шкафу, это, вероятно, не представляет большой проблемы. Но если вы обрабатываете персональные данные или это внутреннее приложение, которое обрабатывает коммерчески важные данные, то это должно быть приоритетом. Даже если данные не являются особо конфиденциальными - например, имена и адреса, к которым можно получить доступ другими способами, - знайте, как ваши клиенты могут их просмотреть.
Динамические функции требуют надежного источника данных.
Если вы хотите, чтобы ваше приложение получило, например, список близлежащих ресторанов, в которых есть определенный вид пищи, то вам нужно подумать, откуда они будут получены и как вы получите доступ. к этому.
Даже если это внутренние данные, помните, что устаревшие системы могут стать препятствием. Они, возможно, не были предназначены для обработки количества вызовов, которые может сделать услуга, основанная на потребителе; в более старых компаниях они могут даже предшествовать сети.
В этом случае наше решение обычно заключается в создании промежуточного уровня, оптимизированного для связи с приложением, который расположен между клиентскими серверами и самим приложением. Это будет извлекать данные на регулярной основе, а затем делать их доступными для пользователей в приложении, не требуя капитального ремонта устаревших систем.
Поймите разницу между первым и последним выпусками.
Итерация - большая часть процесса. Поэтому не ожидайте, что каждая версия, которую вы видите, будет полностью функциональной. Лучше увидеть эти ранние версии, чем ждать до конца, потому что это позволяет вам влиять на разработку в процессе ее разработки.
Часть методологии Agile заключается в том, что, если ваши приоритеты изменяются - что, вероятно, изменится - в течение всего срока проекта, вы можете менять функциональность на модульной основе, пока она переключается, как в терминах сложности.
После завершения каждого из этапов, описанных в этом руководстве, у вас должно появиться живое приложение, которое ваша целевая аудитория начала использовать. В этот момент вы перейдете в четвертый и последний этап - Поддержка.
Первое, на что нужно обратить внимание на этапе поддержки, - это любые ошибки или проблемы с прорезыванием зубов. Независимо от того, сколько тестов было проведено на этапе разработки, всегда будет происходить что-то неожиданное: от использования очень старого устройства, предыдущей ОС и т. Д. Эти проблемы необходимо решать по мере их возникновения.
Следующая часть поддержки, которую можно запланировать, - это когда объявляются новые крупные устройства или происходит обновление ОС. Большинство незначительных обновлений не вызывают проблем в приложении, но при наличии более крупных и серьезных изменений они могут вызвать проблемы. Важно убедиться, что при подготовке бюджета разработки приложения вы разрешаете ресурсы для этих случаев.
Этими обновлениями обслуживания относительно легко управлять. Разработчики получают бета-версии обновлений ОС примерно за месяц до их публичного выпуска. Это позволяет нам планировать их с нашими клиентами и давать рекомендации по наилучшему способу обработки изменений или новых функций.
Еще одна область, в которой мы предоставляем поддержку и понимание, особенно для B2B или внутренних приложений, - это посещение мест, чтобы увидеть, как приложение работает в реальной жизни, со своими предполагаемыми пользователями.
Эта форма исследования может дать очень интересные и ценные результаты. Например, у нас был один клиент, который встроил QR-сканер в приложение, чтобы помочь запускать рекламные акции в магазинах. Первоначальный ответ, который мы получили, был о том, что сканер не работает. Мы тщательно проверили это в нашей студии разработки, и все было хорошо. Поэтому мы договорились о посещении магазина, и сразу стало ясно, в чем проблема.
Магазины, где продавались эти продукты, были небольшими газетными киосками, а освещение внутри прилавка часто было довольно слабым. В результате у камеры возникли проблемы с фокусировкой. Получив это представление, мы смогли обновить приложение, чтобы при выборе функции сканирования вспышка камеры автоматически включалась перед началом работы сканера.
Этот - буквально - момент лампочки никогда бы не произошел, если бы мы не видели, чтобы приложение использовалось в контексте.
Поддержка, которую мы оказываем на последнем этапе, становится более консультативной. Основываясь на аналитике приложений, отзывах пользователей и нашем собственном многолетнем опыте, мы можем подготовить отчет с рекомендациями для потенциальных обновлений и улучшений, основанных на текущих моделях использования, которые могут быть включены в дорожную карту вашего продукта.
Дорожная карта продукта - это то, что мы советуем всем нашим клиентам составить при планировании создания приложения, и это то, с чем мы можем помочь, если вы не создали его раньше. Этот документ дает вам представление о том, где вы хотите, чтобы приложение было через год. Однако, хотя дорожная карта является отличным ресурсом, помогающим управлять развитием вашего приложения, его аналитика может и должна влиять и изменять эти планы.
Последнее, что нужно учитывать после того, как одна из версий вашего приложения выйдет в эфир, - это частота обновлений продукта. Своевременное обновление может стать отличным способом вновь привлечь вашу аудиторию; они получают уведомление на свое устройство о том, что доступно новое обновление, и большинство пользователей все еще выполняют обновление вскоре после его объявления. Затем они неизменно снова откроют приложение, что даст вам отличный шанс поговорить с этой потенциально бездействующей аудиторией.
Однако важно учитывать частоту обновления вашего приложения. Вам необходимо найти правильный баланс между введением новых функций и не слишком частой перегрузкой ненужными новыми функциями.
При планировании этапа поддержки проекта разработки приложения клиенты часто хотят знать, какой бюджет выделить. Исходя из нашего опыта, мы обычно находим, что 15-20 процентов ваших затрат на сборку должны быть направлены на ежегодную поддержку и обслуживание. Это гарантирует, что у вас есть бюджет и ресурсы для использования новых возможностей, своевременного устранения непредвиденных ошибок и планирования дальнейшей эволюции приложения.
Выводы
Мы надеемся, что вы нашли полезную схему четырех этапов, которые мы рекомендуем для любого проекта разработки приложений. Как вы увидите, это больше, чем просто иметь идею для продукта или услуги, которую вы хотели бы представить, просто создав приложение. Однако при правильном планировании, процессах и ресурсах нет причин, по которым идея вашего приложения не может превратиться в надежное и успешное решение, которое будет обслуживать вашу аудиторию, внутреннюю или внешнюю, в течение многих лет.