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

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

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

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

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

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


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

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

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

Архитектура


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

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

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

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


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

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

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


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

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


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

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


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

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


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

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


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

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

Дизайн готов


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

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


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

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


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

Комментарии (3)


  1. dopusteam
    21.07.2017 06:44
    +1

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


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

    Какие данные нам будет передавать серверная часть? А в каком виде она будет передавать те или иные данные?


    Это тоже вряд ли можно отнести к архитектуре, это скорее дизайн (тут я имею в виду не дизайн интерфейса, а некий переходный этап между архитектурой и разработкой, который тоже называется дизайн).

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

    Всё это, конечно, сугубо моё мнение.


    1. AKhatmullin
      21.07.2017 06:56

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

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

      Это тоже вряд ли можно отнести к архитектуре, это скорее дизайн (тут я имею в виду не дизайн интерфейса, а некий переходный этап между архитектурой и разработкой, который тоже называется дизайн).

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

      В идеале, дизайн никак не должен зависеть от архитектуры.

      Согласен, но как часто процесс разработки проходит по идеальному пути?


      1. dopusteam
        21.07.2017 10:24

        Согласен, но как часто процесс разработки проходит по идеальному пути?


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

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


        Понятие не то, что бы широкое, скорее нет чёткого однозначного определения, немного путается с архитектурой.

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


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

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