Речь идёт о функциональных спецификациях к сайтам, приложениям и прочим информационным системам.
В начале карьеры UX-дизайнера я просто делал интерактивные прототипы, а документацию предпочитал не писать. Почему так:
Сложно. Этому навыку никто не обучал, а написать 100 и более страниц текста по проекту — это как диссертацию накатать. Поэтому я говорил клиентам, что, мол, и так справитесь.
У меня не было опыта в роли заказчика. И только после того, как я на собственном проекте увидел, сколько денег экономит этот документ, стал предлагать его каждому новому клиенту.
Продавать это было легко. Достаточно было рассказать о том, как я, заплатив несколько десятков тысяч за документ, экономил несколько сотен тысяч на разработке. И подкрепить рассказ конкретными цифрами и примерами. Чаще всего я рассказываю о том, как пожалел 50к на функциональную спецификацию на участок собственного проекта, и разработчики делали его два с половиной месяца вместо привычного одного. А месяц их работы обходился моей казне почти в 300к рублей. И если бы я не сэкономил на функциональной спецификации, то задача обошлась бы на 400к рублей дешевле.
Также со временем я научился писать документацию так, что это перестало казаться сложным. Не осталось непонятных моментов, формат устаканился.
В итоге обе причины, почему я предпочитал не писать функциональные спецификации, были устранены.
Стоимость документа примерно равна стоимости создания интерактивного прототипа. Поэтому теперь там, где я раньше зарабатывал 200 000 рублей, я начал зарабатывать 400 000. Так что технически это удвоило мой доход за счёт повышения среднего чека с одного клиента в два раза. Если до этого я не был загружен на 100%, то теперь был. Плюс средний проект растягивался во времени, и мне не приходилось слишком часто переключаться между разными направлениями.
Я записал видеоролик, в котором показываю живой пример функциональной спецификации. Вот прям вживую прохожу по 40-страничному документу и комментирую всякие нюансы.
Документ этот в моём рабочем процессе появляется в последнюю очередь. Перед началом работ я собираю с клиента функциональные требования к проекту, затем делаю на их основе интерактивный прототип в Axure, и только после этого перехожу к функциональной спецификации.
Функциональные требования (ФТ);
Интерактивный прототип;
Функциональная спецификация (ФС).
Эта последовательность в моей практике замечательно проработала последние десять лет и не собирается устаревать.
Кстати, у меня тут недавно спросили: что лучше — Figma или Axure? Ответ очевиден. Это просто инструменты. Думать лучше о целях, которые они помогут достичь. Сам я в какой-то момент освоил Фигму, но не стал на неё перебираться, т.к. в этом не появилось необходимости. Мои клиенты всё ещё заинтересованы в интерактивных прототипах в Axure на этапе проектирования, а уже после передают их в дизайн, который делается в Фигме.
Более того, раньше я после завершения работы над базовой версией прототипа предлагал адаптировать его под различные разрешения устройств. Но после того, как начал писать функциональные спецификации к каждому прототипу, увидел, что на этом этапе необходимо вносить в результат работы кучу правок. А вносить правки в прототип с адаптивкой — в икс раз сложнее, чем без адаптивки. Где икс — это количество разрешений экрана, под которые я адаптировал проект. Так что этот этап естественным образом перешёл дальше, в финальную стадию дизайна.
Но сегодня я рассказываю о функциональных спецификациях. Для чего они нужны?
Проверка результата работы
Когда пишу документ, обязательно нахожу какие-то косяки и несостыковки в прототипе. Где-то что-то забыл, где-то недодумал. ФС помогает всё это отловить и исправить. В среднем на этом этапе в прототип вносится до 20% правок. А так всё это легло бы на плечи разработчиков.
Передача информации разработчикам
В документе можно ответить на вопросы, на которые не ответит интерактивный прототип. Сколько система помнит аутентифицированного пользователя? Какие типы ошибок отображаются для той или иной формы? По какому принципу отображаются элементы того или иного списка? Сколько их там максимум может быть? Как они отсортированы по умолчанию? Чем внимательнее проектировщик относится к документу, тем меньше вопросов остаётся без ответов.
Простыми словами ФС помогает мне не допускать ошибок в проектировании и более полно передавать информацию разработчикам. Всё это ускоряет и удешевляет разработку.
В видеоролике я наглядно показал, из чего состоит документ. А здесь озвучу лишь важные моменты, которые делают работу над функциональными спецификациями не такой трудной, как в начале пути.
Использовать «мастера» и «компоненты»
Так же, как в Фигме и Акшуре мы используем мастера и компоненты, в документации можно в отдельном разделе описывать сквозные элементы, а затем к ним обращаться.
Зачем для каждой страницы прописывать наличие шапки и подвала, если можно один раз указать это в разделах, описывающих шапку и подвал?
Но на этом не обязательно останавливаться. Любой сквозной элемент можно описать отдельно, а затем обращаться лишь к его названию. Что это за элементы? Модальные и немодальные окна, различные меню навигации, выбор региона, хлебные крошки, карточки товаров и прочих элементов в списках, подсказки, блоки фильтрации и так далее.
Например, описываю я страницу с карточкой товара. И на ней есть блок с отзывами. И нужно описать один отзыв в списке. Как только я понимаю, что этот отзыв в списке может отображаться ещё и на странице категории товара, и на главной и где-то ещё, его описание тут же переедет в свой отдельный раздел, а дальше я буду на него ссылаться.
Но на этом можно не останавливаться. Помимо сквозных элементов я отдельно описываю общие принципы типовых элементов.
Например, общие принципы работы ссылок. Написал однажды «Ссылки открываются в той же вкладке, если иное отдельно не указано в ФС» и дальше уже об этом не думаешь. Или общие принципы работы форм. Вот наглядный пример:
Фокус должен автоматически ставиться на первое поле в форме, если в ФС не сказано иного;
Поля, в которых данные валидируются, подсвечиваются (если есть ошибка) при смене фокуса. Сообщение об ошибке появляется под конкретным полем;
При фокусе на полях, в которых есть данные, в правой части полей отображать крестик, с помощью которого можно эти данные очистить;
Обязательные поля должны быть отмечены в форме (например, звёздочкой), если их меньше, чем необязательных. Если же необязательных меньше, то нужно отмечать необязательные (например, подписью «не обязательно»). В случае, если в функциональной спецификации не сказано иного;
Сообщения об ошибках при нажатии на кнопку подтверждения внизу формы появляются прямо над кнопкой и должны сразу оказываться в поле зрения пользователя:
При этом поля, в которых допущена ошибка, также подсвечиваются в форме, как и в случае с валидацией данных;
Система не должна допускать двойных нажатий на кнопки в формах. После первого клика кнопки должны блокироваться до завершения инициированной операции:
Рекомендую в этом сценарии делать состояние кнопки с динамическим индикатором того, что происходит операция (какая-нибудь «крутилка»);
Прерывать такие состояния рекомендую лишь ошибкой по тайм-ауту. При попытке закрыть вкладку, выводить системное сообщение с вопросом, уверен ли пользователь, что хочет уйти, не дождавшись завершения операции.
Представляете, если бы мне пришлось каждую форму сопровождать таким полотном дополнительного текста? А так в одном месте всё прописал, а затем для каждой конкретной формы указываешь только важные нюансы.
И главное. Если нужно внести правки в описание какого-то элемента, теперь не нужно выискивать все его упоминания в многостраничном документе. Достаточно исправить в одном месте.
Не писать лишнего
Смотрите, как у меня в одной из ФС описан раздел «Избранное»:
Вроде всё суперкратко, но при этом понятно. А раньше я то же самое начал бы описывать так:
«В этом разделе пользователь может ознакомиться с перечнем товаров, добавленных в избранное. Он состоит из следующих элементов…»
Много слов, ноль информации.
А ещё я напомнил бы о том, что на странице есть шапка и подвал, описал бы, из чего состоит карточка товара в списке (вместо того, чтобы вынести это описание в начало документа и обращаться к нему). А вот тезисов в моём документе образца десятилетней давности не было бы…
Не бояться вольных формулировок и тезисов
Раньше, когда я писал документ, чувствовал, что работаю над чем-то серьёзным и важным. Что-то вроде диссертации. И стеснялся объяснять сложные вещи простыми словами.
Сегодня же я понимаю, что читатель документа — не академик, который оценивает мои навыки письма, а человек, которому нужна информация о том, как работает проект. Никто меня не осудит за просторечные выражения и айтишные жаргонизмы. Если я пару раз назову чекбокс «галочкой», перепутаю аутентификацию и авторизацию, а также назову кукис печеньками — ничего страшного не произойдёт.
Можно потратить уйму времени, пытаясь подобрать сложные слова для объяснения принципов работы простого элемента. А можно забить и представить, как бы я объяснял ту или иную штуку в разговоре с другом-программистом. И использовать именно эти формулировки.
В конце концов одна из целей функциональной спецификации — зафиксировать как можно больше мелких нюансов, о которых все позабудут через несколько месяцев. И нюансы эти не всегда касаются непосредственно функций проекта.
Например иногда я курсивом пишу в документе, почему были приняты те или иные решения. В каком-то случае просто клиент захотел сделать так, а не иначе. В другом — это требования маркетолога. Я как проектировщик в курсе всех этих вещей, а вот программист, которому придётся воплощать в жизнь иногда откровенно странные решения, будет в недоумении. А с моими комментариями всё встанет на свои места.
Иногда я и сам не уверен в собственных решениях, потому что на этапе проектирования могу не обладать информацией о стеке технологий, который выберут разработчики. И частенько делаю пометки, что, мол я здесь описал своё видение работы системы поиска, но если можно использовать готовое решение и сэкономить сотни часов программистов, то лучше так и поступить.
Экспериментировать
Со временем и с большим количеством документации вырабатывается устоявшийся процесс. Пишешь и не особо задумываешься. Это здорово с точки зрения эффективности. Чем меньше думаешь над формой, тем больше думаешь над содержанием.
Однако не стоит останавливаться в развитии. Я каждый раз запрашиваю обратную связь от тех, кто читает мою документацию. Всё ли им понятно, всё ли удобно? Ведь конечная цель — донести до разработчиков всё то, что мы с клиентом месяцами обсуждали во время проектирования. Донести понятно и лаконично.
С каждым днём способы донесения информации становятся всё лучше и нагляднее. Рынок IT развивается с огромной скоростью, ГОСТы устаревают, не успев появиться. А ещё у каждой команды разработчиков свои представления о том, как должен выглядеть идеальный процесс. Я общался с сотнями различных клиентов: агентств, владельцев IT-продуктов, стартаперов с новыми идеями. И ни разу не встречал двух команд с одинаковыми подходами к работе.
Поэтому не стоит строить иллюзий, что где-то существуют люди, которые точно знают, как правильно. У каждого свои нюансы, у каждого срабатывает что-то своё.
Важно в таких условиях не закостенеть. Не зацикливаться на процессах, а помнить о результатах. Если в голову приходит какая-то идея, позволяющая улучшить результат за счёт изменения подхода к написанию технической документации — нужно её сразу проверять в бою.
Написание функциональной спецификации в разных командах берут на себя разные люди. Где-то это технический писатель, где-то системный аналитик, где-то бизнес-аналитик, где-то проектировщик, где-то программист. Да и документы называться могут по-разному. Требования к проекту, техническое задание, спецификация на разработку.
В давно работающих и обеспечивающих себя проектах может оказаться много разных ролей. А два молодых стартапера — маркетолог и программист, могут на старте разделить между собой функции целого штата сотрудников.
Мой собственный рассказ — от лица внештатного проектировщика интерфейсов (не люблю термин UX-дизайнер, но он больше знаком представителям рынка). Чаще всего ко мне обращаются за проектированием новых версий устаревших продуктов. Чуть реже — за проектированием чего-то с нуля. Ещё реже — за доработками живого работающего продукта. Основная моя задача — снабдить разработчиков всей необходимой информацией для оценки и реализации чего-то нового.
Про функциональные спецификации я могу много чего рассказать, поэтому не стесняйтесь задавать вопросы в комментариях. Возможно, наберётся материал для новой статьи.
Если прочитанное и увиденное показалось вам полезным — за моей деятельностью можно следить в Телеграм-канале. Я в последнее время всё чаще пишу там на тему проектирования.
Ну и хочу напомнить о своей бесплатной книге нормального фрилансера. Там весь мой опыт становления проектировщиком, который работает на себя.
