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