Комментарии 20
Сохранил
Спасибо за пример. Меня смущает, что из-за ограничений Figma, невозможно сделать в прототипе ввод данных с клавиатуры (у вас это ситуация при поиске банка или вводе суммы), и это ограничивает функциональность (нет реального поведения элементов, трудно реализовать проверку ошибок в условиях естественного поведения). Как вы объясняете бизнес-заказчику, что в прототипе такой функционал не нужен? Ведь можно было бы взять другой инструмент и все это реализовать.
Иногда это (ввод данных с клавиатуры) не требуется в прототипе, например, если мы хотим проверить понятность флоу в целом. В этом случае скорее потребуется объяснить, зачем мы хотим нагрузить прототип такими неважными для исследования деталями как взаимодействие с клавиатурой.
Но иногда надо проверить какие-то механики, связанные непосредственно с вводом. Например, когда мы дорабатываем поле «Номер телефона», чтобы дать возможность вводить в него зарубежные номера. В этом случае потребуется прототип взаимодействия с полем и клавиатурой, чтобы пользователь мог нажимать на конкретные цифры, символ «+», удалять ввод и так далее. Его тоже можно сделать в Фигме, а если будет слишком сложно, конечно, придётся взять другой инструмент прототипирования.
Мне казалось, что в продукте с миллионами клиентов мелких задач не бывает, а черти как раз в деталях и прячутся. Тем более, если посмотреть на сценарии с точки зрения времени прохождения флоу, то на клавиатурный ввод уходит огромная его часть, и во время ввода возникает разное количество дополнительных сценариев (валидация, фокус ввода, видимая область, быстрые результаты, подсказки и т.д.).
Из вашего ответа я понял, что вы для требовательных прототипов просто берете другой инструмент и как я понял бизнес-заказчику надо вас аргументировано убедить, что простого прототипа в Figma будет недостаточно и нужно капнуть глубже. Или Figma всегда хватает?
Прототип и уровень его проработки зависит от того, что мы проверяем и как будем оценивать. В ответе выше я писал о проверке «понятности флоу». Если мы хотим оценить прототип по скорости прохождения флоу, то, действительно, может потребоваться более детальное отражение механики заполнения таких полей. Но если мы сравниваем скорость прохождения 2 конкурирующих флоу, в которых количество и механика заполнения полей одинаковые, то это можно вынести за скобки. В любом случае создание прототипа происходит после обсуждения плана конкретного исследования с UX-исследователем.
Если Фигмы не хватает, берём другой инструмент.
Бизнес-заказчик не должен убеждать дизайнера использовать тот или иной инструмент. Перед подготовкой прототипа продакт, исследователь и дизайнер собираются и обсуждают план исследования. Этот план и определяет, каким должен быть прототип.
Фигмы не всегда хватает.
А что используете, как другой инструмент?
А что чаще сейчас используете для требовательных случаев ProtoPie, Axure или что-то другое? Я просто в обоих работаю и, на мой взгляд, они очень разные по ресурсоемкости и то, что в одном сделать легко, то во втором будет слелать можно, но сложно.
ProtoPie.
Axure в начале статьи я упомянул для примера, куда ещё можно посмотреть, так как сам долгое время работал именно с этим инструментом и даже рассказывал, как там всё устроено.
Чёт делать такое в Фигме слишком сложная задача, быстрее будет просто взять Framer или сделать живой прототип "ручками".
В Фигме всё равно огромное количество ограничений. Какой смысл тестить такие простые сценарии? А более сложные сценарии прототипировать настолько долго, что эффективнее будет просто не проводить подобное тестирование в принципе. Это реально тупо лишние косты.
Иногда есть смысл. Если сценарии настолько сложные, что их очень долго прототипировать, можно либо попробовать их разделить, чтобы проверить отдельные гипотезы по-отдельности, либо использовать другой инструмент.
Ну вот я просто в одном из ваших примеров прочитал о тестировании поля с вводом иностранного номера телефона. Честно не пойму, зачем такие вещи тестировать. Разве это не велосипед? Ну то есть с одной стороны, я могу понять, что клиенты, возможно, привыкли к определенному уровню сопровождения + это хорошая возможность добавить часы в чек. С этой точки зрения смысл я вижу. Я лид ux/ui дизайнер в небольшом продукте, и моя презентация всегда сводилась к презентации последовательности экранов, которая сопровождается моими комментариями. В 99% случаев этого достаточно. Если бы мы делали прототипы, с наличными ресурсами, это затягивало бы сроки в 1,5-2 раза и убило бы возможность быстро итерировать по новым требованиям. А теперь учтите, что один флоу может затрагивать другой. Это просто либо невероятное количество дополнительной работы, либо аутдейтед артефакты по всему проекту. Сори за душнину.
Я нечаянно отклонил один комментарий (когда в последний раз писал на Хабр, такой функциональности, кажется, ещё не было). Если он всё ещё актуален, пожалуйста, напишите ещё раз.
Спасибо за статью! Искала подобную информацию несколько месяцев назад, когда собирала свой первый интерфейсный прототип. Было тогда чувство, что через эти переменные можно избавиться от лишних экранов, но самой не получилось в них так разобраться.
И еще тогда такой вопрос возник, на который вы возможно сможете ответить))
Сам вопрос:
Возможно ли через эти переменные собрать прототип, в котором при нажатии на кнопку "далее/продолжить" будут меняться незаполненные, но обязательные инпуты на состояние "error" (с просьбой заполнить поле). Соль в том, что мы изначально не знаем, какие именно поля не захочет заполнять пользователь, поэтому пришлось бы делать слишком много экранов для такого простого флоу.
Ну или может с высоты своего опыта скажите, есть ли смысл тестировать такое в прототипах?
В общем, буду очень благодарна, если дадите совет на эту тему)
Да, так вполне можно сделать в Фигме. Нажатие на кнопку «Далее» должно вести на новый экран формы, на котором будет уже немного другая реакция на те же локальные переменные. У каждого поля будет триггер After delay, который будет запускать экшен Conditional. В нём будет условие, что связанная с полем переменная равна True. Если она равна True, то будет отображаться заполненный вариант компонента поля. Если равна False, то будет отображаться вариант компонента поля с ошибкой.
Единственное, надо предусмотреть ситуацию, что пользователь заполнил все поля формы. Тогда нажатие на «Далее» должно открывать не этот экран с ошибками, а какой-то следующий экран в сценарии. Это можно реализовать через экшен Conditional, который будет запускаться по нажатию на кнопку «Далее». В условии этого экшена надо проверить значения локальных переменных, и если все они равны True, то открывать следующий экран в сценарии, а если нет, то открывать экран с ошибками.
А насчёт того, есть ли смысл тестировать, в ответах на комментарии выше я написал, что всё зависит от плана исследования.
Честно говоря, я не совсем понял, почему это сокращает количество экранов. Чтобы сработал After Delay нам же все равно нужен новый экран, так?
Ну и еще вопрос, что будет, если я захочу выбрать не ВТБ?
Если доступен выбор только ВТБ, то как будто бы вообще нет никакой необходимости делать через variables. Если слои будут проименованы на экранах одинаковым образом, то при переходе на следующий экран, используя обычные компоненты, состояние все равно сохранится.
Чтобы сработал After delay, новый экран формы не нужен. В статье показаны все фреймы, из которых собраны оба прототипа, показанные на видео.
Если вы хотите дать пользователю возможность выбрать не только ВТБ, можно запомнить выбор банка и подставить его в поле «Откуда». Но это уже немного другая история. Вопрос только в том, нужна ли эта вариативность в конкретном пользовательском тестировании, оправдана ли она целью исследования.
Переменные и условия: как быстро сделать в Фигме нелинейный прототип