На Хабрахабре уже не раз поднимался вопрос о том, что популярные на сегодняшний день жизненные циклы разработки веб-интерфейсов, прямо говоря, устарели. Последний раз его обсуждали в публикации «Дизайн в браузере», но так и не пришли к единому мнению.
Настало время наконец-то найти ответы на два главных вопроса: “Кто виноват?” и “Что делать?” в вечной борьбе дизайна и верстки…
Типовой жизненный цикл разработки веб-интерфейсов
Начать статью стоит с рассмотрения вопроса о том, как собственно происходит разработка веб-интерфейсов, кто в ней участвует, что конкретно делает и за что отвечает. Существуют десятки методологий, по которым строится жизненный цикл разработки веб-интерфейсов, но их всех объединяют базовые этапы:
Этап первый: Создание формальных требований на разрабатываемый интерфейс. Конечный результат этого этапа — бриф или техническое задание, где описано, что должно быть на макете, и как это будет реализовано. Занимаются этим люди с проектными ролями: бизнес-аналитик, технический писатель;
Этап второй: Разработка графического дизайн-макета по брифу или ТЗ. Данную работу выполняет дизайнер (веб-дизайнер, дизайнер GUI);
Этап третий: Верстка интерфейса (создание htmlcssJS кода) по графическому дизайн-макету. Над версткой работает верстальщик (фронтенд разработчик, веб-разработчик).
Ограничиться базовыми этапами и получить высококлассный результат можно, пожалуй, только в “сферических условиях в вакууме”. На практике на каждом этапе возникает ряд проблем, решать которые приходится, вводя подэтапы и усложняя жизненный цикл разработки интерфейса.
Примерами проблем и возникающих по их вине подэтапов могут быть:
- Отсутствие общего видения или непонимание предметной области — ограничиться текстовым описанием в брифе или ТЗ не получится. Необходимо будет создать несколько прототипов, провести дополнительные исследования.
- Приятно выглядящий интерфейс может оказаться неудобным в использовании. Чтобы этого избежать приходится привлекать к работе юзабилити-специалиста и проводить дополнительную экспертизу на предмет удобства использования и т.д.
Подробнее о возникающих проблемах и способах их решения поговорим ниже, начав с вопроса объективности оценки качества дизайн-макетов.
Проблема формальной оценки дизайна
Под разработкой дизайна веб-интерфейсов подразумевают работу по проектированию взаимодействия и оформлению внешнего вида веб-страниц. Внешний вид удобно передать в графическом дизайн-макете. Т.е. работа над дизайном сводится к созданию макета.
Оценка макета, по большому счету, субъективна. Часто строится на таких эпитетах, как красиво, нравится, приятный, аккуратный, и их вариантами с приставкой “не”… Качество макета оценивается по личным предпочтениям. Встает вопрос: а можно ли вообще формально оценить макет по субъективным критериям? Можно. И самый действенный способ — тестирование на фокус группе: набирается группа людей из целевой аудитории, для которой разрабатывается макет, проводится его демонстрация, после чего участники исследования заполняют анкеты-опросники, выставляя оценки исходя из своего личного мнения по этим субъективным параметрам. Среднестатистическое значение — адекватная оценка качества макета.
Часто ли на практике происходит такое тестирование на фокус группе? К сожалению, очень редко. Обычно всё сводится к согласованию личного мнения дизайнера и заказчика. При этом, по опыту, как исполнитель не всегда может адекватно оценивать свою работу, так и заказчик имеет бесполезное или даже вредящее качеству мнение. В итоге страдает конечный пользователь, ради которого, казалось бы, и делается макет.
Другой подход к формальной оценке макета основан на принципах взаимодействия с пользователями, которые иногда называют “Принципами Стива Джобса”:
Разработчики не считаются с мнением пользователей, сами определяя то, что нужно пользователю, т.к. разработчики — это эксперты и профессионалы, видящие ситуацию в целом и адекватно, а конечные пользователи в большинстве случаев сами не знают, чего хотят, и способны лишь наслаждаться результатом, который удовлетворяет их потребности, о которых они ранее и не подозревали.
По этим принципам в начале эпохи домашних компьютеров создавались решения от Apple, превратившие в произведение дизайнерского искусства эти самые ПК, в противовес “квадратно-практичному” внешнему виду продуктов конкурентов. Потребители сами не догадывались, что им понравится тот факт, что такая утилитарная вещь, как компьютер, может быть стильным дизайнерским решением. Но увидев реализацию, созданную дизайнерами, не считавшимися с мнением потребителя, все же положительно оценили её. Впрочем, это другая история, вернемся к разработке внешнего вида веб-страниц…
Да, многие дизайнерские студии работают над оценкой макетов по схожим принципам, без всяких фокус групп из представителей ЦА, самостоятельно определяя, каким должен быть макет, и получая в итоге очень удачный и качественный результат. Происходит всё то же самое, что и с фокус группой, только здесь собирается экспертная группа, состоящая из нескольких опытных дизайнеров, работающих в той же области, им также презентуется макет, и происходит его оценка.
Но, опять же, как часто на практике собираются экспертные группы, состоящие еще хоть из кого-нибудь, кроме исполнителя-дизайнера и заказчика? Кажется, мы об этом уже говорили…
Формальная оценка качества дизайн-макета возможна, но на деле редко осуществима. Любая индивидуальная оценка — субъективна, и это помимо прочих проблем разработки веб-интерфейсов…
Несоответствие ощущений от графического макета и сверстанной веб-страницы
Проблема, озвученная в подзаголовке, хорошо известна в среде веб-дизайнеров:
Как бы качественно и детально ни был отрисован макет, он остается графическим изображением, иногда его ещё называют “мертвым” макетом. Даже если вы разрабатываете дизайн веб-страницы, где нет динамических элементов (раскрывающихся меню, меняющихся по клику теней и т.д.), все равно ваш макет по ощущениям отличается от конечной, сверстанной страницы (даже на статике можно выделить текст, проскроллить и прочее).
Касается эта проблема и удобства использования. Частично юзабилити-экспертизу можно провести и по графическому макету (оценив расположение и компоновку элементов и т.д.), но полноценно понять, насколько удобным оказался интерфейс, выявить все подводные камни в работе с ним, можно только по конечной, готовой веб-странице.
Сюда же идет и ещё одна беда как дизайнеров, так и верстальщиков — отсутствие контента. Порой в брифе написано: “здесь на странице текст, а здесь — картинка”. А что это за текст, какого он размера, сколько абзацев и заголовков в нём; что там за картинка, в какой она цветовой гамме, какие у нее пропорции — не указано. Тогда приходится в дизайн-макете использовать “рыбу” (заглушки) — сторонние тексты, картинки. Иногда их же приходится применять и при верстке. А после, когда на странице размещается уже конечный, рабочий контент, ужасаться конечному результату,
Выходит, даже если изначально дизайн-макет оценивался положительно, оценка конечного результата может сильно поменяться в худшую сторону.
Как можно было бы избежать всех этих проблем при разработке веб-интерфейсов
Что мы имеем в итоге? Озлобленных дизайнеров, рисующих N’ую версию макета и правомерно заявляющих: “нужно более формально задавать требования к макету”. Не менее раздраженных верстальщиков, переверстывающих страницу в M’ый раз. Дополняют эту картину растянувшиеся сроки, проваленные дедлайны, превышенные бюджеты и извечные вопросы “Кто виноват?” и “Что делать?”
Всего этого можно было бы избежать, если изменить типовую модель жизненного цикла разработки веб-интерфейсов. После небольшой корректировки, она выглядела бы так:
Этап первый: Подготовка контента;
Этап второй: Создание краткого брифа с описанием функциональности и формальных требований к разрабатываемому интерфейсу;
Этап третий: Быстрая разработка интерфейса в тех условиях, где он будет использоваться (прямо в браузере), сразу верстая его как готовую веб-страницу, с непрерывной экспертной и юзабилити оценкой.
Все проблемы исчезают сами по себе, конечный результат всегда на высоком уровне, в дополнение — сроки и расходы на разработку сокращаются в несколько раз, по сравнению с существующими типовыми жизненными циклами разработки веб-интерфейсов. Спрашивается, почему все до сих пор не пользуются такой удачной схемой? На самом деле, как раз сейчас такой подход набирает обороты.
Об этом говорилось в статье, ссылку на которую мы дали в начале поста (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
Кирилл,
руководитель проекта Ahoba.co
В соавторстве с нашим дизайнером Сергеем Sevenvampire и веб-разработчиком Антоном skrutty.
Автор: JackHammeret
