40% багов на верстке можно избежать: сплит-тестирование

Расскажем три истории экспериментов с тестированием макетов: как, зачем и чем это все заканчивалось.

Это был крупный проект. Заказчик хотел реализовать много фич каталога, дополнительных сервисов и визуальных решений. Количество макетов росло в геометрической прогрессии.
Тогда мы решили провести эксперимент — взяли аналитика и QA-менеджера. Аналитик протестировал дизайн-макеты, т. к. он в контексте проекта делал прототипы, QA-менеджер — верстку. Баг-листы совпали на 40%. Значит, почти половины багов при верстке можно было избежать еще на этапе дизайна.

Как проходило тестирование
1. Аналитик протестировал макеты: проверял соответствие бэклогу и прототипу (смета на подстраховке) и юзабилити элементов дизайна.

2. Собрал в баг-лист баги и предложения по улучшению, передал все менеджеру проекта.

3. Менеджер передал правки в макете дизайнеру и, если нужно, согласовал с клиентом.

4. Баги поправили, юзабилити улучшили.

5. Макет сверстали.

6. Завершал процесс QA-менеджер, который тестировал верстку и принимал баг-листы по мере исправления багов.

7. Готово, можно собирать.

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

1. Старая логика, старый макет
Чтобы вписать новый дизайн-макет в общую дизайн-концепцию сайта, мы взялись тестировать макеты, с которыми пришел заказчик, чтобы убедиться, что они соответствуют друг другу. Параллельно менеджер проекта прошелся по макету, как пользователь. Собрали 200 строк баг-листа, 20 из них — ошибки в бизнес-логике. Макеты были со сложным юзабилити, непонятными стейтами и неочевидным для пользователя алгоритмом сервиса, который предполагал определенный порядок действия.

2. Старая логика, новый макет
Мы перерисовали макеты так, чтобы и новый дизайн-макет вписывался в общий дизайн сайта, и чтобы избежать тех ошибок в бизнес-логике. Дизайн разросся с 14 страниц до 24. Юзабилити улучшилось, но сервисом было все еще было сложно пользоваться. Тем временем на стороне клиента сменился менеджер, курирующий проект. Вместе с ним мы пришли к общему выводу, что нужно менять все: и логику, и дизайн.

3. Новая логика, новый макет
Проработав совместно логику и дизайн, вместо 28 страниц мы уложились в 7.

Заказчик прислал нам 2 Гбайта макетов (для сравнения: наши 400 Мбайт обычно занимают). Проект был не просто большой, он был огромный и сложный. К примеру, вся правая панель состоит из 25 элементов, часть из которых — геозависимые. Дизайн уже обошелся заказчику очень дорого и мы все понимали, что без теста макетов верстать нельзя. Работали мы с дизайнером заказчика до и во время верстки, что неизбежно затягивало сроки спринтов.

С какими проблемами мы столкнулись:

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

Клиент: Иконки SVG лежат в папке Advantages Block
Сибирикс: Коллеги, svg-иконки лежат в разных папках. Как узнать нужные?

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

Клиент: Слетели кнопки «Успейте купить», «Количество ограничено»
Сибирикс: Это не кнопки. Кнопки на месте. Вероятно мы недопоняли что значит «слетели»)) Прокомментируете?
Клиент: Съехали))

• У нас разный формат работы
  Сторонний дизайнер работал, следуя своей логике, мы — своей. Это приводило к тому, что не совпадали понятия, не было четкого понимания, как это все верстать и собирать.

(о странице категории каталога)
Дизайнер клиента: Переработан макет на 2, 3, 4 подкатегории. 5, 6, 7 и более подкатегорий реализуются дублированием вариантов, например 5=1+2+2, 6=3+3, 7=1+3+3, 8=2+2+2+2, 9=3+3+3, 10=1+3+3+3.
Сибирикс: Нет никакой закономерности в формировании для 5 и более категорий с таким подходом. Почему 5=1+2+2, а не 2+3 или 1+4. И почему 4 вообще в формировании не участвует. Пожалуйста, поясните какова система?

• Баги в бизнес-логике
  При тестировании макетов находили ошибки, которые влияли на бизнес-логику. Это значит, что нужно было менять и макеты, и техническое задание к дизайну.

Клиент: Убрать информационный блок в первом ряду товаров. Оставить только во втором ряду, четвертом, шестом и т.д.
Сибирикс: Просто не выводить — неправильно. Сетка рассчитана на определенное количество элементов. Прошлую логику мы разработали совместными усилиями на этапе ТЗ. Уверены что хотите от нее отказаться? Клиент: Да, логику меняем.

• Дизайн оказался не рассчитан на мобильную версии

Клиент: При клике на стрелку должен быть переход к следующему цвету и товару в этом цвете. Т.е. шаблон «цвет+товар в этом цвете» должен быть единым.
Сибирикс: На мобилках не получится выводить одновременно и товар, и цвет товара — мало места. Для планшетов уже сделали вывод двух изображений в одном слайде, так как место позволяет.

• Дизайн не утвержден окончательно
  Пока тестировали макет, клиенту переставал нравиться дизайн, что приводило к мелким, но регулярным изменениям некоторых визуальных элементов.

Клиент: Предложение месяца – смайлик изменить на малиновый.
Сибирикс: Вы замените иконку сами или нам нужно отрисовать ее?
Клиент: Было бы хорошо если бы вы сами ее отрисовали и заменили.

Это лишь несколько затруднений из теста стороннего макета. На практике их намного больше.

Что чаще всего теряется при отрисовки дизайна:

• подсказки;
• иконки;
• блоки;
• контент этих блоков;
• мелкие элементы, входящие в состав больших (например, картинка-анонс к статье содержит теги, имя автора, дату, время, название статьи и пр.);
• блок в формате слайдера (а не в виде плитки);
  
• адаптивный дизайн.
  

Формы на сайте

Фильтры

Юзабилити интернет-магазинов

Юзабилити сайта

Пре-лонч проекта