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

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

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

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

Дизайн — это не то, как продукт выглядит и воспринимается. Дизайн — это то, как он работает. Steve Jobs

Я предлагаю вместе пройтись по некоторым аспектам приложений и подумать как влияет дизайн на тот или иной аспект.

Функциональность

Итак, почему же мы используем программные продукты в целом и мобильные приложения в частности? Ответ прост — потому что нам нужны какие-либо функции того или иного приложения.
Какзалось бы ну как дизайн может определять функциональность? Да никак! Все функции приложения должны быть описаны в требованиях, ТЗ или спецификации.

Но давайте не будем спешить и посмотрим на это с другой стороны. Предположим в приложении есть некий прекрасный функционал (для примера пусть это будет отправка отзыва о полученной услуге в каком-то приложении-агрегаторе), но вы не можете найти тот раздел приложения где это можно сделать. Но ведь те возможности приложения, которые пользователь в приложении так и не нашел — это, по сути, возможности, которых нет в этом приложении для этого пользователя. А что если таких пользователей не один а 5 человек или 10%?

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

Архитектура

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

При чем тут дизайн? Так ведь эти вещи связаны напрямую. Что будет в основе самого приложения: вкладки внизу или боковая панель с разделами? Какие данные нам будет передавать серверная часть? А в каком виде она будет передавать те или иные данные?

Я уверен, что человеку ответственному за проектирование архитектуры будет полезно знать что мы будем показывать пользователю в каких разделах. И конечно ему лучше бы сразу увидеть весь дизайн и может даже оценить кликабельный макет иначе какая-нибудь мелочь может спровоцировать взрыв эмоций и необходимость больших правок в уже почти готовой архитектуре.
А как все это в дальнейшем масштабировать?

И многое другое...

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

По этим причинам я считаю что дизайн — это половина приложения.

Как с этим быть?

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

Что должно быть первым шагом в создании дизайна?

Что должен сделать дизайнер когда он начинает работу над новым проектом? На мой взгляд это не вайрфреймы. В первую очередь дизайнер должен быть пользователем той платформы/устройства под которую ему поручили нарисовать макет. К примеру если это приложение для iPhone, то желательно, чтобы дизайнер использовал это устройство в повседневной жизни.

Отлично, дизайнер пользователь этой платформы. Что дальше?

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

Теперь приступаем к созданию вайрфреймов

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

У нас есть одобренные вайрфреймы

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

Разработчики и дизайнеры вместе должны думать о каждом разделе приложения. Допустим дизайнер подготовил наброски для какого-то списка. Как он будет выглядеть если для отображения нет данных? Или наборот слишком много данных? Как это будет выглядеть на экране больше/меньше?

Дизайн готов

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

Дизайн утвержден

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

Вместо заключения

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