Comments 6
@Grav необходимость функциональная спецификация интерфейса мне очевидна, ну и когда в универе учился году в 2010 это прям основа основ была. На мой взгляд форма в виде обычного документа с параграфами устарела и не обеспечивает ни версионируемости, ни интерактивности, ни интегрируемости с другими инструментами типа векторных редакторов, система учета требований или кода. На мой взгляд функциональные спецификации должны быть вынесены в дизайн систему. Есть ли в вашей компании дизайн система? Если нет, сколько уходит времени на написание, поддержание, передачу и контроль исполнения функциональных спецификаций разработчикам?
Функциональная спецификация интерфейса в таком виде, как она описана в статье (без версионируемости, интерактивности и т.п.), полезна в водопадной модели разработки, в агентской разработке, а также при создании MVP. То есть когда можно сначала сделать некий план в виде проектной документации, а затем отдать его на реализацию. Возможно даже совершенно другой команде.
В случае развивающегося продукта со спринтами, доработкой и изменением существующих страниц, конечно, надо решать вопрос с версионностью как макетов, так и текстового их описания. В статье решений для этого я не предлагаю.
Что касается дизайн-системы, в сторибук можно вынести описание взаимодействия с компонентами. Это позволит убрать из спецификации только описание «типовых элементов» (в терминах из статьи). Но останется описание особенностей конкретного компонента на конкретной странице вроде текста сообщений об ошибках при валидации текстового поля, лейблы, плейсхолдеры и так далее.
Плюс: 1) не все элементы интерфейса становятся компонентами в дизайн-системе, 2) есть элементы интерфейса, собранные из компонентов, и обладающие совершенно новыми свойствами и особенностями взаимодействия, которые надо фиксировать.
Отвечая на ваш вопрос: в компании, где я сейчас работаю, дизайн-система есть.
Спасибо за ответ. Если дизайн-система есть, тогда вопрос: как вы передаете функциональные требования в текущей компании?
Не вполне понял вопрос. Как передаём описание того, как должен работать интерфейс?
— Макеты.
— Для отдельных сценариев с не самой прямолинейной логикой взаимодействия — юзерфлоу (пока что картинками диаграмм, но хочу перейти на встроенный в Конфлюенс плагин для создания диаграмм) и функциональные спецификации (в Конфлюенсе).
— Персональное общение с фронтендерами.
Вся логика работы компонентов дизайн-системы, из которых собраны макеты, описана в сторибуке.
Интересно, как на практике в такой спецификации вы учитываете следующие моменты:
Как описывается поведение системы при взаимодействии с ней пользователя?
Связь элементов UI с конкретными методами API или структурой данных?
Межэкранную логику в спецификации лучше не описывать. Для этого больше подходят сценарии и, если логика разветвлённая, диаграммы юзерфлоу.
То есть вы готовите отдельный артефакт, демонстрирующий связь экранов / переходы между экранами?
Описывается реакция системы на действия пользователя (по сути и на визуальном уровне).
Например, пользователь редактирует карточку сотрудника и решает его деактивировать. Он нажимает на кнопку «Деактивировать», система: 1) меняет статус сотрудника, 2) отображает список сотрудников, 3) отображает снекбар с сообщением о блокировке. Эти действия и описываем как реакцию системы на пользовательское нажатие на кнопку «Деактивировать».
Не описываем. Связывает нажатие на кнопку «Деактивировать» с методом редактирования свойств пользователя уже разработчик или системный аналитик.
По поводу артефакта для связей экранов.
В случае с кнопкой «Деактивировать» возможны 2 исхода: 1) метод редактирования свойств пользователя не отрабатывает, тогда человек остаётся на текущей странице и видит снекбар с сообщением о том, что деактивировать пользователя не получилось, 2) метод отрабатывает, происходит линейный набор действий (описанный в примере выше), по итогам которого человек переходит на страницу со списком пользователей.
В этом случае связь экранов линейна и завязана на кнопку «Деактивировать», поэтому её легко можно описать текстом в спецификации.
Если человек может перейти к редактированию пользователя из списка и из карточки пользователя в режиме просмотра, после сохранения изменений он будет возвращаться на разные страницы. Связь экранов уже нелинейна, но всё ещё завязана на кнопку «Деактивировать», да и можно просто написать, что система отобразит человеку ту страницу, с которой он перешёл к редактированию пользователя. Так что здесь всё ещё можно обойтись без отдельных артефактов. А вот для описания более сложной связи уже может потребоваться отдельный артефакт.
Функциональная спецификация интерфейса: что это, зачем нужна, как её писать