** Este artigo foi escrito por Alex Lee. Este artigo foi publicado pela primeira vez no final de abril deste ano no Design in Government GOV.UK Blog . Você pode ler o artigo original ** [ aqui ](https://designnotes.blog.gov.uk/2021/04/29/designing-at-pace-at-the-driver-and-vehicle- standards-agency-dvsa /).
Este artigo contém informações do setor público licenciadas sob a Open Government License v3.0.
Em 23 de março de 2020, foi tomada a decisão de interromper os testes de direção devido à pandemia do coronavírus (COVID-19). Esta postagem do blog é um estudo de caso que mostra como uma equipe multidisciplinar trabalhou em conjunto para criar um serviço de emergência em 34 dias que ajudou 30.000 trabalhadores críticos a reservar um exame de direção.
• Quer escrever para nós? Dê uma olhada no ** [ guia para colaboradores **] do Apolitical (https://apolitical.co/opinion-writing-becoming-an-apolitical-contributor/)
Fundo
Pela terceira vez em seus 85 anos de história, o serviço de exames de direção foi suspenso por causa do bloqueio. As outras 2 vezes anteriores foram por causa da 2ª Guerra Mundial e da Crise de Suez em meados dos anos 50.
Um serviço de substituição temporária, que funcionou de 23 de março de 2020 a 14 de agosto de 2020, foi construído pela equipe da Driver and Vehicle Standards Agency (DVSA) e lançado em 34 dias para permitir que trabalhadores críticos ainda se inscrevam em testes práticos e teóricos.
A equipe incluiu designers de serviço, pesquisadores de usuários, analistas de desempenho, designers de conteúdo, desenvolvedores, testadores e engenheiros de plataforma. O serviço permitiu a aplicação de 110 mil provas práticas e teóricas e priorizou os profissionais de saúde e assistência social, que representaram 40% das inscrições.
** A linha do tempo dos eventos **
Em 24 de abril, após uma [revisão por pares GDS](https://services.blog.gov.uk/2020/04/30/were-changing-the-way-we-do-service-assessments-to-support- serviços relacionados ao coronavírus /) em 8 de abril, o serviço foi lançado. Ele se tornou o primeiro serviço relacionado ao COVID-19 em todo o governo a entrar em operação.
O serviço então teve uma revisão de pares GDS de acompanhamento em 29 de abril e lançou uma segunda iteração em 13 de maio de 2020. Houve 3 iterações subsequentes do serviço antes de ser retirado em 14 de agosto de 2020, uma vez que os testes de direção padrão foram retomados.
** Como a equipe trabalhou junta **
Devido ao ritmo de trabalho e à procura de um serviço a ser lançado, queríamos garantir que a equipa trabalhava em conjunto com eficácia. Com a vantagem do conhecimento de domínio e um departamento digital interno, criamos uma equipe dedicada de especialistas e começamos o trabalho imediatamente. As 3 coisas principais que nos permitiram maximizar nossos esforços como uma equipe e trabalhar no ritmo foram: documentação, prototipagem de alta fidelidade e uso do ciclo de feedback construir-medir-aprender.
Documentação
Devido à equipe trabalhando em casa, sabíamos que o trabalho tinha que ser documentado online. Também precisava mostrar o processo de pensamento e as decisões por trás de nossas escolhas para permitir que qualquer pessoa entendesse por que certas coisas foram feitas. Decidimos usar uma ferramenta de colaboração remota como base para documentar nosso trabalho, conforme previsto um conjunto de recursos úteis que nos permitiu construir um recurso abrangente e compartilhável.
Inicialmente, identificamos 4 áreas principais para nossa documentação que daria à equipe as informações necessárias para aprender sobre o projeto. Essas foram as jornadas do usuário, mudanças de design, links úteis e as próximas etapas.
** Reserve um tempo para documentar seu trabalho de design, mesmo quando estiver sob pressão - no futuro, você e outros ficarão agradecidos! **
Essas 4 áreas principais foram agrupadas horizontalmente e apresentadas cronologicamente para destacar as principais mudanças, fornecendo assim à equipe todas as informações de que precisariam.
Um exemplo de 2 raias em nosso quadro online, apresentando o trabalho em 2 iterações
Isso foi crucial para garantir a clareza enquanto projetava no ritmo, já que os membros da equipe podiam navegar pelo recurso para entender não apenas a versão mais recente, mas as iterações de antemão. Essa estrutura de documentação também permitiu que os usuários entendessem como o design havia evoluído ao longo do tempo, já que a leitura de cima para baixo contava a história do serviço e nosso pensamento na época.
Construímos sobre essa estrutura, também introduzindo linhas de design e desenvolvimento em nosso processo. Isso rapidamente se tornou uma maneira simples e eficaz de ilustrar a relação entre os lançamentos e o trabalho exploratório. Ao definir claramente a natureza da raia, os usuários podem pular direto para a versão ao vivo ou entender o trabalho exploratório que aconteceu entre eles.
Após o lançamento inicial, cada linha de design destacou a pesquisa e as ideias de design que tínhamos na época e, eventualmente, "se fundiram" nas linhas de desenvolvimento para formar a iteração mais recente.
Um exemplo de várias pistas de desenvolvimento em verde e pistas de design em azul e a relação entre o trabalho
** Prototipagem de alta fidelidade **
Como tínhamos conhecimento prévio de como esse serviço deveria funcionar e das perguntas que deveríamos fazer, decidimos pular direto para o [estágio de prototipagem](https://apolitical.co/en/solution_article/how-to-bring-a -spirit-of-prototyping-in-the-policymaking-process) aproveitando os excelentes recursos fornecidos pelo GDS, o GOV.UK Design System e o GOV.UK Prototype Kit. Isso nos permitiu criar rapidamente uma jornada do usuário que era confiável e tinha componentes que foram bem testados em todo o setor público.
Também adicionamos JavaScript aos nossos protótipos para criar uma jornada interativa do usuário que incluía mensagens de erro e componentes dinâmicos. Isso permitiu que a equipe entendesse as diferentes jornadas do usuário, dependendo das ações dos usuários, e deu à equipe uma visão muito mais clara de como as páginas deveriam funcionar.
Um exemplo de como nossa funcionalidade de mensagem de erro funcionou no protótipo para dar à equipe uma ideia de como a página deve funcionar
Usamos nossa documentação para registrar nossas viagens e o Heroku para compartilhá-las. Isso permitiu que a equipe entendesse como o novo serviço deveria funcionar e foi uma ótima maneira de obter feedback.
Ao criar protótipos de alta fidelidade e atualizar os mapas de jornada do usuário regularmente, estabelecemos rapidamente um estilo de trabalho que permitiu à equipe ver a jornada do usuário mais recente, fornecer feedback sobre essa jornada e visualizar as próximas etapas propostas. Isso proporcionou a todos os membros da equipe e às partes interessadas um recurso em que poderiam contar para ver o andamento do trabalho.
** Construir-medir-aprender **
Outra etapa importante em nosso processo de design para este trabalho foi a adaptação rápida às informações que recebemos sobre o serviço após seu lançamento inicial. Diariamente, discutiríamos os comentários mais recentes do usuário e, como uma equipe, estabeleceríamos padrões de preocupação e melhorias que poderiam ser feitas.
Esse feedback foi adicionado à nossa ferramenta de documentação online, dentro de nossas raias, para mostrar a todos os envolvidos os problemas que encontramos, nossas ideias e conceitos iniciais e as decisões de design que ocorreram. Esse nível de detalhe ilustrou ainda mais para as partes interessadas como medimos, aprendemos e, assim, adaptamos o serviço com base nas informações que recebemos.
Depois que melhorias foram adicionadas ao serviço, introduzimos cartões de alerta em nossa documentação para indicar que o recurso foi adicionado. Esta foi uma ótima maneira de indicar o que havia se "mesclado" com as raias de desenvolvimento, uma vez que ficamos felizes com o trabalho na fase de design. A partir daqui, pudemos usar nosso histórico de design junto com as métricas de serviço para avaliar a mudança no desempenho de nosso serviço depois que os recursos foram colocados em operação, pois tínhamos uma ideia clara do cronograma.
Um exemplo de como usamos cartões nas versões de lançamento em nossa documentação para mostrar rapidamente à equipe quais recursos foram adicionados à versão mais recente do serviço
** Conclusão e principais lições **
Pode parecer contra-intuitivo sugerir certificar-se de que você está detalhado ao documentar seu trabalho quando está projetando no ritmo, mas para nós, essa forma de trabalhar se tornou um recurso crucial que usamos diariamente para fornecer clareza e discutir as decisões que tiveram foram feitos e quais foram os próximos passos.
** Principais lições **
Abaixo estão algumas lições-chave bônus que aprendemos ao fazer este trabalho:
- Encontre um estilo de documentação que funcione para sua equipe e comece a documentar o mais cedo possível
- Reserve um tempo para documentar seu trabalho de design, mesmo quando estiver sob pressão - no futuro, você e outros ficarão gratos!
- Capture todas as suas ideias - mostrar o trabalho que não teve sucesso constrói a história e valida ainda mais a melhor opção
- A documentação pode ser uma ferramenta eficaz usada para comunicação
- A documentação pode ser um ótimo recurso para extrair informações quando necessário
Como uma equipe de design, estamos ansiosos para levar o que aprendemos com isso de volta aos nossos serviços principais para melhorar a forma como documentamos no futuro. Assista esse espaço! ** - Alex Lee **
** Queremos saber sua opinião sobre este artigo. ** ** Lance um artigo ** ** para nós ou envie seus comentários para ** hello@apolitical.co
(Crédito da foto: Blog Design in Government GOV.UK)
Certifique-se de partilhar as suas próprias ideias com o autor ao deixar um comentário abaixo
Inicie sessão ou registe-se para continuar a conversa