Чтобы сработал After delay, новый экран формы не нужен. В статье показаны все фреймы, из которых собраны оба прототипа, показанные на видео.
Если вы хотите дать пользователю возможность выбрать не только ВТБ, можно запомнить выбор банка и подставить его в поле «Откуда». Но это уже немного другая история. Вопрос только в том, нужна ли эта вариативность в конкретном пользовательском тестировании, оправдана ли она целью исследования.
Да, так вполне можно сделать в Фигме. Нажатие на кнопку «Далее» должно вести на новый экран формы, на котором будет уже немного другая реакция на те же локальные переменные. У каждого поля будет триггер After delay, который будет запускать экшен Conditional. В нём будет условие, что связанная с полем переменная равна True. Если она равна True, то будет отображаться заполненный вариант компонента поля. Если равна False, то будет отображаться вариант компонента поля с ошибкой.
Единственное, надо предусмотреть ситуацию, что пользователь заполнил все поля формы. Тогда нажатие на «Далее» должно открывать не этот экран с ошибками, а какой-то следующий экран в сценарии. Это можно реализовать через экшен Conditional, который будет запускаться по нажатию на кнопку «Далее». В условии этого экшена надо проверить значения локальных переменных, и если все они равны True, то открывать следующий экран в сценарии, а если нет, то открывать экран с ошибками.
А насчёт того, есть ли смысл тестировать, в ответах на комментарии выше я написал, что всё зависит от плана исследования.
Я нечаянно отклонил один комментарий (когда в последний раз писал на Хабр, такой функциональности, кажется, ещё не было). Если он всё ещё актуален, пожалуйста, напишите ещё раз.
Иногда есть смысл. Если сценарии настолько сложные, что их очень долго прототипировать, можно либо попробовать их разделить, чтобы проверить отдельные гипотезы по-отдельности, либо использовать другой инструмент.
Axure в начале статьи я упомянул для примера, куда ещё можно посмотреть, так как сам долгое время работал именно с этим инструментом и даже рассказывал, как там всё устроено.
Прототип и уровень его проработки зависит от того, что мы проверяем и как будем оценивать. В ответе выше я писал о проверке «понятности флоу». Если мы хотим оценить прототип по скорости прохождения флоу, то, действительно, может потребоваться более детальное отражение механики заполнения таких полей. Но если мы сравниваем скорость прохождения 2 конкурирующих флоу, в которых количество и механика заполнения полей одинаковые, то это можно вынести за скобки. В любом случае создание прототипа происходит после обсуждения плана конкретного исследования с UX-исследователем.
Если Фигмы не хватает, берём другой инструмент.
Бизнес-заказчик не должен убеждать дизайнера использовать тот или иной инструмент. Перед подготовкой прототипа продакт, исследователь и дизайнер собираются и обсуждают план исследования. Этот план и определяет, каким должен быть прототип.
Иногда это (ввод данных с клавиатуры) не требуется в прототипе, например, если мы хотим проверить понятность флоу в целом. В этом случае скорее потребуется объяснить, зачем мы хотим нагрузить прототип такими неважными для исследования деталями как взаимодействие с клавиатурой.
Но иногда надо проверить какие-то механики, связанные непосредственно с вводом. Например, когда мы дорабатываем поле «Номер телефона», чтобы дать возможность вводить в него зарубежные номера. В этом случае потребуется прототип взаимодействия с полем и клавиатурой, чтобы пользователь мог нажимать на конкретные цифры, символ «+», удалять ввод и так далее. Его тоже можно сделать в Фигме, а если будет слишком сложно, конечно, придётся взять другой инструмент прототипирования.
Такое ощущение, что в конце статьи что-то пропущено. Читаю «Ведь если дойти до максимального прагматизма, то визуально число 5 — это тоже «шум», который стоит за реальными данными ••••• — пять объектов. Аналогично, числа 2423 и 7822 в массиве других четырёхзначных чисел…» и ничего не понимаю. Там должен был быть ещё один пример?
Спасибо, что поднимаете эту тему. Я в прошлом году опубликовал статью о функциональной спецификации интерфейса — похожем по сути документе, который повышает качество работы проектировщика интерфейсов. В продуктовых компаниях этот документ не особо востребован, так как требования действительно часто передаются лаконично и на словах: выступал с докладом в одном продукте-единороге, там подтвердили, да и в комментариях к анонсу той статьи в UX Notes тоже делились этой болью. Так что спасибо.
Возможно, это опечатка: «При этом у кнопок также есть состояния «кликабельна» или «некликабельна», то есть основная или альтернативная».
Обычно в дизайн-системах кнопки могут быть основными и альтернативными (второстепенными, третьестепенными), но при этом каждая из них может быть кликабельной и некликабельной (disabled). А в этом предложении как будто приравнены кликабельные кнопки к основным, а некликабельные к альтернативным.
Описывается реакция системы на действия пользователя (по сути и на визуальном уровне).
Например, пользователь редактирует карточку сотрудника и решает его деактивировать. Он нажимает на кнопку «Деактивировать», система: 1) меняет статус сотрудника, 2) отображает список сотрудников, 3) отображает снекбар с сообщением о блокировке. Эти действия и описываем как реакцию системы на пользовательское нажатие на кнопку «Деактивировать».
Не описываем. Связывает нажатие на кнопку «Деактивировать» с методом редактирования свойств пользователя уже разработчик или системный аналитик.
По поводу артефакта для связей экранов.
В случае с кнопкой «Деактивировать» возможны 2 исхода: 1) метод редактирования свойств пользователя не отрабатывает, тогда человек остаётся на текущей странице и видит снекбар с сообщением о том, что деактивировать пользователя не получилось, 2) метод отрабатывает, происходит линейный набор действий (описанный в примере выше), по итогам которого человек переходит на страницу со списком пользователей.
В этом случае связь экранов линейна и завязана на кнопку «Деактивировать», поэтому её легко можно описать текстом в спецификации.
Если человек может перейти к редактированию пользователя из списка и из карточки пользователя в режиме просмотра, после сохранения изменений он будет возвращаться на разные страницы. Связь экранов уже нелинейна, но всё ещё завязана на кнопку «Деактивировать», да и можно просто написать, что система отобразит человеку ту страницу, с которой он перешёл к редактированию пользователя. Так что здесь всё ещё можно обойтись без отдельных артефактов. А вот для описания более сложной связи уже может потребоваться отдельный артефакт.
Не вполне понял вопрос. Как передаём описание того, как должен работать интерфейс? — Макеты. — Для отдельных сценариев с не самой прямолинейной логикой взаимодействия — юзерфлоу (пока что картинками диаграмм, но хочу перейти на встроенный в Конфлюенс плагин для создания диаграмм) и функциональные спецификации (в Конфлюенсе). — Персональное общение с фронтендерами.
Вся логика работы компонентов дизайн-системы, из которых собраны макеты, описана в сторибуке.
Функциональная спецификация интерфейса в таком виде, как она описана в статье (без версионируемости, интерактивности и т.п.), полезна в водопадной модели разработки, в агентской разработке, а также при создании MVP. То есть когда можно сначала сделать некий план в виде проектной документации, а затем отдать его на реализацию. Возможно даже совершенно другой команде.
В случае развивающегося продукта со спринтами, доработкой и изменением существующих страниц, конечно, надо решать вопрос с версионностью как макетов, так и текстового их описания. В статье решений для этого я не предлагаю.
Что касается дизайн-системы, в сторибук можно вынести описание взаимодействия с компонентами. Это позволит убрать из спецификации только описание «типовых элементов» (в терминах из статьи). Но останется описание особенностей конкретного компонента на конкретной странице вроде текста сообщений об ошибках при валидации текстового поля, лейблы, плейсхолдеры и так далее.
Плюс: 1) не все элементы интерфейса становятся компонентами в дизайн-системе, 2) есть элементы интерфейса, собранные из компонентов, и обладающие совершенно новыми свойствами и особенностями взаимодействия, которые надо фиксировать.
Отвечая на ваш вопрос: в компании, где я сейчас работаю, дизайн-система есть.
Опубликовал ссылку на эту статью в UX Notes, в комментариях подсказали, что в психологии есть более подходящий термин — интервизия (когда участники занимают равные позиции).
Кажется, там опечатка: «4,46 из 7». Не должно ли быть «4,46 из 5»?
Чтобы сработал After delay, новый экран формы не нужен. В статье показаны все фреймы, из которых собраны оба прототипа, показанные на видео.
Если вы хотите дать пользователю возможность выбрать не только ВТБ, можно запомнить выбор банка и подставить его в поле «Откуда». Но это уже немного другая история. Вопрос только в том, нужна ли эта вариативность в конкретном пользовательском тестировании, оправдана ли она целью исследования.
Да, так вполне можно сделать в Фигме. Нажатие на кнопку «Далее» должно вести на новый экран формы, на котором будет уже немного другая реакция на те же локальные переменные. У каждого поля будет триггер After delay, который будет запускать экшен Conditional. В нём будет условие, что связанная с полем переменная равна True. Если она равна True, то будет отображаться заполненный вариант компонента поля. Если равна False, то будет отображаться вариант компонента поля с ошибкой.
Единственное, надо предусмотреть ситуацию, что пользователь заполнил все поля формы. Тогда нажатие на «Далее» должно открывать не этот экран с ошибками, а какой-то следующий экран в сценарии. Это можно реализовать через экшен Conditional, который будет запускаться по нажатию на кнопку «Далее». В условии этого экшена надо проверить значения локальных переменных, и если все они равны True, то открывать следующий экран в сценарии, а если нет, то открывать экран с ошибками.
А насчёт того, есть ли смысл тестировать, в ответах на комментарии выше я написал, что всё зависит от плана исследования.
Я нечаянно отклонил один комментарий (когда в последний раз писал на Хабр, такой функциональности, кажется, ещё не было). Если он всё ещё актуален, пожалуйста, напишите ещё раз.
Иногда есть смысл. Если сценарии настолько сложные, что их очень долго прототипировать, можно либо попробовать их разделить, чтобы проверить отдельные гипотезы по-отдельности, либо использовать другой инструмент.
ProtoPie.
Axure в начале статьи я упомянул для примера, куда ещё можно посмотреть, так как сам долгое время работал именно с этим инструментом и даже рассказывал, как там всё устроено.
ProtoPie
Прототип и уровень его проработки зависит от того, что мы проверяем и как будем оценивать. В ответе выше я писал о проверке «понятности флоу». Если мы хотим оценить прототип по скорости прохождения флоу, то, действительно, может потребоваться более детальное отражение механики заполнения таких полей. Но если мы сравниваем скорость прохождения 2 конкурирующих флоу, в которых количество и механика заполнения полей одинаковые, то это можно вынести за скобки. В любом случае создание прототипа происходит после обсуждения плана конкретного исследования с UX-исследователем.
Если Фигмы не хватает, берём другой инструмент.
Бизнес-заказчик не должен убеждать дизайнера использовать тот или иной инструмент. Перед подготовкой прототипа продакт, исследователь и дизайнер собираются и обсуждают план исследования. Этот план и определяет, каким должен быть прототип.
Фигмы не всегда хватает.
Иногда это (ввод данных с клавиатуры) не требуется в прототипе, например, если мы хотим проверить понятность флоу в целом. В этом случае скорее потребуется объяснить, зачем мы хотим нагрузить прототип такими неважными для исследования деталями как взаимодействие с клавиатурой.
Но иногда надо проверить какие-то механики, связанные непосредственно с вводом. Например, когда мы дорабатываем поле «Номер телефона», чтобы дать возможность вводить в него зарубежные номера. В этом случае потребуется прототип взаимодействия с полем и клавиатурой, чтобы пользователь мог нажимать на конкретные цифры, символ «+», удалять ввод и так далее. Его тоже можно сделать в Фигме, а если будет слишком сложно, конечно, придётся взять другой инструмент прототипирования.
А какой конкретно сервис использовали для теста?
Такое ощущение, что в конце статьи что-то пропущено. Читаю «Ведь если дойти до максимального прагматизма, то визуально число 5 — это тоже «шум», который стоит за реальными данными ••••• — пять объектов. Аналогично, числа 2423 и 7822 в массиве других четырёхзначных чисел…» и ничего не понимаю. Там должен был быть ещё один пример?
Спасибо, что поднимаете эту тему. Я в прошлом году опубликовал статью о функциональной спецификации интерфейса — похожем по сути документе, который повышает качество работы проектировщика интерфейсов. В продуктовых компаниях этот документ не особо востребован, так как требования действительно часто передаются лаконично и на словах: выступал с докладом в одном продукте-единороге, там подтвердили, да и в комментариях к анонсу той статьи в 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.