Выберите оптимальный подход к именованию для UI-сущностей в дизайн-системах и избегайте траты времени и ресурсов.

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

Дизайн-системы могут иметь сотни и более сущностей, и для упрощения ссылок в проектах каждая сущность должна иметь уникальный идентификатор, имя, под которым инкапсулируется определение.

«Имя - это что-то бессмысленное в том смысле, что оно не выражает универсальное, и по той же причине оно кажется просто условным, произвольным, поскольку на самом деле имена собственные могут быть произвольно приняты, присвоены или также изменены. . “

Георг Вильгельм Фридрих Гегель. Наука логики.

Проще говоря, все системы знаний «заботятся» только об определениях, а не о самих именах, а только об их уникальности. Название кнопки «пончик с желе» не сделает ее пончиком с желе, поскольку ее характеристики и поведение определяют ее иначе. Эмпирическое правило любой системы состоит в том, что сначала дается определение, затем дается имя, а не наоборот.

Кроме того, в дизайн-системах имена должны быть стандартизированы для использования всеми заинтересованными сторонами (разработчиками, тестировщиками, дизайнерами, бизнес-аналитиками, функциональными дизайнерами) на всех уровнях продукта: документация, код, концепции, сценарии тестирования и т. Д.

Есть две противоположные тенденции в том, как давать определения определениям, каждая со своими плюсами и минусами:

  1. Склонность имени содержать определение внутри имени. Имя содержит (является) определение, является конкретным именем;
  2. Склонность имени абстрагироваться от определения. Имя не содержит определения, является абстрактным именем.

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

Именование сущностей UI: конкретный подход

Здесь наблюдается тенденция к частичному включению определения в название. Полное включение определения в название будет повторением определения - избыточностью.

Примеры конкретных имен для UI-сущностей:

  • «Товар в списке покупок» - элемент списка, в котором отображаются товары;
  • «Icon Button Tooltip» - текстовая подсказка действия / функции иконки кнопки;
  • «Фиолетовая бирка товара» - этикетка, прикрепляемая к объекту с целью идентификации, цвет бирки фиолетовый;
  • «Таблица цен на автомобили» - таблица, содержащая автомобили и их цены.
  • «Синяя текстовая кнопка» - интерактивный элемент с белой текстовой меткой, запускающий действие и окрашенный в синий цвет.

Конкретный подход приводит к более легко запоминающейся идентификации определений для большинства заинтересованных сторон, но проблема в том, что если ключевое измерение или поведение в определении изменится (например, наша синяя кнопка теперь оранжевая), нам придется либо 1) переименуйте объект в соответствии с определением, чтобы избежать путаницы, или 2) абстрагируйте имя от определения, рассматривайте его как что-то бессмысленное, как набор букв или случайных слов, которые не описать содержимое (например, сохранить название синей кнопки, превращенной в оранжевую, как «Синяя текстовая кнопка»).

  1. Переименование будет работать, но обновление имен на первый взгляд может показаться простым, учитывая унификацию имен на разных уровнях продукта (кодирование, тестирование, проектная документация, билеты задач, перекрестные ссылки), изменение одного имени приведет к заставляют команду работать много человеко-часов. Эта проблема становится еще более «болезненной» при использовании подхода MVP (минимально жизнеспособный продукт), поскольку с каждым спринтом есть шанс, что требование изменится, поэтому определение изменится, поэтому имя определения будет противоречить определению.
  2. Абстрагирование имени от определения, трактовка имени как чего-то бессмысленного, как показывает практика, слишком сложно для неподготовленного ума (который не используется для абстракций), поскольку он всегда пытается экстраполировать имя на определение.

Еще одна проблема с этим подходом - субъективность интерпретации. Конкретные имена субъективны; разные заинтересованные стороны могут по-разному интерпретировать определения, делать акцент на одних характеристиках, игнорируя другие, и иметь разные ассоциации. Простая процедура наименования (присвоение уникального идентификатора) может попасть в ловушку выяснения, чья интерпретация определения лучше - ловушка поиска того, кто прав или кто ошибается в интерпретациях - ложная цель именования. Для одного заинтересованного лица элемент может быть назван «кнопкой», потому что он выглядит как кнопка, но для других его можно назвать «ссылкой», потому что он ведет себя как ссылка. Они оба субъективно правы; мы здесь не для того, чтобы определять, чья интерпретация лучше, и оба эти имени работают, если они уникальны.

Именование объектов пользовательского интерфейса: абстрактный подход

В отличие от предыдущего подхода, здесь тенденция состоит в том, чтобы ни в какой степени не включать указанное определение в имя. Имя абстрагируется от содержания и рассматривается как нечто бессмысленное. Подойдут любые полностью случайные существительные, имена собственные, числа и буквы, если они уникальны, поскольку единственная цель именования - дать определению уникальный идентификатор.

Примеры:

  • Существительные собственные: Алиса, Джон, Юпитер, Альфа, Лондон и т. Д.
  • Случайный набор цифр и букв: ITM-56657; BB-12662-C; as24s # 42523, R2D2, C3PO и др.
  • Случайные существительные, которые абстрагируются от их собственного определения и определения именования, например, яблоко, апельсин, автомобиль, гора, небо, синий.

Абстрактный подход имеет дело с проблемами, которые проявляются в противоположном подходе. Поскольку имя не привязано к определению, при изменении определения нет необходимости обновлять имя в каких-либо слоях продукта; он хорошо справляется с изменениями требований. Если согласовано, что все приведенные имена абстрагируются от определения, то этот подход отрицает субъективность интерпретации заинтересованной стороны; Сеансы присвоения имен становятся довольно быстрыми и не требуют присутствия всех заинтересованных сторон, и любое имя равнозначно, если согласовано, что оно абстрагируется от контента. Вы можете заметить, что этот подход широко используется в машиностроении, например, производители автомобилей, электроники и т. Д., Ссылки на детали через номера деталей.

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

В какой-то момент заинтересованные стороны изучат новый словарь и сформируют ассоциации между абстрактными именами и фактическим названным контентом, изучат новый язык дизайн-системы. Это означает, что даже абстрактные имена через их ассоциации с определениями (внешностью и поведением) со временем станут конкретными со всеми чертами и проблемами - логический переход прямо к конкретному подходу с его плюсами и минусами.

Именование абстракции: разделение конкретного и абстрактного подхода

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

Сосредоточиться на том, чтобы сделать имена идеально абстрактными или в идеале конкретными, невозможно. Какое бы название вы ни выбрали, оно всегда будет содержать оба этих момента. Невежественные умы сосредоточатся на одном из моментов с его плюсами и минусами. Две группы невежественных умов, сосредоточенные на противоположных моментах, приведут к противостоянию мнений. Проблема здесь в том, что обе эти группы правы, а конфронтации - пустая трата времени и ресурсов. Образованные умы не будут сосредотачиваться на этих моментах и ​​будут сосредоточены исключительно на том, чтобы сделать имена уникальными.

Снижение конкретности и абстракции заключается в уникальности имени. Единственная цель именования определений - дать уникальный идентификатор, который согласован на всех уровнях продукта и заинтересованных сторон, используя один из обозначенных моментов: абстрактный или конкретный. Уникальные имена не нужно переименовывать, но имена могут сбивать с толку некоторых заинтересованных лиц. И либо заинтересованные стороны их узнают, либо определения будут переименованы. И уникальность, и запоминаемость недостижимы из-за плюсов и минусов лежащих в основе абстрактных и конкретных подходов.

Практика именования

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

Передовая практика сеанса именования состоит из трех шагов:

  1. Проблема и теория наименования и имеющиеся риски доводятся до сведения всех заинтересованных сторон для повышения осведомленности; описаны абстрактный и конкретный подход, его плюсы и минусы. Объясняется, что имена нужны для целей идентификации и что всегда будут запутанные имена, с которыми можно справиться с переименованием. Переименование следует свести к минимуму из-за рисков.
  2. Инженер дизайн-системы должен начинать с временных имен для новых элементов, чтобы их не блокировал ожидание решения о том, как назвать определенные элементы. На этом этапе переименование не потребует больших усилий, и его легко сделать, поскольку они локализованы внутри части документа.
  3. Когда выделено достаточно элементов с временными именами, следует организовать сеанс именования. На этих сессиях инженер-системотехник должен представлять каждый элемент один за другим заинтересованным сторонам, в идеале, по крайней мере, одной заинтересованной стороне с другого уровня продукта: разработка, тестирование, функциональный дизайн, владелец продукта, бизнес-аналитика. Представлен каждый элемент, и название проходит доработку и окончательное утверждение. Если какое-то имя сбивает с толку большинство, любой участник может позже предложить лучшее имя для голосования. Будьте готовы к множеству мнений и дебатов во время этих дискуссий; имя, получившее наибольшее количество голосов, становится официальным - истинная демократия. После этого сеанса имена блокируются, документация обновляется с правильными именами, если это необходимо, и передается дальше для уточнения разработки.

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

Мой опыт показал, что этот подход является оптимальным и позволяет команде Design System не преследовать ложные цели при построении дизайн-систем, оптимизировать время и ресурсы клиентов и справляться с рисками, недопониманием и недопониманием.