Согласен, универсальных правил нет. Но есть базовые рекомендации — такие решения, которые обычно хорошо работают в своей сфере (я бы разделил массовые и профессиональные интерфейсы). Эти базовые рекомендации можно применять по умолчанию, но не считать догмой. Стоит каждый раз задумываться, есть ли в конкретном случае факторы, из-за которых придётся от базового правила отступить.
Заголовок статьи, как мне кажется, как раз подсвечивает, что у базового решения есть свои недостатки, о которых полезно знать.
Это уже вопрос терминологии. В данном случае первое поле действительно может по факту оказаться необязательным. Но оно таковым оказывается только после того, как второе поле становится заполненным. То есть по умолчанию первое поле не необязательное, а «условно обязательное».
Если в форме два условно обязательных поля, дизайнер скорее всего поставит на первое место поле какое-то особое поле: либо то, которое бизнес хочет чаще видеть заполненным, либо то, которое по факту чаще заполняют пользователи.
Таким образом рекомендация помещать фокус в первое поле в форме кажется вполне разумной.
«Особенный конфуз может случиться, если первое поле не обязательное для заполнения. Или если форма структурирована таким образом, что пользователи привыкли заполнять её с конца» — это уже какие-то совсем экстремальные случаи. Если дизайнер сделал форму, в которой первое поле необязательное, вопрос к этому дизайнеру.
Я вот сделал итоги прошлого года для своего канала UX Notes. С помощью этого скрипта — за пару минут. За год вышло 134 поста. Я бы запарился самостоятельно выписывать их параметры в табличку, чтобы посчитать количество просмотров, реакций, пересылок и так далее, найти самый просматриваемый, залайканный, закомментированный пост. Что-то похожее делают сервисы типа TGStat, но у них своя логика построения годовых итогов, свои разрезы статистики и кое-каких параметров (вроде количества символов в публикациях) просто нет
«Вмешиваемся, только если произошел срыв сценария, чтобы помочь респонденту и посмотреть оставшийся участок флоу (при технической возможности).» — а как это учитывается в столбце «Прошёл этапов»? Записывается количество этапов, пройденных до срыва?
Для 12-го пункта не хватает какого-то примера. Слишком абстрактно. Тезис: «Иногда надо переделать базовое, фундаментальное решение». Ну да, такое бывает, но что считается базовым решением в проектировании интерфейсов, какие новые вводные или совершённые в проектировании ошибки могут привести к изменению базового решения, как избежать таких ситуаций? Может быть, пример из твоей практики сделал бы тезис понятнее. Иначе кажется, что это лишний пункт для статьи с таким заголовком.
Если оставить чекбокс «Мало соуса», будет не вполне ясно, что будет, если он выключен. Обычная порция соуса, много соуса, совсем без соуса? Лучше заменить на радиогруппу с конкретными вариантами добавления соуса
Мне вот не хватило конкретики по пункту «Фиксирую перечень вопросов от целевой аудитории, без ответов на которые она не в состоянии будет принять ключевых решений и откажется от достижения цели».
Фиксирую перечень вопросов — это значит «интервьюирую представителей ЦА и узнаю, что им важно знать для принятия решения о покупке»? Не может же эксперт по интерфейсам знать, что важно людям, покупающим щебень, срубы для бани и прочие специфические товары.
Чтобы сработал After delay, новый экран формы не нужен. В статье показаны все фреймы, из которых собраны оба прототипа, показанные на видео.
Если вы хотите дать пользователю возможность выбрать не только ВТБ, можно запомнить выбор банка и подставить его в поле «Откуда». Но это уже немного другая история. Вопрос только в том, нужна ли эта вариативность в конкретном пользовательском тестировании, оправдана ли она целью исследования.
Да, так вполне можно сделать в Фигме. Нажатие на кнопку «Далее» должно вести на новый экран формы, на котором будет уже немного другая реакция на те же локальные переменные. У каждого поля будет триггер After delay, который будет запускать экшен Conditional. В нём будет условие, что связанная с полем переменная равна True. Если она равна True, то будет отображаться заполненный вариант компонента поля. Если равна False, то будет отображаться вариант компонента поля с ошибкой.
Единственное, надо предусмотреть ситуацию, что пользователь заполнил все поля формы. Тогда нажатие на «Далее» должно открывать не этот экран с ошибками, а какой-то следующий экран в сценарии. Это можно реализовать через экшен Conditional, который будет запускаться по нажатию на кнопку «Далее». В условии этого экшена надо проверить значения локальных переменных, и если все они равны True, то открывать следующий экран в сценарии, а если нет, то открывать экран с ошибками.
А насчёт того, есть ли смысл тестировать, в ответах на комментарии выше я написал, что всё зависит от плана исследования.
Я нечаянно отклонил один комментарий (когда в последний раз писал на Хабр, такой функциональности, кажется, ещё не было). Если он всё ещё актуален, пожалуйста, напишите ещё раз.
Иногда есть смысл. Если сценарии настолько сложные, что их очень долго прототипировать, можно либо попробовать их разделить, чтобы проверить отдельные гипотезы по-отдельности, либо использовать другой инструмент.
Axure в начале статьи я упомянул для примера, куда ещё можно посмотреть, так как сам долгое время работал именно с этим инструментом и даже рассказывал, как там всё устроено.
Согласен, универсальных правил нет. Но есть базовые рекомендации — такие решения, которые обычно хорошо работают в своей сфере (я бы разделил массовые и профессиональные интерфейсы). Эти базовые рекомендации можно применять по умолчанию, но не считать догмой. Стоит каждый раз задумываться, есть ли в конкретном случае факторы, из-за которых придётся от базового правила отступить.
Заголовок статьи, как мне кажется, как раз подсвечивает, что у базового решения есть свои недостатки, о которых полезно знать.
Это уже вопрос терминологии. В данном случае первое поле действительно может по факту оказаться необязательным. Но оно таковым оказывается только после того, как второе поле становится заполненным. То есть по умолчанию первое поле не необязательное, а «условно обязательное».
Если в форме два условно обязательных поля, дизайнер скорее всего поставит на первое место поле какое-то особое поле: либо то, которое бизнес хочет чаще видеть заполненным, либо то, которое по факту чаще заполняют пользователи.
Таким образом рекомендация помещать фокус в первое поле в форме кажется вполне разумной.
«Особенный конфуз может случиться, если первое поле не обязательное для заполнения. Или если форма структурирована таким образом, что пользователи привыкли заполнять её с конца» — это уже какие-то совсем экстремальные случаи. Если дизайнер сделал форму, в которой первое поле необязательное, вопрос к этому дизайнеру.
Я вот сделал итоги прошлого года для своего канала UX Notes. С помощью этого скрипта — за пару минут. За год вышло 134 поста. Я бы запарился самостоятельно выписывать их параметры в табличку, чтобы посчитать количество просмотров, реакций, пересылок и так далее, найти самый просматриваемый, залайканный, закомментированный пост. Что-то похожее делают сервисы типа TGStat, но у них своя логика построения годовых итогов, свои разрезы статистики и кое-каких параметров (вроде количества символов в публикациях) просто нет
«Вмешиваемся, только если произошел срыв сценария, чтобы помочь респонденту и посмотреть оставшийся участок флоу (при технической возможности).» — а как это учитывается в столбце «Прошёл этапов»? Записывается количество этапов, пройденных до срыва?
«Ну сделал и сделал»
Для 12-го пункта не хватает какого-то примера. Слишком абстрактно. Тезис: «Иногда надо переделать базовое, фундаментальное решение». Ну да, такое бывает, но что считается базовым решением в проектировании интерфейсов, какие новые вводные или совершённые в проектировании ошибки могут привести к изменению базового решения, как избежать таких ситуаций? Может быть, пример из твоей практики сделал бы тезис понятнее. Иначе кажется, что это лишний пункт для статьи с таким заголовком.
Если оставить чекбокс «Мало соуса», будет не вполне ясно, что будет, если он выключен. Обычная порция соуса, много соуса, совсем без соуса? Лучше заменить на радиогруппу с конкретными вариантами добавления соуса
А есть в паблике эти хелперы, может быть, в виде файла в Фигма-комьюнити?
"Итого 12 токенов — View, Navigation, Background, Border, Overlay, Primary, Secondary, Accent, Danger, Success, Warning, OnAccent, Disabled."
Я посчитал, получается 13 токенов…
Среди полезных ссылок не хватает, конечно, ссылки на серию видео Axure 7 для начинающих за 100 минут :)
В Альфа-Банке проверку разработанного дизайна тоже называют дизайн-ревью. А проверка перед отправкой макетов в разработку — дизайн-чек.
Мне вот не хватило конкретики по пункту «Фиксирую перечень вопросов от целевой аудитории, без ответов на которые она не в состоянии будет принять ключевых решений и откажется от достижения цели».
Фиксирую перечень вопросов — это значит «интервьюирую представителей ЦА и узнаю, что им важно знать для принятия решения о покупке»? Не может же эксперт по интерфейсам знать, что важно людям, покупающим щебень, срубы для бани и прочие специфические товары.
Кажется, там опечатка: «4,46 из 7». Не должно ли быть «4,46 из 5»?
Чтобы сработал After delay, новый экран формы не нужен. В статье показаны все фреймы, из которых собраны оба прототипа, показанные на видео.
Если вы хотите дать пользователю возможность выбрать не только ВТБ, можно запомнить выбор банка и подставить его в поле «Откуда». Но это уже немного другая история. Вопрос только в том, нужна ли эта вариативность в конкретном пользовательском тестировании, оправдана ли она целью исследования.
Да, так вполне можно сделать в Фигме. Нажатие на кнопку «Далее» должно вести на новый экран формы, на котором будет уже немного другая реакция на те же локальные переменные. У каждого поля будет триггер After delay, который будет запускать экшен Conditional. В нём будет условие, что связанная с полем переменная равна True. Если она равна True, то будет отображаться заполненный вариант компонента поля. Если равна False, то будет отображаться вариант компонента поля с ошибкой.
Единственное, надо предусмотреть ситуацию, что пользователь заполнил все поля формы. Тогда нажатие на «Далее» должно открывать не этот экран с ошибками, а какой-то следующий экран в сценарии. Это можно реализовать через экшен Conditional, который будет запускаться по нажатию на кнопку «Далее». В условии этого экшена надо проверить значения локальных переменных, и если все они равны True, то открывать следующий экран в сценарии, а если нет, то открывать экран с ошибками.
А насчёт того, есть ли смысл тестировать, в ответах на комментарии выше я написал, что всё зависит от плана исследования.
Я нечаянно отклонил один комментарий (когда в последний раз писал на Хабр, такой функциональности, кажется, ещё не было). Если он всё ещё актуален, пожалуйста, напишите ещё раз.
Иногда есть смысл. Если сценарии настолько сложные, что их очень долго прототипировать, можно либо попробовать их разделить, чтобы проверить отдельные гипотезы по-отдельности, либо использовать другой инструмент.
ProtoPie.
Axure в начале статьи я упомянул для примера, куда ещё можно посмотреть, так как сам долгое время работал именно с этим инструментом и даже рассказывал, как там всё устроено.
ProtoPie