[pullquote align=right]
Андерс Лассен, основатель и директор Fuse, инструмента как для дизайнеров, так и для разработчиков, на TechCrunch
[/pullquote]
Мобильные приложения стали настолько распространенными, что многим кажется естественным предположить, что их создание — простой и прямолинейный процесс. Тем не менее, если заглянуть за кулисы, вы в большинстве случаев обнаружите истории, полные боли, перерасходов, раздутого кода и затрат, а также просроченных дедлайнов.
Многие из этих проблем уникальны для мобильной разработки. Мобильные приложения сегодня часто являются основным интерфейсом общения компаний с их клиентами. Это означает, что количество заинтересованных сторон в мобильном приложении очень велико: сами по себе дизайнеры, команда по продукту, маркетологи, их менеджеры, даже потребители (или ценные заказчики), которые в конце концов финансируют разработку — немногие из них понимают, как приложение работает на уровне кода.
Это не означает, что только разработчики понимают процесс создания приложения — просто всегда существует разрыв между фазой планирования большинства приложений (т.е. концептом и дизайном) и кодом, необходимым для реализации (т.е. разработкой).
Это культурное и технологическое разделение между разработчиками, которые реализуют конечный код, и просто всеми остальными — ключевая точка трения при создании приложений. Другими словами, большинство из нас — часть проблемы. Давайте я объясню.
Фиксация на видении, которое нельзя реализовать в коде
Когда мы говорим о дизайне мобильных приложений, мы обычно имеем в виду то, как выглядит приложение в Photoshop или платформе прототипирования InVision, Pixate и других мощных средствах визуализации, отображающих, как конечное приложение будет выглядеть и ощущаться.
Тем не менее, эти платформы напрямую не связаны с кодом и могут показать только амбициозные версии конечного продукта, которые не всегда можно реализовать (большое количество анимации, очень динамический UI, например, визуально привлекательны, но могут потребовать дополнительных месяцев разработки).
Но привлекательный визуальный дизайн приложения часто становится для компании основной версией обращения к самому приложению (в противоположность веб-дизайну, где конечный HTML/CSS код обычно можно прототипировать в реальном времени).
Я видел, как это происходит раз за разом: вы показываете дизайн клиенту, он фиксируется на нем, и, неделями или месяцами позже испытывает сильное разочарование, когда сравнивает дизайн с тем, как выглядит реальное приложение.
Что приводит нас к следующему пункту…
Парадокс распределения ресурсов в дизайне
Дизайн-прототип определяет внешность и функциональность приложения и является необходимым инструментом коммуникации с клиентом и внутри команды разработки, это эффективная (в смысле цены) часть скорее процесса, чем продукта.
Как только приложение реализовано в коде, прототип теряет свою ценность, и большая часть времени и денег на разработку тратится на что-то, что в конце концов будет отброшено. Сюда включаются ресурсы, потраченные на планирование функций, которые не попадут в конечное приложение.
Разрыв между прототипом и разработкой означает, что дизайнер может легко придумать анимацию, UI концепцию и ричмедиа контент, которые нельзя будет реализовать в коде.
В этих случаях время и силы дизайнера просто пропадают впустую, нужны новые циклы дизайна, когда проблема обнаруживается — часто после того, как «финальный» прототип был подтвержден и передан в разработку.
Опасность дизайна без реальных данных
Во время процесса прототипирования дизайнеры склонны использовать красивые числа, имена и картинки, которые лучше показывают, как конечное приложение будет отвечать на пользовательский ввод. Они часто забывают, каким разным и беспорядочным может быть то, что вводят пользователи — это может стать причиной отталкивающего вида или даже бесполезности приложения (Джош Пакетт из dropbox написал об этом богато иллюстрированный пост на medium).
К несчастью, проблемы данные vs дизайн обнаруживаются только после того, как приложение проходит активное бета-тестирование, если разработчик удачлив — или, что случается чаще, после выхода в магазин приложений, если ему не очень везет. В любом случае почти всегда требуется затратное в смысле денег и времени обновление, процесс, требующий новых раундов работы от дизайнеров и разработчиков.
Стройте приложения, не прототипы
Столкнувшись с этими проблемами, некоторые начинают думать, что решением для дизайнеров может быть обучение программированию. Как и Джесс Вевер, я не думаю, что это приемлемо или желаемо. Что правда требуется, так это лучшее понимание приложения в целом, от основ его программирования до лоска UI и визуальных элементов, в контексте разных платформ, на которых оно будет в конце концов работать.
Сюда же входит понимание того, что разработка приложения — не линейный процесс, в конце которого просто передача дизайна в руки разработчикам. Вместо этого нужен органический процесс совместной работы дизайнеров и разработчиков над созданием привлекательного и волнующего видения — с одновременной проверкой того, что каждый шаг можно на самом деле реализовать.
Сейчас, когда приложения все больше являются единственным продуктом компании, воспитание такого подхода важно, как никогда.