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

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

Создание реалистичного и осуществимого дизайна

Имея четкое представление о том, как будет реализовываться конечный продукт, дизайнер будет предлагать более реальные и практически осуществимые идеи. Поскольку работа дизайнера является неотъемлемой частью процесса разработки сайта, он должен озаботиться тем, чтобы дизайн можно было успешно претворить в сетевую реальность, в частности, учитывая юзабилити сайта, удобство его просмотра и доступность. Дружественный интерфейс сайта подразумевает не только удобство и четкую логическую организацию навигации, но и предоставление пользователю всей необходимой ему информации упорядоченно и не перегружая его сверх меры. Единственный реальный способ узнать, правильно ли «работает» ли верстка сайта, — это научиться делать её самому.

Упрощение коммуникаций

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

Удобный циклический процесс разработки

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

Лучший и более гармоничный результат

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

Экономия времени на разработку

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

Дизайнер начинает соответствовать требованиям рынка

Сегодня дизайнеру, чтобы оставаться востребованным, нужно постоянно расширять свое портфолио и улучшать свои конкурентные качества — уже недостаточно обладать каким-то одним набором навыков. Часто приходится быть мастером на все руки — и дизайнером, и разработчиком пользовательских интерфейсов, и копирайтером, и менеджером проекта.

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

Однако, у такого сценария, когда дизайнер занимается версткой своих инноваций, есть и недостатки.

Как написал Лукас Мэтис (Lukas Mathis) в одной противоречивой статье на нашу тему под названием «Дизайнеры — не программисты» [1]:
Если дизайнер претворяет в жизнь собственные идеи, перед ним стоят две разные задачи: написать качественный код и создать приятный пользовательский интерфейс. Эти две задачи противоречат друг другу. Если вам необходимо самому воплощать свой дизайн, вам придется чем-то поступиться ради качества кода, а это повредит дизайну.

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

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

Заключение

Учитывая все сказанное, объем разрабатываемого проекта может, в конечном итоге, определять роли, которые отводятся в нем дизайнеру и разработчику. Небольшое приложение может с успехом контролировать менеджер проекта [2], в то время как обширной системой, определенно, должен управлять специализированный персонал!

[1] — Mathis, Lukas.»Designers are not Programmers».

[2] — Spolsky, Joel. «How to be a program manager».