Smashing Podcast Episódio 7 Com Amy Hupe: O que é um sistema de design do governo?

Você já se perguntou como os sistemas de design são usados ​​dentro de um governo? Além disso, se você quisesse documentar um sistema de design da melhor maneira possível, como faria isso? Falei com a defensora da Design Systems, Amy Hupe, que compartilha seus conselhos e lições aprendidas.

Mostrar notas

• O Sistema de Design GOV.UK
• Siga Amy no Twitter
• site da Amy

Atualização semanal

• “Entendendo CSS Grid: Criando um Grid Container”, por Rachel Andrew
• “Lista de verificação de desempenho de front-end 2020”, de Vitaly Friedman
• “Por que você deve escolher HTML5 <article> em vez de <section>”, de Bruce Lawson
• “A personalidade dividida do desenvolvimento web brutalista”, por Frederick O'Brien
• “Como criar e implantar o aplicativo de material angular”, por Shubham

Transcrição

Drew McLellan: Ela é especialista em conteúdo e defensora de sistemas de design que passou os últimos três anos trabalhando como designer de conteúdo sênior no Government Digital Service. Nesse período, ela liderou a estratégia de conteúdo para o sistema de design GOV.UK, incluindo uma abordagem direta e inclusiva à documentação. Ela já trabalhou para a empresa de defesa do consumidor, que? onde ela escreveu sobre tudo, desde compostagem até transporte. E uma nova função para 2020 a vê como Gerente de Projetos do Babylon Health Design System, DNA.

Drew: Ela é uma cozinheira habilidosa, uma Instagrammer e sabe usar a linguagem para tornar os serviços acessíveis e inclusivos. Mas você sabia que ela já cantou backing vocals para Billy Ray Cyrus? Meus amigos, por favor, dêem as boas-vindas a Amy Hupe. Olá Amy. Como você está?

Amy Hupe: Estou arrasando. Obrigada.

Drew: Então eu queria falar com você hoje sobre o papel dos sistemas de design dentro das organizações governamentais em geral, mas especificamente o sistema de design GOV.UK, com o qual eu sei que você trabalhou muito. Acho que em primeiro lugar, o que o sistema de design GOV.UK abrange? E qual foi o seu envolvimento com isso enquanto esteve na GDS?

Amy: Então engloba todos os tipos de coisas. Então eu acho que a representação mais óbvia disso é o tipo de lado do site, que é GOV.UK/design-system. E lá você encontrará todo o tipo de documentação. Então, todas as diretrizes de design, e os componentes e padrões, e você verá alguns dos códigos, muitos exemplos e muitos conselhos sobre como usá-los. Mas pensando de forma mais ampla do que isso, também abrange coisas como o kit de protótipos, que é uma ferramenta de prototipagem usada no governo para fazer protótipos HTML e CSS. Portanto, protótipos de alta fidelidade e também tem seu próprio tipo de estrutura de front-end, chamada GOV.UK Front-End. Então esse é todo o código que eles usam para construir os serviços.

Amy: Mas gosto de pensar em sistemas de design de forma mais holística. Então, além de todas essas coisas, há também todos os processos que estão ao redor disso. Então, coisas como como as pessoas contribuem para isso e como as pessoas sabem que ela existe. Coisas como adoção e conscientização e todo esse tipo de coisa. Então, todas as coisas que permitem que as pessoas projetem e construam serviços no governo é como eu definiria.

Drew: Então, qual foi o seu envolvimento enquanto você estava na GDS com isso? Onde você entrou nesse sistema?

Amy: Tudo meio que aconteceu por acaso, eu acho. Então, entrei como designer de conteúdo em janeiro de 2017, e minha intenção quando cheguei ao GDS era realmente me juntar às equipes de conteúdo do Gov UK. Então eu pensei em começar a escrever orientações para o sistema, e esse era o meu sonho. Era isso que eu queria fazer. Então cheguei no primeiro dia e fui colocado nessa pequena equipe de proteção, chamada de equipe de Padrões e Ferramentas do Manual de Serviço.

Amy: Naquela época, o sistema de design não existia, mas tínhamos nossos padrões de design e algumas peças espalhadas em lugares diferentes. Havia uma ambição de tentar juntar essas coisas. Então, fui colocado nessa equipe como designer de conteúdo. Eu não sabia o que era um padrão de design, não sabia nada sobre código, não sabia nada sobre web design. Tudo o que eu realmente sabia era o conteúdo.

Amy: Então foi uma curva de aprendizado bastante íngreme e eu passei os próximos seis meses a um ano, acho, ajudando a equipe a prototipá-lo e descobrir como seria organizado e apresentado e como redigiríamos nossa orientação, e todo esse tipo de coisa. Então, no meio de tudo isso, além de trabalhar no conteúdo, comecei também a olhar para o lado da contribuição. Então, como as pessoas contribuiriam para isso e como as pessoas viriam a descobri-lo e entrar em contato conosco, e o que faríamos quando eles entrassem em contato conosco para tentar torná-lo melhor.

Drew: Então, o que o design de conteúdo nesse tipo de contexto envolve? Quais eram os tipos de tarefas diárias que você estava enfrentando?

Amy: Então, todos os tipos de coisas realmente. Quero dizer, houve semanas em que eu acho que não escrevi uma única palavra e foi mais apenas sair para pesquisar e conhecer nossos usuários e tentar entender o que eles queriam de um sistema de design. Então, sim, sem ir muito longe nisso, houve tentativas de fazer algo como o sistema de design GOV.UK antes, e foi assim que acabamos com esse tipo de conjunto de recursos ligeiramente díspares.

Amy: Por uma razão ou outra, essas coisas acabaram muito espalhadas, e nunca foi realmente uma delas que foi vista como o lugar central para essas coisas. Então, muito disso, era apenas tentar entender o que havia acontecido antes e por que essas coisas não necessariamente decolaram da maneira que esperávamos. Tentando entender quais partes de nossa paisagem existente estavam funcionando para as pessoas e quais não estavam.

Amy: Então, muito disso estava saindo com nossa pesquisa [inaudível 00:05:07], e participando de entrevistas de pesquisa de usuários, tomando notas e conversando com as pessoas, e apenas entendendo o que elas precisavam. Então, houve dias em que eu realmente consegui sentar em um teclado e escrever algumas orientações sobre algumas coisas, o que foi legal também. Mas sim, foi muito diferente para mim. Como você mencionou na introdução, minha formação foi trabalhar na Which? Então era muito mais um papel editorial tradicional e eu estava acostumado a trabalhar em conteúdo longo, e apenas escrever artigos realmente longos e peças. Então, sim, foi uma grande mudança. Foi um grande salto disso.

Drew: Então seus usuários neste contexto são pessoas que trabalham em diferentes organizações governamentais? Isso está certo? Diferentes departamentos dentro do governo?

Amy: Sim. Sim, está certo. Então, as pessoas que trabalham, acho que há 25 departamentos ministeriais diferentes no governo, e também há muitas agências e departamentos do governo local. Então, estávamos tentando nos espalhar e conversar com uma grande variedade de pessoas de todo o serviço público. Então, sim, muitas viagens naqueles primeiros dias.

Drew: Você acha que projetar ou trabalhar em um sistema de design para um governo, essencialmente, é diferente de um sistema de design para uma pequena empresa ou um grande tipo de empresa empresarial?

Amy: Acho que sim. Quero dizer, acho que pelo que posso reunir de conversas que tive e conferências em que estive e outras coisas, cada sistema de design é um pouco diferente e o contexto é sempre um pouco diferente, e o governo não é diferente nesse aspecto . Mas sim, suponho que alguns dos desafios únicos de trabalhar em algo para o governo são, antes de tudo, a escala disso. Portanto, o público é provavelmente o maior que você poderia ter porque o governo é muito grande e todos os diferentes tipos de departamentos e a distribuição geográfica dessas organizações. Então, a escala disso é definitivamente algo um pouco diferente.

Amy: Acho também o fato de não ser comercialmente competitivo. Então não estávamos tentando manter tudo em segredo. Tudo foi feito ao ar livre na medida do possível. Sim, é tudo executado como um grande projeto de código aberto, o que era um conceito um pouco incomum para mim. Demorei um pouco para me acostumar com isso.

Amy: Certamente, quando o lançamos pela primeira vez, veríamos pedaços de nossa orientação e código surgindo nos sistemas de design de outras pessoas. Demorou um pouco para eu me sentir bem sobre isso. Eu acho que no começo eu estava tipo, “O que está acontecendo? Por que essas pessoas estão pegando nossas coisas?” Mas, na verdade, agora, eu realmente gosto disso. Eu vejo isso como um grande elogio, e acho muito bom reutilizar o que você pode. Mas sim, esse é um tipo estranho de mundo para entrar quando você está acostumado a trabalhar em um ambiente mais comercial, eu acho.

Drew: Suponho que o fato de ser um sistema essencialmente com financiamento público significa que é especialmente adequado para o público que o usa, mas também em todo o mundo você viu muito uso fora do Reino Unido?

Amy: Sim, sim, houve alguns projetos realmente empolgantes em todo o mundo que o pegaram. Então eu sei que o governo da Nova Zelândia tem usado bastante. Não tenho certeza em que estágio eles estão no momento, mas certamente vi seu sistema de design de dados inicial e eles realmente usaram muito de nossa orientação e nosso código, nossos layouts e coisas assim. Acho que o governo holandês também está usando o sistema de design GOV.UK principalmente como sua primeira prova de conceito. O governo australiano começou com todas as nossas diretrizes de contribuição e as adaptou com base em suas pesquisas. Então, conseguimos trazer algumas dessas coisas de volta. Sim, então se tornou bastante global. É emocionante.

Drew: Você levaria em consideração o fato de que as pessoas o usariam ao tomar decisões sobre o tipo de próxima fase das coisas? Será que levaria em conta em suas decisões que na verdade seu público de repente não é apenas o governo do Reino Unido, na verdade poderia ser um público mundial?

Amy: É definitivamente uma consideração e acho que às vezes isso definitivamente nos deixou bastante nervosos com certas coisas que estávamos fazendo porque nosso público e o escopo de repente ficaram muito maiores quando estávamos pensando em todas as pessoas diferentes que estavam usando. Mas, pessoalmente, acho que você não pode ficar muito preso a isso, principalmente, para servir ao governo do Reino Unido. Portanto, não é prático considerar todos os públicos potenciais para isso. Eu meio que acho que cabe às equipes adaptá-lo como eles precisam para seus próprios usuários. Mas sim, definitivamente isso faz você pensar com bastante cuidado sobre apenas jogar as coisas lá fora antes que elas estejam prontas para serem testadas e outras coisas.

Drew: Então, houve algum outro tipo de surpresa ao trabalhar neste sistema de design além do fato de que ele foi então levado e usado de forma mais ampla do que você esperava inicialmente? Alguma outra coisa surgiu e surpreendeu você sobre isso?

Amy: Uma coisa que definitivamente se destacou para mim foi a variedade de pessoas em nosso público. Portanto, não apenas o tamanho do público, mas como a variação no nível de conhecimento das pessoas, suas habilidades, sua confiança, os diferentes tipos de trabalho que faziam e o tipo de contexto em que trabalhavam. Eu acho que definitivamente há muita variação lá. Acho que minha percepção foi que eu tinha essa visão de um desenvolvedor front-end de designer na minha cabeça, alguém que tem muito conhecimento técnico e, na verdade, esse é apenas um tipo de usuário. Existem muitas outras pessoas como designers de conteúdo e as coisas não eram necessariamente um público esperado para isso, mas acabaram sendo usuários-chave.

Amy: Então eu acho que sim, isso foi definitivamente uma surpresa para mim. Então, pensar em como poderíamos atender a todas essas pessoas com um conjunto tão amplo de necessidades com o sistema de design foi definitivamente um grande desafio. Sim, acho que foi provavelmente a minha maior surpresa. Então eu acho que junto com isso o quanto as pessoas viram para adotá-lo como seu. Então, acho que depois que lançamos muito rapidamente, fiquei muito agradavelmente surpreso com quantas pessoas eu veria defendendo isso em seus próprios departamentos e equipes e pessoas tentando contribuir para isso e pessoas entrando em contato conosco para perguntar como eles poderiam adaptá-lo para seus próprios usuários. Parecia realmente propriedade da comunidade desde o primeiro dia e isso não era necessariamente algo que eu esperava, mas algo que estava pronto muito bom de ver.

Drew: Acho que grande parte do papel de um sistema de design é como uma forma de documentar as decisões de design que foram tomadas para que essas decisões possam ser implementadas, compreendidas e usadas pelas pessoas. Então eu acho que um sistema de design é tanto quanto qualquer coisa, um artefato de documentação, não é? É tomar as decisões que foram tomadas e explicá-las de uma forma que as pessoas possam reutilizá-las. Como você abordou como uma equipe eles projetam o sistema como uma espécie de artefato de documentação? Como você documentou o que estava fazendo?

Amy: Então eu acho que era sobre conseguir o máximo que pudéssemos ter uma imagem realmente clara do que as pessoas precisavam dessa documentação. Então, isso volta ao ponto que eu fiz sobre ser um público de alcance bastante amplo, porque há toda uma gama de necessidades diferentes que as pessoas falam sobre documentar um componente ou um padrão como se fosse um tipo de tarefa única. Mas, na verdade, existem muitas maneiras diferentes de fazer isso e existem muitas necessidades diferentes que você precisa levar em consideração. Então, temos pessoas que, por exemplo, apenas diriam: “Oh, eu quero ver a pesquisa por trás disso”. Para algumas pessoas isso significa um número. Eles querem saber que está sendo usado em 20 serviços diferentes para que possam dizer ao gerente de produto que vale a pena investir tempo e dinheiro na implementação do serviço.

Amy: E para eles, trata-se apenas de obter esse apoio baseado em evidências para a decisão que eles estão tentando fazer. Mas há outras pessoas que realmente se preocupam em entender a pesquisa e se ela é apropriada para seu contexto e quais pesquisas adicionais elas podem precisar preencher para preencher quaisquer lacunas que foram perdidas ou talvez com as quais estejam lidando em sua situação única. Então, acho que a abordagem foi tentar entender todas essas necessidades diferentes e tentar obter um senso de prioridade entre elas e entender como poderíamos atender a todos os vários requisitos diferentes que as pessoas tinham na documentação. Não é apenas um tipo de coisa que se adapta a todos.

Amy: Então, descobrir como lidar com todas essas necessidades e sinalizar o conteúdo muito bem de uma forma que significasse que as pessoas poderiam pular as partes que não eram relevantes para elas também. Porque quando você está tentando atender a um público tão amplo, obviamente acaba fornecendo bastante informação. Então, ter certeza de que está realmente bem sinalizado e organizado, acho que foi a chave para o que estávamos fazendo.

Drew: Então, estou certo em entender que diferentes departamentos dentro do governo não são realmente obrigados a adotar o sistema de design? Você realmente tem que vendê-lo efetivamente para eles e convencê-los a usá-lo?

Amy: Sim, então é um pouco complicado. Então, no governo há algo chamado padrão de serviço governamental e é um padrão que todos os serviços governamentais com mais de um certo número de usuários são obrigados a cumprir para obter financiamento e depois entrar em Alpha e depois Beta e depois viver. Um dos pontos do padrão de serviço, saí há três semanas e já saiu da minha cabeça qual é o número, mas um dos pontos do padrão de serviço, ele fala em reutilizar padrões e componentes e tentar reutilizar o que está já lá. Então, sob esse ponto, eles são obrigados a usá-lo, mas é solto e depende de quem é o avaliador. Não é meio que fortemente mandatado. Todos nós sempre defendemos fazer o que há de melhor no contexto específico, em vez de apenas reutilizar padrões prontos para uso para marcar um ponto em uma avaliação de serviço. Então é difícil forçar. Portanto, a abordagem sempre foi muito mais colaborativa e sempre foi sobre construir apoio e defesa para o sistema de design, sem enfiá-lo goela abaixo das pessoas.

Drew: Eu acho que para isso, uma das maneiras que você conseguiu fazer isso é encorajando a contribuição. Isso está certo?

Amy: Sim, definitivamente. Então, eu sou um grande fã da contribuição para sistemas de design. Acho que é algo realmente interessante e sim, certamente na equipe trabalhamos muito para tornar possível contribuir para o sistema de design GOV.UK. Um dos benefícios reais que vimos disso foi o aumento dos defensores da rede para o sistema de design. Então, quando você recebe alguém para contribuir com isso e eles se sentem mais investidos nisso e no que recebemos, essas pessoas vão para suas equipes e se tornam nossos melhores vendedores quase porque sentem que tiveram um pedacinho disso e eles tinham algo para mostrar às pessoas e então encorajavam mais pessoas a contribuir. Então esse efeito acaba sendo bastante exponencial. Sim. Então, nós nos esforçamos muito para tornar isso possível.

Drew: Que tipo de coisas você fez para incentivar a contribuição?

Amy: Começamos muito cedo. Então, muito antes de termos um sistema de design público, começamos a nos envolver com pessoas que pensávamos que seriam contribuintes interessados. Devo mencionar aqui que tínhamos um designer de serviço brilhante na equipe. Ela se juntou a nós, não vou acertar as datas de forma alguma no momento, mas acho que ela trabalhou conosco durante todo o ano de 2018 e o nome dela é Ignatia e ela fez um trabalho fantástico ao redor e engajando as pessoas. Então, uma das coisas que ela fez foi identificar todos os diferentes padrões no governo e todas as diferentes variações desses padrões. Então, sair e dizer, ok, existem 10 maneiras diferentes de pedir um endereço no governo. Vamos analisá-los todos juntos e decidir qual achamos ser a abordagem mais apropriada.

Amy: Como podemos consolidá-los em um só? Ela dirigiu um grande workshop para tentar fazer as pessoas olharem para eles e fazer esse tipo de consolidação como uma equipe. Eu acho que definitivamente a abordagem dela para construir a colaboração antes de lançarmos qualquer coisa para o público realmente ajudou com isso porque significava que as pessoas já tinham esse tipo de consciência disso e muitas pessoas já haviam contribuído para isso de uma forma ou de outra antes de nós realmente o tornou público. Portanto, coloque-nos alguns passos à frente. Então eu acho que isso foi muito importante. E apenas persistência, como muita persistência de toda a equipe em ajudar as pessoas a contribuir. Eu acho que há uma ideia de que se você conseguir que as pessoas contribuam para um sistema de design, isso é um show muito legal, porque você pode simplesmente fazer com que as pessoas façam todo o trabalho para você.

Amy: E você apenas senta lá e faz suas correções de código de nível e todo mundo está realmente dando a você todas as coisas boas. Mas, na verdade, como qualquer um que trabalhou em um sistema de design sabe, é incrivelmente complexo. É muito difícil criar uma solução centralizada que funcione para várias equipes diferentes e, na verdade, a menos que você tenha trabalhado em um sistema de design, não é razoável esperar que alguém realmente entenda o que isso exige. Então, há um monte de mão segurando. Há muito trabalho envolvido em apoiar os contribuidores para contribuir, acho que já disse isso antes, mas provavelmente leva mais tempo, acho, para ajudar alguém a contribuir com um sistema de design do que apenas fazer a coisa na equipe centralizada . Mas acho que reconhecer o valor que isso traz e ser persistente em seus esforços para conscientizar as pessoas da contribuição e ajudá-las a fazê-lo, ajudá-las a se sentirem motivadas a fazê-lo. Eu acho, sim, que essa persistência foi realmente a chave para o nosso sucesso nessa área.

Drew: E falando praticamente sobre o gerenciamento dessas contribuições da comunidade, havia alguma ferramenta ou processo ou algo que ajudasse nisso?

Amy: Sim, então tivemos um processo bastante rigoroso, eu diria. Estrito na medida em que talvez, rigoroso é a palavra errada, abrangente é provavelmente uma palavra melhor. Então, sim, temos um conjunto de critérios de contribuição que estão no sistema de design. Então, tudo é o mais aberto possível para que as pessoas saibam o que esperar. Portanto, há um conjunto de critérios que desenvolvemos com várias pessoas da comunidade governamental fora de nossa equipe, então, novamente, como tentar envolver as pessoas na criação desses processos, acho muito importante. Portanto, há um conjunto de critérios que todas as contribuições para o sistema de design devem atender e, para garantir que estávamos sendo imparciais, suponho, e justos em termos de tomar decisões sobre se as coisas atendiam a esses critérios ou não, alistamos o apoio de um grupo de trabalho, que era um painel de representantes de todo o governo. Todos de diferentes departamentos e diferentes disciplinas e pessoas com diferentes níveis de antiguidade.

Amy: Então todos teriam uma perspectiva ligeiramente diferente sobre as contribuições e nós nos reuníamos com eles uma vez por mês e pedíamos que revisassem quaisquer novas contribuições e decidissem se eles atenderam ou não aos critérios. Então, sim, foi um tipo de processo projetado para tentar democratizar o design do sistema de design, suponho, e torná-lo representativo e garantir que não fosse apenas nossa equipe no meio tomando todas as decisões sem realmente entender como isso afetaria as equipes usando essas coisas.

Amy: Sim, esse foi o nosso tipo de processo. Mais um post que devo mencionar é que há um backlog da comunidade no GitHub, que qualquer um pode usar. Você não tem que trabalhar no governo para ir vê-lo. É acessível a partir do sistema de design e é basicamente um lugar onde tentamos hospedar toda a pesquisa e todo o material experimental e os exemplos que entram em seus componentes e padrões no sistema de design. Então, novamente, trata-se de pressionar por essa transparência e trabalhar abertamente o máximo possível para que as pessoas possam ter voz e influenciar as coisas antes de serem publicadas.

Drew: E você acha que esse processo funcionou bem? Se você estivesse embarcando na mesma coisa novamente, você acha que adotaria um processo semelhante ou há algo que não funcionou?

Amy: Acho que adotaria um processo semelhante, mas talvez com expectativas ligeiramente diferentes. O que eu diria é talvez expectativas um pouco mais realistas e tendo dito o que eu disse sobre como achamos que contribuir tornará as coisas mais fáceis e rápidas. Eu definitivamente estava nesse acampamento. Acho que pensei que haveria um pico de trabalho no começo para familiarizar as pessoas com a contribuição e, com o tempo, poderíamos ficar mais livres e as pessoas simplesmente pegariam o jeito e ficaria tudo bem. Mas, na verdade, isso nunca se materializou. Sempre houve muito trabalho envolvido em ajudar as pessoas a contribuir e, como eu disse, acho que isso é de se esperar. Eu não acho que você pode realmente fugir disso, mas eu ainda acho que é valioso.

Amy: Eu ainda acho que vale a pena investir esse tempo, mas talvez não com a ideia de que você vai acelerar as coisas ou que você será capaz de escalar mais rápido ou mais por ter contribuído. Então, sim, acho que o processo funcionou bem. Eu acho que precisa ser adaptado para diferentes organizações, então estou começando uma nova função na segunda-feira, estou trabalhando em outro sistema de design e não espero ser capaz de pegar esse processo e simplesmente mudar isso aí. Acho que tudo tem que ser adaptado à organização e ao contexto com o qual você está lidando, mas definitivamente há elementos que eu gostaria de tentar trazer. Mas sim, com expectativas um pouco moderadas, eu acho.

Drew: Falei alguns episódios atrás com Hayden Pickering sobre projetar componentes, particularmente dentro de um sistema de design para ser acessível. Isso é algo com o qual você tem muita experiência também, eu acredito. Obviamente, a acessibilidade é muito, muito crucial quando se trabalha dentro de um sistema de design do governo, mas muitos de nós argumentam que é muito, muito crucial onde quer que você esteja trabalhando. Você acha que os sistemas de design desempenham um papel na acessibilidade de um design ou na implementação de um design?

Amy: Então, há uma palestra brilhante de Tatiana Mack sobre a construção de sistemas de design inclusivos que toca nisso e isso foi muito influente para mim e ela fala sobre o tipo de efeito multiplicador dos sistemas de design. Então, com sistemas de design, estamos dizendo às pessoas como é bom e estamos dando às pessoas maneiras rápidas de implementar o que estamos dizendo às pessoas que são as melhores práticas. Então isso pode funcionar de qualquer maneira. Pode funcionar muito bem se você der às pessoas um bom design e um bom design acessível, então você tem o potencial de multiplicar esse design acessível e tornar as coisas mais acessíveis e mais inclusivas por padrão.

Amy: Se você toma decisões que excluem pessoas em um sistema de design, naquele espaço centralizado, que se torna o ponto de partida para as pessoas que projetam serviços, então você realmente tem o potencial de proliferar esse design excludente. Então, eu definitivamente acho que os sistemas de design desempenham um papel na promoção e multiplicação da acessibilidade. Mas acho que tudo começa com a intenção das equipes trabalharem e usarem o sistema de design para que isso aconteça. Um sistema de design é realmente o tipo de veículo que eu suponho e a intenção precisa estar lá para tornar as coisas acessíveis.

Drew: Uma das coisas que sempre me fascina, particularmente com sistemas de design que têm um público tão grande e variado como o sistema de design GFI UK, é o processo de proliferação de mudanças em todo o sistema. Então, se você, por exemplo, encontrar uma melhoria de acessibilidade que poderia fazer em um padrão específico e fizer isso no sistema de design, como garantir que isso seja implementado em um público tão amplo? Isso é algo que você tem alguma experiência?

Amy: Sim. Então, novamente, acho que na equipe do sistema de design GOV.UL, colocamos muita consideração em como isso funcionaria. Tenho que ser honesto, muito disso tem a ver com a forma como é implementado tecnicamente e definitivamente não sou a pessoa certa para falar tanto sobre o aspecto técnico da equipe. Acho que existem dois campos com sistemas de design e há um campo que é como vamos colocar as coisas lá fora o mais rápido possível. Vamos apenas abri-lo o mais rápido possível e isso impedirá a duplicação de esforço e a multiplicação de esforço e então podemos iterar à medida que avançamos. Então eu acho que há um pouco mais de vamos nos mover um pouco mais devagar, no qual eu acho que estou, que favorece adiar o lançamento de coisas até que você tenha um certo nível de confiança nisso.

Amy: E acho que isso é muito importante porque acho que, em geral, se você está projetando produtos e serviços, começando com o mínimo e iterando conforme você avança, acho que funciona muito bem, mas acho que quando você está construindo algo central que é projetado para muitas e muitas pessoas para reutilizar e dar a muitos públicos diferentes, você usa muito rapidamente o controle da coisa e da maneira como ela está sendo usada. Então, acho que ter uma certa confiança em algo antes de lançá-lo e ter um tipo de processo de garantia em vigor, isso significa que você tem alguma confiança de que é acessível antes de sair por aí é muito importante e espero que o a coisa é um pouco mais estável e acho que isso é muito importante para a confiança. Eu acho que a confiança é muito importante quando estamos falando sobre fazer mudanças nos sistemas de design porque se estamos lançando mudanças o tempo todo, isso torna o sistema bastante instável para usar e acho que isso quebra a confiança e as pessoas não t tão propensos a instalar atualizações e coisas assim.

Amy: Enquanto eu acho que se você pode mostrar que está sendo atencioso com o que está lançando e está lançando mudanças apenas quando necessário, então você tem essa Boa Vontade e as pessoas estão mais dispostas a fazer atualizações e outras coisas, eu acho. Mas sim, quero dizer, eu sei que muito trabalho foi feito para garantir que o processo de atualização fosse bastante suave e fácil de implementar no sistema de design GPV.UK. Eu não sou a pessoa certa para falar sobre isso, eu acho.

Drew: Então falamos brevemente sobre documentação. Se eu estivesse procurando documentar um sistema de design e quisesse fazer um trabalho realmente bom, há algo que você me aconselharia a fazer para ter certeza de que estava documentando bem as coisas?

Amy: Eu nunca acho que é possível apenas dar uma declaração geral aqui porque realmente precisa atender ao público específico com o qual você está lidando. Meu objetivo é sempre ser um pouco mais inclusivo do que você talvez sinta que precisa ser. Então, se você está pensando, especialmente em uma organização menor que talvez esteja escalando, acho que você precisa ser tão atencioso quanto seu público futuro e seu público potencial quanto seu público atual. Então, se você tem uma pequena organização e tem 10 desenvolvedores front-end e todos eles sabem o mesmo tipo de coisa e são capazes de conversar entre si e se comunicar com bastante liberdade, então sua documentação pode não ser tão abrangente quanto dentro da organização maior.

Amy: Mas acho que, para ajudar um sistema de design a escalar e garantir que ele esteja equipado para fazer isso, você precisa pensar em quem pode ingressar na organização no futuro e quem você precisa deixar a porta aberta para? Para quem você precisa deixar as coisas claras? Então, acho que sempre procure ser um pouco mais claro do que você sente que precisa ser no momento. Eu acho que testar muito a documentação é útil, então há muitas maneiras diferentes de testar o conteúdo e a documentação e acho que é muito importante sair e ter certeza de que faz sentido para outras pessoas. Acho que Caroline Darret sempre diz que se você entende bem o suficiente para saber que está correto, então sabe demais para dizer que está claro.

Amy: Eu disse isso corretamente? Se você o conhece bem o suficiente para saber que está correto, então você o conhece muito bem para dizer que está claro, é melhor, eu acho. E eu realmente meio que concordo com isso. Eu acho que para escrever uma boa documentação você tem que ter um bom conhecimento do assunto ou você precisa ou você acaba desenvolvendo esse conhecimento ao longo do tempo e através do processo de escrevê-lo. No momento em que você tem esse conhecimento do assunto, é realmente difícil julgar se você o transmitiu ou não de uma maneira que seja clara para alguém que não o transmitiu. Então, sair e testá-lo com pessoas que não conhecem o assunto como você conhece e fazê-los realmente tentar usá-lo em uma tarefa prática, acho muito importante. Sim, isso é o meu tipo de coisa número um. Você aprenderá muito mais colocando isso na frente das pessoas do que você aprenderá lendo ao redor e olhando o que outras pessoas fizeram, eu acho.

Drew: E ao fazer isso, você obviamente obterá feedback sobre essa documentação. Você tem alguma sugestão de como abordaria a correção das coisas com base nesse feedback? Is there anything specific that you'd be looking for in the feedback to understand how well your documentation had worked?

Amy: Yeah, I mean there's a few things I think to watch out for. I think it's is really important to separate preferences and people perhaps not liking the documentation from people actually not being able to use it. So I think any task-based testing with documentation is better because it might be that actually somebody complains their way through an entire guide but they still complete the task that you've set them. That's not to say that that doesn't matter. If they wanted to do the thing but they actually hated the process, then you of course need to take that into consideration. But I think that some people and I'm probably one of them just can't help themselves and will start, especially if it's a content designer, I think we can't kind of ever quite put that content design mentality aside.

Amy: So I definitely have a tendency to start live editing stuff if I'm supposed to be participating as research candidate on it. So I think yeah, separating preference from actual kind of usability and blockers is quite important. I think that making sure that your really interrogating the need to make changes and to update things. I think sometimes if somebody is particularly engaged with a design system, depending on the sort of person they are, they can be quite vocal about how they think it could be better or how they think that how they would've done it perhaps or how it could be clearer. I think it can be quite, especially if you're sort of trying to build Goodwill and you're in that early stage with the design system, it can be quite tempting to just immediately respond to that feedback and do what they say or try and make it clearer.

Amy: But then you can end up building it too far in the direction of the loud minority and I think actually really saying like how many people have got this problem? What evidence do we have that this isn't working for people? And does that warrant a kind of update? I think yeah, trying to resist the temptation to respond to every comment and bit of criticism that you receive is quite important too, yeah.

Drew: I suppose I'm a common theme here with design systems that enable consistent design and give you a reusable resource in your design and about accepting contributions that make those designs stronger and implementing accessible design choices and documenting your design to make it easy to access and use. It really all comes back to sort of inclusion, would you say that was fair that including people as much as possible?

Amy: Definitely. Sim. I mean I think that a good design system is a representative design system and I don't think it's possible to achieve representation by acting on people's behalf. I think you really need to try and involve people in the process as much as possible. I think often for people working on design systems and certainly it was the case for us at the GOV.UK design system, you tend to be one step removed from your organizations end users. So if you think for the GOV.UK design system, the people that the design system is ultimately there to serve are members of the public and citizens and people using government services. But we in our team, we're really working directly with those people. Most of the time our direct users are people working in the civil service. So making sure that you've got really strong feedback loops between your direct users and then their users to ensure that it's representative I think is really important and I think that's where inclusion comes in and yeah, I completely agree. I think it's a really central thing, like I can't imagine how you could build a successful design system without a focus on that.

Drew: Is there anything else that you'd like to share with us about your work on the GOV.UK design system?

Amy: I think my sort of main takeaway from working on it is that, I hate using the word physical when I'm talking about anything on the web, but the the visual representation of a design system I think can end up being the thing that we all get really fixated on. We look at how it's coded and we look at how it's organized and what it looks like and how it's documented and what the design is. I think that obviously that stuff is really important. I think that it's the thing that you can look at and show people and share. So it's easy to see why we get fixated on that. But I really think that the most important factor of it is the people. I think that having inclusive processes and making sure that you're kind of fostering safe discussion spaces and that you're giving people an opportunity to get involved in the work and to participate and feel motivated to help you with it and to feel this sense of ownership over it.

Amy: I think all of that stuff is really important and all of that stuff really happens outside of the code and outside of the documentation. So yeah, I think my key takeaway from working on the GOV.UK design system is how much of it is really just people work and not really anything to do with guidance and code.

Drew: Here's at Smashing we're all about learning. So what have you been learning lately?

Amy: Lately I've been learning a lot about productivity and focus. I think definitely towards the end of last year I became aware that I was really plate spinning and luckily I don't think I smashed any of those plates but I found myself kind of working quite chaotically and moving around lots of different projects and saying yes to everything. So this year is the year that I want to really improve my focus. So I'm trying to learn a little bit about mindfulness and organization and how to say no to things strategically so that I don't get overwhelmed and too distracted. I've started bullet journaling so I've really become the full 2020 cliche at this point. So that's what I'm learning at the moment.

Drew: If you dear listener, would like to hear more from Amy, you can follow her on Twitter where she's @Amy_Hupe or find her on the web at amyhupe.co.uk. Thanks for joining us today. Amy, do you have any parting words for us?

Amy: Stay cool. Que? Why did I say that? Just came out, it just came out.