Сообщества вроде «Адовые клиенты!» научили нас, что клиенты в большинстве своём — неадекваты, а правки — неизбежная часть работы дизайнера. Однако, правки можно свести к минимуму, если придерживаться простых правил: работа с ТЗ, итеративный подход и аргументация решений.
Шаг 1: тщательно прорабатываем ТЗ
Перед тем, как начать работать над проектом необходимо убедиться, что для тебя в ТЗ не осталось чего-то непонятного. Не стоит пытаться предугадать мысли и желания заказчика: если есть вопрос лучше его прояснить ещё до начала работы над проектом, чтобы затем не оказалось, что заказчик видит, например, понятие «утончённый дизайн» совсем по-другом, чем ты.
Идеальный вариант — созвониться с клиентом и попросить прокомментировать каждый спорный момент в ТЗ и дополнить документ по итогам разговора. Ещё одна частая история — отсутствующее или неполное техническое задание. Попытки начать работать с туманным запросом в 100% случаев приводит к тому, что дизайнер не попадает в ожидания заказчика, ведь они не были озвучены и, соответсвенно, к шквалу правок.
Поэтому первое, что нужно сделать — помочь клиенту написать/дополнить ТЗ таким образом, чтобы на этот документ можно было опираться в работе и возвращаться к нему в случае спорных ситуаций.
Шаг 2: Разбиваем работу над проектом на итерации
После обсуждения проекта можно сразу приступить к визуальной части, но это не такая хорошая идея, как кажется. Часто этап исследований и проектирования рассматривается как пустая трата времени. Однако работа над портретом целевой аудитории, мудбордом, анализом конкурентов, ресёчем, пользовательским сценарием, CJM, вайрфреймами не только позволяет по-настоящему профессионально решить задачу, но и сведёт количество правок к минимуму.
Дело в том, что условно разделяя работу на 3 этапа: этап исследований, этап проектирования и этап работы над визуальным дизайн мы можем получить фидбэк от клиента после каждого этапа и на основе этого фидбэка скорректировать последующий курс. Например, по результатам этапа исследований составляется мудборд проекта, где дизайнер демонстрирует своё видение того, как будет выглядеть проект с точки зрения визуала.
На этом этапе синхронизируются ожидания от будущего дизайна у клиента и дизайнера и дизайнер по итогам полученного фидбэка может скорректировать визуальный курс ещё до того, как начал делать первые макеты проекта. Соответсвенно, с таким подходом получится не только сэкономить время, но и минимизировать количество правок: если они и будут в дальнейшем, то не такие фатальные, ведь дизайнер будет опираться в работе над визуалом на мудборд, который уже утверждён.
То же самое и с этапом проектирования — на вайрфреймах проще отсмотреть UX-часть и на финальном этапе сосредоточиться уже именно на том, чтобы логику из этапа проектирования соединить с визуалом, утверждённым на этапе исследований. Таким образом, планомерно двигаясь от постановки задачи к её реализации дизайнер находится в постоянном диалоге с клиентом и результат его работы никогда не будет сюрпризом, а значит и правок будет значительно меньше.
Шаг 3: Аргументируем каждое дизайн-решение
Дизайн — это прежде всего решение задач бизнеса, а не творчество, поэтому именно на логику и ресёч стоит опираться в защите проекта перед заказчиком. В дизайне пользовательских интерфейсов свободы для творчества ещё меньше, чем в других отраслях дизайна, так как самое главное качество хорошо сделанного интерфейса — удобство для пользователя, понятность, интуитивность, а значит соответствие пользовательским паттернам.
То есть, например, при проектировании корзины в мобильном приложении стоит опираться на решения, которые используются в наиболее популярных приложениях схожей тематики, чтобы пользователь мог легко и быстро совершить целевое действие. Выбор определённой цветовой палитры, шрифтовой пары, композиции, системы отступов, изображений всегда должен опираться на анализ конкурентов, чтобы пользователю не приходилось заниматься обучением взаимодействию с интерфейсом вместо того, чтобы решать свою задачу (например, заказать доставку, записаться на приём в клинику или занести планы в to-do list).
На практике чаще всего удаётся избежать правок если изначально объяснять клиенту, что всё, что мы делаем направлено на то, чтобы пользователю было максимально комфортно и понятно, поэтому и желание поиграть со шрифтами или перекрасить кнопку пропадает после аргументации, что такие действия приведут к тому, что интерфейсом будет неудобно пользоваться, он будет непонятным, а значит велика вероятность того, что пользователь не будет тратить своё время и найдёт более понятный аналог.
Эти простые шаги помогают работать почти без правок, а если они и возникают, то как правило связаны с тем, что клиент лучше знает свой бизнес и его задачи, поэтому это уже скорее нюансы, а не глобальное «переделывай!», которое случается, если подойти невнимательно к составлению ТЗ, переходить сразу к дизайну итогового визуала и не аргументировать решения с точки зрения логики и принципов дизайна.
