Избежать обеих крайностей помогает следование гибкой методологии разработки (Agile), позволяющей подстраиваться под проект, сохраняя его целостность и имея явные ограничения в виде сроков и сложности кода. Обычно проект разбивается на этапы, каждый из которых является самодостаточным и законченным проектом, в то же время оставаясь частью большего проекта.
В самом начале достаточно подробно, как отдельный проект, описывается только первый этап разработки приложения. После этого начинается разработка. Результат показывается заказчику, а затем обсуждается дальнейшая работа и корректируются как второй этап разработки приложения, так и проект разработки приложения в целом. Таким образом, проект имеет явные и четкие ограничения. Разработчик может довольно точно определить стоимость и срок реализации каждого отдельного этапа, что значительно облегчает его сотрудничество с заказчиком, да и заказчику так спокойнее.
На этапе проектирования разработчику важно понимать и учесть в договоре, что заказчик наверняка захочет что-то усовершенствовать. Нужно предусмотреть возможность улучшений в некоторых местах реализации проекта, потому что для разработчика это дополнительный расход времени, а для заказчика – денег. Даже если разработчик об этом ничего не говорит, имейте в виду, что при вашем желании что-то существенно доделать или переделать срок работы может растянутся, а стоимость – вырасти.
Многие используют user story, тщательно разбирая поведение пользователя, порядок его действий, перемещений и функции, которыми он будет пользоваться. Для этого создаются несколько выдуманных пользователей, каждый из которых хочет решить конкретные проблемы. Разработчики продумывают весь путь пользователя от загрузки приложения до решения своих проблем и пытаются понять, как его можно улучшить с точки зрения простоты для пользователя и реализации целей заказчика. Лучше сразу подключать к работе заказчика или его представителя, отлично знающего целевую аудиторию и результат, которого заказчик ожидает от выпуска приложения. Также необходимо подключать разных специалистов, в том числе программиста и дизайнера.
В результате описания проекта должна появиться навигационная карта, из которой будет понятно, как пользователь будет перемещаться в приложении и, возможно, за его границами, используя другие приложения. В результате пользователь должен добраться куда хочет, но управлять этим процессом и ненавязчиво подталкивать его в нужном направлении должны вы. С этой целью можно одни элементы делать большими и видимыми, другие – менее видимыми, а третьи – вообще прятать.