Данные в макетах

ИНН, названия организаций, ФИО, адреса электронной почты и остальные реквизиты должны быть близки к жизни. На таких данных вы будете видеть, насколько хорошо они читаются и помещаются в отведённое им место.

Например, ИНН, состоящий из единиц будет короче реалистичного ИНН примерно на 18 пкс.

Неправильно

Правильно

Если длина реквизита бывает разной, используйте примеры разной длины, а не такой, которая хорошо входит в поля или ячейки таблиц.

Неправильно

Правильно

Неправильно

Правильно

Это поможет не забыть показать, что происходит с данными, когда они не вошли: должны ли они обрезаться многоточием или выводиться в несколько строк, или просто исчезать за границей поля ввода.

Так у вас будут получаться надёжные решения, то есть такие, которые работают на любых данных.

Чтобы длина поля, ячейки таблицы или просто строки в интерфейсе была оптимальна, и в большинстве случаев вмещала в себя данные в одну строку, нужно знать какие, значения встречаются у пользователя. Для этого надо обратиться к метрикам и данным о пользователе. Иногда в команде есть человек, который этим уже занимается, обратитесь к нему. Но что именно спросить?

Если спросить про среднее значение, и подстраивать поля под него, данные не будут влезать в отведённое им место примерно у половины пользователей. Если спросить про максимальное значение длины, интерфейс будет заточен под статистические выбросы — поля и ячейки будут иметь избыточный размер, а это тоже плохо.

Поэтому мы используем персентили. Это статистический показатель того, какое положение занимает определённое значение во всём наборе данных.

Если вы хотите, чтобы данные поместились в одну строку у 80% пользователей, нужно посчитать длину по 80-у персентилю. На деле это значит: «Не длиннее скольки символов будет значение, если мы возьмём все значения реквизита наших пользователей, а потом отсортируем их по возрастанию и возьмём первые 80% из них».

Если вы будете таким образом формулировать вопрос, а потом ориентироваться на полученное значение, то места для данных будет достаточно, но оно не будет избыточным.

Когда данных надо много, а сочинять тяжело, их можно сгенерировать. Можно использовать AI-инструменты.

Дизайнер не использует «рыбный» текст. Например, если в интерфейсе должен быть текст ошибки, но его нет, дизайнер пишет этот текст сам, опираясь на знания о задаче. Если не хватает информации, дизайнер идёт к аналитику, продакту или исследователю.

Неправильно

Правильно

Пользователь разбирается в своей предметной области и сразу видит ошибки и нестыковки. Логические и фактические ошибки будут отвлекать его от задания и приводить к дискуссии с юзабилистом.

Убедитесь, что:

• на разных экранах совпадают данные, которые должны совпадать; например, даты документов, названия организаций;
• всё правильно по предметной области; например, если отчёт сдаётся поквартально, то в прототипе его периодом отчётности должен быть квартал.

Подробнее — в гайде Подготовка прототипа к юзабилити-тестированию.

Не используйте грубые имена и названия.

Неправильно

Правильно

«Оригинальные» названия это не плохо, но во всём важна мера.

Неправильно

Правильно

Когда нужно подготовить макеты для публикации во внешний мир, старайтесь не использовать реквизиты реальных организаций. Невозможно гарантировать, что человека с некоторым ФИО или организации с определённым названием или ИНН не существует, или что они не появятся в будущем, но можно снизить вероятность претензий:

• не используйте реквизиты известных людей и организаций;
• когда нужно проиллюстрировать неприятную ситуацию, используйте «невозможные» реквизиты.

Неправильно

Правильно