{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

К шаблонам с любовью или Love your templates

Наталья Никулина
Product Manager и Team Lead онбординга команды Doczilla

О проблеме

Мы регулярно получаем заказы на автоматизацию, при этом документы нередко находятся в плачевном состоянии. Бывает и так, что текст представляет собой свалку типовых положений. В таких документах прослеживается, что задача состояла не в том, чтобы сделать хороший шаблон, а чтобы попросту уместить его на одной странице. Поэтому текст разъезжается по полям, шрифт уменьшается до нечитаемого, а документ выглядит так, будто по нему проехались утюгом.

В мире, где все стремятся к новизне, само по себе слово «шаблон» имеет негативную окраску. Шаблонное выражение, шаблонное мышление, шаблонный метод — эти фразы вызывают отрицательные мысли.

Шаблон воспринимается как ненастоящий документ. Если ты использовал шаблон, то будто бы позволил себе слабость, в то время как настоящая работа — создавать уникальные документы с узкой направленностью.

Конечные пользователи

Шаблоны никто не любит заполнять: это квадратные скобки, желтая заливка, достаточно неприятное количество копипасты, перепроверка за собой, удаление примечаний, сносок и прочих лишних частей. А если работа происходит в ворде, то это постоянное ощущение необходимости соблюдать рамки: это можно, а это нельзя. Поэтому работа с шаблонами зачастую воспринимается как обязанность, а не как способ решить свою задачу при помощи готового образца без необходимости что-то придумывать.

В этом примере пользователю придется прибраться за собой после заполнения

Согласованты

С точки зрения согласующих шаблоны не любят, потому что шаблон вроде бы существует, но тем не менее приходится проверять, не нарушил ли сотрудник какие-то регламенты и не влечет ли его финальный документ рисков для компании. Проверкой мало кто любит заниматься.

Создатели

Разрабатывать шаблоны тоже мало кто любит — приходится тратить время, чтобы спроектировать документ, укладывать логику и потом поддерживать документ в актуальном состоянии. Все хотели бы вместо шаблонов заняться более креативной работой.

Никто не любит шаблоны, потому что они обычно затыкают дырки каких-то быстрых однотипных действий, которые никто не хочет делать.

Как все изменить?

Как правило, стремление делать шаблоны качественно отсутствует потому, что сотрудники не видят в них ценность. Все хотели бы, чтобы шаблоны не отнимали ни у кого времени и незаметно решали свою задачу.

Если исходить из ценности, то стоит заглянуть в этот вопрос поглубже. Ведь типовая форма появляется не просто так — это значит, что в компании существует некий процесс, который происходит с той или иной степенью регулярности и который решается при помощи документа. То есть при помощи документа человек может закрыть свою задачу.

Шаблон — эталон качества. Он должен быть понятным, красивым, структурным документом, с которым хочется работать. Его главная цель — быстро и незаметно закрывать важные задачи.

Если ставить перед собой цель сделать отличный документ, который принесет масштабируемую пользу, то в этом и может быть смена парадигмы в восприятии поставленной задачи, а именно: делать продукт, который состоит из документа, глубоко понимая при этом, как с документом работают люди.

Продуктовый подход

Мы продуктовая команда, поэтому при подготовке шаблона используем продуктовый подход Jobs To Be Done. Это означает, что мы непрерывно думаем про успех конечного пользователя, который в итоге будет заполнять документ. С продуктом должно быть удобно работать, а проблемы пользователя нужно свести к нулю и помочь ему максимально эффективно достигнуть желаемого результата.

Jobs To Be Done — метод, позволяющий выяснить, какие задачи ваш продукт будет решать для клиента. То есть, почему пользователь решает «нанять продукт на работу».

Какие составляющие подхода JTBD можно применить к подготовке шаблона?

Хочу

Чтобы пользователь испытывал позитивные эмоции при работе с документом, документ должен быть как минимум ему симпатичен. Сравнивая ощущения между двустраничным документом 8-м шрифтом без воздуха между абзацами и структурным текстом с хорошо подобранными шрифтами, полями и отступами, сразу становится понятно, где пользователь почувствует себя плохо, а где — хорошо.

В Doczilla мы применяем концепцию Legal design, основными составляющими которой являются хорошая 1) форма и 2) содержание документа.

К сожалению, корпоративные требования клиентов обычно запрещают нам перерабатывать содержание. Поэтому мы чаще работаем именно с формой. Первое, что делают LegalTech-юристы, получая документ от клиента — перерабатывают его формат в наши собственные стили.

Так выглядит набор стилей нашей команды

Удобно

Если пользователь будет работать с шаблоном в ворде, подумайте, сколько лишних действий ему придется выполнить? Можно ли их сократить? Например, если можно избежать постановки квадратных скобок, не ставьте их, чтобы по завершении работы пользователю не приходилось их вычищать. Просто разметьте вариативность цветом — ее будет удобно снять одним действием, выделив весь текст и сняв заливку.

Если предполагается вариативность, то создавайте ее в абзацах: так удобнее выделять и удалять ненужный абзац, чем вычищать вариативные кусочки из сплошного параграфа.

Примечания по заполнению лучше оставлять в комментариях, а не в сносках — так их удобнее будет удалить одним действием через вкладку «рецензирование», «удалить все комментарии».

Соблюдайте гигиену форматирования. Нужно помочь пользователю работать быстро, и с этим поможет хороший формат. Если нумерованные части документа могут исчезать в зависимости от условий сделки, то нумерация должна быть автоматической, чтобы не перенумеровывать вручную поехавшие абзацы.

Мы все еще встречаем шаблоны, где нумерация сделана полностью вручную. Например, недавно мы столкнулись с проблемой 250 документов одного клиента, которые невозможно было переработать. Каждый документ состоял из 70−80 страниц, а нумерация в нем — два, точка, два пробела; два-один, точка, два пробела и т. д. Пришлось написать программу, которая проставит в документе автоматическую нумерацию.

При форматировании табличной части рекомендуем создавать отдельную ячейку для каждого абзаца. В первую очередь это относится к двуязычным документам, которые создаются при помощи таблицы из двух колонок с невидимыми границами. Текст на русском и английском языках имеет разный объем и поэтому визуально не будет соответствовать друг другу. Поэтому важно соблюдать принцип 1 абзац=1 ячейка, чтобы удобно было как читать документ, так и редактировать его.

Тот же принцип стоит применять к реквизитам, подписным блокам, месту и дате в преамбуле — все эти компоненты договора обычно создаются при помощи таблиц.

Сплошной текст в таблицах выглядит нечитабельным
Таблица, которая дышит

Исходить из потребности

Подумайте о том, в каких условиях будет использоваться документ? Кто будет его заполнять — линейный сотрудник или юрист, какими знаниями он обладает, чтобы быстро справиться с задачей? Если условия сделки позволяют конечному пользователю потратить достаточное количество времени на подготовку документа, то можно составить большой документ с детальной вариативностью. Если сотруднику нужно отработать задачу молниеносно, то лишняя вариативность и поля будут только мешать. В таком случае будет более эффективным создать набор одинаковых предзаполненных шаблонов, в которых пользователю нужно самостоятельно внести буквально пару штрихов, чтобы получить готовый документ.

Понятность и коридорные тесты

Нужно регулярно анализировать, как команда использует шаблон после создания и дорабатывать его, учитывая пользовательский опыт. «Дебажить», как говорят программисты. Разработали шаблон — запустите А/В тесты (то есть разные варианты, что из этого лучше сработает).

Покажите шаблоны людям. Понаблюдайте, как пользователь их заполняет. Спросите коллег, проведите коридорный тест перед запуском. Иначе впоследствии это может вылиться в непонимание пользователем требований к заполнению критичных положений документа и его возврат с согласования. Вы же сами вернете шаблон на доработку, если пользователь что-то не поймет. А в худшем случае, если сделка срочная, вам самостоятельно придется заниматься форматированием или исправлением некорректных положений.

Текст был опубликован автором:

0
Комментарии
-3 комментариев
Раскрывать всегда