ADV.Systems

09 Июл 2017

Определение круга обязанностей и полномочий

Крайне распространённая ошибка большинства GUI-дизайнеров это попытка перекроить имеющуюся базовую систему, нередко запущенную в серийное производство, на новый лад.

Первое, что необходимо сделать, начиная работу над проектом – определить рамки, за которые не стоит выходить. Крайне распространённая ошибка большинства GUI-дизайнеров это попытка перекроить имеющуюся базовую систему, нередко запущенную в серийное производство, на новый лад.

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

Плавное внедрение новшеств имеет ряд неоспоримых преимуществ

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

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

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

Предложения по расширению функционала не должны касаться дизайнера

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

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

Решение об использовании элементов должно оставаться за дизайнером

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

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

Идти на поводу у заказчика в доработках продуманного дизайна, то же самое что учить его как вести его же бизнес. Личные предпочтения здесь ни причём, существует только два варианта – либо заказчик хочет картинку, либо потенциального потребителя его товаров/услуг/продукта. Здесь неважно кто платит деньги и заказывает реализацию проекта. Здесь важно будет этот проект отвечать заявленным требованиям или не будет.

Неукоснительное соблюдение технического задания

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

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

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

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

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