В прошлый раз я писал, что проектирование — это формирование образа продукта в головах исполнителей и заказчиков. При этом стороны активно создают документы и обмениваются ими.
Илья Бирман, арт-директор бюро Артёма Горбунова, говорит, что не читает присылаемые технические задания. Проекты всегда нужно обсуждать. Один и тот же документ разные люди поймут по-разному.
По этой причине дизайнеры Бюро не пишут спецификаций для разработчиков. Разработчики сами разбираются в проекте, задают дизайнерам вопросы и спецификациями показывают, как поняли сказанное.
Джоэл Спольски в книге «Джоэл о программировании» предлагает писать забавно.
«Даже попытки так писать оживляют текст, как бывает смешон печальный клоун. В спецификации проще всего быть занимательным, приводя примеры. Рассказывая о том, как работает некая функция, не говорите:
Чтобы создать новую таблицу “Служащие”, пользователь нажимает клавиши Ctrl+N и начинает вводить их имена.
Лучше написать примерно так:
Мисс Пигги, тыча в клавиатуру карандашом для подведения глаз, потому что ее маленькие пухлые пальчики слишком толсты, чтобы нажимать клавиши по отдельности, набирает Ctrl+N, чтобы создать таблицу “Бойфренды”, и вводит в нее единственную запись “Кермит”.
Один из простейших способов быть занимательным — это быть конкретным тогда, когда этого не требуется. “Мопсы всех мастей” звучит забавнее, чем “собаки”. “Мисс Пигги” звучит забавнее, чем “пользователь”. Вместо “пользователей с особыми запросами” напишите о “фермерах левшах, выращивающих авокадо”. Не говорите “тех, кто не хочет убирать за своими собаками, следует наказывать”; лучше скажите, что “их следует помещать в такие глухие тюрьмы, где заключенным приходится покупать секс у пауков”.
Если вы считаете, что быть занимательным — это непрофессионально, то у вас просто нет чувства юмора. А если вы работаете в такой компании, где вас будут меньше уважать, если ваши спецификации станут живыми, забавными и приятными для чтения, то лучше поищите себе другую компанию, потому что жизнь так чертовски коротка, что жаль проводить светлое время суток в таком суровом и несчастном месте».
Джоэлу легко говорить. Он не только генеральный директор компании, создавшей Trello, и сооснователь Stack Overflow, но и автор 5 книг и популярного блога.
Возможно, оживить спецификации поможет «Пишите живее!» — «бесплатный курс по защите ваших текстов от словесной мертвечины» (цитата). Я недавно его нашёл и ещё не успел прочитать, но описание оставило хорошее впечатление.
И конечно, забавность — это лишь оливка в бокале понятного и лаконичного текста. Понятность и лаконичность (то есть инфостиль) прокачивает рассылка Главреда.
Игорь Манн рассказал историю:
«Руководитель одной компании купил 50 экземпляров книги, которая ему понравилась, раздал своим ключевым людям, попросив почитать и поделиться идеями. Он попросил написать секретаря на 35 странице каждой книги “Дочитаешь до этой страницы, зайди — обсудим”. И никто не зашел. Никто не нашел времени прочесть 30 страниц даже по просьбе своего руководителя».
Это было пасхальное яйцо.
Раньше в играх Atari не указывали имён авторов. В 1979 году разработчик Adventure Уоррен Робинетт создал в игре секретную комнату со своим именем. Чтобы попасть в неё, следовало отыскать невидимую точку в одной из частей лабиринта и перенести её в другой конец уровня.
Такие скрытые или труднодоступные штуки в играх и интерфейсах стали называть пасхальными яйцами (и просто пасхалками) по аналогии с охотой за спрятанными пасхальными яйцами — детской игрой, традиционной для западной Европы, США и Канады.
В сервисе Mailchimp, через который я отправляю эти письма, есть пасхалка. После рассылки маскот сервиса подставляет ладошку, чтобы я дал пять. Клик на ладошку — это high five с моей стороны, после которых его ладонь немного краснеет. После нескольких кликов запускается игра.
Если в документацию заложить пасхалки и никому об этом не говорить, реакция читателей и её отсутствие покажет, насколько внимательно они изучили документы. Например (по мотивам обсуждения в Гильдии вольных проектировщиков):
1. В техническом задании была фраза «Что произойдёт при нажатии на кнопку, узнает только тот, кто прочтёт этот документ». Менеджер, клиент и разработчик не спросили, что же произойдёт. Документ был подписан. Чтобы этого не повторилось, компания внедрила правила приёмки ТЗ.
2. Дизайнер вставлял в макеты матерные слова. Когда клиент начинал возмущаться, дизайнер журил его, что он совсем не смотрел макеты до этого момента.
3. Дизайнер писал осмысленные тексты, но заменял отдельные слова на «рыбу»: «Поручите нам подбор рыбы и сопровождение сделки. Без комиссии». Копирайтеры переписывали текст, разработчики брали согласованную версию, а тестировщики всё проверяли. Если рыба доплывала до разработки, тестового или рабочего проекта, становилось видно, кто работает плохо.
4. В укромных местах интерактивных прототипов прятались призы. Находивший их специалист получал сладкое или денежное вознаграждение.
Кстати, в прототипах я стараюсь выносить на отдельные страницы промежуточные состояния всех интерактивных элементов, чтобы команда не потеряла их при оценке.
Группа Van Halen использовала требование предоставить M&M's без конфеток коричневого цвета в середине описания технических требований к сцене для того чтобы проверить, читал ли исполнитель контракт.
Требования к прочности сцены необходимо выполнять для безопасности зрителей и самих членов группы. Если конфеток не было или там были коричневые, то управляющий группы мог сразу сказать, внимательно ли организаторы отнеслись к требованиям, и нужно ли идти проверять сцену.
Натасия из 2-го выпуска рассылки (про Airbnb в Китае):
«Я отказывала гостям с незаполненным профилем и напоминала им его заполнить. В моих условиях аренды есть требование к профилю, и если человек его проигнорировал, значит, он вообще невнимательно относится к требованиям».
Пасхалки могут быть не только показателем, но и стимулом. Достаточно анонсировать их наличие в документации и предложить скидку на разработку продукта, если клиент обнаружит все закладки.