Tópico 3.2 — Sistemas de design e prototipagem

Um sistema de design transforma boas decisões de design em infraestrutura compartilhada e reutilizável — de modo que acessibilidade, segurança clínica e consistência sejam incorporadas uma vez e herdadas em toda parte, em vez de rediscutidas e requebradas a cada tela.

Por que isso importa na saúde e nos cuidados#

Na saúde e nos cuidados, a interface costuma ser os últimos centímetros entre uma decisão clínica e um paciente. Um campo de medicação confuso, um seletor de datas inacessível, um botão que significa "cancelar consulta" num serviço e "cancelar e perder seus dados" em outro — não são problemas cosméticos. São problemas de segurança do paciente, de equidade e de confiança. Quando cada equipe projeta seus próprios componentes do zero, os defeitos se multiplicam e as garantias de segurança se tornam impossíveis de raciocinar em todo um portfólio.

Um sistema de design é como você deixa de pagar repetidamente pelos mesmos erros. Quando um componente acessível e bem testado é construído uma vez e reutilizado em dezenas de serviços, você corrige um defeito de acessibilidade ou uma ambiguidade de segurança num só lugar e todos os serviços herdam a correção. A alternativa — interfaces sob medida por toda parte — significa qualidade desconhecida e desigual: alguns serviços cumprem as Web Content Accessibility Guidelines (WCAG) e outros excluem silenciosamente as pessoas que mais dependem dos serviços públicos de saúde.

A consistência também é uma questão de compreensão. Pacientes e profissionais circulam entre serviços — um aplicativo do Serviço Nacional de Saúde (NHS), o portal ambulatorial de um hospital, uma ferramenta de agendamento de clínica geral — e cada padrão desconhecido impõe carga cognitiva. Numa população que inclui pessoas doentes, ansiosas, idosas, digitalmente excluídas ou que usam tecnologia assistiva, essa carga não se distribui de forma uniforme. Padrões compartilhados a reduzem para todos. Este tópico trata da maquinaria — componentes, padrões, tokens, protótipos e operações de design — que faz do design seguro, acessível e consistente o caminho de menor resistência, e não um ato de heroísmo.

Conceitos centrais#

Um sistema de design é uma fonte única da verdade para os componentes, padrões, estilos e orientações reutilizáveis usados para construir um conjunto de serviços digitais. É mais do que um guia de estilo: combina componentes funcionais e codificados com a justificativa de design, as notas de acessibilidade e as orientações de uso que dizem quando e como usar cada um. Os dois exemplos públicos mais relevantes são o sistema de design do NHS (mantido pelo NHS England, construído sobre o front-end do NHS.UK) e o Sistema de Design do GOV.UK, mantido pelo Government Digital Service (GDS). Ambos são abertos, de livre acesso e testados em batalha em milhões de interações.

Uma biblioteca de componentes guarda os blocos de construção discretos — botões, campos de formulário, cabeçalhos, resumos de erros —, enquanto uma biblioteca de padrões guarda as soluções de ordem superior para problemas recorrentes: como pedir uma data de nascimento, como estruturar uma página de perguntas, como relatar um erro, como pedir a um usuário o número do NHS. Os componentes são o vocabulário; os padrões são as frases. Ambos se baseiam na engenharia de software baseada em componentes, em que os sistemas são montados a partir de partes fracamente acopladas, testáveis de forma independente e reutilizáveis.

Os design tokens são as menores decisões compartilhadas expressas como variáveis nomeadas — uma cor, uma unidade de espaçamento, um tamanho de fonte, um contorno de estado de foco. Como os tokens são referenciados por nome e não fixados no código, uma mudança num token (digamos, aumentar o tamanho mínimo da área de toque ou o contraste) se propaga de modo consistente a todo componente que o utiliza. Os tokens são o mecanismo que mantém um sistema coerente à medida que escala e que torna possível adaptar visualmente um sistema compartilhado para uso local sem bifurcá-lo.

Uma fonte única da verdade é a ideia que governa: cada decisão de design é mantida em exatamente um lugar, de modo que não pode se dessincronizar entre serviços. Quando o design, o código e a orientação de um componente vivem numa única biblioteca autoritativa, você elimina a classe de erros em que a imagem e o produto divergem.

A prototipagem de software é a prática de construir versões deliberadamente incompletas de um serviço para aprender algo antes de se comprometer a construir o real. Os protótipos vão de baixa fidelidade (esboços em papel, wireframes em tons de cinza) a alta fidelidade (interativos, realistas, muitas vezes construídos em código). O princípio do GDS é prototipar para aprender, não para manter: o trabalho de um protótipo é responder a uma pergunta por meio de teste de usabilidade com usuários reais, após o que é descartado — é a prototipagem descartável (ou "rápida"), distinta de um protótipo evolutivo que você pretende endurecer até a produção.

O DesignOps (operações de design) é a disciplina de conduzir o design em escala — as pessoas, os fluxos de trabalho, a governança, o modelo de contribuição e as ferramentas que mantêm saudável, financiado e confiável um sistema de design compartilhado numa organização ou num sistema de cuidados integrados (ICS). Ele está para o design como a engenharia de plataforma está para o código: quase invisível quando funciona, dolorosamente óbvio quando não funciona. A prototipagem é feita em ferramentas de design como o Figma ou diretamente em código, usando o front-end de um sistema de design, o que nos leva ao desenvolvimento web front-end — a camada de HTML, CSS e JavaScript em que a reutilização de fato reduz duplicação, custo e risco.

Este tópico deliberadamente não retoma o que os usuários precisam (ver Tópico 3.0 — Pesquisa com usuários e design de serviços) nem como as palavras são escritas (ver Tópico 3.1 — Design de conteúdo e letramento em saúde). Essas disciplinas alimentam o sistema de design; este tópico trata da maquinaria reutilizável que leva suas conclusões com segurança até a produção.

Boas práticas#

1. Adote antes de construir. Parta do sistema de design do NHS e do Sistema de Design do GOV.UK em vez de inventar o seu. Eles já codificam anos de testes de acessibilidade, design de conteúdo e uso no mundo real em serviços de saúde e de governo. Reinventar um seletor de datas ou um resumo de erros não é um bom uso da escassa e cara capacidade de design e engenharia, e uma versão caseira será quase sempre menos acessível. Estenda e adapte visualmente esses sistemas às necessidades locais; não os bifurque sem uma razão deliberada e documentada.

2. Incorpore acessibilidade e segurança clínica aos componentes compartilhados, e não às telas individuais. Todo o argumento econômico e de segurança de um sistema de design é que você corrige algo uma vez e herda em toda parte. Um componente de data de nascimento acessível, navegável por teclado e testado com leitor de tela, construído e assegurado uma vez, protege todos os serviços que o usam. Incorpore ao próprio componente a conformidade com a WCAG, o tratamento sensato de erros e comportamentos relevantes para a segurança (confirmação clara de ações destrutivas, unidades inequívocas para doses e medidas), de modo que as equipes não consigam errar com facilidade (ver Tópico 1.9 — Inclusão digital e acessibilidade e Tópico 1.6 — Segurança clínica e gestão de riscos).

3. Prototipe para aprender, não para manter. Trate os protótipos como experimentos descartáveis que respondem a uma pergunta específica — "um paciente com baixo letramento em saúde consegue concluir este encaminhamento?" — de forma barata e rápida. Ajuste a fidelidade à pergunta: use esboços de baixa fidelidade para testar o fluxo e a compreensão cedo e protótipos codificados de alta fidelidade para testar a interação realista, a acessibilidade e os casos extremos mais tarde. Resista à atração de promover um protótipo diretamente à produção; o código de protótipo otimizado para a velocidade do aprendizado raramente é seguro, protegido ou sustentável o bastante para um serviço clínico em produção.

4. Prototipe no front-end real quando a interação e a acessibilidade são a pergunta. Os protótipos em ferramentas de design (Figma e similares) são excelentes para explorar layout, fluxo e conteúdo de forma rápida e colaborativa. Mas não conseguem testar com fidelidade a navegação por teclado, o comportamento do leitor de tela, o gerenciamento de foco nem o desempenho em equipamentos antigos do parque do NHS. Quando esses são os riscos, prototipe em código usando o front-end do sistema de design, para testar algo próximo do que os usuários reais de fato vivenciarão com tecnologia assistiva real.

5. Teste os protótipos com usuários reais antes de construir. Um protótipo que nunca é posto diante de usuários representativos é apenas uma opinião cara. Teste com pessoas que reflitam a sua população real — incluindo idosos, pessoas com deficiência, pessoas com baixa confiança digital e profissionais trabalhando sob pressão de tempo. Mesmo cinco participantes trarão à tona a maior parte dos problemas graves de usabilidade e compreensão, e encontrá-los num protótipo é ordens de grandeza mais barato do que encontrá-los em produção (ver Tópico 3.7 — Testes e garantia da qualidade).

6. Gerencie os tokens como o contrato da consistência. Expresse cores, espaçamento, tipografia e estados de interação como design tokens nomeados e trate as mudanças neles com a seriedade de uma mudança de dependência compartilhada. Os tokens permitem impor, em todo o sistema, o contraste mínimo, o tamanho da área de toque e a visibilidade do foco, e permitem que uma equipe local adapte a aparência à sua marca sem quebrar as garantias de acessibilidade subjacentes. Quando um padrão nacional muda, você quer mudar um token, e não auditar dez mil telas.

7. Adote um modelo de contribuição, e não um jardim murado. Um sistema de design que só aceita contribuição de uma equipe central sempre ficará atrás das necessidades reais dos serviços e será ressentido pelas equipes de entrega. Publique uma via clara para as equipes proporem novos componentes e padrões, com critérios para o que é aceito, quem revisa e como a acessibilidade e a segurança são asseguradas antes de qualquer coisa ser promovida à biblioteca compartilhada. Este é o trabalho central do DesignOps: equilibra a tensão entre flexibilidade local e consistência compartilhada sem deixar o sistema apodrecer ou se fragmentar.

8. Versione, documente e comunique as mudanças. Trate o sistema de design como um produto com usuários (as suas equipes de entrega), um roteiro, notas de versão e um canal de suporte. O versionamento semântico, os registros de mudanças e os avisos claros de descontinuação permitem às equipes adotar melhorias com segurança e no próprio ritmo. Mudanças incompatíveis não documentadas destroem a confiança que faz as equipes escolherem o sistema compartilhado em vez de fazerem o seu.

9. Meça a adoção e a qualidade, e não só a existência. Um sistema de design só entrega valor quando é usado. Acompanhe quais serviços usam os componentes compartilhados, onde as equipes tiveram de construir alternativas sob medida (e por quê) e se a conformidade de acessibilidade melhora à medida que a adoção sobe. Altas taxas de gambiarras locais são um sinal de que ao sistema falta algo real — trate-as como backlog, e não como desobediência.

Perguntas para discutir com a sua equipe#

1. Onde deve ficar a linha entre a consistência compartilhada e a flexibilidade local, e quem decide? Esta é a tensão de governança central de qualquer sistema de design. Rígido demais, e as equipes de entrega se sentem bloqueadas, constroem componentes paralelos e contornam o sistema — fragmentando a própria consistência que vocês queriam proteger. Frouxo demais, e o "sistema" vira uma pilha de peças avulsas pouco relacionadas, sem garantias compartilhadas de segurança ou acessibilidade. Num contexto de saúde e cuidados, o que está em jogo é específico: alguma variação é legítima (um serviço de crise de saúde mental tem necessidades genuinamente diferentes de um agendador de consultas de rotina), enquanto alguma variação é perigosa (formas inconsistentes de confirmar uma ação clínica destrutiva). Uma boa resposta nomeia quais decisões são inegociáveis (acessibilidade, padrões críticos para a segurança, comportamentos centrais de interação) e quais estão abertas à adaptação local e define um processo explícito e humano para uma equipe pedir uma exceção ou contribuir com um novo padrão, em vez de simplesmente proibir a divergência.

2. Como a acessibilidade e a segurança clínica serão de fato asseguradas dentro dos nossos componentes — e quem as aprova? É fácil alegar que a acessibilidade e a segurança estão "incorporadas"; é difícil garanti-lo. Esta pergunta obriga a ser concreto sobre o fluxo de garantia: quem testa cada componente frente à WCAG, com quais tecnologias assistivas e com quais usuários com deficiência; como os comportamentos relevantes para a segurança são revistos frente ao seu processo de segurança clínica (DCB0129/DCB0160); e que evidência é anexada a um componente antes de ele ser publicado como "seguro para reutilizar". O debate deve trazer à tona lacunas honestas — talvez vocês tenham verificações automáticas de contraste, mas nunca testaram com um usuário real de leitor de tela, ou o seu Responsável pela Segurança Clínica nunca revisou a biblioteca de componentes compartilhada. Uma resposta forte produz um responsável nomeado, um regime de testes definido e uma regra de que nenhum componente entra na biblioteca compartilhada sem evidência documentada de acessibilidade e segurança, porque um defeito herdado por cinquenta serviços é cinquenta vezes o dano.

3. Quem financia, dota de pessoal e mantém o sistema de design quando o entusiasmo inicial esmaecer? Os sistemas de design são frequentemente criados num surto de energia e depois silenciosamente abandonados quando a equipe fundadora segue em frente, deixando uma biblioteca obsoleta em que as equipes não confiam mais. Esta é, fundamentalmente, uma questão de DesignOps e de financiamento, e não de design. Debatam com honestidade se vocês têm uma equipe permanente e financiada, responsável pelo sistema como um produto contínuo — com capacidade para suporte, revisão de contribuições, versionamento e para acompanhar os sistemas de origem do NHS e do GOV.UK — ou se estão contando com uma boa vontade que se evaporará. Num ICS isso é ainda mais agudo: o sistema pertence a uma organização dominante, é governado em conjunto ou fica órfão entre elas? Uma boa resposta trata o sistema de design como infraestrutura de longa duração, com um responsável nomeado, um orçamento corrente e uma relação clara com os sistemas nacionais em que se baseia, e não como um projeto que "termina".

4. Qual é a nossa relação com os sistemas de origem do NHS e do GOV.UK — e como acompanharemos o ritmo deles quando mudarem? Adotar um sistema de design nacional não é um download único; é uma dependência contínua de uma infraestrutura que vocês não controlam. Esta pergunta obriga a decidir, deliberadamente, onde vocês se situam no espectro que vai de "adaptar levemente e acompanhar de perto a origem" a "bifurcar e divergir". Cada escolha tem um custo: ficar perto significa absorver as mudanças da origem (uma nova correção de acessibilidade, um padrão revisado) no cronograma de outros e, ocasionalmente, refazer personalizações locais; bifurcar significa assumir toda correção futura de acessibilidade e segurança que a equipe nacional lhes daria de graça. Na saúde e nos cuidados, a atração pela divergência é real — fluxos de trabalho clínicos e a marca local criam uma pressão genuína —, mas cada divergência é um passivo permanente. Uma boa resposta nomeia quem acompanha as notas de versão da origem, como as extensões locais são estruturadas para sobreviver a uma atualização da origem e o teste explícito que uma divergência proposta deve passar antes de ser permitida, para que "precisávamos que parecesse diferente" nunca se torne silenciosamente "agora mantemos uma bifurcação obsoleta e menos acessível do seletor de datas do NHS".

5. Como manteremos de fato a linha entre "prototipar para aprender" e "construir para manter"? Todos concordam em princípio que protótipos descartáveis não devem virar serviços em produção; a falha acontece sob pressão de prazo, quando um protótipo de alta fidelidade convincente está ali, ao alcance, e entregá-lo parece um atalho. Esta pergunta torna a fronteira concreta, e não aspiracional. Debatam o que, na prática, impede que o código de protótipo — otimizado para a velocidade do aprendizado, e não para segurança, resiliência ou manutenibilidade — seja promovido a um serviço clínico em produção: é uma separação técnica (protótipos construídos num ambiente isolado que não alcança a produção), uma barreira de governança (sem aprovação de segurança clínica, sem entrada em produção) ou apenas uma boa intenção compartilhada que se evapora na primeira vez em que uma data de entrega escorrega? O que está em jogo na saúde e nos cuidados é específico, porque código não assegurado numa via clínica é uma exposição de segurança do paciente, e não apenas dívida técnica. Uma resposta honesta admite de onde virá a pressão, nomeia quem tem poder para dizer não e define o que "reconstruir para produção a partir de componentes assegurados" de fato exige, para que a fronteira se sustente quando for testada.

6. Como saberemos se o sistema de design está de fato funcionando — e o que faremos quando as métricas forem desconfortáveis? Um sistema de design pode existir, ser lindamente documentado e ainda assim entregar pouco valor se as equipes o contornam em silêncio. Esta pergunta vai além de "temos um sistema de design" para "ele está justificando o seu custo". Decidam o que medirão: adoção entre serviços, a taxa e as razões das gambiarras sob medida, se a conformidade de acessibilidade de fato melhora à medida que a adoção sobe e quanto tempo as equipes economizam reutilizando em vez de reconstruir. A parte difícil não é coletar os números, mas acordar de antemão como vocês os lerão — porque uma alta taxa de gambiarras locais é um sinal de que ao sistema compartilhado falta algo real, e não evidência de que as equipes de entrega estão sendo desobedientes. Uma boa resposta se compromete a tratar dados desconfortáveis de adoção como insumo de backlog e de roteiro, define quem os revisa e com que frequência e resiste à tentação de medir apenas o que lisonjeia (existência, contagem de downloads) em vez do que importa (serviços mais seguros, mais acessíveis e mais consistentes de fato entregues).

Na prática: um exemplo de saúde e cuidados#

Um sistema de cuidados integrados que abrange três hospitais de agudos, um hospital de saúde mental e um prestador comunitário decide consolidar seu parque digital voltado ao paciente. Hoje cada organização opera o próprio portal ambulatorial; entre elas, há quatro seletores de data incompatíveis, três formas diferentes de pedir um número do NHS e uma conformidade de acessibilidade muito variada. Uma auditoria interna constata que apenas um dos quatro portais passa num teste básico de leitor de tela do seu fluxo de agendamento — uma clara exposição de equidade e de segurança clínica.

O ICS monta uma pequena equipe de sistema de design, financiada em conjunto. Em vez de construir do zero, adotam o sistema de design do NHS como alicerce e definem uma fina camada local de design tokens para a marca específica do ICS, mais um punhado de padrões genuinamente locais (por exemplo, um padrão compartilhado para agendar apoio de intérprete, que nenhum dos sistemas nacionais cobre). Todo componente compartilhado carrega evidência documentada de WCAG e a aprovação do Responsável pela Segurança Clínica do ICS, sob o processo DCB0129, antes de ser publicado.

Antes de reconstruir o fluxo de agendamento ambulatorial, a equipe prototipa. Começa em baixa fidelidade, testando uma versão em papel e tons de cinza do novo fluxo com doze participantes recrutados para refletir a população local — incluindo dois usuários de leitor de tela, três pessoas com mais de 75 anos e várias com baixa confiança digital. O protótipo expõe um grave problema de compreensão: os pacientes não distinguem uma ação de "remarcar" de uma de "cancelar". A equipe corrige o padrão e depois constrói um protótipo codificado de alta fidelidade com o front-end do sistema de design e testa de novo, desta vez confirmando o comportamento de teclado e de leitor de tela no equipamento real usado nas clínicas ambulatoriais de um hospital parceiro.

Só então constroem de verdade, montando o serviço de produção em grande parte a partir de componentes assegurados e reutilizáveis. Dezoito meses depois, uma atualização da WCAG reforça as exigências de visibilidade do foco. Como o estilo de foco vive em um único design token, a equipe entrega uma mudança e todo serviço do ICS a herda na versão seguinte — uma correção que, no antigo parque fragmentado, teria significado cinco projetos de remediação separados e, realisticamente, ao menos um serviço deixado quebrado.

Perspectivas setoriais#

Startup#

Uma pequena startup de saúde digital quase nunca deve construir o próprio sistema de design do zero — não tem como arcar com a sobrecarga dos testes de acessibilidade, e os investidores estão pagando por validação clínica, não por botões sob medida. Adotem o front-end do NHS ou do GOV.UK onde constroem para usuários do NHS e tratem a prototipagem como sua principal vantagem competitiva: protótipos baratos, rápidos e descartáveis, testados com pacientes reais, permitem aprender mais depressa do que concorrentes estabelecidos com mais financiamento. O risco é o oposto — promover um protótipo de alta fidelidade e aparência polida diretamente à produção para cumprir uma demonstração a investidores, levando código não assegurado e inseguro a um serviço clínico em produção. Mantenham uma linha firme entre "prototipar para aprender" e "construir para manter", mesmo sob pressão de financiamento.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou uma clínica de unidade única que encomenda uma ferramenta voltada ao paciente — tem pacientes ativos, mas nenhuma capacidade dedicada de design ou de front-end e não consegue absorver o custo de componentes sob medida. Sua jogada mais poderosa é insistir que qualquer fornecedor construa sobre o front-end do NHS ou do GOV.UK, de modo que as garantias de acessibilidade e segurança sejam herdadas e não prometidas, e fazer disso uma condição escrita do contrato, e não uma esperança. Raramente precisa operar um sistema de design próprio; precisa consumir bem um e reconhecer que a demonstração polida de um fornecedor não é evidência de um serviço em produção acessível e assegurado. Onde de fato prototipa — testando um novo fluxo de agendamento on-line com os seus pacientes reais, muitas vezes mais velhos ou menos confiantes digitalmente —, algumas sessões com usuários reais pegarão muito mais do que uma maquete polida jamais revelará. Aplicam-se os mesmos deveres estatutários de acessibilidade e segurança clínica de um grande hospital; assim, a pergunta honesta não é se se deve cumprir, mas como obter a conformidade herdada de forma barata a partir da infraestrutura nacional compartilhada.

Grande organização#

Um grande hospital do NHS ou uma empresa de tecnologia em saúde já tem várias equipes construindo interfaces sobrepostas; seu problema, portanto, é a fragmentação e o custo duplicado. O argumento de valor é uma equipe de sistema de design permanente e financiada, conduzindo um modelo real de contribuição, com métricas de adoção reportadas à liderança e uma linha clara de governança para a garantia de segurança clínica e de acessibilidade. A tensão central é política: equipes de entrega poderosas resistem a ceder controle, e uma equipe central autoritária gera componentes paralelos. As grandes organizações têm sucesso tornando o sistema compartilhado a escolha genuinamente mais fácil — bem documentado, bem apoiado e demonstravelmente de maior qualidade —, em vez de impô-lo e esperar.

Governo#

Um órgão nacional como o NHS England ou o GDS opera o sistema de design como infraestrutura pública usada por organizações que não controla; por isso a abertura, a estabilidade e a compatibilidade retroativa importam enormemente. Suas obrigações são as mais fortes: regulamentos estatutários de acessibilidade, deveres de igualdade e a realidade de que um defeito num componente nacional compartilhado se propaga a milhões de cidadãos. O trabalho tem menos a ver com invenção e mais com cuidado — versionamento claro, política de descontinuação, evidência exaustiva de acessibilidade e capacidade de resposta às centenas de equipes a jusante. O sistema de design do NHS e o Sistema de Design do GOV.UK são os exemplos de referência justamente porque tratam o sistema como um bem público de longa duração, e não como um projeto.

Modos de falha comuns#

• O sistema abandonado. Um sistema de design é construído com estardalhaço e depois deixado sem manutenção quando a equipe fundadora se dispersa; as equipes perdem a confiança e voltam ao trabalho sob medida. Evita-se financiando uma equipe de produto permanente, e não um projeto pontual.
• A imagem que mente. Os arquivos de design e o código de produção divergem porque não há fonte única da verdade, de modo que "o sistema de design" descreve algo que o produto já não faz. Mantenha os componentes codificados e sua documentação como autoridade e versionados em conjunto.
• Acessibilidade como reflexão tardia. Componentes são entregues sem teste real com tecnologia assistiva, de modo que um padrão inacessível é herdado em toda parte — multiplicando, e não reduzindo, o dano. Exija evidência documentada de WCAG e de leitor de tela antes de publicar qualquer componente.
• Do protótipo à produção. Um protótipo de alta fidelidade é promovido diretamente a um serviço em produção para economizar tempo, levando código inseguro, insustentável e não assegurado a um ambiente clínico. Imponha a fronteira do descartável; reconstrua para produção a partir de componentes assegurados.
• O jardim murado. Uma equipe central recusa todas as contribuições, de modo que o sistema nunca atende às necessidades reais dos serviços e as equipes de entrega o contornam. Publique um processo de contribuição e de exceção e trate as gambiarras locais como sinal de backlog.
• Teatro da consistência. Impõe-se uma uniformidade rígida onde se justifica uma variação local genuína (serviços de crise, pediatria), degradando a segurança e a usabilidade em nome da arrumação. Distinga as decisões inegociáveis das legitimamente locais.
• Testar a fidelidade errada. Os riscos de interação e de acessibilidade são "testados" apenas numa ferramenta de design estática, que não consegue exercitar o comportamento de teclado nem de leitor de tela, dando falsa confiança. Prototipe em código quando a interação é a pergunta.

Modelo de maturidade#

Lista de verificação#

• Vocês adotaram o sistema de design do NHS e/ou o Sistema de Design do GOV.UK como alicerce, em vez de construir do zero.
• Os componentes compartilhados carregam evidência documentada de conformidade com a WCAG, testada com tecnologia assistiva real e usuários com deficiência.
• Os componentes relevantes para a segurança foram revistos sob o seu processo de segurança clínica antes de serem publicados para reutilização.
• Design tokens governam cor, espaçamento, tipografia e estados de interação, permitindo mudanças em todo o sistema a partir de um só lugar.
• Existe uma fonte única da verdade em que os componentes codificados e suas orientações vivem e são versionados em conjunto.
• Os protótipos têm a fidelidade ajustada à pergunta, são testados com uma amostra representativa de usuários e tratados como descartáveis.
• Fluxos críticos para a interação e a acessibilidade são prototipados em código, e não apenas numa ferramenta de design.
• Uma equipe financiada e nomeada responde pelo sistema de design como produto contínuo, com roteiro e canal de suporte.
• Um processo publicado de contribuição e de exceção permite às equipes de entrega propor novos componentes e padrões.
• A adoção e a qualidade são medidas, e altas taxas de gambiarra local são tratadas como backlog, e não como desobediência.

Fontes-chave#

• Sistema de design do NHS — NHS England: componentes, padrões, estilos e orientações de acessibilidade para serviços digitais do NHS.
• Sistema de Design do GOV.UK — Government Digital Service: estilos, componentes e padrões para serviços do governo do Reino Unido.
• GOV.UK Service Manual — prototipagem e "make a prototype" — Government Digital Service: orientação sobre prototipar para aprender e testar com usuários.
• NHS Digital Service Standard — NHS England: o padrão frente ao qual os serviços compartilhados e consistentes são avaliados.
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative: o padrão de conformidade de acessibilidade.
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — governo do Reino Unido: o dever estatutário de acessibilidade para serviços do setor público.
• Normas de gestão de riscos clínicos DCB0129 / DCB0160 — NHS England: normas de segurança clínica para a fabricação e a implantação de sistemas de TI em saúde.
• Double Diamond do Design Council — Design Council: o modelo descobrir–definir–desenvolver–entregar que sustenta a descoberta e o design.

Referências#

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