Код или внешний вид: кто в доме хозяин?
В командах разработки сотрудники традиционно формируются в отделы (пусть даже в отделы из одного человека): программисты, верстальщики, дизайнеры, маркетологи. В неопытных командах сотрудники каждого отдела по естесственным причинам стремятся оптимизировать свою работу и сделать ее легче для себя, что зачастую приводит к конфликту интересов между отделами: каждый стремится поставить свои интересы во главе: «нам так удобнее, а вы уже там сами как-нибудь», «сначала мы сделаем как нам надо, а уже потом вы сверху доработаете» и тому подобное.
В процессе работы мне довелось войти в команду, где отдел программирования занял лидирующие позиции и фактически определил вектор развития всего коллектива. Поскольку программисты — люди, склонные к логике и прагматизму, в команде постепенно сформировалась культура строгого следования регламентам. Число правил неуклонно росло: появились детализированные гайдлайны, чёткие UI-сетки, продуманные пайплайны разработки интерфейсов. Ключевым принципом стало неукоснительное соблюдение установленных норм. Любое отклонение жёстко пресекалось аргументом: «Ваши дизайнерские решения увеличивают стоимость разработки программного модуля и ведут к росту технического долга». В результате рабочий процесс выстроился следующим образом: сначала разрабатывался код для нового раздела, а затем предпринимались попытки адаптировать его визуально — с обязательным соблюдением всех регламентированных требований. Однако добиться этого удавалось далеко не всегда.
Например: кнопка, которая не поместилась в сетку.
Дизайнер рисует кнопку для сайта на настольных компьютерах, определяет четкое значение отступов, затем делает версию для мобильных устройств, и кнопка немного не помещается:
Что делает программист или верстальщик? Вписывает кнопку в установленную сетку, меняя величину отступов в ней:
Эстетика в кнопке утеряна: считывается неряшливость. Как известно, неряшливость вызывает недоверие к бренду, но отдел разработки этот аргумент не интересует.
Или, например, он выведет надпись в кнопке в две строки. Не влезло же, какие проблемы?
Теперь кнопка превратилась в плашку, и стала менее привлекательной для нажатия.
Правильным решением здесь будет учет дизайнерских практик и рекомендаций, поскольку отдел дизайна оперирует понятиями, о которых мало что знает отдел разработки. Необходимо соблюдать метрики, утвержденные дизайнерами: оставить боковые отступы в кнопке и допустить ее выступ справа и слева вопреки сетке. Скруглённые края хуже поддаются визуальному выравниванию, в результате чего выступ за сетку не будет заметен конечному потребителю. Это наименьшее из зол.
Неучет дизайнерских практик в разработке проекта очевидно приведет к негативным последствиям во взаимодействии с конечным потребителем (то есть к ухудшению UX составляющей). Становится не важным то, с чем клиенту придется взаимодействовать в первую очередь, то, что создает нужное впечатление о продукте, то, что в конце концов приведет клиента к покупке.
Кто в конечном итоге будет платить за продукт? Программист или клиент?