Tópico 3.4 — Fases de descoberta

Em uma frase: A descoberta é o esforço disciplinado e de duração limitada para entender os seus usuários e o problema real antes de comprometer dinheiro, risco clínico ou reputação com a construção de uma solução.

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

Na maioria dos setores, construir a coisa errada desperdiça dinheiro. Na saúde e nos cuidados, pode também desperdiçar tempo clínico, consolidar desigualdades em saúde e — no extremo — causar dano a pacientes. Um serviço digital que presume que todo usuário tem um smartphone, banda larga confiável e inglês confiante exclui em silêncio os frágeis, os pobres e os digitalmente marginalizados: precisamente as pessoas a quem o NHS e os cuidados sociais existem para servir. A descoberta é onde você descobre isso pelo preço de algumas semanas de pesquisa, e não depois de um lançamento nacional.

Os gastos com saúde e cuidados são dinheiro público mantido em custódia, e boa parte dele flui por deveres estatutários: a Constituição do NHS, o dever de igualdade do setor público previsto na Equality Act 2010 e os Princípios de Caldicott para o tratamento de informações confidenciais de pacientes. A descoberta é a fase em que você testa se um serviço proposto é necessário, lícito, seguro e equitativo — antes que essas perguntas se tornem caras de responder. Pulá-la não remove as perguntas; apenas as adia para um ponto em que a resposta honesta é politicamente impossível de aceitar.

O NHS Digital Service Standard e o GOV.UK Service Manual tornam a descoberta a primeira fase obrigatória de qualquer serviço digital voltado ao usuário exatamente por essa razão. Não é teatro burocrático. É o seguro mais barato que você jamais comprará.

Conceitos centrais#

Descoberta, definida. A descoberta é uma fase curta (tipicamente de 6 a 10 semanas) cujo objetivo é entender um espaço de problema: quem são os usuários, o que tentam fazer, o que os impede, o que já existe e se há sequer um problema que valha a pena resolver. Sua saída é compreensão e evidência, e não um produto. Uma boa descoberta pode validamente concluir "não faça nada" ou "isto é um problema de política, não digital".

O Duplo Diamante. O duplo diamante (2005) do Design Council enquadra o design como dois diamantes ligados. O primeiro — Descobrir e depois Definir — diverge para explorar o problema amplamente e depois converge para enquadrá-lo com precisão. O segundo — Desenvolver e depois Entregar — diverge para explorar soluções e depois converge para construir uma. A descoberta, como fase de entrega, vive quase inteiramente no primeiro diamante. A falha recorrente são equipes que disparam para o segundo diamante antes de terminar o primeiro.

Necessidade do usuário versus desejo do interessado. Uma necessidade do usuário é algo que uma pessoa está tentando realizar, expressa do ponto de vista dela ("Preciso saber que minha consulta está confirmada para não faltar ao trabalho à toa"). Um desejo do interessado é uma funcionalidade ou solução que alguém já decidiu ("precisamos de um aplicativo"). A disciplina central da descoberta é traduzir desejos de volta em necessidades, porque as necessidades são estáveis e as soluções são baratas e intercambiáveis uma vez que a necessidade esteja clara.

Enquadramento do problema. O modo como você enuncia um problema restringe toda solução que considerará. "Os pacientes perdem consultas" convida a um aplicativo de lembretes. "Os pacientes não conseguem remarcar com facilidade consultas que já não lhes convêm" convida ao reagendamento por autoatendimento. Mesmo sintoma, problema diferente, serviço radicalmente diferente. A descoberta justifica seu custo em boa parte pela qualidade da declaração do problema que produz.

Suposições, hipóteses e evidências. Todo projeto repousa em suposições. A descoberta as torna explícitas, classifica-as por risco e testa as mais arriscadas com usuários reais. O objetivo não é a certeza — que é inalcançável —, mas a incerteza reduzida nas coisas que afundariam o projeto.

Boas práticas#

1. Parta de um problema, não de uma solução. Escreva a declaração do problema antes que alguém nomeie uma tecnologia. Se a proposta de financiamento, o documento do conselho ou a oferta do fornecedor já especifica "um aplicativo" ou "um portal", trate isso como uma suposição a testar, e não como uma decisão a implementar. As soluções a que se chega antes de o problema ser entendido são quase sempre o hábito de alguém, e não a necessidade do usuário.

2. Faça pesquisa com usuários de verdade, com usuários de verdade. Entreviste e observe as pessoas reais que usarão o serviço — pacientes, cuidadores, recepcionistas, enfermeiros comunitários, assistentes sociais — em seu contexto real, e não numa oficina de gestores falando em nome delas. Busque profundidade em vez de volume; uma dúzia de entrevistas contextuais bem escolhidas revela mais do que uma pesquisa com mil respostas. Recrute deliberadamente os usuários mais difíceis de alcançar, porque são aqueles com quem um serviço mais frequentemente falha.

3. Mapeie o serviço inteiro, não a fatia digital. Os usuários vivenciam um serviço de ponta a ponta — um encaminhamento, uma avaliação, um tratamento, um acompanhamento — do qual o seu componente digital é uma etapa. Mapeie a jornada atual por todos os canais e organizações, incluindo as partes em papel, por telefone e presenciais. As mudanças digitais costumam falhar porque otimizam uma etapa e quebram as duas de cada lado dela.

4. Enquadre o problema explicitamente e obtenha acordo. Produza uma declaração do problema por escrito e a evidência por trás dela e obtenha o acordo explícito do seu patrocinador sênior. Este artefato é o seu contrato: define o que significa "pronto" para as fases seguintes e lhe dá autoridade para dizer não ao escopo que não serve ao problema acordado.

5. Dimensione com honestidade a oportunidade e o risco. Estime quantas pessoas são afetadas, o quanto e quanto isso custa ao sistema hoje. Combine isso com os riscos que uma solução introduziria — clínicos, de governança da informação, de equidade, de entrega. Os líderes financiam descobertas; decidem com base num quadro defensável de oportunidade e risco; portanto, dê-lhes um.

6. Projete para as margens desde o primeiro dia. Recrute participantes de pesquisa ao longo de todo o espectro de inclusão digital, teste cedo frente às expectativas das Web Content Accessibility Guidelines (WCAG 2.2 AA) e trate as vias de digital assistido e offline como de primeira ordem, e não como reflexão tardia. Na saúde e nos cuidados, o usuário excluído costuma ser o usuário de alta necessidade; um serviço que só funciona para os confiantes e conectados amplia a desigualdade.

7. Mantenha-a multidisciplinar e de duração limitada. Componha a descoberta com um pesquisador de usuários, um designer de serviços, uma pessoa de produto, um arquiteto técnico e — para qualquer coisa que toque o cuidado — contribuição clínica e de governança da informação. Limite o tempo com firmeza (semanas, não trimestres) para forçar a convergência. Uma descoberta sem prazo é um sinal de alerta de que a equipe está evitando uma decisão.

8. Registre por escrito o que faria você parar. Acorde, no início, as condições em que a recomendação honesta seria "não prosseguir": nenhuma necessidade genuína do usuário, uma barreira intransponível de governança da informação ou de segurança, uma solução não digital melhor ou um problema de outra equipe. Uma descoberta que não pode recomendar parar não é uma descoberta; é uma construção pré-justificada.

Perguntas para discutir com a sua equipe#

1. O que teríamos de ver na descoberta para recomendar honestamente "não prosseguir", e alguém nesta sala tem autoridade para dizê-lo? As condições de parada são inúteis se não podem ser exercidas, e na saúde e nos cuidados a pressão para não exercê-las é intensa: um diretor anunciou o aplicativo, um contrato com fornecedor está meio assinado ou uma janela de financiamento se fecha se a equipe hesitar. Esta pergunta obriga a equipe a nomear a evidência específica — nenhuma necessidade genuína do usuário, uma barreira intransponível de governança da informação ou de segurança clínica, uma solução não digital melhor, um problema de outro serviço — que inverteria a recomendação para parar e a registrá-la por escrito antes de a pesquisa começar, para que não possa ser redefinida em silêncio mais tarde. A tensão que vale debater está entre a confiança do patrocinador e a independência do pesquisador: uma descoberta que estruturalmente não pode dizer não é uma construção pré-justificada vestindo as roupas da descoberta. Considerem quem protege os achados do pesquisador de edição, se alguém de fora revisa as evidências e qual foi a última descoberta que a sua organização de fato interrompeu — se não houve nenhuma, isso é, em si, um achado. Uma resposta honesta identifica as razões reais pelas quais o "não" é difícil aqui e um mecanismo concreto (critérios de parada acordados, um questionamento independente, um patrocinador que abençoou publicamente a possibilidade de parar) que o torna dizível.

2. Quem são os usuários que temos mais probabilidade de excluir, e como os traremos para a pesquisa em vez de adiá-los para o beta? Na saúde e nos cuidados, o usuário excluído — o frágil, o digitalmente marginalizado, a pessoa com pouca confiança no inglês, o cuidador que lida com três sistemas — é desproporcionalmente o usuário de alta necessidade a quem o serviço existe para servir, de modo que amostrar por conveniência embute silenciosamente a desigualdade na arquitetura. A concessão a debater é a profundidade e a inclusão versus o cronograma e o custo de recrutamento: alcançar os mais difíceis de alcançar toma tempo, parceiros comunitários, incentivos e métodos de pesquisa assistidos ou offline que uma descoberta apressada é tentada a pular "por ora". Ângulos concretos incluem mapear explicitamente o espectro de inclusão digital, recrutar por meio de porteiros do setor voluntário e clínicos em vez de uma lista de e-mails e tratar as vias de digital assistido e não digitais como achados de primeira ordem, e não reflexões tardias. Vale nomear o dever de igualdade do setor público e o contexto de Caldicott, para que a inclusão seja entendida como obrigação legal e ética, e não como sutileza. Uma boa resposta produz um plano de recrutamento nomeado que deliberadamente sobreamostra as margens e uma declaração clara de quais usuários a equipe tratará como centro de gravidade do projeto.

3. Enquadramos um problema, ou contrabandeamos uma solução para dentro da declaração do problema? O modo como um problema é enunciado restringe silenciosamente toda solução que a equipe considerará — "os pacientes esquecem as consultas" convida a um aplicativo de lembretes, enquanto "os pacientes não conseguem remarcar com facilidade consultas que já não lhes convêm" convida ao reagendamento por autoatendimento e a uma revisão da política de horários —; assim, a redação da declaração do problema é onde a descoberta justifica a maior parte do seu custo. O debate é se a proposta de financiamento, o documento do conselho ou a oferta do fornecedor já fixou a resposta ("um aplicativo", "um portal", "uma ferramenta de triagem com IA") e a vestiu de necessidade, e se a equipe tem a disciplina de traduzir esse desejo de volta ao objetivo subjacente do usuário. Ângulos úteis incluem banir substantivos de solução da declaração do problema, mapear o serviço inteiro de ponta a ponta por todos os canais e organizações para que a fatia digital seja vista em contexto e verificar se cada necessidade declarada é expressa do ponto de vista do usuário, e não da organização. A evidência importa aqui: um enquadramento deve ser rastreável ao que usuários reais disseram e fizeram, e não a um hábito ou a um slide de estratégia. Uma resposta honesta ou confirma que a declaração nomeia uma necessidade estável do usuário com evidência por trás ou admite que uma solução foi presumida e reabre o enquadramento antes que qualquer alfa seja delimitado.

4. Temos as disciplinas certas na sala, e a segurança clínica e a governança da informação estão moldando o trabalho em vez de aprová-lo no final? Uma descoberta composta apenas por um gerente de produto e um líder de entrega encontrará problemas de produto e de entrega; os usuários, clínicos e deveres legais que ela nunca convida para a sala se tornam os riscos que emergem de forma cara no alfa ou, pior, após a entrada em produção. A tensão é que uma equipe genuinamente multidisciplinar — pesquisador de usuários, designer de serviços, arquiteto técnico, responsável pela segurança clínica, expertise em governança da informação e em Caldicott — é escassa, disputada e lenta de reunir; assim, as equipes são tentadas a "tomar emprestado" um clínico por uma hora ou a acrescentar a governança da informação como uma barreira final. Essa sequência é a armadilha: a segurança clínica e a governança da informação são baratas de projetar durante o enquadramento e ruinosamente caras de retroajustar depois que uma arquitetura presume que os dados fluirão entre fronteiras organizacionais. Ângulos concretos incluem nomear um responsável pela segurança clínica desde a primeira semana para qualquer coisa que toque o cuidado, tratar uma avaliação de impacto sobre a proteção de dados como um artefato vivo da descoberta, e não como formalidade posterior, e verificar se as pessoas que entendem o fluxo de trabalho da linha de frente são colaboradoras ou meramente consultadas. Uma resposta honesta nomeia quem de fato está na equipe, quais deveres são representados por uma pessoa e quais por uma caixa de seleção e onde a descoberta seria cega por falta de uma disciplina.

5. Como saberemos que a descoberta terminou, e o que a impede de derivar por meses ou de ser cortada após uma quinzena? A descoberta tem dois modos de falha opostos, e ambos têm a ver com o tempo: o estudo sem limite, que mapeia tudo e não decide nada, e a quinzena truncada, que corre para uma conclusão preestabelecida porque uma data de entrega foi fixada antes de a pesquisa começar. A disciplina que o duplo diamante exige é a convergência — saber quando o problema é compreendido o bastante para tomar uma decisão defensável, e não quando toda pergunta foi respondida, porque a certeza é inalcançável e o objetivo é a incerteza reduzida nas coisas que afundariam o projeto. A concessão que vale debater é profundidade versus impulso: uma janela de tempo rígida de semanas força a equipe a priorizar as suposições mais arriscadas, mas uma janela apertada demais priva da pesquisa inclusiva e de difícil alcance de que este domínio mais precisa. Ângulos úteis incluem acordar a decisão que a descoberta deve informar e os artefatos de que um patrocinador precisa para tomá-la, classificar as suposições para que a janela seja gasta no que importa e nomear um ponto de decisão em vez de deixar a fase escorrer para um alfa não reconhecido. Uma resposta honesta declara a duração da janela, como é "entendido o bastante" para este problema e quem decreta o fim.

6. Quando a descoberta terminar, conseguiremos entregar a um conselho de financiamento um quadro defensável da oportunidade e do risco — ou apenas uma história? Os líderes não financiam compreensão; financiam decisões, e uma descoberta que produz insight rico, mas nenhum relato legível pelo conselho de quantas pessoas são afetadas, o quanto, quanto isso custa ao sistema hoje e o que uma solução poria em risco, deixa a decisão a quem contar a história mais confiante. A tensão está entre os achados nuançados e ressalvados do pesquisador e a necessidade do conselho de um caso dimensionado, comparável e defensável — comprimir demais perde as sutilezas de equidade e de segurança que eram o ponto; recusar-se a comprimir impede que a evidência chegue a quem aloca o dinheiro. Na saúde e nos cuidados, o quadro deve combinar a oportunidade com os riscos que uma solução introduz — clínicos, de governança da informação, de equidade, de entrega —, porque um conselho que só vê o lado bom está sendo preparado para fazer uma má aposta. Ângulos concretos incluem dimensionar a população afetada com dados reais, e não com uma estimativa esperançosa, tornar os achados rastreáveis para que um cético possa segui-los até o que os usuários disseram e enquadrar a recomendação (incluindo "não prosseguir" ou "fazer alfa deste item mais restrito") em termos que a fase seguinte possa usar. Uma resposta honesta mostra que a equipe consegue passar da evidência a uma recomendação que um conselho de financiamento poderia escrutinar às claras sem que ela desmorone.

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

Um sistema de cuidados integrados (ICS) está sob pressão para reduzir as taxas de não comparecimento (DNA, did not attend) em clínicas ambulatoriais. Um fornecedor apresentou um aplicativo de lembretes movido a IA, e um diretor está ansioso para financiá-lo. Em vez de comprar, o ICS conduz uma descoberta de oito semanas.

O pesquisador de usuários entrevista dezoito pacientes que haviam perdido consultas recentemente, além de recepcionistas e dois gerentes de clínica. Emerge um padrão que a teoria dos lembretes deixou passar: muitos "faltosos" haviam tentado remarcar, mas encontraram a linha telefônica ocupada por dias, ou haviam recebido uma consulta em horário comercial que não podiam aceitar sem perder o pagamento. Um subconjunto havia falecido ou sido internado em outro lugar e continuava na lista. Os lembretes não tocariam em nenhuma dessas causas.

A equipe mapeia a jornada de agendamento de ponta a ponta e descobre três organizações, dois sistemas de administração de pacientes e um aparelho de fax no circuito. Reformulam o problema de "os pacientes esquecem as consultas" para "os pacientes não conseguem nos contatar com facilidade para remarcar consultas que já não funcionam para eles". Quantificam: cerca de 40% dos DNAs nas clínicas amostradas envolveram uma tentativa de contato anterior fracassada. Sinalizam uma questão de governança da informação (uma ferramenta compartilhada de reagendamento cruzaria fronteiras organizacionais) e um achado de equidade (as maiores taxas de DNA estavam entre pacientes dos códigos postais mais carentes, para quem o horário comercial era a barreira).

A descoberta recomenda contra o aplicativo e a favor de um alfa que explore o reagendamento por autoatendimento e uma revisão da política de horários. O problema reformulado é aceito pelo patrocinador, um responsável pela segurança clínica é nomeado para o alfa e uma avaliação de impacto sobre a proteção de dados é encomendada. O ICS gastou oito semanas e evitou financiar uma solução que teria fracassado de modo mensurável em público.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital conduz a descoberta com poucos recursos e contra o relógio — muitas vezes a "descoberta" é a própria experiência vivida dos fundadores mais uma quinzena de entrevistas com usuários espremidas entre reuniões com investidores. A pressão de financiamento é mostrar tração, o que tenta os fundadores a ir direto a uma demonstração; a disciplina que mais importa é nomear a suposição mais arriscada e matar a ideia barato se ela falhar, porque uma startup não pode se dar ao luxo de construir a coisa errada nem uma vez. A responsabilização é perante investidores e primeiros adotantes, e não um conselho estatutário; assim, as condições de parada são comerciais (nenhuma disposição de pagar, nenhum mercado alcançável) tanto quanto clínicas. A vantagem é a velocidade e a liberdade de mudar de rumo; o risco é confundir uma narrativa persuasiva do fundador com evidência de uma necessidade real do usuário.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso, uma agência de cuidados domiciliares, uma clínica de unidade única ou um pequeno fornecedor de tecnologia em saúde que já passou da fase pré-receita — tem pacientes reais e operações em curso, mas raramente um pesquisador de usuários ou designer de serviços sobrando para compor uma descoberta formal. Aqui a descoberta é leve e oportunista: a "pesquisa" é o recepcionista que já sabe por que os pacientes não conseguem completar a ligação, os cuidadores que veem a duplicação de papelada diariamente e um punhado de conversas deliberadas com os usuários que uma mudança afetaria. A armadilha é que os mesmos deveres estatutários — Caldicott, UK GDPR, o dever de igualdade, a segurança clínica — se aplicam por inteiro, haja ou não alguém internamente que seja responsável por eles; assim, a disciplina que mais importa é enquadrar o problema com honestidade e testar a suposição mais arriscada antes de comprometer caixa escasso com o produto de um fornecedor. Como as operações em curso não podem parar, um pequeno prestador muitas vezes conduz sua descoberta em torno de um único ponto de dor concreto, e não de um amplo espaço de problema, e sua condição de parada mais valiosa é reconhecer quando a solução é uma mudança de processo ou uma plataforma regional compartilhada, e não um sistema a comprar.

Grande organização#

Um hospital do NHS ou um grande fornecedor de tecnologia em saúde pode compor uma descoberta multidisciplinar adequada — pesquisadores de usuários, designers de serviços, segurança clínica, governança da informação —, mas precisa lutar contra a gravidade organizacional: um contrato de fornecedor já estabelecido, um conselho que já anunciou "o aplicativo" ou um caso de negócio que pré-decidiu a solução. Aqui o trabalho mais difícil da descoberta é político — reformular uma solução sancionada de volta a uma necessidade do usuário sem perder o apoio do patrocinador. O financiamento é anual e preso a comitês; assim, as descobertas competem por vagas e precisam produzir artefatos legíveis pelo conselho. O apetite por risco é baixo e a responsabilização é ampla (reguladores, auditores, o público), o que torna um "não prosseguir" honesto, ao mesmo tempo, mais valioso e mais difícil de dizer em voz alta.

Governo#

Um órgão público nacional ou local — NHS England, DHSC, um governo descentralizado, uma autoridade local — conduz a descoberta sob todo o peso do Service Standard, das barreiras de controle de gastos e do escrutínio público, onde o próprio relatório de descoberta pode ser publicado e contestado. A base de usuários é enorme e o dever de incluir os marginalizados é uma preocupação legal, e não opcional; portanto, o recrutamento inclusivo e as vias de digital assistido são obrigatórios desde a primeira semana. A responsabilização é perante ministros, o Parlamento e o eleitorado; assim, uma descoberta deve ser defensável às claras e pode ser interrompida pelos controles de gastos quando a evidência é fraca. A concessão é rigor versus ritmo: a descoberta governamental é mais lenta e mais assegurada, o que protege o dinheiro público, mas pode frustrar equipes acostumadas a andar depressa.

Modos de falha comuns#

• Solucionar cedo demais. A equipe entra na descoberta com a resposta já escolhida e gasta as semanas construindo um caso de negócio para ela. Antídoto: banir substantivos de solução da declaração do problema; fazer da suposição mais arriscada uma pergunta de pesquisa.
• Teatro da pesquisa. Consultam-se alguns interessados amistosos, os usuários de difícil alcance são pulados "por falta de tempo" e os achados convenientemente confirmam o plano. Antídoto: recrutar para as margens; fazer os achados serem questionados por alguém de fora da equipe.
• A descoberta que não pode dizer não. Financiamento, política ou um contrato assinado tornam o "não prosseguir" indizível, de modo que a descoberta vira ritual. Antídoto: acordar as condições de parada de antemão e proteger a independência do pesquisador.
• Ferver o oceano. Uma descoberta sem limite deriva por meses, mapeando tudo e decidindo nada. Antídoto: uma janela de tempo rígida e uma decisão nomeada ao final.
• Ignorar o serviço não digital. A equipe estuda a tela e deixa passar a linha telefônica, a carta e o recepcionista que de fato carregam a jornada. Antídoto: mapear todos os canais e organizações de ponta a ponta.
• Tratar a acessibilidade e a inclusão como coisas para depois. Os usuários das margens são adiados para o beta, quando a arquitetura já os exclui. Antídoto: recrutar de forma inclusiva e testar frente à WCAG desde o primeiro protótipo.

Modelo de maturidade#

Lista de verificação#

• Existe uma declaração do problema por escrito que nomeia uma necessidade do usuário, e não uma solução.
• Usuários reais — incluindo os mais difíceis de alcançar — foram entrevistados ou observados em contexto.
• O serviço de ponta a ponta está mapeado por todos os canais e organizações.
• As suposições mais arriscadas estão listadas, classificadas e as principais foram testadas.
• Riscos de segurança clínica, de governança da informação (Caldicott, UK GDPR/DPIA) e de desigualdade em saúde foram identificados.
• A acessibilidade (WCAG 2.2 AA) e a inclusão digital são consideradas desde o primeiro protótipo.
• As condições de parada foram acordadas no início, e "não prosseguir" é um resultado possível genuíno.
• A oportunidade está dimensionada e a recomendação é defensável perante um conselho de financiamento.
• Uma equipe multidisciplinar (incluindo contribuição clínica/de governança da informação) conduziu a fase dentro de uma janela de tempo fixa.
• O patrocinador acordou a declaração do problema antes de qualquer alfa começar.

Fontes-chave#

• NHS England — NHS Digital Service Manual e NHS Service Standard (service.nhs.uk).
• GOV.UK Service Manual — "How the discovery phase works" e o Government Service Standard (Government Digital Service).
• Design Council — arcabouço de processo de design The Double Diamond.
• NHS England — Digital Technology Assessment Criteria (DTAC): segurança clínica, proteção de dados, garantia técnica, interoperabilidade, usabilidade e acessibilidade.
• NICE — Evidence Standards Framework for Digital Health Technologies.
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C; e orientações do GOV.UK sobre acessibilidade e digital assistido.
• Princípios de Caldicott do Reino Unido e Data Protection Act 2018 / UK GDPR (avaliações de impacto sobre a proteção de dados).
• Equality Act 2010 — o dever de igualdade do setor público (relevante para a avaliação de desigualdades em saúde na descoberta).

Referências#

1. Double Diamond (design process model) — Wikipedia — https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)
2. Design Council — Wikipedia — https://en.wikipedia.org/wiki/Design_Council
3. User research — Wikipedia — https://en.wikipedia.org/wiki/User_research
4. Contextual inquiry — Wikipedia — https://en.wikipedia.org/wiki/Contextual_inquiry
5. Problem statement — Wikipedia — https://en.wikipedia.org/wiki/Problem_statement
6. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
7. Equality Act 2010 — Wikipedia — https://en.wikipedia.org/wiki/Equality_Act_2010
8. NHS Constitution for England — Wikipedia — https://en.wikipedia.org/wiki/NHS_Constitution_for_England
9. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
10. Privacy impact assessment (data protection impact assessment) — Wikipedia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
11. How the discovery phase works — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works
12. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
13. The Double Diamond — Design Council — https://www.designcouncil.org.uk/our-resources/the-double-diamond/
14. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C — https://www.w3.org/TR/WCAG22/
15. Equality Act 2010 — UK legislation (legislation.gov.uk) — https://www.legislation.gov.uk/ukpga/2010/15/contents
16. Data protection impact assessments (DPIAs) — Information Commissioner's Office (ICO) — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
17. The Caldicott Principles — National Data Guardian, GOV.UK — https://www.gov.uk/government/publications/the-caldicott-principles
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health