Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

Что нужно, чтобы сделать сложный и навороченный инструмент простым и понятным для пользователя? Как создать такой продукт? Мы предлагаем вам историю Роба Райна и его приложения Briefs.

Четыре года назад, когда iPhone был ещё «молодым», я создал простой инструмент для тестирования дизайна приложений. После года безуспешных попыток пробиться через цензоров Apple я сдался и занялся клиентскими проектами, но всё же мы поклялись возродить наш собственный продукт, и в итоге нам это удалось — Briefs благополучно добрался до App Store, однако, прежде нам пришлось решить несколько важнейших дизайнерских проблем, всплывающих в процессе создания приложения.

После столь долгой войны с Apple проект Briefs отошёл на второй план, и я сосредоточился на своей компании, последние 3 года занимающейся созданием приложений для довольно серьёзных клиентов. Вооружившись опытом и командой хороших специалистов, мы вернулись к Briefs.

За это время эволюционировала сама концепция продукта. Я больше не хотел создавать простой инструмент для тестирования, моей целью стало создание инструмента, который вывел бы процесс взаимодействия разработчиков и дизайнеров на качественно новый уровень. В команде разработка именовалась «Project Boo», потому что имя Briefs получило репутацию продукта, который никогда не пропустят в App Store.

Что такое Briefs? 450 гигабайт данных на моём жёстком диске, более 100 тысяч строк кода, бесчисленные часы, потраченные на работу в ущерб сну, эскизы, фотографии, видеоматериалы.

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

Адаптация к существующим рабочим процессам

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

Мы начали изучать интерфейс существующих популярных продуктов. Наша разработка должна была поселиться где-то между профессиональными продуктами Adobe и операционной системой Apple. Мы искали вдохновение в Final Cut Pro, Photoshop, Illustrator, а также в исключительно «программистских» инструментах наподобие Xcode. Задача Briefs — скомпоновать и доставить графические наработки от дизайнера к разработчику, а это значит, что интерфейс нашего приложения должен казаться знакомым и понятным как для первых, так и для вторых.

Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

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

Нажимаем пробел — получаем инструмент-руку.

Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

Нажимаем Option и перетаскиваем объект — получаем его копию.

Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

Выбор устройства для эмуляции, аналогичный Xcode.

Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

Остановка и возобновление работы

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

Home — не вариант, поскольку зачастую пользователю необходимо выйти из текущего прототипа, но при этом остаться в приложении. А ещё есть вопрос: где должен оказываться пользователь, если он запустил приложение повторно? В текущем брифе? В списке? Как сделать так, чтобы пользователь корректно выходил из проекта?

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

Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

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

Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

Устранение отвлекающих элементов

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

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

Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

Взаимодействие

В крупных компаниях есть разные дизайнеры: кто-то отвечает непосредственно за отрисовку, а есть те, в чьи задачи входит создание оптимальной модели взаимодействия пользователя с приложением. Такому дизайнеру нужно средство, позволяющее отображать структуру прототипа. Для этого мы сделали режим, в котором на экране отображается «карта приложения».

Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

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

Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

При создании продукта важно учитывать все основные и вторичные (специфические) потребности целевой аудитории. Мы знали, что в определённых ситуациях необходимо оценить внешний вид проекта с некоторого расстояния, и мы сделали это. Если нужно, то вы сможете посмотреть на свой проект с расстояния 7 километров.

Больше, чем мешок с пикселями

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

Разработчикам: 5 препятствий на пути к хорошему дизайну приложения

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

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