Эволюция

На работу в A&P Media я попал всего с двумя полноценными приложениями в портфолио и большим желанием работать, тогда компания полноценно дизайном еще не занималась, поэтому все ошибки мне пришлось пережить на своем опыте, что ожидаемо дало хорошие результаты.

Картинки

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

Следует отметить, что дизайн скевоморфных приложений iOS с большим количеством растровой графики и эффектов был очень ресурсоемким для открытия и редактирования, а файл Photoshop мог весить несколько сотен мегабайт.

Как оказалось в дальнейшем, этот подход имеет гораздо больше недостатков, чем достоинств:

1. Из-за грубого и неполного прототипирования приходилось очень часто додумывать структуру уже в дизайне. Это не экономило время, а только увеличивало его трату;
2. Из-за слишком детализированного дизайн-макета крайне сложно было вносить оперативные правки в структуру и как следствие создавать разные версии и итерации;
3. Об анимациях и сколько-нибудь сложном взаимодействии практически не было речи. Вся коммуникация с разработчиками была построена на уровне статичных картинок и письменных объяснений «как это должно работать»;
4. Указание размеров и отступов на макетах экранов уже тогда казалось занятием довольно трудоемким и малополезным, однако никакого более эффективного способа обеспечить хотя бы относительную точность при сборке интерфейса я на тот момент еще не видел.

Прототипы

Поработав некоторое время в таком режиме я начал постепенно перекладывать детализацию элементов на проектирование, тем более что с выходом Sketch.app оно стало очень наглядным, а с выходом iOS7 сам процесс «раскрашивания» прототипов серьезно упростился.

Параллельно я начал процесс выбора инструмента для проектирования анимаций. Тут хочу отметить Edge Animate, который до появления Origami и Framer (которыми я так и не успел начать пользоваться) неплохо помогал объяснить разработчикам, что конкретно и как я хочу. Приятной особенностью был с одной стороны относительно полноценный таймлайн, а с другой – интерактивность и возможность создавать довольно сложные взаимодействия с помощью кода уровня JQuery, чем не мог похвастаться After Effects. Были и свои недостатки, конечно, но выбор тогда был небольшой.

Таким образом, с началом работы над оптимизацией процессов, произошли следующие изменения

1. Работать с простыми формами на большом холсте стало очень легко. Как следствие, прототипы легко делились на версии и итерации;
2. Стили упростились за счет влияния трендов, поэтому с подробным прототипом необходимость в детальном дизайне отпала сама собой. Делались только основные экраны, остальные просто раскрашивались разработчиком на подобие под контролем одного из дизайнеров;
3. Первый шаг к проектированию анимаций был сделан. Разработчику отдавалась работающая интерактивная анимация и ее подробное описание;
4. С разметкой все еще приходилось жить. Причем, со временем как дизайнеры, так и разработчики, начали округлять какие-то значения или ставить на глаз, что деструктивно сказывалось как на качестве продукта, так и на необходимости самого процесса.

Обмен опытом

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

Не бойтесь потратить 20 минут объясняя, как измерить расстояние с кнопкой Alt и нарезать ассет с помощью слайса. Разработчики стали обращаться по мелким вопросам гораздо реже и работа сильно ускорилась. Это очень помогло в дальнейшем. Некоторые разработчики даже захотели нарезать ассеты сами, чтобы не ждать «окна» у дизайнера и не тратить время на объяснения, как надо нарезать.

В свою очередь я параллельно начал интересоваться разработкой интерфейсов под iOS и делал это сразу в наших работающих проектах. Ставил себе микрозадачи типа правки расстояний, открывал xCode и искал решение в сети. Если возникали вопросы, обращался к разработчикам и они объясняли мне какие-то вещи. Это очень быстро помогло разобраться с основами работы с интерфейсами в xCode.

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

На тот момент ситуация была следующей:

1. Проектирование становилось менее подробным за счет того что некоторые экраны делались сразу в коде;
2. Тенденция к уменьшению количества предварительно раскрашенных экранов сохраняется;
3. Анимации стали описываться грубо и минимальными средствами. После такой же грубой имплементации разработчиком я правил в коде тайминги и изинги попутно пытаясь что-то дорабатывать;
4. Разметка ушла сама собой в свете проведенных изменений. Теперь каждый разработчик может сам все измерить и нарезать так как нужно. Это сэкономило колоссальное количество времени и сил для всей компании.

Про ассеты

Почти сразу же на этапе погружения в программирование мое внимание привлек PaintCode. Это инструмент для генерации изображений кодом. С помощью относительно развитой системы переменных и простых выражений он позволяет без какого-либо знания кода (базовая математика, правда, все-таки понадобится) делать ассеты в меру интерактивными и все это легко интегрировать в конечный продукт.

Самым простым примером тут послужит обычный прогресс-бар. Можно создать fraction-переменную (от 0 до 1) progress и привязать ее к числовой переменной ширине полоски stripeWidth. Потом выражением progress * stripeWidth мы обозначим зависимость одной переменной от другой и выставив первую параметром метода сможем экспортировать его, а разработчик легко встроит этот прогресс-бар в готовый проект просто привязав прогресс загрузки к отданному нами параметру.

Этим возможности программы не ограничиваются. Возможно, когда-нибудь я опишу ее возможности более подробно. В рамках же этой статьи могу сказать, что PaintCode довольно сильно изменил мой подход к работе с графикой. Например, в одном из больших наших проектов я нарисовал в дизайне только стилеобразующие экраны, а остальное сделал путем собирания отдельных ассетов уже в PaintCode, а конечный интерфейс вспомогательных экранов собрал уже в xCode.

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

На этом этапе я пришел к следующим выводам:

1. Основная работа по созданию интерфейса происходит в прототипе. Он же является отправной точкой в разработке, так что к его созданию я подходил максимально детально и комплексно. Отдельно хранилось большинство версии, потому что к ним периодически возвращались;
2. Дизайн был максимально упрощен до уровня утверждения стилей на нескольких основных экранах . С остальным работали уже в коде или во время разработки;
3. Базовые анимации дизайнер делает в сразу коде, более сложные вместе с разработчиком привлекая последнего в большинстве случаев для консультации.

На будущее

Сейчас я работаю в направлении оптимизации и каталогизации элементов и стилей в наших iOS-интерфейсах (в Андройде с этим все довольно неплохо), в первую очередь продолжаю идею СтайлКитов из PaintCode, то есть создаю классы с элементами и описываю необходимые методы, которые потенциально облегчат работу команды. Например, в классе со стилями лейблов я сделал метод, добавляющий межбуквенное расстояние, и теперь это можно делать быстро одной строчкой для любого из лейблов.

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

Все это поможет в дальнейшем прийти вот к таким результатам:

1. Проектировать интерфейсы сразу в коде, отдавая клиенту на утверждение живой прототип работающего приложения, в котором ничего не забыто и не упущено;
2. Оформлять приложения с минимумом усилий используя наработки по структуризации стилей и утверждать с клиентом, опять же, работающий прототип;
3. Проектировать анимации в коде используя реальные данные для максимально качественного и в перспективе быстрого результата.

Послесловие

В этой статье описана хронология проделанного мной пути и сделанные выводы не претендуют на абсолютную объективность. Я уверен, что с приобретением нового опыта процессы будут еще не раз оптимизированы.