Обеспечение качества дизайна
Хороший опыт клиентов не происходит случайно. В цифровом дизайне продукта, опыт клиента включает все производные от действий команды-разработчика: разработка, дизайн и, не в последнюю очередь, обеспечение качества.
Почему обеспечение качества дизайна имеет значение?
Последовательность — одна из главных принципов хорошего дизайна продукта. Со временем как продукт проектируется и развиваются несоответствия неизбежно всплывают. Со временем это может сложиться и превратиться в “дизайнерский долг».
Дизайнерский долг — это понятие отражающие плохое качество целостности пользовательского интерфейса. Это то, что происходит, когда множество небольших изменений собираются в течение долгого времени и дают несвязанный, непоследовательный опыт.
Хотя может быть сложным, чтобы решить 100% несоответствий, обеспечения качества дизайна (или Design QA — Quality Assurance) является большим шагом на пути решения этой проблемы.
Обеспечение качества дизайна может быть вызовом
Есть и другие фундаментальные недостатки, которые могут сделать обеспечение качества дизайна проблемой:
- Команды или компании не понимают или не ценят дизайн достаточно, чтобы создать процесс, который способствует хорошим результатам проектирования (не трогать то, что работает);
- Люди не видят разницы между дизайном и его плохо закодированной версией (это выглядит достаточно хорошо для меня);
- Основное внимание команд уделяется скорости и доставке функций — и визуальную целостность страдает больше, чем кодирование (у нас нет на это времени).
Скорость против качества
Чтобы уточнить последний момент, поскольку команда разработчиков работает вместе, они иногда рискуют попасть в режим доставки функций. Команды могут упустить из виду общую картину и внимание к деталям, пытаясь закрыть как можно больше функций до окончания этапа разработки. По мере того, как команда мчится до конца сроков и увеличивает скорость, это может создать сценарий, в котором целостность реализации проекта может упасть на обочину в качестве “экономии времени”.
Сотрудничество — это хорошо, но этого недостаточно
Очевидно, что командная работа и сотрудничество являются необходимыми требованиями для команд которые хотят эффективно работать. Совместное проектирование на концептуальном этапе, сопряжение дизайнера и разработчика, использование таких инструментов, как Zeplin, для создания прозрачности и преодоления разрыва между дизайном и CSS; все это здорово и помогает, но они не заменяют прямого сотрудничества дизайнера и разработчика.
Это то место где начинается обеспечение качества дизайна
Что такое дизайн QA
QA (QA = обеспечение качества) просто шаг в процесс между развитием и испытанием. Это шанс для дизайнера проверить реализацию его концепции, он включает:
- Ревью закодированной версии пользовательского интерфейса перед тестированием;
- Совместная работа с разработчиками для обновления пользовательского интерфейса.
Возможно, вы работаете в такой компании, как Pivotal, где дизайнеры и разработчики проводят все рабочее время вместе, а обеспечение качества дизайна уже встроено в рабочий процесс. Если нет, то дизайнеру и конечной концепции пользовательского интерфейса очень легко потерять свое место в процессе.
Обеспечение качества дизайна, как часть рабочего процесса
Как обеспечить целостность дизайна в таком рабочем процессе? Когда функция выполняется в разработке, обычно Разработчик, работающий над этой функцией, или менеджер продукта перемещают её в тестирование. Конечно, команды могут привыкнуть пытаться сделать какую-то версию QA, не имея отдельного шага в этом процессе, но это быстро ломается; люди забывают или решают для себя, что реализация дизайна и так достаточно хороша.
Более важный вопрос: если реализация дизайна необходима, почему бы нам просто не сделать шаг для этого?
Обеспечение качества дизайна стоит сделать отдельным шагом в этом процессе, который нельзя пропустить. Это также признание того, что реализация дизайна является важной частью процесса, который ценит команда. Когда мы учитываем обеспечение качества дизайна в процессе, рабочий процесс, упомянутый выше, теперь будет выглядеть так.
Включение разработчиков в процесс дизайна
Так же, как это помогает для дизайнеров, чтобы быть вовлеченным, когда проекты кодируются, это также хорошее решение, чтобы включить разработчиков в процессе проектирования.
Дизайн и разработка — это две стороны одной медали, и чем более изолированными они являются друг от друга, тем более сложным будет весь процесс.
Чтобы включить разработчиков в процесс проектирования, можно выполнить следующие действия:
- Обсудите требования функции перед началом проектирования, чтобы выяснить технические детали, которые могут повлиять на проектные решения
- Вместе создайте исходные проектные решения
- Обеспечьте связь между дизайнерам и разработчиками на протяжении всего процесса, для получения обратной связи.
Так большинство проблем, с которыми мы сталкиваемся в проектировании и разработке продукта, могут быть решены с взаимным уважением, общением и честностью.