Что такое верстка дизайн
Что такое дизайн сайта и вёрстка, почему мы платим за них отдельно?
За внешней оболочкой сайта скрываются коды и операции. Если за первое отвечает дизайнер, то вторым занимается верстальщик. Вёрстка и дизайн идут рука об руку, но заказчик сайта платит за эти работы отдельно, потому что у каждого направления — своя задача.
Дизайн сайта — не просто красивые картинки
Дизайн интернет-ресурса — оформление контента, комплекс графических элементов на странице. Не так давно web-дизайн связывали только с визуальным оформлением. Цель современного дизайна сайта — удобство пользователя, в связи с чем разработчик занимается ещё и аналитикой, а также структурирует информацию.
Главная задача дизайнера — создать облик сайта, который понравится посетителям и будет удобен в использовании. Грамотно разработанный стильный интернет-ресурс создаёт о владельце нужное впечатление.
Для создания макета дизайнер использует подходящие цвета, анимацию, текст. Расстановка заголовков, изображений, выбор шрифтов — всё это также его задачи. Но результат этой деятельности — не готовый сайт. Над этим нужно потрудиться программисту или верстальщику.
Вёрстка — воплощение идеи в реальность
Вёрстка сайта — это этап разработки, когда созданный дизайнером макет преобразуется в HTML и CSS-код. То есть, верстальщик берет готовый дизайн и описывает его программным кодом и языком разметки, благодаря чему получается рабочая web-страница.
Таким образом, работа состоит в том, что обычные картинки превращаются в специальный код, понятный компьютеру. Верстальщик составляет определённый набор команд, указывающий нашим браузерам, как показывать сайты.
Чтобы заниматься вёрсткой, надо знать:
Разные, но не могут друг без друга
Дизайн и вёрстка — то, без чего не может существовать ни один сайт. Для описания внешнего вида ресурса программным кодом нужен результат работы художника (макет сайта), а дизайн без вёрстки ничего не значит. Тем не менее, это различные области и профессии: web-дизайнер и верстальщик. Они нужны друг другу, но работа у них разная, поэтому и оплачивается по отдельности.
Может ли один и тот же человек делать дизайн и вёрстку
Есть «вундеркинды», которые берут деньги за услугу «два в одном». Насколько она качественная? Ровно настолько, насколько один человек может в совершенстве овладеть разными профессиями — творческой и требующей математического, логического мышления.
Иногда можно немного сэкономить. Например, когда нужен скромный сайт-визитка для маленькой организации. Если же компания будет расширяться, всё равно потребуется хороший сайт, поэтому услуги дизайна и вёрстки придется разделить. Конечно, в компании, которая занимается созданием и разработкой сайтов, дизайнер и верстальщик работают в команде, но их задачи отличаются.
Важно понимать, что сложные информационные или торговые сайты должны делать узкие специалисты. При этом в ответственной компании они понимают работу друг друга. Дизайнер должен в общих чертах знать, как его макет будет использовать верстальщик, который, в свою очередь, должен суметь качественно сверстать любой вменяемый макет. Плохо, если хотя бы один из специалистов будет ниже среднего. Каждый из них должен выполнять свою работу на отлично — это залог появления красивого и функционального сайта.
Что нужно для хорошей вёрстки
Чем ответственнее дизайнер подойдёт к решению своих задач, тем меньше трудностей будет в дальнейшем. Но если с сайтом что-то будет не так, все шишки достанутся верстальщику. Поэтому он тщательно следит за тем, какой получает материал. Обратим внимание на несколько моментов в работе дизайнера, которые важны для верстальщика. Это поможет понять зону ответственности каждого из них и разобраться, почему платить надо и тому, и другому:
Это лишь несколько ответственных моментов, определяющих результат работы верстальщика и дизайнера. У каждого из них свои задачи, очень ответственные и сложные. Клиент, оплачивающий их труд, получает качественный сайт, достигающий поставленных целей.
Верстка сайта: инструкция для начинающих
Что такое вёрстка сайта
Вёрстка – это структура всех элементов на странице документа, сайта или другого информационного носителя. Такими элементами могут быть изображения, заголовки, подзаголовки, таблицы, инфографика и сам текст.
Изначально понятие вёрстки было применимо к издательской деятельности. Книги, газеты, журналы содержат структурированную информацию. В них есть чёткая сетка, блоки, в которых текст и графические материалы упорядочены таким образом, чтобы максимально облегчить читателю процесс потребления информации и заинтересовать его.
Сейчас актуальность вёрстки для издательств сохраняется, но к ним также примкнула и сфера веб-дизайна.
В разработке сайтов вёрсткой называется перевод дизайн-макетов в интерактивный, читаемый браузерами вид. То есть, верстальщик пишет код, который формирует из предоставленного графического шаблона «живую» веб-страницу, с элементами которой может работать пользователь.
В контексте создания сайтов есть два вида разработки:
Вёрстка относится к front-end. Она не отвечает за базовые возможности сайта, например, за регистрацию пользователей, товарную корзину или прочие операции, связанные с вычислениями, внешними и внутренними запросами, хранением и загрузкой данных.
Вёрстка правильно располагает все элементы на странице и делает так, чтобы с ними было удобно работать. Поэтому вёрстка сайта – это ответственная задача, требующая внимательности, терпения и постоянного тестирования.
Вёрстку веб-страниц невозможно представить без HTML. Если говорить простыми словами, то HTML — это единый стандарт отображения всех элементов веб-страницы. Это язык разметки, с помощью которого браузеры показывают нам порядок, размер, формы и шрифт текста. С его тегами знакомы все, кто занимался созданием сайтов, например:
Дизайнь как верстальщик
Ваш дизайнер – настоящий гений и его продукт идеален. Он доблестен в неравной борьбе с ТЗ и всегда выходит победителем. Но уже пятый по счету верстальщик, матерясь, делает из его макетов какую-то гадость? Не торопитесь искать шестого. Чаще всего причина легко устранима – достаточно лишь поведать вашему гению о нескольких приземленных правилах и попросить его им следовать.
В этой статье я попробовал собрать некоторые рекомендации для дизайнеров, делающих мир чуть светлее. Спросите у верстальщика о его проблемах, отправьте эту статью дизайнеру. Ибо совершенству нет предела.
Проблема существовала всегда, сколько я себя помню айтишником. Когда проектирование интерфейсов было лишь красивым словосочетанием, смысл которого понимали только настоящие профи, дизайн отвечал минимум за две трети впечатления пользователя от сайта. Сейчас немного проще, UI-проектирование все чаще отделено от дизайна, хотя и делает его порой один и тот же человек. В любом случае, именно веб-дизайнер преобразует смутные образы или сухие прототипы в то, с чем потом взаимодействовать пользователю. И очень важно, чтобы верстальщик перенес этот дизайн в веб максимально точно. Желательно – вообще без изменений. Попиксельно. Спросите у любого дизайнера, насколько часто финальная верстка полностью его устраивает? Уверен, ответ будет печальным, если не резким.
О причинах этого говорить можно долго, но чаще всего винят верстальщика. Оно и понятно: дизайн есть, дизайн хороший, будь как дизайн. Но помимо простого копирования, на верстальщика ложится еще целый ворох обязанностей. Он должен сделать сайт адаптивным, быстрым, легким. Его верстка должна быть семантичной, изображения – пожатыми или векторными, а формы – заточенными под бэкенд. Да frontend-разработчик вообще много чего и кому должен, если он хороший (как дизайн). Вот и берет наш герой какой-нибудь фреймворк для ускорения и оптимизации работы – причем не важно, комбайн-бутстрадейшн или собственный велосипед, с гридами на флексбоксах. Открывает макеты и начинает ваять. И то тут, то там, ему приходится немного отступать от дизайна. Или раздувать таблицы стилей, делая их сложночитаемыми и неоправданно большими. Результат всегда не очень: дизайнер недоволен, фронтендер недоволен, в мире стало чуток темнее.
Но это только в том случае, если наш дизайнер, создавая макеты и передавая их дальше по цепочке, не учел несколько важных моментов, о которых я и собираюсь рассказать. Конечно, вряд ли я смогу здесь описать все, что мешает правильному взаимодействию дизайнера с верстальщиком. Да и проблемы, возникающие в этой связке, бывает, вообще никак не относятся к профессиональным качествам сторон. Но следование изложенным ниже рекомендациям точно не повредит ни проекту, ни его разработчикам.
Текст ниже — для дизайнера и, чуть-чуть, для фронтендщика. Итак, погнали.
Унифицируйте элементы
Представим, что на сайте полсотни различных кнопок. От банальной «читать далее» до «произвести расчет стоимости лечения за первое полугодие». А есть еще круглые кнопки с иконками и кнопки-списки. И на каждой странице они немного отличаются: где-то кнопка на 5 пикселей шире остальных, где-то иконка переместилась в правую часть, где-то радиус углов немного разный… Выглядит, конечно, очень круто. И различия на дизайн-макетах даже не бросаются в глаза. Но на деле такое отношение к элементам оборачивается несколькими проблемами:
— верстать сложнее, дольше и дороже;
— возрастает вероятность, что верстальщик будет использовать на всем сайте только один из визуально почти одинаковых элементов;
— пользователю приходится каждый раз «привыкать» к новому виду элемента (хотя он и сам может этого не осознавать);
— при развитии проекта, скорее всего, получится чехарда из разномастных кнопок, инпутов и тд.
Решение простое. Дорогие дизайнеры, создайте единый документ, в который поместите все-все типовые элементы. Заголовки, списки, параграфы, ссылки, кнопки, поля форм, контролы, миниатюры изображений и прочее. Такую доку называют «UI Style Guide» или «Frontend Style Guide» — кто как привык. Обычно это просто послойный исходник вроде этого. И везде в проекте используйте только эти элементы и только в той форме, в которой они здесь запечатлены. Появился новый мультиселект? Добавляйте его в «стайлгайд».
Причем не стоит ограничиваться только элементами. Создайте набор главных цветов интерфейса — это тоже полезно. В ряде случаев мы даже делаем список основных отступов, используемых в макетах.
Если верстальщик опытный, он сразу сделает себе такой же «стайлгайд» в вебе, откуда просто будет копировать элементы. Да и вообще, преимуществ у «стайлгайдов» тьма: от удобства в развитии проекта до ускорения работы всех, причастных к фронтенду.
Изучите основы верстки
Одна из самых спорных рекомендаций, пожалуй. Многие мне возразят, и это нормально. Но веб-дизайнер, понимающий хотя бы самые базовые принципы HTML и CSS, по моему опыту, стоит дороже и работать с ним приятнее. Такой дизайнер понимает, что есть шесть типов заголовков, что параграф обычно имеет отступ снизу, что списки могут быть вложенными и прочее. И здесь речь не просто о типографике — тут важно, чтобы макет был не только красивым, но и реализуемым, легким (о скорости мы еще поговорим ниже).
Это не сложно, поверьте. За пару недель ежедневных часовых занятий можно приобрести базовое понимание основных HTML-тегов и возможностей CSS. Никто не просит вас, дорогие творцы, становиться технарями и вникать в дебри псевдоэлементов. Но следует понимать, какие из ваших решений могут быть реализованы в вебе, а для каких потребуется заключать союз с нечистой силой.
Научитесь работать по гридам
Гриды, сетка, колонки — суть одна. Если упростить, то модульная сетка для дизайнера представляет из себя условное разделение макета на вертикальные колонки одинаковой ширины, с определенными отступами между ними. Стоит один раз распределить элементы макета внутри этих колонок, и обратного пути уже не будет вы поймете, насколько это удобно.
Привычка работать по сетке — одна из самых полезных (после утренних пробежек, раздельного питания и использования хоткеев). Она позволяет упорядочивать визуальную структуру документа, с легкостью переиспользовать блоки, ускоряя разработку как дизайна, так и верстки. Кроме того, именно на гридах строятся популярные front-end фреймворки вместе с адаптивностью, а это важно — и я к этому еще вернусь.
Для дизайнера же гриды хороши еще и тем, что при переносе его макета в верстку шанс точного «совпадения» возрастает во много раз. Для верстальщика в целом упрощается все. Опытный фронтендщик просто создаст у себя в проекте точно такие же колонки, и не будет тратить время на попиксельное сравнение отдельных блоков, не говоря уже об адаптивности.
Тем, кто работает в Photoshop’е, могу предложить даже небольшую подборку шаблонов. Для предпочитающих Sketch такой штуки у меня, увы, нет — но она есть в гугле.
Помните про адаптивность
В предыдущем пункте она упоминается аж два раза не просто так. Игнорировать мобильный трафик сейчас — настоящее преступление, за которое нужно ввести порку розгами. Вот уже два года, как мне перестали попадаться проекты, в которых не нужно было бы реализовывать корректное отображение сайта на экранах мобильных устройств. Вместе с тем многие дизайнеры продолжают создавать только один вариант дизайна — основной, самый широкий.
Что происходит после этого? У верстальщика, получившего такой макет, есть несколько вариантов действий:
— запросить недостающие компоновки страниц, под остальные разрешения;
— сделать только то, что ему прислали — то есть неадаптивную верстку;
— попытаться самостоятельно адаптировать имеющийся дизайн.
Первый вариант частенько нереален, потому как дизайнер уже получил свои деньги, а заказчик — жлоб (например). Второй вариант отпадает, потому что тогда фронтендщик становится соучастником и рискует оказаться наказанным. Чаще всего в таком случае отрабатывается третий вариант. И получается так себе, потому что верстальщик, даже очень хороший — это не дизайнер. Исключения крайне редки.
Так вот, дизайнеры. Очень прошу, делайте несколько вариантов макетов, под разные разрешения. Этим вы сэкономите время на разработку и повысите шансы положить проект в портфолио, потому что за его реализацию не будет стыдно. Ну и в очередной раз докажете собственный профессионализм.
И к слову о гридах. Использование модульной сетки в дизайне очень упрощает проектирование адаптивности. Мне, например, уже как-то привычны следующие шаги (ширина макетов): 1440px, 1200px, 960px, 768px, 600px и 320px. Иногда заменяю 600 на 480, но это уже индивидуальности проекта. При переходе на каждый шаг уменьшается ширина колонки, но расстояние между ними остается прежним. Найти уже готовые шаблоны можно по ссылке в пункте выше.
Будьте в курсе трендов
В общем-то, банальный совет. Но буквально на днях я обнаружил дизайнера, не знакомого с принципами material design. Ну то есть общее понимание концепции у него было, а вот о «гайдлайнах» material он слыхом не слыхивал. Конечно, у матерого дизайнера изучение практически любого направления не займет много времени, но иногда незнание основ может помешать получить вкусный и интересный заказ.
Однако, помимо направлений в дизайне как таковых, существуют еще и популярные фронтенд-фреймворки. Их задача — упростить и ускорить разработку внешней части сайта, включая верстку, js и прочее. Если вы, дизайнер, работаете в команде, которая предпочитает использовать определенный фреймворк, изучение его базовых особенностей сохранит время и нервы всей команды. И речь тут не только о цветовой схеме или компоновке блоков, не стоит загонять себя в чересчур жесткие рамки, вы же творец. Речь, скорее, о базовых элементах или особенностях анимации. Например, в некоторых фреймворках боковое меню, появляющееся на небольших экранах, накладывается поверх контента, а не сдвигает его. И изменить такое поведение порой стоит немалых жертв. Поэтому не стесняйтесь общаться с frontend-разработчиками на самых первых этапах, узнавайте о фреймворках и их особенностях.
Из популярных могу назвать:
— Bootstrap. Не нуждается в особом представлении. Почти все, что нужно на старте — есть из коробки. Самый популярный в мире.
— Foundation. Гибкий, современный, настоящий комбайн. Достойная альтернатива бутстрапу.
— Materialize. Заточен под material design, что видно из названия. Включает в себя также анимации в стиле материал.
— Material Design Lite. По сути, брат предыдущего. Имеет в себе все необходимые для быстрого создания проекта в стиле material.
— Ionic. Фреймворк для создания мобильных приложений на базе cordova. По сути, реализуется той же HTML-версткой, а потом компилится под разные платформы.
— Mobile Angular UI. То же самое, что и предыдущий, но использует верстку bootstrap.
Frontend-фреймворков тьма, все перечислять не стану. В случае необходимости сами загуглите.
Учитывайте скорость загрузки сайта
Да, скорость загрузки и работы сайта во многом закладывается на этапе дизайна. Знаю, для кого-то это будет новостью. Но стоит вдуматься — и это становится очевидно. От чего зависит скорость загрузки сайта? Исключим сервер и кривые руки фронтедеров. Статика. Изображения, скрипты, стили.
С картинками, вроде, все понятно — чем их и они меньше, тем быстрее пользователь увидит сайт в том виде, на который вы рассчитываете. Но это ведь не повод отказываться от фоновых изображений, верно? Современные технологии разработки позволяют верстальщикам подставлять разные изображения на разных разрешениях. Так зачем на экраны мобильных устройств тянуть те же мегабитные фоны, что и на десктопах? Подготовьте несколько вариантов фона для разных разрешений — хотя бы просто в макетах, верстальщик сам их вынет оттуда. Ну или предоставьте верстальщику готовую папку с фонами, если Вы совсем уж святой.
По возможности, используйте векторную графику для иконок или простых изображений — она и весит меньше, и выглядит лучше.
Скрипты не во власти дизайна, это очевидно. Но если во время дизайна понавтыкать в каждый квадратный сантиметр сайта параллаксы, анимированное появления блоков и прочие свистелки, у кого-то сайт не загрузится никогда. Очень прошу, дорогие дизайнеры, не увлекайтесь анимацией, если того не требует ТЗ.
О стилях же я уже писал в самом начале. Если в макете отсутствует унификация элементов, а верстальщик попался добросовестный и усердный, размер таблицы стилей будет сопоставим с размером изображений на сайте. И все это придется тащить браузеру, покуда он не закэширует все это безобразие. Мне в одном проекте встретился файл стилей размером с небольшого котенка — 17 мегабайт. И это в минифицированном виде. До сих пор кошмары снятся.
Изучите, наконец, векторную графику
Мой самый любимый и одновременно ненавистный пункт. Именно он пришел мне на ум первым, когда я собрался писать эту статью. Прошу дизайнеров отнестись к нему со всей серьезностью.
Речь, конечно, об SVG. Это такой формат векторных изображений, о котором в последнее время говорят все чаще. И я не стану плодить сущности, рассказывая о его преимуществах. Я расскажу о проблеме, которая с ним связана.
Про себя я ее обзываю «псевдо-SVG». Это когда дизайнер дает верстальщику SVG-файл, но тот не может его нигде использовать. Весьма распространенное явление. Причина простая — дизайнер, работая в фотошопе, просто экспортирует иконку как SVG (по ctrl+shift+alt+w), хотя она является растровой. Внутри таких бесполезных эсвэгэшек обычно лежит текст с:
Такое изображение не получится масштабировать, да и разницы между ним и растром, по сути, никакой.
Происходит это от того, что дизайнер не очень понимает, что такое SVG, и не умеет правильно его использовать. Для таких я бы рекомендовал, все-таки, изучить формат. Если же вы работаете в фотошопе, то стараться такие изображения создавать «перьями». Или использовать готовые наборы иконок. Пользователям Sketch тут проще — у них вектор получается по умолчанию. В любом случае, если вы хотите быть «дизайнером будущего», знать SVG необходимо. Вот несколько полезных ресурсов на русском языке: раз, два, три.
Для уменьшения количества запросов к серверу (привет, HTTP/2), да и просто для удобства использования все SVG-иконки на сайте очень часто объединяют в спрайты — этакие комбинированные файлы. Создать SVG-спрайт можно тремя способами:
— вручную, копируя содержимое каждого SVG в один общий файл;
— программно, при помощи различных библиотек;
— посредством специальных онлайн-сервисов.
—
Первый способ оставим людям, у которых много свободного времени. Со вторым все понятно — он используется верстальщиком и требует определенных навыков. А вот третий способ может подойти и дизайнеру. К примеру, если он ведет развивающийся проект и регулярно добавляет в него новые иконки. Тогда дизайнер может самостоятельно изменять SVG-спрайт, например, через этот вот сервис и отправлять готовый файл на фронтенд. Мелочь, а приятно.
Прикладывайте шрифты
Хочу открыть небольшую тайну дизайнерам. По крайней мере тем из них, кто с ней еще не знаком. Каждый шрифт, который вы хотите использовать в макете (если он не входит в список «безопасных»), должен быть представлен как минимум в четырех форматах: ttf, eot, woff (или woff2, а лучше оба) и svg. А если вы используете проприетарный шрифт, то его использование в вебе может быть несколько осложнено. Да и не совсем законно.
Я всегда советую подбирать шрифт из Google Fonts, предварительно посмотрев, есть ли у него поддержка кириллицы. Если же этот вариант не подходит, то стоит проверить проприетарность шрифта или сразу подготовить архив со всеми необходимыми форматами. Сконвертировать их можно при любезной помощи этого сервиса (не забудьте переключиться в режим «EXPERT. » и в секции «Subsetting», отметив «Custom Subsetting. », проставить галочку рядом с «Cyrillic»).
Ибо нет более надежного способа покорить сердце верстальщика, чем вручить ему готовый набор шрифтов для интеграции в веб.
Эпилог
Конечно, множество моментов оставлено здесь без внимания: иерархия и наложение слоев в исходниках, типографика, наборы иконок и многое, многое другое. Однако статья и так получилась объемной, а большинство того, о чем я не написал, прекрасно находится в интернете по запросу «советы дизайнеру». Вот, например, еще рекомендации от Spaceoddity: habrahabr.ru/post/173271
И да, о смысле. Если этот пост помирит хотя бы одну пару дизайнера с верстальщиком, или сэкономит десяток-другой человекочасов — значит, время на его написание было потрачено не зря.
Дизайн vs. Верстка?
На Хабрахабре уже не раз поднимался вопрос о том, что популярные на сегодняшний день жизненные циклы разработки веб-интерфейсов, прямо говоря, устарели. Последний раз его обсуждали в публикации «Дизайн в браузере», но так и не пришли к единому мнению.
Настало время наконец-то найти ответы на два главных вопроса: “Кто виноват?” и “Что делать?” в вечной борьбе дизайна и верстки…
Типовой жизненный цикл разработки веб-интерфейсов
Начать статью стоит с рассмотрения вопроса о том, как собственно происходит разработка веб-интерфейсов, кто в ней участвует, что конкретно делает и за что отвечает. Существуют десятки методологий, по которым строится жизненный цикл разработки веб-интерфейсов, но их всех объединяют базовые этапы:
Этап первый: Создание формальных требований на разрабатываемый интерфейс. Конечный результат этого этапа — бриф или техническое задание, где описано, что должно быть на макете, и как это будет реализовано. Занимаются этим люди с проектными ролями: бизнес-аналитик, технический писатель;
Этап второй: Разработка графического дизайн-макета по брифу или ТЗ. Данную работу выполняет дизайнер (веб-дизайнер, дизайнер GUI);
Этап третий: Верстка интерфейса (создание html\css\JS кода) по графическому дизайн-макету. Над версткой работает верстальщик (фронтенд разработчик, веб-разработчик).
Ограничиться базовыми этапами и получить высококлассный результат можно, пожалуй, только в “сферических условиях в вакууме”. На практике на каждом этапе возникает ряд проблем, решать которые приходится, вводя подэтапы и усложняя жизненный цикл разработки интерфейса.
Подробнее о возникающих проблемах и способах их решения поговорим ниже, начав с вопроса объективности оценки качества дизайн-макетов.
Проблема формальной оценки дизайна
Под разработкой дизайна веб-интерфейсов подразумевают работу по проектированию взаимодействия и оформлению внешнего вида веб-страниц. Внешний вид удобно передать в графическом дизайн-макете. Т.е. работа над дизайном сводится к созданию макета.
Оценка макета, по большому счету, субъективна. Часто строится на таких эпитетах, как красиво, нравится, приятный, аккуратный, и их вариантами с приставкой “не”… Качество макета оценивается по личным предпочтениям. Встает вопрос: а можно ли вообще формально оценить макет по субъективным критериям? Можно. И самый действенный способ — тестирование на фокус группе: набирается группа людей из целевой аудитории, для которой разрабатывается макет, проводится его демонстрация, после чего участники исследования заполняют анкеты-опросники, выставляя оценки исходя из своего личного мнения по этим субъективным параметрам. Среднестатистическое значение — адекватная оценка качества макета.
Часто ли на практике происходит такое тестирование на фокус группе? К сожалению, очень редко. Обычно всё сводится к согласованию личного мнения дизайнера и заказчика. При этом, по опыту, как исполнитель не всегда может адекватно оценивать свою работу, так и заказчик имеет бесполезное или даже вредящее качеству мнение. В итоге страдает конечный пользователь, ради которого, казалось бы, и делается макет.
Другой подход к формальной оценке макета основан на принципах взаимодействия с пользователями, которые иногда называют “Принципами Стива Джобса”:
Разработчики не считаются с мнением пользователей, сами определяя то, что нужно пользователю, т.к. разработчики — это эксперты и профессионалы, видящие ситуацию в целом и адекватно, а конечные пользователи в большинстве случаев сами не знают, чего хотят, и способны лишь наслаждаться результатом, который удовлетворяет их потребности, о которых они ранее и не подозревали.
По этим принципам в начале эпохи домашних компьютеров создавались решения от Apple, превратившие в произведение дизайнерского искусства эти самые ПК, в противовес “квадратно-практичному” внешнему виду продуктов конкурентов. Потребители сами не догадывались, что им понравится тот факт, что такая утилитарная вещь, как компьютер, может быть стильным дизайнерским решением. Но увидев реализацию, созданную дизайнерами, не считавшимися с мнением потребителя, все же положительно оценили её. Впрочем, это другая история, вернемся к разработке внешнего вида веб-страниц…
Да, многие дизайнерские студии работают над оценкой макетов по схожим принципам, без всяких фокус групп из представителей ЦА, самостоятельно определяя, каким должен быть макет, и получая в итоге очень удачный и качественный результат. Происходит всё то же самое, что и с фокус группой, только здесь собирается экспертная группа, состоящая из нескольких опытных дизайнеров, работающих в той же области, им также презентуется макет, и происходит его оценка.
Но, опять же, как часто на практике собираются экспертные группы, состоящие еще хоть из кого-нибудь, кроме исполнителя-дизайнера и заказчика? Кажется, мы об этом уже говорили…
Формальная оценка качества дизайн-макета возможна, но на деле редко осуществима. Любая индивидуальная оценка — субъективна, и это помимо прочих проблем разработки веб-интерфейсов…
Несоответствие ощущений от графического макета и сверстанной веб-страницы
Проблема, озвученная в подзаголовке, хорошо известна в среде веб-дизайнеров:
Как бы качественно и детально ни был отрисован макет, он остается графическим изображением, иногда его ещё называют “мертвым” макетом. Даже если вы разрабатываете дизайн веб-страницы, где нет динамических элементов (раскрывающихся меню, меняющихся по клику теней и т.д.), все равно ваш макет по ощущениям отличается от конечной, сверстанной страницы (даже на статике можно выделить текст, проскроллить и прочее).
Касается эта проблема и удобства использования. Частично юзабилити-экспертизу можно провести и по графическому макету (оценив расположение и компоновку элементов и т.д.), но полноценно понять, насколько удобным оказался интерфейс, выявить все подводные камни в работе с ним, можно только по конечной, готовой веб-странице.
Сюда же идет и ещё одна беда как дизайнеров, так и верстальщиков — отсутствие контента. Порой в брифе написано: “здесь на странице текст, а здесь — картинка”. А что это за текст, какого он размера, сколько абзацев и заголовков в нём; что там за картинка, в какой она цветовой гамме, какие у нее пропорции — не указано. Тогда приходится в дизайн-макете использовать “рыбу” (заглушки) — сторонние тексты, картинки. Иногда их же приходится применять и при верстке. А после, когда на странице размещается уже конечный, рабочий контент, ужасаться конечному результату,
Выходит, даже если изначально дизайн-макет оценивался положительно, оценка конечного результата может сильно поменяться в худшую сторону.
Как можно было бы избежать всех этих проблем при разработке веб-интерфейсов
Что мы имеем в итоге? Озлобленных дизайнеров, рисующих N’ую версию макета и правомерно заявляющих: “нужно более формально задавать требования к макету”. Не менее раздраженных верстальщиков, переверстывающих страницу в M’ый раз. Дополняют эту картину растянувшиеся сроки, проваленные дедлайны, превышенные бюджеты и извечные вопросы “Кто виноват?” и “Что делать?”
Всего этого можно было бы избежать, если изменить типовую модель жизненного цикла разработки веб-интерфейсов. После небольшой корректировки, она выглядела бы так:
Этап первый: Подготовка контента;
Этап второй: Создание краткого брифа с описанием функциональности и формальных требований к разрабатываемому интерфейсу;
Этап третий: Быстрая разработка интерфейса в тех условиях, где он будет использоваться (прямо в браузере), сразу верстая его как готовую веб-страницу, с непрерывной экспертной и юзабилити оценкой.
Все проблемы исчезают сами по себе, конечный результат всегда на высоком уровне, в дополнение — сроки и расходы на разработку сокращаются в несколько раз, по сравнению с существующими типовыми жизненными циклами разработки веб-интерфейсов. Спрашивается, почему все до сих пор не пользуются такой удачной схемой? На самом деле, как раз сейчас такой подход набирает обороты.
Там же, в комментариях были озвучены и другие примеры, говорящие за актуальность описанного подхода — это появившиеся в недавнем времени специализированные продукты. Во-первых, это решения для быстрого создания прототипов веб-страниц, такие как: www.axure.com, http://froont.com. Во-вторых, это программы и сервисы нового поколения, где при визуальной разработке макета, сразу генерится готовая верстка (и в отличие от похожих продуктов “старого поколения”, эти решения генерят чистый и лаконичный код, как будто его писал высококлассный верстальщик): http://macaw.co, https://webflow.com.
Продукты для создания прототипов хороши тем, что можно быстро получить визуальный результат, но о лаконичной и чистой верстке, а тем более о полноценных интерфейсах, созданных в них, речи не идет. Решения, которые генерируют качественный код, нельзя назвать простыми, и быстро работать в них не получится. Порой время работы с ними, напротив, соизмеримо или даже дольше, нежели в случае, когда сперва нужно отрисовать графический макет, а затем “вручную” его сверстать. При этом ни в тех, ни в других нет возможности работать над макетом в тех условиях, в которых он будет использоваться (т.е. прямо в браузере, с отсутствующими рабочими элементами редактора). Да и функция автосохранения и хостинга проектов, дающая непрерывный доступ к промежуточному результату третьим лицам (для оценки качества, юзабилити-экспертизы и т.д.), имеется далеко не у всех…
Когда появится решение, лишенное всех этих недостатков и способное полноценно реализовать предложенный жизненный цикл разработки веб-интерфейсов, остается лишь вопросом времени. Все тенденции ведут именно к такому продукту.
Если вас заинтересовала проблематика, описанная в статье, и её решение, в качестве бонуса предлагаем посмотреть вот это короткое видео — http://www.youtube.com/watch?v=nIOVU9_KRKA
Кирилл,
руководитель проекта Mockup editor SletchBuilder
В соавторстве с нашим дизайнером Сергеем Sevenvampire и веб-разработчиком Антоном skrutty.