Главное Свежее Вакансии Образование
Выбор редакции:
0 18 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Дизайн vs. Верстка?

Уже не раз поднимался вопрос о том, что популярные на сегодняшний день жизненные циклы разработки веб-интерфейсов, прямо говоря, устарели. Последний раз его обсуждали в публикации «Дизайн в браузере», но так и не пришли к единому мнению. Настало время наконец-то найти ответы на два главных вопроса: “Кто виноват?” и “Что делать?” в вечной борьбе дизайна и верстки…

Типовой жизненный цикл разработки веб-интерфейсов

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

Этап первый: Создание формальных требований на разрабатываемый интерфейс. Конечный результат этого этапа — бриф или техническое задание, где описано, что должно быть на макете, и как это будет реализовано. Занимаются этим люди с проектными ролями: бизнес-аналитик, технический писатель;

Этап второй: Разработка графического дизайн-макета по брифу или ТЗ. Данную работу выполняет дизайнер (веб-дизайнер, дизайнер GUI);

Этап третий: Верстка интерфейса (создание html\css\JS кода) по графическому дизайн-макету. Над версткой работает верстальщик (фронтенд разработчик, веб-разработчик).

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

Примерами проблем и возникающих по их вине подэтапов могут быть:

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

Подробнее о возникающих проблемах и способах их решения поговорим ниже, начав с вопроса объективности оценки качества дизайн-макетов.

Проблема формальной оценки дизайна

Под разработкой дизайна веб-интерфейсов подразумевают работу по проектированию взаимодействия и оформлению внешнего вида веб-страниц. Внешний вид удобно передать в графическом дизайн-макете. Т.е. работа над дизайном сводится к созданию макета.

Оценка макета, по большому счету, субъективна. Часто строится на таких эпитетах, как красиво, нравится, приятный, аккуратный, и их вариантами с приставкой "не"… Качество макета оценивается по личным предпочтениям. Встает вопрос: а можно ли вообще формально оценить макет по субъективным критериям? Можно. И самый действенный способ — тестирование на фокус группе: набирается группа людей из целевой аудитории, для которой разрабатывается макет, проводится его демонстрация, после чего участники исследования заполняют анкеты-опросники, выставляя оценки исходя из своего личного мнения по этим субъективным параметрам. Среднестатистическое значение — адекватная оценка качества макета.

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

Другой подход к формальной оценке макета основан на принципах взаимодействия с пользователями, которые иногда называют "Принципами Стива Джобса":

Разработчики не считаются с мнением пользователей, сами определяя то, что нужно пользователю, т.к. разработчики — это эксперты и профессионалы, видящие ситуацию в целом и адекватно, а конечные пользователи в большинстве случаев сами не знают, чего хотят, и способны лишь наслаждаться результатом, который удовлетворяет их потребности, о которых они ранее и не подозревали.
По этим принципам в начале эпохи домашних компьютеров создавались решения от Apple, превратившие в произведение дизайнерского искусства эти самые ПК, в противовес "квадратно-практичному" внешнему виду продуктов конкурентов. Потребители сами не догадывались, что им понравится тот факт, что такая утилитарная вещь, как компьютер, может быть стильным дизайнерским решением. Но увидев реализацию, созданную дизайнерами, не считавшимися с мнением потребителя, все же положительно оценили её. Впрочем, это другая история, вернемся к разработке внешнего вида веб-страниц…

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

Но, опять же, как часто на практике собираются экспертные группы, состоящие еще хоть из кого-нибудь, кроме исполнителя-дизайнера и заказчика? Кажется, мы об этом уже говорили…

Формальная оценка качества дизайн-макета возможна, но на деле редко осуществима. Любая индивидуальная оценка — субъективна, и это помимо прочих проблем разработки веб-интерфейсов…

b_5472c8823cfcf.jpg

Несоответствие ощущений от графического макета и сверстанной веб-страницы

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

Касается эта проблема и удобства использования. Частично юзабилити-экспертизу можно провести и по графическому макету (оценив расположение и компоновку элементов и т.д.), но полноценно понять, насколько удобным оказался интерфейс, выявить все подводные камни в работе с ним, можно только по конечной, готовой веб-странице.

Сюда же идет и ещё одна беда как дизайнеров, так и верстальщиков — отсутствие контента. Порой в брифе написано: "здесь на странице текст, а здесь — картинка". А что это за текст, какого он размера, сколько абзацев и заголовков в нём; что там за картинка, в какой она цветовой гамме, какие у нее пропорции — не указано. Тогда приходится в дизайн-макете использовать "рыбу" (заглушки) — сторонние тексты, картинки. Иногда их же приходится применять и при верстке. А после, когда на странице размещается уже конечный, рабочий контент, ужасаться конечному результату,

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

Как можно было бы избежать всех этих проблем при разработке веб-интерфейсов

Что мы имеем в итоге? Озлобленных дизайнеров, рисующих N'ую версию макета и правомерно заявляющих: "нужно более формально задавать требования к макету". Не менее раздраженных верстальщиков, переверстывающих страницу в M'ый раз. Дополняют эту картину растянувшиеся сроки, проваленные дедлайны, превышенные бюджеты и извечные вопросы "Кто виноват?" и "Что делать?"

b_5472c8a82cda8.jpg

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

Этап первый: Подготовка контента;

Этап второй: Создание краткого брифа с описанием функциональности и формальных требований к разрабатываемому интерфейсу;

Этап третий: Быстрая разработка интерфейса в тех условиях, где он будет использоваться (прямо в браузере), сразу верстая его как готовую веб-страницу, с непрерывной экспертной и юзабилити оценкой.

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

Об этом говорилось в статье, ссылку на которую мы дали в начале поста (http://habrahabr.ru/post/238485/), но продублирую ещё раз сюда:

  • На питерском WSD большая часть докладов была посвящена этой теме — http://webstandardsdays.ru/2014/06/28/;
  • Об этом говорилось в докладе Антона Виноградова из Альфа-лаб на BEMup (https://tech.yandex.ru/events/bemup/6-september-2014/talks/2189/), где он рассматривал тему на примере верстки приложения Яндекс.Такси;
  • Доклад Ильи Пухальского на Rest in PS (https://vimeo.com/85995812) также наглядно разъяснил аналогичную проблему.

В тексте той статьи и в комментариях к ней был высказан, а главное — опровергнут тезис, как реализовать данный подход: "Необходимо, чтобы дизайнер был и верстальщиком, и разрабатывал интерфейс сразу как готовую верстку".

Там же, в комментариях были озвучены и другие примеры, говорящие за актуальность описанного подхода — это появившиеся в недавнем времени специализированные продукты. Во-первых, это решения для быстрого создания прототипов веб-страниц, такие как:www.axure.com, http://froont.com. Во-вторых, это программы и сервисы нового поколения, где при визуальной разработке макета, сразу генерится готовая верстка (и в отличие от похожих продуктов "старого поколения", эти решения генерят чистый и лаконичный код, как будто его писал высококлассный верстальщик): http://macaw.co, https://webflow.com.

Продукты для создания прототипов хороши тем, что можно быстро получить визуальный результат, но о лаконичной и чистой верстке, а тем более о полноценных интерфейсах, созданных в них, речи не идет. Решения, которые генерируют качественный код, нельзя назвать простыми, и быстро работать в них не получится. Порой время работы с ними, напротив, соизмеримо или даже дольше, нежели в случае, когда сперва нужно отрисовать графический макет, а затем "вручную" его сверстать. При этом ни в тех, ни в других нет возможности работать над макетом в тех условиях, в которых он будет использоваться (т.е. прямо в браузере, с отсутствующими рабочими элементами редактора). Да и функция автосохранения и хостинга проектов, дающая непрерывный доступ к промежуточному результату третьим лицам (для оценки качества, юзабилити-экспертизы и т.д.), имеется далеко не у всех…

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

Если вас заинтересовала проблематика, описанная в статье, и её решение, в качестве бонуса предлагаем посмотреть вот это короткое видео — http://www.youtube.com/watch?v=nIOVU9_KRKA

Кирилл, руководитель проекта Design and layout solution SketchBuilder

Оригинал статьи на Хабрахабре - http://habrahabr.ru/company/ahoba/blog/240271/

+7
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
VJ-X
Модульная система управления предприятием для малого бизнеса
Ян 38
Интересный материал, спасибо!
Думаю стоит отметить, что проблематика относиться к достаточно сложным проектам. В случае создания небольшого сайта визитки, все значительно проще.
Ответить
GML
Сервис организации ваших интернет линков
GM2mars 10790
Интересный жизненный цикл разработки, где на первом этапе составляют бриф или ТЗ бизнес-аналитик и технический писатель. Ну ладно, бизнес аналитика ещё можно за уши притянуть, но тех писатель что здесь делает?
Обычно составляет ТЗ менеджер продукта (тот кто ответственен за продукт и напрямую общается с заказчиком), а тех. писатель всего лишь готовит документацию к готовому продукту, исходя из ТЗ и готового прототипа, как правило на последних этапах разработки.
Ответить
Кирилл Рассказчиков
Как отметили в первом комментарии - для простых проектов всё проще. Да, при простом сайте, ТЗ\Бриф может составлять и менеджер проектов.

В сложных решениях, больших или удаленных командах, ПМ только руководит постановкой задач и управлением рисками. Над ТЗ\Брифом работает бизнес-аналитик, при этом для формального полного описания задач может привлекаться и технический писатель, который создает внутреннюю документацию с описанием архитектуры проекта, используемых библиотек и т.д. Часто эти функции перекладываются на тим лида, ПМ'а, рядовых разработчиков. И в принципе это не всегда плохо. В общем, всё в большей степени зависит от выбранной методологии управления проектом.
Ответить
Юрий 6443
Извините конечно, но как человек (бизнес-аналитик) без ориентации в технических решениях может составлять ТЗ?
У БА совсем другие задачи, в любом проекте они с сайтом никак не связаны (технической частью). На то он и аналитик, он должен анализировать деятельность бизнес-процессов компании и предлагать решения! А ПМ должен отвечать за продукт в целом, писать ТЗ на доступном языке для тех. специалистов с составление конкретной задачи.
Ответить
Кирилл Рассказчиков
Повторюсь:
Есть разные методологии управления проектами, в разных методология обязанности распределены по разным ролям.

Вы описали вариант, где бизнес-аналитик не пишет ТЗ, есть и такие методологии. Я просто описал другую методологию, где ТЗ - это обязанность бизнес-аналитика.

И я повторюсь - нет плохихи или хороших методологий, нет плохого или хорошего распределения обязанностей по ролям в команде. У каждого подхода есть как свои достоинства, так и не достатки, а так же сфера его эффективного применения.
Ответить
Юрий 6443
как бы да, но в прошлом комментарии вы утверждали что в "сложных решениях" такая схема... Но все же это больше исключение чем правило...
Ответить
Кирилл Рассказчиков
Ну например в методологие PRINCE2, которая как раз расчитана на сложные и большие проекты, эта обязанность и лежит на бизнес-аналитике и техническом писателе. И это не исключение, это правило, в этой формальной методологии.

В другой методологии - MSF, которая применима как для больших, так и для не крупных проектов, напротив, эта обязанность возложена на ПМа и Тим Лида.

И т.д. и т.п., в моём прошлом комментарии, я привел частный случай, а не пытался описать типовые тенденции, для крупных проектов.
Ответить
Юрий 6443
Простите конечно, но я не знаю где вы взяли такую информацию, не хочу вас переубеждать... Но основа методологии PRINCE2 в том что каждый член команды делает то в чем он профи и понимает что от него требуется, там наоборот нет такого что Back-end кодер будет верстать кое как, или СЕОшник тексты писать... Я не знаю лично о таком правиле что BA пишет ТЗ, да такого в требованиях ни к одной вакансии даже нет... В данной методологии вообще BA управляет командой, а он участвует в обсуждении ТЗ (на планерке) но никак не пишет... Ну и конечно те обязаности что я выше писал, управление бизнес процессами и тд... Но да ладно, а MSF - вообще просто пример одного проекта, если завтра Vk например заявит что у него ТЗ копирайтер пишет - так тоже назовем это методологией? :)
Но я скажу так, сейчас грань между PM и BA очень тонка, так как там требуют PM с навыками некоторыми BA, в другом месте наоборот... А сертифицированных спецов PRINCE2 в России/Украине можно на пальцах пересчитать, которые явно не сайтами занимаются :) Но мне бы было интересно если бы вы поделились литературой где сказано что BA пишет ТЗ, прям очень интересно!
Ответить
Кирилл Рассказчиков
Да вот, по второй же ссылке из Гугла неплохая заметка по теме "Чем же отличаются ПМ и БА" - http://www.corpedgroup.com/resources/ba/CareerBA-PMBAConfusion.asp

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

Но соглашусь, мои знания по PRINCE2 и прочим методологиям неподкреплены никакими сертификатами, а основаны на исключительно самостоятельном изучение и использование на практике, так как их понял. Так что я вполне могу ошибаться.
Ответить
Юрий 6443
ну вы немного перекрутили, как я понял:
БА отвечает за конечный продукт, он общается с заказчиком и описывает его требования. Заказчик не скажет что мне надо less, zepto и node.js, он скорее скажет мне нужно там анимация, там цвет, там какой то блок...
Я не знаю какое ТЗ у вас на практике получает программист, верстальщик... Но в большом проекте это конкретное задание с использованием конкретны технологий (так как один верстальщик сделает слайдер на mootools, второй сделает паралакс на jquery, а третий будет использовать less... в итоге "каша" получилась...), а не описание требований.
Но это так же мое понимание. :) Жаль там не конкретизировали, интересно бы было посмотреть описание проекта по этой технологии как это сделали MSF - поделившись опытом...
Просто как минимум странно получить техзадание от человека который не имеет технического образования...
Хотя конечно за границей там все делается именно по инициативе работника, никто над тобой не стоит и не командует, там больше ориентируются на собственную инициативу разработчика, потому возможно что они работают таким методом... Но повторюсь, для меня это была бы странная практика)
Ответить
Кирилл Рассказчиков
Ну не совсем, тут вы упустили такую сущность как Team Lead, который то же участвует в цепочке работ над ТЗ. В общем случаи, работа над ТЗ, по данным методологиям выглядит так:

1. Проект менеджер общается с заказчиком, собирает общий бриф на проект, затем приступает к административным функциям, передав бриф бизнес аналитику.

2. Бизнес аналитик в общем ознакамливается с проектом по брифу, планирует свою работу по анализу и формальному описанию предметной области разрабатываемого решения.

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

4. Системный архитектор, на основе полученной документации проектирует архитектуру будущего программного решения. (Прорабатываю структуру БД, создает диаграмму классов и т.д.)

5. Паралельно с работой системного архитектора, работают и GUI-дизайнеры, юзабилити эксперты верхнего уровня. Они по описаниям от бизнес аналитика проектируют интерфейсы системы, для описанной функциональности.

После чего всё это передается Тим Лиду.

5. Тим Лид анализирует: описание от бизнес-аналитика, диаграммы и схемы от системного архитектора, макеты интерфейсоф от дизайнера. После дополняет их техническими требованиями и спецификациями (выбором технологий и инструментов, на которых всё это будет реализовываться).

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

6. Далее это ТЗ Тим Лидом единолично или совместно с Проект Менеджером разбивается на отдельные таски (задачи для программистов). Готовый таск - это и кусок описание от бизнес аналитика и относящиеся к нему диаграммы и схемы от системного архитектора и дизайн-макеты интерфейсов от дизайнеров.

***
И вот после всего этого и изобрели XP, методологии разработки ПО вообще без создания документации, основываясь только на протатипах и прочий agile :)
Ответить
Юрий 6443
так по вашей же ссылке написано что БА общается с клиентом!
"Business analysts' primary responsibilities are communicating with stakeholders, gathering requirements, and making sense of these requirements in order to ensure that the end products will solve the business problems at hand."
или я не так понял?
Спасибо за подробное описание.
Ответить
Кирилл Рассказчиков
Ну видимо не так уж я и подробно описал, раз ещё остались вопросы :)

Под пунктом №3:
3. Бизнес аналитик, часто совместно с техническим писателем, создают документацию с формальными требованиями, описанием процессов и сущностей системы...

И подразумевалось, что БА не просто изучает предметную область, но и общается с заказчиком, в том числе выявляя его требования и изыскивая решения по их удовлетворению, на выходе давая те самые спецификации и документацию. Об это общении и говорится в статье по ссылке.
Ответить
Дизайн-бюро «Баярд»
Помогаем увеличивать продажи с сайтов
Виталий Кузнецов
Дизайн это решение задачи, как можно говорить протипоставлять Дизайн и верстку? Все равно, что сравнивать машина vs рама.
Ответить
Кирилл Рассказчиков
А вы статью вообще читали? Или ограничились заголовком?

В статье говорится ни о дизайне и верстке в целом, а о их частном случаи: "создание графических дизайн макетов веб-страниц" VS . "создания готовой веб-страницы по графйическому макету" и о том, что эти вещи как раз пора перестать противоставлять, и объеденить в один процесс.
Ответить
Дизайн-бюро «Баярд»
Помогаем увеличивать продажи с сайтов
Виталий Кузнецов
Я дополнил емко :-).
Ответить
Михаил Войцеховский
Любой интерфейс - это всего лишь посредник между человеком и технологией, с которой он взаимодействует. Для того, чтобы убедиться в этом достаточно сравнить самые первые автомобили и концепты последних лет. Но, если в автомобилестроении профессия дизайнера предполагает наличие навыков конструирования со всеми вытекающими, то в искаженном мире цифрового зазеркалья дизайнером может назвать себя любой невежда, освоивший с горем пополам графические пакеты. Мой взгляд на проблему дизайнеров таков: или набор навыков дизайнера определяется как full stack, либо это не дизайнер, а как бы это помягче то сказать.
Как человек может создать интерфейс, совершенно не понимая того, с чем взаимодействует?
Почему дизайнер, придумавший новый гибрид пилы с молотком и гаечным ключом должен иметь представления об эргономике, кинетике, о свойствах используемых материалов, ограничениях накладываемых технологией производства , экономической целесообразности тех или иных решений. А в IT это так? Если бы. Не всякий front-end разработчик понимает, что происходит на сервере. И с каждым годом таких будет становиться все больше и больше. Давно в IT случались прорывные открытия? Да лет 30 назад. Это кризис жанра и деградация, а вы тут все о частностях. Аналитики, usability - неудобно даже, право слово, коллеги.
Что такого существенного за истекшие десятилетия IT принесла в реальный мир: резкий рост числа финансовых спекулянтов, падение уровня грамотности, игровую зависимость с летальными исходами - ведь это все не то, к чему мы стремились?
А вы все о частностях.
Ответить
Кирилл Рассказчиков
Видили какую полемику мы развели с товарищем Юрием выше, о методологиях разработки ПО?

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

НО. Есть ряд методологий, в которых бизнес-аналитик разрабатывает москап будущего интерфейса, отображая на нём всю функциональность, что должна быть в GUI. Затем этот москап передается Юзабилите эксперту, который уже "правильно" распологает все элементы интерфейса, задает им размер и т.д., что бы им было удобно пользоваться. И только после этого москап попадает к дизайнеру, который по сути только "раскрашивает" интерфейс, задавая цвета элементам, добавляя какие-то декаративные вещи. А размер, форму, расположение, механику взаимодействия GUI - всё это уже определили ДО дизайнера. Да и цвета с оформлением, очень часто делаются не по "дизайнерскому" вкусу, а по формальному брифу, в котором описаны цветовая гамма и требования к оформлению, которые составлены другим специалистом, на базе анализа предпочтений и вкусов целевой аудитории.
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.