40% багов на верстке можно избежать: сплит-тестирование
Как мы тестировали собственные и сторонние дизайн-макеты
Расскажем три истории экспериментов с тестированием макетов: как, зачем и чем это все заканчивалось.
Нечего на программистов гнать.
Рыба гниет в начале конвейера.
Рыба гниет в начале конвейера.
Владимир Завертайлов
CEO «Сибирикс»
История 1: сплит-тестирование собственных проектов
Это был крупный проект. Заказчик хотел реализовать много фич каталога, дополнительных сервисов и визуальных решений. Количество макетов росло в геометрической прогрессии.
Тогда мы решили провести эксперимент: взяли аналитика и QA-менеджера. Аналитик протестировал дизайн-макеты, т.к. он в контексте проекта делал прототипы, QA-менеджер — верстку. Баг-листы совпали на 40%. Значит, почти половины багов при верстке можно было избежать еще на этапе дизайна.
Как проходило тестирование
1. Аналитик протестировал макеты: проверял соответствие бэклогу и прототипу (смета на подстраховке) и юзабилити элементов дизайна.
2. Собрал в баг-лист баги и предложения по улучшению, передал все менеджеру проекта.
Тогда мы решили провести эксперимент: взяли аналитика и QA-менеджера. Аналитик протестировал дизайн-макеты, т.к. он в контексте проекта делал прототипы, QA-менеджер — верстку. Баг-листы совпали на 40%. Значит, почти половины багов при верстке можно было избежать еще на этапе дизайна.
Как проходило тестирование
1. Аналитик протестировал макеты: проверял соответствие бэклогу и прототипу (смета на подстраховке) и юзабилити элементов дизайна.
2. Собрал в баг-лист баги и предложения по улучшению, передал все менеджеру проекта.
Пример баг-листа из теста дизайн-макетов
3. Менеджер передал правки дизайнеру и, если нужно, согласовал с клиентом.
4. Баги поправили, юзабилити улучшили.
5. Макет сверстали.
6. Завершил процесс QA-менеджер, который тестировал верстку и принимал баг-листы по мере исправления багов.
7. Готово, можно собирать.
4. Баги поправили, юзабилити улучшили.
5. Макет сверстали.
6. Завершил процесс QA-менеджер, который тестировал верстку и принимал баг-листы по мере исправления багов.
7. Готово, можно собирать.
Вывод
Расхождения макета дизайна с прототипом есть и будут в 100 случаях из 100. Тестирование — это не только их сверка, это и субъективное мнение QA-менеджера или аналитика по части юзабилити. Сказываются опыт и здравый смысл. Дизайнеры нарисуют красиво — бесспорно, но пользовательский опыт тоже важная часть сайта.
История 2: тестирование стороннего дизайн-макета
Проект мы разрабатывали с нуля. Через некоторое время у заказчика появился новый сервис и его необходимо было реализовать на сайте. За помощью обратились к нам, но пришли не с пустыми руками, а с готовыми логикой сервиса и макетами от стороннего дизайнера.
Далее произошли три события:
Далее произошли три события:
- Старая логика, старый макет
Чтобы вписать новый дизайн-макет в общую дизайн-концепцию сайта, мы взялись тестировать макеты, с которыми пришел заказчик, чтобы убедиться, что они соответствуют друг другу. Параллельно менеджер проекта прошелся по макету, как пользователь. Собрали 200 строк баг-листа, 20 из них — ошибки в бизнес-логике. Макеты были со сложным юзабилити, непонятными стейтами и неочевидным для пользователя алгоритмом сервиса, который предполагал определенный порядок действия.
- Старая логика, новый макет
Мы перерисовали макеты так, чтобы и новый дизайн-макет вписывался в общий дизайн сайта, и чтобы избежать тех ошибок в бизнес-логике. Дизайн разросся с 14 страниц до 24. Юзабилити улучшилось, но сервисом было все еще было сложно пользоваться. Тем временем на стороне клиента сменился менеджер, курирующий проект. Вместе с ним мы пришли к общему выводу, что нужно менять все: и логику, и дизайн. - Новая логика, новый макет
Проработав совместно логику и дизайн, вместо 28 страниц мы уложились в 7.
Вывод
Логика и дизайн неотъемлемы друг от друга — это раз. Обязательно тестировать дизайн-макет на юзабилити, особенно сложные продукты — это два. Делать все этапы проекта одной командой для экономии времени и денег — это три.
История 3: как мы верстали и собирали сайт по чужому дизайну
Заказчик прислал нам 2 Гбайта макетов (для сравнения: наши 400 Мбайт обычно занимают). Проект был не просто большой, он был огромный и сложный. К примеру, вся правая панель состоит из 25 элементов, часть из которых — геозависимые. Дизайн уже обошелся заказчику очень дорого и все мы понимали, что без теста макетов верстать нельзя. Работали мы с дизайнером заказчика до и во время верстки, что неизбежно затягивало сроки спринтов.
С какими проблемами мы столкнулись:
1. Глухой телефон
Если чего-то не хватало в дизайне, нужно было просить это дорисовать. Схема была такой: программист — менеджеру, менеджер — менеджеру на стороне клиента, менеджер на стороне клиента — подрядчику-дизайнеру, и затем в обратную сторону.
2. Забрать файлы от заказчика
Т. к. дизайнер находился не в студии, мы часто не могли оперативно найти нужные нам файлы: было непонятно, к какому блоку или странице они принадлежат.
Клиент: Иконки SVG лежат в папке Advantages Block.
Сибирикс: Коллеги, svg-иконки лежат в разных папках. Как узнать нужные?
3. У нас разный уровень компетенции
Заказчик не обязан быть дизайнером или программистом, ему не нужно знать технические термины и особенности формулировки ошибки. Однако это усложнило общую работу: мы разговаривали на разных языках.
Клиент: Слетели кнопки «Успейте купить», «Количество ограничено».
Сибирикс: Это не кнопки. Кнопки на месте. Вероятно, мы недопоняли: что значит «слетели». Прокомментируете?
Клиент: Съехали))
4. У нас разный формат работы
Сторонний дизайнер работал, следуя своей логике, мы — своей. Это приводило к тому, что не совпадали понятия, не было четкого понимания, как это все верстать и собирать.
(о странице категории каталога)
Дизайнер клиента: Переработан макет на 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 вообще в формировании не участвует. Пожалуйста, поясните какова система?
5. Баги в бизнес-логике
При тестировании макетов находили ошибки, которые влияли на бизнес-логику. Это значит, что нужно было менять и макеты, и техническое задание к дизайну.
Клиент: Убрать информационный блок в первом ряду товаров. Оставить только во втором ряду, четвертом, шестом и т.д.
Сибирикс: Просто не выводить — неправильно. Сетка рассчитана на определенное количество элементов. Прошлую логику мы разработали совместными усилиями на этапе ТЗ. Уверены что хотите от нее отказаться?
Клиент: Да, логику меняем.
6. Дизайн оказался не рассчитан на мобильную версию
Клиент: При клике на стрелку должен быть переход к следующему цвету и товару в этом цвете. Т.е. шаблон «цвет+товар в этом цвете» должен быть единым.
Сибирикс: На мобилках не получится выводить одновременно и товар, и цвет товара — мало места. Для планшетов уже сделали вывод двух изображений в одном слайде, так как место позволяет.
7. Дизайн не утвержден окончательно
Пока тестировали макет, клиенту переставал нравиться дизайн, что приводило к мелким, но регулярным изменениям некоторых визуальных элементов.
Клиент: Предложение месяца – смайлик изменить на малиновый.
Сибирикс: Вы замените иконку сами или нам нужно отрисовать ее?
Клиент: Было бы хорошо если бы вы сами ее отрисовали и заменили.
Это лишь несколько затруднений из теста стороннего макета. На практике их намного больше.
С какими проблемами мы столкнулись:
1. Глухой телефон
Если чего-то не хватало в дизайне, нужно было просить это дорисовать. Схема была такой: программист — менеджеру, менеджер — менеджеру на стороне клиента, менеджер на стороне клиента — подрядчику-дизайнеру, и затем в обратную сторону.
2. Забрать файлы от заказчика
Т. к. дизайнер находился не в студии, мы часто не могли оперативно найти нужные нам файлы: было непонятно, к какому блоку или странице они принадлежат.
Клиент: Иконки SVG лежат в папке Advantages Block.
Сибирикс: Коллеги, svg-иконки лежат в разных папках. Как узнать нужные?
3. У нас разный уровень компетенции
Заказчик не обязан быть дизайнером или программистом, ему не нужно знать технические термины и особенности формулировки ошибки. Однако это усложнило общую работу: мы разговаривали на разных языках.
Клиент: Слетели кнопки «Успейте купить», «Количество ограничено».
Сибирикс: Это не кнопки. Кнопки на месте. Вероятно, мы недопоняли: что значит «слетели». Прокомментируете?
Клиент: Съехали))
4. У нас разный формат работы
Сторонний дизайнер работал, следуя своей логике, мы — своей. Это приводило к тому, что не совпадали понятия, не было четкого понимания, как это все верстать и собирать.
(о странице категории каталога)
Дизайнер клиента: Переработан макет на 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 вообще в формировании не участвует. Пожалуйста, поясните какова система?
5. Баги в бизнес-логике
При тестировании макетов находили ошибки, которые влияли на бизнес-логику. Это значит, что нужно было менять и макеты, и техническое задание к дизайну.
Клиент: Убрать информационный блок в первом ряду товаров. Оставить только во втором ряду, четвертом, шестом и т.д.
Сибирикс: Просто не выводить — неправильно. Сетка рассчитана на определенное количество элементов. Прошлую логику мы разработали совместными усилиями на этапе ТЗ. Уверены что хотите от нее отказаться?
Клиент: Да, логику меняем.
6. Дизайн оказался не рассчитан на мобильную версию
Клиент: При клике на стрелку должен быть переход к следующему цвету и товару в этом цвете. Т.е. шаблон «цвет+товар в этом цвете» должен быть единым.
Сибирикс: На мобилках не получится выводить одновременно и товар, и цвет товара — мало места. Для планшетов уже сделали вывод двух изображений в одном слайде, так как место позволяет.
7. Дизайн не утвержден окончательно
Пока тестировали макет, клиенту переставал нравиться дизайн, что приводило к мелким, но регулярным изменениям некоторых визуальных элементов.
Клиент: Предложение месяца – смайлик изменить на малиновый.
Сибирикс: Вы замените иконку сами или нам нужно отрисовать ее?
Клиент: Было бы хорошо если бы вы сами ее отрисовали и заменили.
Это лишь несколько затруднений из теста стороннего макета. На практике их намного больше.
Вывод
Если работаете с дизайн-макетами стороннего дизайнера, их тестирование обязательно. В идеале не браться за проект вовсе, т. к. процесс выяснений, изменений, уточнений занимает слишком много времени и сил. Внутри компании коммуникация протекает быстрее, потому и вопросы решаются на лету.
Мини чек-лист теста макетов
Что чаще всего теряется при отрисовки дизайна:
- подсказки;
- иконки;
- блоки;
- контент этих блоков;
- мелкие элементы, входящие в состав больших (например, картинка-анонс к статье содержит теги, имя автора, дату, время, название статьи и пр.);
- блок в формате слайдера (а не в виде плитки);
- адаптивный дизайн.
От ошибок никто не застрахован. Ни тестировщики, ни дизайнеры. У нас есть подробные чек-листы на разные случаи жизни, и те спасают не всегда. А «чужие» макеты — это всегда риски. Скрытые и коварные. Как минимум, макеты нужно проверять на связность и бизнес-логику. Как максимум — на соответствие дизайн-системе, системе отступов, наличию ховеров и всех необходимых элементов. Это очень трудоемко и нет алгоритма, который гарантированно обеспечит 100% выявление нестыковок. И да, доделывать за кем-то всегда сложнее, чем делать с нуля. Рисковать или нет — вопрос ну, очень интересный.
Владимир Завертайлов
CEO «Сибирикс»
Еще полезные чек-листы