Какие компоненты интерфейса должны быть собраны в дизайн-систему?

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

Обобщая прочитанное, в дизайн-систему следует инкапсулировать все повторяющиеся и атомарные элементы: кнопки, поля ввода, навигацию, типографику, модальные окна и сетки. Как отмечал Брэд Фрост в своей методологии Atomic Design, фундаментальные "атомы" и "молекулы" формируют связную структуру. Дополнительно следует охватить тональность коммуникации и руководство по композиции, что формирует целостную парадигму взаимодействия.

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

Раньше в 2010-х мы вообще обходились без дизайн-систем, просто копировали стили из PSD-шек, и ничего. Сейчас подход изменился. В первую очередь, собирать стоит то, что напрямую влияет на взаимодействие с пользователем: тултипы, уведомления, скелетоны загрузки и состояния ошибок. Атомарные кнопки с полями - это база, её все собирают, но вот состояния (пусто, загрузка, ошибка) почему-то часто забывают, а зря. Это как раз то, что в старые времена «выпадало» при верстке, и потом дизайнеры воевали с разработчиками.

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