Спасибо, что поднимаете эту тему. Я в прошлом году опубликовал статью о функциональной спецификации интерфейса — похожем по сути документе, который повышает качество работы проектировщика интерфейсов. В продуктовых компаниях этот документ не особо востребован, так как требования действительно часто передаются лаконично и на словах: выступал с докладом в одном продукте-единороге, там подтвердили, да и в комментариях к анонсу той статьи в UX Notes тоже делились этой болью. Так что спасибо.
Возможно, это опечатка: «При этом у кнопок также есть состояния «кликабельна» или «некликабельна», то есть основная или альтернативная».
Обычно в дизайн-системах кнопки могут быть основными и альтернативными (второстепенными, третьестепенными), но при этом каждая из них может быть кликабельной и некликабельной (disabled). А в этом предложении как будто приравнены кликабельные кнопки к основным, а некликабельные к альтернативным.
Описывается реакция системы на действия пользователя (по сути и на визуальном уровне).
Например, пользователь редактирует карточку сотрудника и решает его деактивировать. Он нажимает на кнопку «Деактивировать», система: 1) меняет статус сотрудника, 2) отображает список сотрудников, 3) отображает снекбар с сообщением о блокировке. Эти действия и описываем как реакцию системы на пользовательское нажатие на кнопку «Деактивировать».
Не описываем. Связывает нажатие на кнопку «Деактивировать» с методом редактирования свойств пользователя уже разработчик или системный аналитик.
По поводу артефакта для связей экранов.
В случае с кнопкой «Деактивировать» возможны 2 исхода: 1) метод редактирования свойств пользователя не отрабатывает, тогда человек остаётся на текущей странице и видит снекбар с сообщением о том, что деактивировать пользователя не получилось, 2) метод отрабатывает, происходит линейный набор действий (описанный в примере выше), по итогам которого человек переходит на страницу со списком пользователей.
В этом случае связь экранов линейна и завязана на кнопку «Деактивировать», поэтому её легко можно описать текстом в спецификации.
Если человек может перейти к редактированию пользователя из списка и из карточки пользователя в режиме просмотра, после сохранения изменений он будет возвращаться на разные страницы. Связь экранов уже нелинейна, но всё ещё завязана на кнопку «Деактивировать», да и можно просто написать, что система отобразит человеку ту страницу, с которой он перешёл к редактированию пользователя. Так что здесь всё ещё можно обойтись без отдельных артефактов. А вот для описания более сложной связи уже может потребоваться отдельный артефакт.
Не вполне понял вопрос. Как передаём описание того, как должен работать интерфейс? — Макеты. — Для отдельных сценариев с не самой прямолинейной логикой взаимодействия — юзерфлоу (пока что картинками диаграмм, но хочу перейти на встроенный в Конфлюенс плагин для создания диаграмм) и функциональные спецификации (в Конфлюенсе). — Персональное общение с фронтендерами.
Вся логика работы компонентов дизайн-системы, из которых собраны макеты, описана в сторибуке.
Функциональная спецификация интерфейса в таком виде, как она описана в статье (без версионируемости, интерактивности и т.п.), полезна в водопадной модели разработки, в агентской разработке, а также при создании MVP. То есть когда можно сначала сделать некий план в виде проектной документации, а затем отдать его на реализацию. Возможно даже совершенно другой команде.
В случае развивающегося продукта со спринтами, доработкой и изменением существующих страниц, конечно, надо решать вопрос с версионностью как макетов, так и текстового их описания. В статье решений для этого я не предлагаю.
Что касается дизайн-системы, в сторибук можно вынести описание взаимодействия с компонентами. Это позволит убрать из спецификации только описание «типовых элементов» (в терминах из статьи). Но останется описание особенностей конкретного компонента на конкретной странице вроде текста сообщений об ошибках при валидации текстового поля, лейблы, плейсхолдеры и так далее.
Плюс: 1) не все элементы интерфейса становятся компонентами в дизайн-системе, 2) есть элементы интерфейса, собранные из компонентов, и обладающие совершенно новыми свойствами и особенностями взаимодействия, которые надо фиксировать.
Отвечая на ваш вопрос: в компании, где я сейчас работаю, дизайн-система есть.
Опубликовал ссылку на эту статью в UX Notes, в комментариях подсказали, что в психологии есть более подходящий термин — интервизия (когда участники занимают равные позиции).
Согласен, что мокап и прототип — это разные вещи. Но мокап — это средне или высоко детализированное статичное представление дизайна. Очень часто мокап — это черновик дизайна или даже фактический дизайн-макет.
Мокапы часто путают с вайрфреймами из-за названий таких программ как Mockingbird, Mockup Builder, Balsamiq Mockups.
Как вы считаете, следует ли при таком подходе показывать пользователю параметры, выбранные в расширенной форме, после того, как форма возвращается к лаконичному отображению? По сути это информирование о состоянии системы: каким условиям соответствует получившийся список.
И нужна ли возможность такой дополнительный параметр быстро сбросить, не открывая расширенный фильтр, если с этим параметром результаты поиска не устраивают пользователя?
Спасибо, что поднимаете эту тему. Я в прошлом году опубликовал статью о функциональной спецификации интерфейса — похожем по сути документе, который повышает качество работы проектировщика интерфейсов. В продуктовых компаниях этот документ не особо востребован, так как требования действительно часто передаются лаконично и на словах: выступал с докладом в одном продукте-единороге, там подтвердили, да и в комментариях к анонсу той статьи в UX Notes тоже делились этой болью. Так что спасибо.
Возможно, это опечатка: «При этом у кнопок также есть состояния «кликабельна» или «некликабельна», то есть основная или альтернативная».
Обычно в дизайн-системах кнопки могут быть основными и альтернативными (второстепенными, третьестепенными), но при этом каждая из них может быть кликабельной и некликабельной (disabled). А в этом предложении как будто приравнены кликабельные кнопки к основным, а некликабельные к альтернативным.
Описывается реакция системы на действия пользователя (по сути и на визуальном уровне).
Например, пользователь редактирует карточку сотрудника и решает его деактивировать. Он нажимает на кнопку «Деактивировать», система: 1) меняет статус сотрудника, 2) отображает список сотрудников, 3) отображает снекбар с сообщением о блокировке. Эти действия и описываем как реакцию системы на пользовательское нажатие на кнопку «Деактивировать».
Не описываем. Связывает нажатие на кнопку «Деактивировать» с методом редактирования свойств пользователя уже разработчик или системный аналитик.
По поводу артефакта для связей экранов.
В случае с кнопкой «Деактивировать» возможны 2 исхода: 1) метод редактирования свойств пользователя не отрабатывает, тогда человек остаётся на текущей странице и видит снекбар с сообщением о том, что деактивировать пользователя не получилось, 2) метод отрабатывает, происходит линейный набор действий (описанный в примере выше), по итогам которого человек переходит на страницу со списком пользователей.
В этом случае связь экранов линейна и завязана на кнопку «Деактивировать», поэтому её легко можно описать текстом в спецификации.
Если человек может перейти к редактированию пользователя из списка и из карточки пользователя в режиме просмотра, после сохранения изменений он будет возвращаться на разные страницы. Связь экранов уже нелинейна, но всё ещё завязана на кнопку «Деактивировать», да и можно просто написать, что система отобразит человеку ту страницу, с которой он перешёл к редактированию пользователя. Так что здесь всё ещё можно обойтись без отдельных артефактов. А вот для описания более сложной связи уже может потребоваться отдельный артефакт.
Не вполне понял вопрос. Как передаём описание того, как должен работать интерфейс?
— Макеты.
— Для отдельных сценариев с не самой прямолинейной логикой взаимодействия — юзерфлоу (пока что картинками диаграмм, но хочу перейти на встроенный в Конфлюенс плагин для создания диаграмм) и функциональные спецификации (в Конфлюенсе).
— Персональное общение с фронтендерами.
Вся логика работы компонентов дизайн-системы, из которых собраны макеты, описана в сторибуке.
Функциональная спецификация интерфейса в таком виде, как она описана в статье (без версионируемости, интерактивности и т.п.), полезна в водопадной модели разработки, в агентской разработке, а также при создании MVP. То есть когда можно сначала сделать некий план в виде проектной документации, а затем отдать его на реализацию. Возможно даже совершенно другой команде.
В случае развивающегося продукта со спринтами, доработкой и изменением существующих страниц, конечно, надо решать вопрос с версионностью как макетов, так и текстового их описания. В статье решений для этого я не предлагаю.
Что касается дизайн-системы, в сторибук можно вынести описание взаимодействия с компонентами. Это позволит убрать из спецификации только описание «типовых элементов» (в терминах из статьи). Но останется описание особенностей конкретного компонента на конкретной странице вроде текста сообщений об ошибках при валидации текстового поля, лейблы, плейсхолдеры и так далее.
Плюс: 1) не все элементы интерфейса становятся компонентами в дизайн-системе, 2) есть элементы интерфейса, собранные из компонентов, и обладающие совершенно новыми свойствами и особенностями взаимодействия, которые надо фиксировать.
Отвечая на ваш вопрос: в компании, где я сейчас работаю, дизайн-система есть.
Если я не ошибаюсь, вместо Nginx path error log должно было быть Nginx error log path, чтобы это выражение означало «Путь к логу ошибок Nginx».
Опубликовал ссылку на эту статью в UX Notes, в комментариях подсказали, что в психологии есть более подходящий термин — интервизия (когда участники занимают равные позиции).
Breadcrumbs вместо «строк навигации» у дизайнеров принято называть хлебными крошками.
Ещё можно почитать по теме конспект воркшопа Глеба Кушедова по методологии OOUX.
В ссылке на ozon.travel/flight/ опечатка: написано «https//» вместо «https://». Из-за этого ссылка не открывается.
Написал краткие содержания докладов, на которых был. Может пригодиться для более детального впечатления о конференции:
Мокапы часто путают с вайрфреймами из-за названий таких программ как Mockingbird, Mockup Builder, Balsamiq Mockups.
Из переводной статьи Wireframing, Prototyping, Mockuping — What’s the Difference.
И нужна ли возможность такой дополнительный параметр быстро сбросить, не открывая расширенный фильтр, если с этим параметром результаты поиска не устраивают пользователя?
Все эти преимущества есть у боковой фильтрации.
На самом деле, правило 7±2 ни на чём не основывается.