Есть ли у дизайнера будущее без Xсode

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

Материал – текстовая адаптация доклада Дениса Сушкова, iOS-разработчика MobileUp, с ноябрьского Behance Portfolio Review. Привет студии Chipsa, которая нас позвала спикерами.

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

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

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

• упростить коммуникацию между участниками всех пяти этапов
• наладить флоу задач
• исключить риск выхода из плана

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

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

Стандартные инструменты платформы iOS работают только с однострочными заголовками в навигационной панели. И если дизайнеру захотелось сделать его в две строки (заказчику идея, конечно же, понравилась), разработчик хватается за голову. Потому что время разработки вырастает в разы. Для масштабирования и анимации двух строчек в заголовке придется писать целый модуль.

Подобных нюансов довольно много. Мы выявили основные проблемы взаимодействия дизайнера и разработчика:

1. Творческий размах (он же разный фокус)

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

2. Неэффективная отгрузка макетов

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

3. Различные состояния экрана

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

4. Кастомные анимации

Каждая мобильная платформа имеет огромное количество «украшений». Не все из них достигаются стандартными методами. Если появляются необычные — это стоит учитывать. Внутри своей команды мы придумали, как можно устранить эти проблемы и даже предупредить их появление.

Ситуация

Каждая система предоставляет нативные элементы для управления. Например, в интерфейсе iPhone кнопка «Назад» находится в верхнем левом углу. Но в официальном приложении PlayStation из AppStore кнопка «Назад» переехала вниз, а на ее привычном для пользователя месте расположились чаты.

У Google Календаря похожая ситуация. Но вряд ли это обусловлено именно творческим полетом — здесь, скорее, сработало желание всё унифицировать. Google приводит свои приложения к единому стилю, естественно, с перекосом в сторону платформы Android. Тем не менее, недавно компания объявила, что перепишет все приложения на нативных iOS-элементах, потому что каждому пользователю нужно давать то, что ему удобно.

Решение

Чтобы справиться с такой проблемой, мы налаживаем совместную коммуникацию. Обычно сотрудники варятся внутри своих отделов: дизайнеры обсуждают задачу между собой, разработчики тоже. И все — на своем языке, в своих терминах. Мы же сделали так, чтобы они общались друг с другом и говорили одними и теми же словами. Теперь каждый участник процесса знает, к чему мы идем, что должно быть в финале, сколько на это должно быть потрачено времени.

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

И еще один момент, который облегчает процесс — гайдлайны интерфейсов. У iOS они называются Human Interface Guidelines, у Google также есть свои. В каждой версии Android и iOS они обновляются. Это обширная документация, которую мобильный дизайнер должен знать практически наизусть.

Ситуация

В реальном макете одного из наших приложений огромное количество деталей: график, заголовки, кнопки и контекстные подсказки. Выглядит довольно массивно, нагружено и, на первый взгляд, даже сложно. При плохом сценарии разработчик смотрит свойства каждого элемента, пытается перенести все это в Xcode руками — в итоге экран займет в верстке невероятное количество времени.

Решение

Мы же создаем библиотеку компонентов для каждого проекта, используя open-source решения для быстрого экспорта. Ребята из RedMadRobot придумали утилиту под названием FigmaExport. Теперь разработчик может двумя-тремя командами все, что есть в библиотеке — цвета, шрифты, иллюстрации и иконки — перенести в проект, сохранив не только их свойства, но и имена.

Мы стремимся к консистентному дизайну: не плодим сущностей без необходимости и максимально переиспользуем типовые элементы. И, наконец, закладываем время на передачу проекта другому дизайнеру на случай, если произойдет смена на проекте. Это нужно учитывать и предупреждать как менеджера, так и заказчика.

Ситуация

Самая банальная ситуация — в процессе использования приложения отваливается интернет или упал сервер. Об этом пользователя нужно предупреждать, а в идеале ему вообще это не должно мешать.

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

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

Решение

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

Пример нашего реального макета — Android-приложение с тремя различными состояниями. Одно из них — состояние загрузки, когда ошибки не произошло и, возможно, ее и не будет, но данные грузятся слишком долго. Пользователю в это время нужно что-то показывать. Желательно учитывать это как можно раньше.

Также мы создаем макеты для маленьких экранов — такая вариативность есть и в Android, и в iOS. И рассказываем дизайнерам о базовых принципах работы сервер-клиента, чтобы они могли заранее продумать макеты с вариантами состояния экрана.

Ситуация

На гифке ниже приложение — «РБК Инвестиции», созданное в MobileUp. На главном экране есть шторка «Все материалы» – похожий элемент можно найти в «Яндекс Go» или «Тинькофф».

На первый взгляд кажется, что это довольно стандартный и знакомый разработчикам элемент. На самом деле, для его реализации потребовалось больше времени, чем ожидалось. Потому что «Лента» — это тоже шторка. Одна в другой. Обеспечить их корректное взаимодействие и анимацию во всех возможных состояниях стало настоящим вызовом для команды.

Решение

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

Перечисленных решений нам показалось мало, поэтому мы придумали ноу-хау – краткий курс iOS-разработки для сотрудников MobileUp, которые не имеют к ней отношения, то есть для дизайнеров. Позже к нему подключились тестировщики, HR, сейлзы, проджект-менеджеры и так далее. Курс из восьми занятий называется «Нашкодим».

За месяц обучения ребята узнали об основах UIKit — это основной фреймворк, который используется для создания интерфейсов в iOS. Научились верстать экраны по своим же макетам из Figma, и адаптировать их под разные размеры девайса и состояний экрана. Поработали с сервером и научились хранить пользовательские данные.

Конечно, на курсе не было цели создать невероятное коммерчески успешное приложение. То, что сделали наши «нашкодники» — это довольно простые проекты с капелькой фантазии. Один из результатов — приложение «Какой ты Меладзе?». Каждый день оно предлагает оценить по шкале от 0 до 100, насколько ты сегодня Валерий. Данные отправляются на сервер, и показывается средний балл среди всех пользователей.

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

Порог входа в мобильный дизайн быстро растет. Желающих меньше не становится, но критерии увеличиваются буквально с каждым месяцем. Поэтому у iOS-дизайнера есть будущее без Xcode, но недолгое.

Материалы курса «Нашкодим» выложены в открытом доступе на GitHub. А если есть желание пойти дальше, на образовательной платформе Udemy есть курс iOS Bootcamp, где с нуля учат разработке мобильных приложений. Буквально первые несколько модулей дадут вам знания, которые пригодятся в абсолютно любой сфере, имеющей отношение к мобильной разработке. И, конечно, стоит изучить гайдлайны Apple и Google. Так вы будете подготовленными не только в своей компетенции, но и в соседних. А ваше знание основ разработки станет заметным плюсом в резюме.