Какой цвет лучше – бирюзовый или оливковый, а кнопки – глянцевые или плоские, а шрифт – антиква или гротеск, а вёрстка – фиксированная, резиновая, или адаптивная… и еще 100500 подобных вопросов. Добро пожаловать в голову дизайнера. Попробуем разобраться, что здесь лишнее, а чего не хватает.
Итак, речь пойдет о дизайнерах в маленьких компаниях. Но не о тех, кто рисует одноразовые художественные промо-сайты (где часто работает подход «чем оригинальнее, тем лучше»), а о тех, кто создает функциональные, полезные приложения и веб-интерфейсы, рассчитанные на долгосрочное использование. Вроде бы, какая разница, что рисовать – везде кнопки, странички, картинки, текст… А вот и нет. Это совершенно разные задачи и решать их должны люди с совершенно разными навыками и талантами. Но, обо всем по порядку.
Что не так
Заглянем в обычную среднестатистическую компанию, в которой начинается разработка продукта. В голове у руководителя есть видение будущей системы, он понимает, что хочет от нее получить. Какие-то схемы и куски интерфейса нарисованы на бумаге, функционал частично описан в виде текста и диаграмм, бывает, что даже есть ТЗ. Приглашается дизайнер, чтобы нарисовать красивый интерфейс. Загвоздка в том, что ставя задачу дизайнеру, директор представляет себе только основные сценарии работы продукта, причем идеальной ситуации. Отдельно выделенных архитекторов, проектировщиков и юзабилити специалистов, как правило, нет (мы говорим о маленьких компаниях). Поэтому, часто задача выглядит неполно, противоречиво и непродуманно. Заполнять пустые места и устранять противоречия в постановке приходится самому дизайнеру. И от того, насколько грамотно он это сделает, зависит успех проекта.
По моему опыту, если дизайнер просто отрисовывает то, что ему говорят, то в большинстве случаев получается старательно нарисованная бесполезная картинка. На этапе внедрения половина красивого макета разъезжается, т.к. он натягивается на реальные данные, обнаруживаются нестыковки в навигации и др. Результат не нравится ни самому дизайнеру, ни директору (или заказчику). После этого либо все остается как есть, либо начинаются утомительные переделки, ведущие к костылям и подпоркам. Кто виноват – дизайнер?
От большего к меньшему
Чтобы избежать подобной ситуации, в начале работы над проектом дизайнеру нужно выяснять, не что нарисовать на странице, какого цвета сделать кнопочки и какие взять шрифты, а какие нужно решить задачи. Чего мы хотим добиться от пользователя. Как мы можем это получить. А от этого уже будет зависеть все остальное.
Начав с целей пользователей и основных сценариев взаимодействия их с продуктом, мы сможем посмотреть на систему «с высоты птичьего полета». Сфокусироваться на основных частях системы и проследить основной путь пользователя от входа в приложение до целевого действия, и все свои усилия сконцентрировать на том, чтобы сделать этот путь наиболее понятным и удобным. Этот подход называется «целеориентированным» и очень хорошо описывается в книге Алана Купера «Об интерфейсе. Основы проектирования взаимодействия».
Если при принятии интерфейсных решений мы будем руководствоваться личным художественным вкусом, цветовыми пристрастиями, или просто желанием занять пустующее место на странице, то как эти решения мы будем отстаивать перед начальником или заказчиком?
У нас будет гораздо более сильная позиция, если мы видим, что эти решения помогают в достижении наших целей и если пользователи понимают, что и как они могут делать на странице и ведут себя так, как мы хотим. Как написал Эрик Рис в книге «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»:
«Хороший дизайн – тот, который меняет поведение потребителей к лучшему».
И это единственный объективный критерий хорошего дизайна. И вот вам еще одно высказывание на эту тему из книги Getting Real компании 37signals. Тут нет слово «Дизайнер», но по-моему, к нам эта фраза относится напрямую:
«Лучшие проектировщики и лучшие программисты – не те, у кого лучшие навыки, или самые проворные пальцы, или не те, кто может сделать красивый макет в Photoshop, – это те, кто может определить, что имеет значение. Это те, кто принимает выгоды от решения.»
Думать не надо рисовать
Часто дизайнер оказывается единственным человеком отвечающим за то, как приложение будет восприниматься пользователями, что и как они будут в нем делать, насколько они будут довольны, станут ли постоянными клиентами или закроют приложение и никогда к нему не вернутся. Согласитесь, что изменение цвета кнопочки вряд ли может серьезно на это повлиять.
Получается, что вам нужно брать в свои руки UX дизайн, проектирование, анализ потребностей и задач пользователей и даже разбираться в бизнес-целях организации. А что делать? Се ля ви, как говорят французы. Ситуация часто осложняется тем, что директор и менеджер относятся к дизайнеру, как к простому рисовальщику и скептически воспринимают его вопросы о целях пользователей и предложения по проектированию. Успех в этом сражении будет зависеть от настойчивости героя-дизайнера.
Можно, конечно, не высовываться и аккуратно отрисовывать все, что говорят. А когда на свет появится очередной зомби-проект, развести руками и сказать «Вы сами настояли на таком решении, оно мне сразу не нравилось». Но, лично мое мнение, это – слабая позиция. Мы – дизайнеры – ребята амбициозные. Нам важно гордиться своей работой и наполнять портфолио живыми эффектными работами. Поэтому такой подход не для нас.
Возможно, многие со мной не согласятся и скажут, что дело дизайнера – рисовать, а не гайки крутить. И если руководитель не дал нормального ТЗ, то сам виноват, пусть ищет проектировщика или информационного архитектора, чтобы тот все продумал. Для крупных компаний это имеет смысл, но для шустрой и легкой команды стартапа такой подход неоправдан. Здесь каждый должен быть универсалом, быстро обучаться и нести ответственность за успех проекта. Так, что учитесь проектировать, определять цели пользователей, и думать обо всем проекте сразу. А если вы при этом сможете писать техническую документацию и тексты на сайт, общаться с клиентами, немного верстать и разбираться в архитектуре приложения, то вы станете гораздо более полезным для всей команды и ваш дизайн от этого только выиграет.
Изменчивость задачи
Еще один важный момент. Если говорить о стартапе, то сама задача все время меняется, т.к. проект развивается итерационно, и команда на ходу корректирует направление движения. По этому поводу не надо расстраиваться и вставать в позу обиженного дизайнера, работу которого выкидывают. Нужно сразу признать, что задача будет меняться и то, что вы рисуете – не окончательно и скорее всего будет пересмотрено в будущем. На самом деле, это хорошо, потому, что позволит вам относиться к дизайну как к эксперименту. Вы сможете думать не о том, как увековечить свое творение в истории, а о том, как наиболее эффективно и понятно решить текущую задачу.
Опять же, если иметь ввиду, что первый вариант – не окончательный, то вы будете стремиться делать его как можно более простым и гибким, не станете тратить время на прорисовку второстепенных деталей и сфокусируетесь на основных потребностях пользователей.
Короче говоря
Доля визуального дизайна в дизайне приложений ничтожно мала. Дизайн, конечно, должен быть красивым и модным, по сетке и золотому сечению, но это все вторично. Чтобы делать действительно эффективные дизайны нужно думать о множестве вещей, и прежде всего о том, зачем нужно приложение, какие оно решает задачи, что мы хотим от пользователя. Нужно все время анализировать и тестировать свои решения. Пробовать, проверять и переделывать. Все время улучшать и сомневаться в том, что кажется абсолютной истиной. Совать нос в смежные области и брать на себя часть ответственности за успех проекта.
Просто так рисовать красивые кнопочки – скучно и быстро надоедает. Ворчать на тему того, что нам плохо поставили задачу – непрофессионально. Мы легко можем превратить нашу работу во что-то гораздо более интересное и полезное, так почему бы этого не сделать?
Автор: Lo_ony
