Scott
Экран объединения должен заранее показывать, какой станет итоговая запись. Пользователю важно видеть, какие значения сохранятся, что произойдёт со связанными данными и можно ли отменить решение. Похожие названия — повод проверить записи, но ещё не доказательство того, что они относятся к одному человеку или одной организации.
Разберём объединение двух записей о поставщике в системе закупок. Руководство по таблицам данных в Pixso объясняет, как устроить строки и элементы выбора, с которых начинается эта задача. Здесь главное решение возникает уже после выбора двух записей: какие именно данные должны остаться в объединённой записи?
Разделите проверку поставщика, выбор значений и работу со связями
Представьте, что в системе закупок есть две записи о Northstar Studio. В SUP-104 указан прежний адрес электронной почты для счетов и привязаны три заказа на закупку. В SUP-218 — более новый адрес для счетов и два заказа. Один заказ связан с обеими записями. Совпадающее название компании позволяет предложить их для проверки, однако разные юридические адреса могут указывать на две самостоятельные организации.
Интерфейс должен ответить на три отдельных вопроса. Действительно ли эти записи нужно объединить? Какие значения сохранить в полях, где данные различаются? Что произойдёт с заказами, заметками, файлами и ссылками на записи? Единственное правило «оставить самую новую запись» скрывает все три решения за одним выбором по умолчанию.
Рядом с названием показывайте постоянный идентификатор записи и сведения, по которым можно заметить ошибочное совпадение. Подтверждённый домен, номер учётной записи или известный адрес офиса могут быть полезнее ещё одной аватарки. Для важных данных укажите источник и время последней проверки. Надпись «Обновлено вчера» мало говорит о достоверности контакта, если вчера в записи изменили только метку.
Оставьте понятный выход без объединения. В списке возможных дубликатов действия «Это разные поставщики» и «Проверить позже» означают разное. Первое отклоняет предположение о совпадении, второе оставляет вопрос открытым. Ни одно из них не должно незаметно удалять запись или закрывать другие предложения, которые пользователь не рассматривал.
Объясните выбор по умолчанию, не выдавая его за проверенные данные
Предварительный выбор сокращает работу, если его причина понятна. Команда может предпочесть запись, связанную с системой закупок, но взять контакт для счетов из второй записи. Явно обозначьте предпочтительный источник и покажите каждое выбранное значение в колонке результата. Одной стрелки слева направо недостаточно, чтобы объяснить, чьи данные будут сохранены.
Правила зависят от продукта. В документации HubSpot об объединении записей описаны выбор сохраняемых значений, объединение связей и невозможность отменить объединение. У Attio описан другой подход: при конфликте приоритет получают значения записи справа, а итоговая запись получает новый идентификатор. Оба материала доступны на английском. Эти примеры показывают, почему интерфейс должен объяснять собственные правила: слово «основная» не везде означает одно и то же.
Отделяйте предпочтительный источник значений от идентичности итоговой записи. Если название и электронная почта взяты из SUP-104, это ещё не означает, что после объединения сохранится идентификатор SUP-104. Если система создаёт новый идентификатор, покажите это последствие. Поведение существующих ссылок тоже нужно согласовать с разработчиками: обещать переход к итоговой записи можно только тогда, когда приложение действительно его поддерживает.
Сравнивайте различия отдельно для каждого поля
На большом экране при умеренном количестве полей удобно сопоставить три колонки: источник A, источник B и выбранный результат. Название поля должно оставаться рядом с соответствующей строкой. Обозначайте различие текстом или значком вместе с цветом, а выбранное значение визуально отделяйте от варианта, который лишь доступен для выбора.
| Поле | SUP-104 | SUP-218 | Решение при проверке |
|---|---|---|---|
| Название поставщика | Northstar Studio | Northstar Studio | Значения совпадают: сохранить одно. |
| Почта для счетов | accounts@northstar.example | billing@northstar.example | Выбрать адрес после проверки, какой из них поставщик использует для счетов. |
| Ответственный | Морган Ли | Не указан | Сохранить Морган Ли, если пустое поле означает отсутствие записанного значения. |
| Срок оплаты | 30 дней | 45 дней | Требуется проверка: недавнее изменение ещё не подтверждает действующие условия договора. |
| Заказы на закупку | Связано 3 заказа | Связано 2 заказа | Показать 4 уникальных заказа с учётом одного общего. |
Сохраняйте идентификатор источника рядом с выбранным значением: тогда пользователь сможет проследить происхождение результата, не открывая обе записи заново.
Для длинных записей предложите режим «Показать различия», сохранив возможность «Показать все поля». Совпадающее значение тоже может быть ошибочным, поэтому перед подтверждением человеку может понадобиться вся запись. Если несколько конфликтов ещё не разрешены, перечислите их рядом с действием: «Выберите срок оплаты и почту для счетов». Недоступная кнопка без объяснения не подсказывает, как продолжить.
Не считайте все пустые поля одинаковыми. «Не заполнено», «Значение намеренно удалено» и «Нет права на просмотр» могут требовать разной обработки. Скрытое из-за ограничений доступа значение нельзя показывать как пустое поле, которое пользователь может без последствий перезаписать. Если защищённое поле мешает корректно объединить записи, объясните, кто может его проверить, не раскрывая само значение.
Покажите связанные объекты, а не просто сумму их количеств
Объединение затрагивает не только поля в таблице сравнения. Заказы могут ссылаться на поставщика по внутреннему идентификатору. За одинаковыми именами файлов могут скрываться разные документы. У заметок есть авторы и даты, которые должны сохраниться у исходной заметки.
В нашем примере в результате остаются четыре разных заказа, а не пять. Покажите сами связанные объекты или содержательную сводку с возможностью раскрыть подробности, включая заказ, который присутствовал с обеих сторон. Обещание «Все данные сохранятся» не подходит, если часть связей объединяется, ограничена правами или обрабатывается отдельно.
Объясняйте исключения в тот момент, когда они влияют на решение. Если внешняя интеграция запрещает объединение конкретной записи, сообщите об этом до того, как человек разберёт ещё двенадцать полей. Если вложение нельзя перенести, назовите его и предложите доступный способ решить проблему. Интерфейс должен отличать правило, блокирующее всю операцию, от необязательного объекта, который пользователь вправе сознательно не переносить.
Для полей с особыми правилами недостаточно простого приоритета источников. Настройки подписки, права доступа и подтверждённые идентификационные данные должны обрабатываться по правилам продукта. Более свежая дата или наличие непустого значения сами по себе не делают источник достоверным.
Подтвердите последствия и покажите фактический результат
Полезное подтверждение подводит итог уже сделанному выбору: «Объединить две записи о поставщике в одну». Рядом покажите выбранную почту для счетов, итог по заказам и необратимые последствия, если они есть. Когда экран сравнения уже ясно передаёт эту информацию, дополнительное общее окно «Вы уверены?» мало что добавляет. Расположите окончательное действие там, где удобно проверить результат.
Название кнопки должно прямо называть операцию, например «Объединить записи поставщика». Действия «Отмена» и «Назад к записям» тоже должны быть однозначными. Предлагайте отмену объединения только в том случае, если система может восстановить соответствующие значения, связи и изменения в связанных процессах. Запись в журнале подтверждает, что изменение произошло, но сама по себе не восстанавливает данные.
После отправки запроса визуально разделяйте выполнение и завершение. «Запрос на объединение отправлен» не должно выглядеть как «Записи объединены». Если обработка продолжается в фоне, предусмотрите постоянное место, где можно узнать её состояние, и объясните, как туда вернуться. Медленный ответ не должен запускать второе объединение.
При обрыве соединения результат может остаться неизвестным. В такой ситуации предложите проверить состояние уже запущенной операции, а не сообщайте, что ничего не изменилось. Подтверждённая ошибка проверки данных — другой случай: покажите конкретное поле или связь, из-за которых объединение не прошло, сохраните выбор пользователя и дайте исправить проблему.
Предусмотрите и одновременное редактирование. Допустим, пока открыт экран сравнения, коллега изменил почту для счетов. Перед выполнением операции нужно сравнить данные, по которым строился предварительный результат, с текущими записями. Если они изменились, покажите новое значение и предложите пересмотреть затронутое решение. Незаметное применение устаревшего результата лишает тщательное сравнение смысла.
После завершения откройте итоговую запись или дайте на неё ссылку, объясните судьбу двух исходных записей и сохраните понятную историю изменений. Руководство по дизайну журнала аудита объясняет, как показать исполнителя, действие, затронутые записи и результат, не смешивая их с ошибкой загрузки интерфейса.
Сохраните удобство сравнения на телефоне и при работе с клавиатурой
Если просто сжать три колонки до ширины телефона, длинные значения станет трудно сравнивать. Лучше сгруппировать каждое поле по вертикали: название, значение из SUP-104, значение из SUP-218, затем выбранный результат. Повторяйте короткие идентификаторы записей возле каждого варианта, чтобы пользователь не держал в памяти заголовок, который уже ушёл за пределы экрана.
Для выбора одного сохраняемого значения используйте подходящий элемент выбора с подписью, включающей поле и источник. Одной цветной ячейки, по которой можно нажать, недостаточно. Если в строке разрешено объединить несколько значений, явно объясните это правило, чтобы оно не выглядело ещё одним выбором единственного варианта.
Делайте клавиатурный фокус заметным и сохраняйте его при обновлении предварительного результата. Сообщайте скринридеру об изменении результата, но не переносите фокус в его колонку после каждого выбора. Если отправка выявила неразрешённый конфликт, покажите сводку ошибок со ссылкой на соответствующий элемент управления. Проверьте реализованные элементы со вспомогательными технологиями: описание в макете задаёт поведение, а проверка проводится в работающем интерфейсе.
Сначала соберите в Pixso логику выбора
В файле дизайна Pixso разместите две записи о поставщике и предварительный вид итоговой записи. Используйте конкретные значения из примера, включая разные сроки оплаты и общий заказ. Соберите одну повторно используемую строку сравнения, затем используйте её экземпляры для остальных полей, чтобы сохранить единые отступы и оформление выбора.
Подготовьте отдельные фреймы для начальной проверки, смены выбранной почты, неразрешённого конфликта, выполнения операции, неизвестного результата, изменения исходной записи коллегой и готовой итоговой записи. Соедините нужные переходы по нажатию в прототипе. Так участник проверки сможет пройти решения пользователя; сверка данных и само объединение реализуются в приложении.
Дайте коллеге конкретную задачу: «Сохраните проверенную почту для счетов из SUP-218, оставьте назначенного ответственного и выясните, сколько заказов останется». Наблюдайте, какую информацию человек ищет и может ли объяснить результат до нажатия окончательной кнопки. Если не может, улучшите сравнение или формулировку последствий, вместо того чтобы добавлять ещё одно предупреждение.
При передаче в разработку разместите правила выбора значений рядом с соответствующими строками, а поведение при ожидании, ошибке и одновременном изменении — возле нужных фреймов. Укажите поддерживаемые способы восстановления и правила обновления связанных записей.
