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

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

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

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

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

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

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


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

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

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

    Архитектура


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

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

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

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


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

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

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


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

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


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

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


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

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


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

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


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

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

    Дизайн готов


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

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


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

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


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

    Similar posts

    Comments 3

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


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

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


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

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

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

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

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

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

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

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


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

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


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

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


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

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

      Only users with full accounts can post comments. Log in, please.