В мире, где все стремятся к новизне, само по себе слово “шаблон” имеет негативную окраску. Шаблонное выражение, шаблонное мышление, шаблонный метод — эти фразы вызывают отрицательные мысли.
Шаблон воспринимается как ненастоящий документ. Если ты использовал шаблон, то будто бы позволил себе слабость, в то время как настоящая работа — создавать уникальные документы с узкой направленностью.
Никто не любит шаблоны, потому что они обычно затыкают дырки каких-то быстрых однотипных действий, которые никто не хочет делать.
Шаблон — эталон качества. Он должен быть понятным, красивым, структурным документом, с которым хочется работать. Его главная цель - быстро и незаметно закрывать важные задачи.
Если ставить перед собой цель сделать отличный документ, который принесет масштабируемую пользу, то в этом и может быть смена парадигмы в восприятии поставленной задачи, а именно: делать продукт, который состоит из документа, глубоко понимая при этом, как с документом работают люди.Мы продуктовая команда, поэтому при подготовке шаблона используем продуктовый подход Jobs To Be Done. Это означает, что мы непрерывно думаем про успех конечного пользователя, который в итоге будет заполнять документ. С продуктом должно быть удобно работать, а проблемы пользователя нужно свести к нулю и помочь ему максимально эффективно достигнуть желаемого результата.
Jobs To Be Done — метод, позволяющий выяснить, какие задачи ваш продукт будет решать для клиента. То есть, почему пользователь решает «нанять продукт на работу».
Какие составляющие подхода JTBD можно применить к подготовке шаблона?
Чтобы пользователь испытывал позитивные эмоции при работе с документом, документ должен быть как минимум ему симпатичен. Сравнивая ощущения между двустраничным документом 8-м шрифтом без воздуха между абзацами и структурным текстом с хорошо подобранными шрифтами, полями и отступами, сразу становится понятно, где пользователь почувствует себя плохо, а где — хорошо.
Мы применяем концепцию Legal design, основными составляющими которой являются хорошая 1) форма и 2) содержание документа.
К сожалению, корпоративные требования клиентов обычно запрещают нам перерабатывать содержание. Поэтому мы чаще работаем именно с формой. Первое, что делают LegalTech-юристы, получая документ от клиента — перерабатывают его формат в наши собственные стили.
Так выглядит набор стилей нашей команды:
Если пользователь будет работать с шаблоном в ворде, подумайте, сколько лишних действий ему придется выполнить? Можно ли их сократить? Например, если можно избежать постановки квадратных скобок, не ставьте их, чтобы по завершении работы пользователю не приходилось их вычищать. Просто разметьте вариативность цветом — ее будет удобно снять одним действием, выделив весь текст и сняв заливку.
Если предполагается вариативность, то создавайте ее в абзацах: так удобнее выделять и удалять ненужный абзац, чем вычищать вариативные кусочки из сплошного параграфа.
Примечания по заполнению лучше оставлять в комментариях, а не в сносках — так их удобнее будет удалить одним действием через вкладку «рецензирование», «удалить все комментарии».
Соблюдайте гигиену форматирования. Нужно помочь пользователю работать быстро, и с этим поможет хороший формат. Если нумерованные части документа могут исчезать в зависимости от условий сделки, то нумерация должна быть автоматической, чтобы не перенумеровывать вручную поехавшие абзацы.
Мы все еще встречаем шаблоны, где нумерация сделана полностью вручную. Например, недавно мы столкнулись с проблемой 250 документов одного клиента, которые невозможно было переработать. Каждый документ состоял из 70−80 страниц, а нумерация в нем — два, точка, два пробела; два-один, точка, два пробела
При форматировании табличной части рекомендуем создавать отдельную ячейку для каждого абзаца. В первую очередь это относится к двуязычным документам, которые создаются при помощи таблицы из двух колонок с невидимыми границами. Текст на русском и английском языках имеет разный объем и поэтому визуально не будет соответствовать друг другу. Поэтому важно соблюдать принцип 1 абзац=1 ячейка, чтобы удобно было как читать документ, так и редактировать его.
Тот же принцип стоит применять к реквизитам, подписным блокам, месту и дате в преамбуле — все эти компоненты договора обычно создаются при помощи таблиц.
Сплошной текст в таблицах выглядит нечитабельным:
Таблица, которая дышит:
Подумайте о том, в каких условиях будет использоваться документ? Кто будет его заполнять — линейный сотрудник или юрист, какими знаниями он обладает, чтобы быстро справиться с задачей? Если условия сделки позволяют конечному пользователю потратить достаточное количество времени на подготовку документа, то можно составить большой документ с детальной вариативностью. Если сотруднику нужно отработать задачу молниеносно, то лишняя вариативность и поля будут только мешать. В таком случае будет более эффективным создать набор одинаковых предзаполненных шаблонов, в которых пользователю нужно самостоятельно внести буквально пару штрихов, чтобы получить готовый документ.
Нужно регулярно анализировать, как команда использует шаблон после создания и дорабатывать его, учитывая пользовательский опыт. «Дебажить», как говорят программисты. Разработали шаблон — запустите А/В тесты (то есть разные варианты, что из этого лучше сработает).
Покажите шаблоны людям. Понаблюдайте, как пользователь их заполняет. Спросите коллег, проведите коридорный тест перед запуском. Иначе впоследствии это может вылиться в непонимание пользователем требований к заполнению критичных положений документа и его возврат с согласования. Вы же сами вернете шаблон на доработку, если пользователь что-то не поймет. А в худшем случае, если сделка срочная, вам самостоятельно придется заниматься форматированием или исправлением некорректных положений.
