Тема 3.2 — Дизайн-системы и прототипирование

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

Почему это важно в здравоохранении и уходе#

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

Дизайн-система — способ перестать снова и снова платить за одни и те же ошибки. Когда доступный, хорошо протестированный компонент создан один раз и повторно используется в десятках услуг, вы исправляете дефект доступности или неоднозначность безопасности в одном месте, и каждая услуга наследует исправление. Альтернатива — индивидуальные фронтенды везде — означает неизвестное, неравномерное качество: одни услуги соответствуют Web Content Accessibility Guidelines (WCAG), а другие тихо исключают именно тех людей, которые больше всего зависят от услуг общественного здравоохранения.

Согласованность — также вопрос понимания. Пациенты и персонал перемещаются между услугами (приложение National Health Service (NHS), портал амбулаторных приёмов траста, инструмент записи в практике врача общей практики), и каждый незнакомый паттерн налагает когнитивную нагрузку. В популяции, включающей людей нездоровых, тревожных, пожилых, цифрово исключённых или использующих вспомогательные технологии, эта нагрузка распределена неравномерно. Общие паттерны снижают её для всех. Эта тема — об аппарате (компоненты, паттерны, токены, прототипы и операции дизайна), делающем безопасный, доступный, согласованный дизайн путём наименьшего сопротивления, а не актом героизма.

Ключевые понятия#

Дизайн-система — единый источник истины для повторно используемых компонентов, паттернов, стилей и руководств, применяемых для создания набора цифровых услуг. Это больше, чем руководство по стилю: она сочетает работающие, закодированные компоненты с проектным обоснованием, заметками о доступности и указаниями по использованию, которые говорят, когда и как использовать каждый. Два наиболее релевантных публичных примера — дизайн-система NHS (поддерживается NHS England, построена на фронтенде NHS.UK) и GOV.UK Design System, поддерживаемая Government Digital Service (GDS). Обе открыты, свободно доступны и проверены боем в миллионах взаимодействий.

Библиотека компонентов содержит отдельные строительные блоки (кнопки, поля ввода форм, заголовки, сводки ошибок), тогда как библиотека паттернов содержит решения более высокого порядка для повторяющихся проблем: как спросить дату рождения, как структурировать страницу вопросов, как сообщить об ошибке, как спросить у пользователя номер NHS. Компоненты — словарь; паттерны — предложения. Оба опираются на компонентную разработку программного обеспечения, где системы собираются из слабо связанных, независимо тестируемых, повторно используемых частей.

Токены дизайна (design tokens) — наименьшие общие решения, выраженные именованными переменными: цвет, единица интервала, размер шрифта, контур состояния фокуса. Поскольку токены используются по имени, а не жёстко прописаны, изменение токена (скажем, повышение минимального размера цели касания или контраста) последовательно распространяется на каждый компонент, который его использует. Токены — механизм, удерживающий систему связной по мере роста и позволяющий оформлять общую систему в местной теме без её форка.

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

Прототипирование программного обеспечения — практика построения намеренно неполных версий услуги, чтобы чему-то научиться до того, как вы обязуетесь строить настоящую вещь. Прототипы варьируются от низкой достоверности (бумажные наброски, макеты в оттенках серого) до высокой достоверности (интерактивные, реалистичные, часто построенные в коде). Принцип GDS — прототипировать, чтобы учиться, а не чтобы оставить: задача прототипа — ответить на вопрос через тестирование удобства использования с реальными пользователями, после чего он выбрасывается; это одноразовое (или «быстрое») прототипирование, отличное от эволюционного прототипа, который вы намерены закалить до производства.

DesignOps (операции дизайна) — дисциплина ведения дизайна в масштабе: люди, рабочие процессы, управление, модель вклада и инструменты, поддерживающие общую дизайн-систему здоровой, финансируемой и заслуживающей доверия в организации или интегрированной системе ухода (ICS). Это для дизайна то же, что платформенная инженерия для кода: в основном невидима, когда работает, мучительно очевидна, когда нет. Прототипирование ведётся в инструментах дизайна вроде Figma или непосредственно в коде с использованием фронтенда дизайн-системы, что подводит нас к фронтенд-разработке, слою HTML, CSS и JavaScript, где повторное использование реально сокращает дублирование, затраты и риск.

Эта тема сознательно не повторяет потребности пользователей (см. тему 3.0 — Исследование пользователей и проектирование услуг) и как пишутся слова (см. тему 3.1 — Проектирование контента и медицинская грамотность). Эти дисциплины питают дизайн-систему; эта тема — о повторно используемом аппарате, безопасно проводящем их выводы в производство.

Лучшие практики#

1. Принимайте готовое, прежде чем строить. Начинайте с дизайн-системы NHS и GOV.UK Design System, а не изобретайте собственную. Они уже кодируют годы тестирования доступности, проектирования контента и реального использования в службах здравоохранения и правительства. Изобретать заново выбор даты или сводку ошибок — не лучшее использование дефицитной, дорогой проектной и инженерной мощности, а доморощенная версия почти всегда будет менее доступной. Расширяйте и оформляйте в темах эти системы под местные нужды; не делайте форк без обдуманной, задокументированной причины.

2. Закладывайте доступность и клиническую безопасность в общие компоненты, а не в отдельные экраны. Весь экономический довод и довод безопасности дизайн-системы в том, что вы исправляете что-то один раз и наследуете везде. Доступный, навигируемый с клавиатуры, протестированный с программой чтения с экрана компонент даты рождения, построенный и гарантированный один раз, защищает каждую услугу, которая им пользуется. Закладывайте соответствие WCAG, разумную обработку ошибок и релевантное для безопасности поведение (чёткое подтверждение разрушительных действий, однозначные единицы для доз и измерений) в сам компонент, чтобы командам было нелегко ошибиться (см. тему 1.9 — Цифровая инклюзия и доступность и тему 1.6 — Клиническая безопасность и управление рисками).

3. Прототипируйте, чтобы учиться, а не чтобы оставить. Относитесь к прототипам как к одноразовым экспериментам, отвечающим на конкретный вопрос («может ли пациент с низкой медицинской грамотностью завершить это направление?») дёшево и быстро. Соотносите достоверность с вопросом: используйте наброски низкой достоверности, чтобы рано тестировать поток и понимание, и закодированные прототипы высокой достоверности, чтобы позже тестировать реалистичное взаимодействие, доступность и крайние случаи. Сопротивляйтесь соблазну продвинуть прототип прямо в производство; код прототипа, оптимизированный под скорость обучения, редко достаточно безопасен, защищён или поддерживаем для действующей клинической услуги.

4. Прототипируйте в настоящем фронтенде, когда вопрос — взаимодействие и доступность. Прототипы в инструментах дизайна (Figma и подобные) отлично подходят для быстрого, совместного исследования компоновки, потока и содержания. Но они не могут достоверно тестировать навигацию с клавиатуры, поведение программы чтения с экрана, управление фокусом или производительность на старом оборудовании парка NHS. Когда риски именно в этом, прототипируйте в коде с использованием фронтенда дизайн-системы, чтобы вы тестировали нечто близкое к тому, что реальные пользователи на самом деле будут переживать с реальными вспомогательными технологиями.

5. Тестируйте прототипы с реальными пользователями до разработки. Прототип, который никогда не ставят перед репрезентативными пользователями, — просто дорогое мнение. Тестируйте с людьми, отражающими ваше реальное население, включая пожилых, людей с инвалидностью, с низкой цифровой уверенностью и персонал, работающий под давлением времени. Даже пять участников выявят большинство серьёзных проблем удобства использования и понимания, а находить их в прототипе на порядки дешевле, чем в производстве (см. тему 3.7 — Тестирование и обеспечение качества).

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

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

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

9. Измеряйте принятие и качество, а не только существование. Дизайн-система приносит ценность, только когда ею пользуются. Отслеживайте, какие услуги используют общие компоненты, где командам приходилось создавать индивидуальные альтернативы (и почему) и улучшается ли соответствие доступности по мере роста принятия. Высокая доля местных обходных путей — сигнал, что в системе не хватает чего-то реального; относитесь к ним как к бэклогу, а не как к неповиновению.

Вопросы для обсуждения с командой#

1. Где должна проходить линия между общей согласованностью и местной гибкостью и кто решает? Это центральное напряжение управления любой дизайн-системы. Слишком жёстко, и команды поставки чувствуют себя заблокированными, создают теневые компоненты и обходят систему, дробя ту самую согласованность, которую вы хотели защитить. Слишком мягко, и «система» становится слабо связанной кучей разовых решений без общих гарантий безопасности или доступности. В контексте здравоохранения и ухода ставки специфичны: некоторая вариация законна (кризисная служба психического здоровья имеет действительно иные потребности, чем обычная запись на приём), тогда как некоторая опасна (непоследовательные способы подтверждения разрушительного клинического действия). Хороший ответ называет, какие решения не подлежат обсуждению (доступность, критичные для безопасности паттерны, основное поведение взаимодействия), а какие открыты для местной темы, и определяет явный, гуманный процесс, по которому команда может запросить исключение или внести новый паттерн, а не просто запрещает расхождение.

2. Как доступность и клиническая безопасность на самом деле будут гарантироваться внутри наших компонентов и кто их согласует? Легко заявить, что доступность и безопасность «заложены»; трудно это гарантировать. Этот вопрос заставляет вас быть конкретным в отношении конвейера гарантий: кто тестирует каждый компонент по WCAG, с какими вспомогательными технологиями и с какими пользователями с инвалидностью; как поведение, релевантное для безопасности, рассматривается по вашему процессу клинической безопасности (DCB0129/DCB0160); и какие доказательства прилагаются к компоненту до публикации как «безопасного для повторного использования». Дебаты должны выявить честные пробелы: возможно, у вас есть автоматические проверки контраста, но никогда не было тестирования с реальным пользователем программы чтения с экрана или ваш специалист по клинической безопасности никогда не рассматривал общую библиотеку компонентов. Сильный ответ даёт названного владельца, определённый режим тестирования и правило, что ни один компонент не входит в общую библиотеку без задокументированных доказательств доступности и безопасности, потому что дефект, унаследованный пятьюдесятью услугами, — пятидесятикратный вред.

3. Кто финансирует, обеспечивает персоналом и поддерживает дизайн-систему, когда первоначальный энтузиазм угаснет? Дизайн-системы часто создаются в порыве энергии, а затем тихо забрасываются, когда основавшая команда уходит, оставляя устаревшую библиотеку, которой команды больше не доверяют. Это принципиально вопрос DesignOps и финансирования, а не дизайна. Обсудите честно, есть ли у вас постоянная, финансируемая команда, отвечающая за систему как за продолжающийся продукт, с мощностью для поддержки, пересмотра вкладов, версионирования и поспевания за вышестоящими системами NHS и GOV.UK, или вы полагаетесь на доброжелательность, которая испарится. В ICS это ещё острее: принадлежит ли система одной доминирующей организации, управляется ли совместно или осиротела между ними? Хороший ответ рассматривает дизайн-систему как долгоживущую инфраструктуру с названным владельцем, текущим бюджетом и ясным отношением к национальным системам, на которых она строится, а не как проект, который «заканчивается».

4. Каково наше отношение к вышестоящим системам NHS и GOV.UK и как мы будем оставаться в ногу с ними по мере их изменения? Принятие национальной дизайн-системы — не разовая загрузка; это постоянная зависимость от инфраструктуры, которой вы не управляете. Этот вопрос заставляет вас сознательно решить, где вы находитесь на спектре от «лёгкая тема и пристальное отслеживание вышестоящей системы» до «форк и расхождение». У каждого выбора есть цена: оставаться близко означает усваивать изменения вышестоящей системы (новое исправление доступности, пересмотренный паттерн) по чужому графику и иногда переделывать местные настройки; форк означает, что вы владеете каждым будущим исправлением доступности и безопасности, которое национальная команда иначе дала бы вам бесплатно. В здравоохранении и уходе тяга расходиться реальна (клинические рабочие процессы и местный брендинг создают подлинное давление), но каждое расхождение — постоянное обязательство. Хороший ответ называет, кто следит за примечаниями к релизам вышестоящей системы, как структурированы местные расширения, чтобы пережить обновление вышестоящей системы, и явный критерий, который должно пройти предложенное расхождение, прежде чем оно будет разрешено, чтобы «нам нужно, чтобы это выглядело иначе» никогда тихо не превращалось в «мы теперь поддерживаем устаревший, менее доступный форк выбора даты NHS».

5. Как мы на самом деле будем держать линию между «прототипировать, чтобы учиться» и «строить, чтобы оставить»? В принципе все согласны, что одноразовые прототипы не должны становиться производственными услугами; сбой происходит под давлением срока, когда убедительный прототип высокой достоверности лежит прямо тут, а его выпуск выглядит коротким путём. Этот вопрос делает границу конкретной, а не желаемой. Обсудите, что практически мешает коду прототипа (оптимизированному под скорость обучения, а не под безопасность, устойчивость или поддерживаемость) быть продвинутым в действующую клиническую услугу: техническое разделение (прототипы строятся в песочнице, не достающей производства), ворота управления (нет согласования клинической безопасности, нет запуска) или просто общее доброе намерение, испаряющееся при первом сдвиге даты поставки? Ставки здравоохранения и ухода специфичны, потому что негарантированный код в клиническом маршруте — уязвимость безопасности пациентов, а не просто технический долг. Честный ответ признаёт, откуда придёт давление, называет, кто уполномочен сказать «нет», и определяет, что на самом деле требует «пересборка для производства из гарантированных компонентов», чтобы граница держалась, когда её проверят.

6. Как мы узнаем, действительно ли дизайн-система работает и что мы будем делать, когда метрики неудобны? Дизайн-система может существовать, быть красиво задокументирована и всё равно приносить мало ценности, если команды тихо её обходят. Этот вопрос выходит за «у нас есть дизайн-система» к «окупается ли она». Решите, что вы будете измерять: принятие по услугам, долю и причины индивидуальных обходных путей, действительно ли соответствие доступности улучшается по мере роста принятия и сколько времени команды экономят, используя повторно, а не пересобирая. Трудная часть — не сбор чисел, а заблаговременное согласование того, как вы будете их читать, потому что высокая доля местных обходных путей — сигнал, что в общей системе не хватает чего-то реального, а не доказательство, что команды поставки непослушны. Хороший ответ обязуется считать неудобные данные о принятии входом для бэклога и дорожной карты, определяет, кто их пересматривает и как часто, и сопротивляется соблазну измерять только лестное (существование, число загрузок) вместо того, что важно (более безопасные, доступные, согласованные услуги, действительно поставленные).

На практике: пример из здравоохранения и ухода#

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

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

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

Только тогда они строят по-настоящему, собирая производственную услугу в основном из гарантированных, повторно используемых компонентов. Через восемнадцать месяцев обновление WCAG ужесточает требования к видимости фокуса. Поскольку стиль фокуса живёт в единственном токене дизайна, команда выпускает одно изменение, и каждая услуга ICS наследует его в следующем релизе: исправление, которое в прежнем раздробленном парке означало бы пять отдельных проектов по устранению и, реалистично, по меньшей мере одну услугу, оставленную сломанной.

Отраслевые перспективы#

Стартап#

Небольшой стартап цифрового здравоохранения почти никогда не должен строить собственную дизайн-систему с нуля: он не может позволить себе накладные расходы на тестирование доступности, а инвесторы платят за клиническую валидацию, а не за индивидуальные кнопки. Принимайте фронтенд NHS или GOV.UK там, где строите для пользователей NHS, и считайте прототипирование вашим основным конкурентным преимуществом: дешёвые, быстрые, одноразовые прототипы, протестированные с реальными пациентами, позволяют учиться быстрее, чем лучше финансируемые действующие игроки. Риск обратный: продвижение лощёного прототипа высокой достоверности прямо в производство, чтобы успеть к демонстрации для инвестора, с переносом негарантированного, небезопасного кода в действующую клиническую услугу. Держите жёсткую линию между «прототипировать, чтобы учиться» и «строить, чтобы оставить», даже под давлением финансирования.

Малый бизнес#

Устоявшийся небольшой поставщик (практика врача общей практики, общественная аптека, дом престарелых или клиника в одном месте, заказывающая инструмент для пациентов) имеет живых пациентов, но не имеет выделенных возможностей дизайна или фронтенда и не может позволить себе стоимость индивидуальных компонентов. Его самый мощный ход — настаивать, чтобы любой поставщик строил на фронтенде NHS или GOV.UK, чтобы гарантии доступности и безопасности были унаследованы, а не обещаны, и сделать это письменным условием контракта, а не надеждой. Ему редко нужно вести собственную дизайн-систему; ему нужно хорошо потреблять чужую и понимать, что лощёная демонстрация поставщика — не доказательство доступной, гарантированной действующей услуги. Там, где он всё же прототипирует (тестируя новый поток онлайн-записи с реальными, часто более пожилыми или менее цифрово уверенными пациентами), несколько сессий с реальными пользователями поймают гораздо больше, чем когда-либо раскроет отполированный макет. Применяются те же законодательные обязанности по доступности и клинической безопасности, что и к крупному тресту, так что честный вопрос не в том, соответствовать ли, а в том, как получить унаследованное соответствие дёшево от общей национальной инфраструктуры.

Крупная организация#

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

Государство#

Национальный орган вроде NHS England или GDS ведёт дизайн-систему как публичную инфраструктуру, используемую организациями, которыми он не управляет, поэтому открытость, стабильность и обратная совместимость чрезвычайно важны. Его обязательства самые сильные: законодательные правила доступности, обязанности равенства и реальность, что дефект в общем национальном компоненте распространяется на миллионы граждан. Работа — меньше изобретения и больше управления: ясное версионирование, политика устаревания, исчерпывающие доказательства доступности и отзывчивость к сотням команд ниже по цепочке. Дизайн-система NHS и GOV.UK Design System — эталонные примеры именно потому, что они рассматривают систему как долгоживущее общественное благо, а не проект.

Типичные способы сбоя#

• Заброшенная система. Дизайн-система создаётся с помпой, затем остаётся без поддержки, когда основавшая команда рассеивается; команды теряют доверие и возвращаются к индивидуальной работе. Избегайте этого, финансируя постоянную продуктовую команду, а не разовый проект.
• Картинка, которая лжёт. Файлы дизайна и производственный код расходятся, потому что нет единого источника истины, так что «дизайн-система» описывает то, чего продукт больше не делает. Держите закодированные компоненты и их документацию авторитетными и версионируемыми вместе.
• Доступность как запоздалая мысль. Компоненты поставляются без реального тестирования вспомогательными технологиями, поэтому недоступный паттерн наследуется везде, умножая, а не сокращая вред. Требуйте задокументированных доказательств WCAG и программы чтения с экрана до публикации любого компонента.
• От прототипа к производству. Прототип высокой достоверности продвигается прямо в действующую услугу, чтобы сэкономить время, перенося небезопасный, неподдерживаемый, негарантированный код в клиническую среду. Обеспечьте границу одноразовости; пересобирайте для производства из гарантированных компонентов.
• Огороженный сад. Центральная команда отвергает все вклады, поэтому система никогда не отвечает реальным потребностям услуг, а команды поставки её обходят. Опубликуйте процесс вклада и исключений и считайте местные обходные пути сигналом для бэклога.
• Театр согласованности. Жёсткое единообразие навязывается там, где оправдана подлинная местная вариация (кризисные службы, педиатрия), ухудшая безопасность и удобство использования во имя аккуратности. Различайте не подлежащие обсуждению решения и законно местные.
• Тестирование не на той достоверности. Риски взаимодействия и доступности «тестируются» только в статическом инструменте дизайна, не способном проверить поведение клавиатуры или программы чтения с экрана, давая ложную уверенность. Прототипируйте в коде, когда вопрос — взаимодействие.

Модель зрелости#

Контрольный список#

• Вы приняли дизайн-систему NHS и/или GOV.UK Design System как основу, а не строите с нуля.
• Общие компоненты несут задокументированные доказательства соответствия WCAG, протестированные с реальными вспомогательными технологиями и пользователями с инвалидностью.
• Компоненты, релевантные для безопасности, рассмотрены по вашему процессу клинической безопасности до публикации для повторного использования.
• Токены дизайна управляют цветом, интервалами, типографикой и состояниями взаимодействия, позволяя вносить изменения по всей системе из одного места.
• Существует единый источник истины, где закодированные компоненты и их руководство живут и версионируются вместе.
• Прототипы соответствуют по достоверности вопросу, тестируются на репрезентативной выборке пользователей и считаются одноразовыми.
• Потоки, критичные для взаимодействия и доступности, прототипируются в коде, а не только в инструменте дизайна.
• Финансируемая, названная команда владеет дизайн-системой как продолжающимся продуктом, с дорожной картой и каналом поддержки.
• Опубликованный процесс вклада и исключений позволяет командам поставки предлагать новые компоненты и паттерны.
• Принятие и качество измеряются, а высокая доля местных обходных путей рассматривается как бэклог, а не неповиновение.

Ключевые источники#

• Дизайн-система NHS — NHS England: компоненты, паттерны, стили и руководство по доступности для цифровых услуг NHS.
• GOV.UK Design System — Government Digital Service: стили, компоненты и паттерны для британских государственных услуг.
• GOV.UK Service Manual — прототипирование и «make a prototype» — Government Digital Service: руководство по прототипированию для обучения и тестированию с пользователями.
• NHS Digital Service Standard — NHS England: стандарт, по которому оцениваются общие и согласованные услуги.
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative: стандарт соответствия доступности.
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — правительство Великобритании: законодательная обязанность по доступности для услуг государственного сектора.
• Стандарты управления клиническими рисками DCB0129 / DCB0160 — NHS England: стандарты клинической безопасности для производства и внедрения систем медицинских ИТ.
• Design Council Double Diamond — Design Council: модель discover–define–develop–deliver, лежащая в основе исследования и проектирования.

Ссылки#

1. Design system — Wikipedia — https://en.wikipedia.org/wiki/Design_system
2. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
3. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
4. Usability testing — Wikipedia — https://en.wikipedia.org/wiki/Usability_testing
5. GOV.UK (and the GOV.UK Design System) — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
8. Component-based software engineering — Wikipedia — https://en.wikipedia.org/wiki/Component-based_software_engineering
9. Figma — Wikipedia — https://en.wikipedia.org/wiki/Figma
10. Front-end web development — Wikipedia — https://en.wikipedia.org/wiki/Front-end_web_development
11. NHS design system — NHS England — https://service-manual.nhs.uk/design-system
12. GOV.UK Design System — Government Digital Service — https://design-system.service.gov.uk/
13. Make a prototype — GOV.UK Service Manual — https://www.gov.uk/service-manual/design/making-prototypes
14. NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
15. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
16. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
17. Clinical Risk Management: its Application in the Manufacture of Health IT Systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation-for-clinical-risk-management-standards