Smashing Podcast Episodio 7 con Amy Hupe: ¿Qué es un sistema de diseño gubernamental?

¿Alguna vez te has preguntado cómo se utilizan los sistemas de diseño dentro de un gobierno? Además, si quisiera documentar un sistema de diseño de la mejor manera posible, ¿cómo lo haría? Hablé con la defensora de Design Systems, Amy Hupe, quien comparte sus consejos y lecciones aprendidas.

Mostrar notas

• El sistema de diseño GOV.UK
• Sigue a Amy en Twitter
• sitio web de amy

Actualización semanal

• "Comprender CSS Grid: crear un contenedor Grid", por Rachel Andrew
• "Lista de verificación de rendimiento de front-end 2020", por Vitaly Friedman
• “Por qué debería elegir HTML5 <artículo> en lugar de <sección>”, por Bruce Lawson
• “La doble personalidad del desarrollo web brutalista”, por Frederick O'Brien
• "Cómo crear e implementar una aplicación de material angular", por Shubham

Transcripción

Drew McLellan: es especialista en contenido y defensora de sistemas de diseño y pasó los últimos tres años trabajando como diseñadora de contenido sénior en Government Digital Service. En ese tiempo, lideró la estrategia de contenido para el sistema de diseño GOV.UK, incluido un enfoque directo e inclusivo de la documentación. Anteriormente trabajó para la empresa de defensa del consumidor, Which? donde escribió sobre todo, desde el compostaje hasta el transporte. Y un nuevo rol para 2020 la ve como Gerente de Proyectos para el Sistema de Diseño de Salud de Babylon, DNA.

Drew: Es una cocinera experta, una Instagrammer y sabe cómo usar el lenguaje para hacer que los servicios sean accesibles e inclusivos. Pero, ¿sabías que una vez cantó los coros de Billy Ray Cyrus? Mis grandes amigos, denle la bienvenida a Amy Hupe. Hola Amy. ¿Cómo estás?

Amy Hupe: Estoy genial. Gracias.

Drew: Así que quería hablarles hoy sobre el papel de los sistemas de diseño dentro de las organizaciones gubernamentales en general, pero específicamente el sistema de diseño GOV.UK, con el que sé que han trabajado mucho. Supongo que, en primer lugar, ¿qué abarca el sistema de diseño de GOV.UK? ¿Y cuál fue su participación en él mientras estuvo en GDS?

Amy: Así que abarca todo tipo de cosas. Así que creo que la representación más obvia es el tipo de sitio web, que es GOV.UK/design-system. Y allí encontrarás todo tipo de documentación. Todas las pautas de diseño, los componentes y los patrones, y verán parte del código, muchos ejemplos y muchos consejos sobre cómo usarlo. Pero pensando más ampliamente que eso, también abarca cosas como el kit de prototipos, que es una herramienta de creación de prototipos que se utiliza en el gobierno para hacer prototipos de HTML y CSS. Por lo tanto, prototipos de bastante alta fidelidad y también tiene su propio marco de front-end, que se llama GOV.UK Front End. Así que ese es todo el código que usan para construir los servicios.

Amy: Pero luego me gusta pensar en los sistemas de diseño de manera más holística. Entonces, además de todas esas cosas, también están todos los procesos que se encuentran a su alrededor. Entonces, cosas como cómo la gente contribuye a él y cómo la gente llega a saber que existe. Cosas como la adopción y la conciencia y todo ese tipo de cosas. Entonces, todas las cosas que permiten a las personas diseñar y construir servicios en el gobierno es como lo definiría.

Drew: Entonces, ¿cuál fue tu participación mientras estabas en GDS con eso? ¿Dónde encajaste en ese sistema?

Amy: Todo sucedió por casualidad, supongo. Así que me uní como diseñador de contenido en enero de 2017, y mi intención cuando llegué a GDS era unirme a los equipos de contenido de Gov UK. Así que pensé que iba a comenzar a escribir guías para el sistema, y ​​ese era mi sueño. Eso era lo que quería hacer. Luego llegué el primer día y me metieron en este pequeño equipo de protección, llamado el equipo de herramientas y patrones del manual de servicio.

Amy: En ese momento, el sistema de diseño no existía, pero teníamos nuestros patrones de diseño y algunas partes y piezas dando vueltas en diferentes lugares. Había una ambición de tratar de juntar esas cosas. Así que me pusieron en ese equipo como diseñador de contenido. No sabía qué era un patrón de diseño, no sabía nada sobre código, no sabía nada realmente sobre diseño web en absoluto. Todo lo que realmente sabía era contenido.

Amy: Así que fue una curva de aprendizaje bastante empinada y pasé los siguientes seis meses a un año, creo, ayudando al equipo a crear un prototipo y descubrir cómo se organizaría y presentaría y cómo escribiríamos nuestra guía, y todo ese tipo de cosas. Luego, en medio de todo eso, además de trabajar en el contenido, también comencé a mirar el lado de la contribución. Entonces, cómo la gente contribuiría y cómo la gente vendría a descubrirlo y se pondría en contacto con nosotros, y qué haríamos cuando se pusieran en contacto con nosotros para intentar mejorarlo.

Drew: Entonces, ¿qué implica diseñar contenido en ese tipo de contexto? ¿Cuáles eran el tipo de tareas diarias que estaba abordando?

Amy: Así que todo tipo de cosas en realidad. Me refiero a que hubo semanas en las que creo que no escribí una sola palabra y era más solo salir a investigar y reunirme con nuestros usuarios y tratar de entender qué era lo que querían de un sistema de diseño. Así que sí, sin profundizar demasiado, hubo intentos de hacer algo como el sistema de diseño GOV.UK antes, y así es como terminamos con este tipo de conjunto de recursos ligeramente dispares.

Amy: Por una razón u otra, estas cosas terminaron bastante dispersas, y nunca fue una de ellas la que se consideró el lugar central para buscar estas cosas. Así que mucho de eso, solo estaba tratando de entender lo que había sucedido antes y por qué esas cosas no necesariamente despegaron de la manera que esperábamos que lo hicieran. Tratando de entender qué partes de nuestro paisaje existente funcionaban para las personas y cuáles no.

Amy: Así que mucho de eso salió con nuestra investigación [inaudible 00:05:07], y nos sentamos en entrevistas de investigación de usuarios, y tomamos notas y hablamos con la gente, y simplemente entendíamos qué era lo que necesitaban. Luego hubo días en los que realmente pude sentarme frente a un teclado y escribir una guía sobre algunas cosas, lo cual también fue bueno. Pero sí, fue muy diferente para mí. Como mencionaste en la introducción, mi experiencia fue trabajar en Which? Así que era mucho más un rol editorial tradicional y estaba acostumbrado a trabajar en contenido de formato largo, y solo a escribir artículos y piezas realmente largos. Así que sí, fue un cambio bastante grande. Fue un gran salto de eso.

Drew: Entonces, ¿sus usuarios en este contexto son personas que trabajan en diferentes organizaciones gubernamentales? ¿Está bien? ¿Diferentes departamentos dentro del gobierno?

amy: si Sí es cierto. Entonces, la gente que trabaja, creo que hay 25 departamentos ministeriales diferentes en el gobierno, y también hay muchas agencias y departamentos del gobierno local. Así que estábamos tratando de expandirnos y hablar con una gran variedad de personas de todo el servicio civil. Así que sí, muchos viajes en esos primeros días.

Drew: ¿Crees que diseñar o trabajar en un sistema de diseño para un gobierno, en esencia, es diferente de un sistema de diseño para una empresa pequeña o una empresa grande?

amy: eso creo Quiero decir, creo que de lo que puedo deducir de las conversaciones que he tenido, y las conferencias en las que he estado y esas cosas, cada sistema de diseño es ligeramente diferente y el contexto siempre es ligeramente diferente, y el gobierno no es diferente en ese sentido. . Pero sí, supongo que algunos de los desafíos únicos de trabajar en algo para el gobierno son, en primer lugar, la escala. Entonces, la audiencia es probablemente la más grande que podría tener porque el gobierno es muy grande, y todos los diferentes tipos de departamentos y la distribución geográfica de esas organizaciones. Así que la escala es definitivamente algo ligeramente diferente.

Amy: Pienso también en el hecho de que no es comercialmente competitivo. Así que no estábamos tratando de mantener todo en secreto. Todo se hizo al aire libre en la medida de lo posible. Sí, todo funciona como un gran proyecto de código abierto, lo cual era un concepto un poco inusual para mí. Me tomó un poco de tiempo acostumbrarme a eso.

Amy: Ciertamente, cuando lo lanzamos por primera vez, veíamos fragmentos de nuestra guía y código que aparecían en los sistemas de diseño de otras personas. Me tomó un poco de tiempo sentirme bien acerca de eso. Creo que al principio estaba como, “¿Qué está pasando? ¿Por qué esta gente se lleva nuestras cosas? Pero en realidad ahora, realmente me gusta eso. Veo eso como un gran cumplido, y creo que es realmente bueno reutilizar lo que puedas. Pero sí, ese es un tipo de mundo extraño al que entrar cuando estás acostumbrado a trabajar en un entorno más comercial, supongo.

Drew: Supongo que el hecho de que sea un sistema esencialmente financiado con fondos públicos significa que es especialmente adecuado para que el público lo tome y lo use, pero también en todo el mundo, ¿viste mucho uso fuera del Reino Unido?

Amy: Sí, sí, ha habido algunos proyectos realmente emocionantes en todo el mundo que lo han recogido. Así que sé que el gobierno de Nueva Zelanda ha usado bastante. No estoy seguro de en qué etapa se encuentran en este momento, pero ciertamente vi su sistema de diseño de datos inicial y realmente usaron mucha de nuestra guía y nuestro código, nuestros diseños y demás. Creo que el gobierno holandés también está utilizando el sistema de diseño GOV.UK principalmente como su primera prueba de concepto. El gobierno australiano comenzó con todas nuestras pautas de contribución y las ha adaptado según su investigación. Así que hemos podido recuperar algunas de esas cosas. Sí, se ha vuelto bastante global. Es emocionante.

Drew: ¿Tendrías en cuenta el hecho de que la gente lo usaría al tomar decisiones sobre la próxima fase de las cosas? ¿Influiría en sus decisiones que en realidad su audiencia de repente no es solo el gobierno del Reino Unido, sino que podría ser una audiencia mundial?

Amy: Definitivamente es una consideración y creo que a veces eso definitivamente nos puso bastante nerviosos como equipo sobre ciertas cosas que estábamos haciendo porque nuestra audiencia y el alcance de la misma de repente se hizo mucho más grande cuando pensábamos en todas las diferentes personas que lo estaban usando. Pero, personalmente, creo que no puede dejarse atrapar por el hecho de que principalmente estamos allí para servir al gobierno del Reino Unido. Por lo tanto, no es práctico considerar todas las audiencias potenciales. Creo que depende de los equipos adaptarlo como lo necesiten para sus propios usuarios. Pero sí, definitivamente te hace pensar con mucho cuidado acerca de simplemente tirar las cosas antes de que estén listas para probarse y esas cosas.

Drew: Entonces, ¿hubo algún otro tipo de sorpresas al trabajar en este sistema de diseño además del hecho de que luego se tomó y usó más ampliamente de lo que esperaba inicialmente? ¿Algo más surgió y te sorprendió al respecto?

Amy: Una cosa que definitivamente me llamó la atención fue la variedad de personas en nuestra audiencia. Entonces, no solo el tamaño de la audiencia, sino la variación en el nivel de conocimiento de las personas, sus habilidades, su confianza, los diferentes tipos de trabajos que realizaron y el tipo de contextos en los que trabajaron. Creo que definitivamente hay mucha variación allí. Creo que mi percepción al principio era que tenía esta visión de este desarrollador front-end diseñador en mi cabeza, alguien que tiene mucho conocimiento técnico y en realidad ese es solo un tipo de usuario. Hay muchas otras personas como diseñadores de contenido y las cosas no eran necesariamente una audiencia esperada para él, pero resultaron ser usuarios clave.

Amy: Así que creo, sí, que definitivamente fue una sorpresa para mí. Entonces, pensar en cómo podíamos atender a todas esas personas con un conjunto tan amplio de necesidades con el sistema de diseño fue definitivamente un gran desafío. Sí, creo que esa fue probablemente mi mayor sorpresa. Luego, supongo que, junto con eso, cuánta gente había visto para adoptarlo como propio. Así que creo que después de que lo lanzamos bastante rápido, me sorprendió gratamente la cantidad de personas que veía salir a defenderlo dentro de sus propios departamentos y equipos y personas que intentaban contribuir y personas que se ponían en contacto con nosotros para preguntarnos cómo. podrían adaptarlo para sus propios usuarios. Se sintió realmente propiedad de la comunidad desde el primer día y eso no era necesariamente algo que esperaba, sino algo que estaba listo para ver.

Drew: Supongo que gran parte del papel de un sistema de diseño es como una forma de documentar las decisiones de diseño que se han tomado para que esas decisiones puedan ser implementadas, entendidas y utilizadas por las personas. Así que supongo que un sistema de diseño es más que nada, un artefacto de documentación, ¿no es así? Es tomar esas decisiones que se han tomado y explicarlas de manera que la gente pueda reutilizarlas. ¿Cómo abordaste como equipo el sistema de diseño como una especie de artefacto de documentación? ¿Cómo documentaste lo que estabas haciendo?

Amy: Así que creo que se trataba de obtener todo lo que pudiéramos obtener en una imagen muy clara de lo que la gente necesitaba de esa documentación. Así que esto vuelve a ese punto que mencioné acerca de que es una audiencia de amplio alcance porque hay toda una gama de necesidades diferentes de las que la gente habla sobre documentar un componente o un patrón como si fuera una especie de tarea única. Pero en realidad hay muchas maneras diferentes de hacerlo y hay muchas necesidades diferentes que debe tener en cuenta. Entonces, tenemos personas que, por ejemplo, simplemente dirían: "Oh, quiero ver la investigación detrás de esto". Para algunas personas eso significa un número. Quieren saber que se está utilizando en 20 servicios diferentes para poder decirle a su gerente de producto que vale la pena invertir tiempo y dinero en implementarlo dentro de su servicio.

Amy: Y eso es para ellos, solo se trata de obtener ese respaldo basado en evidencia para la decisión que están tratando de impulsar. Pero luego hay otras personas que realmente se preocupan por comprender la investigación y si es apropiada para su contexto y qué investigación adicional podrían necesitar completar para llenar los vacíos que se han perdido o tal vez con los que están lidiando en su situación única. Entonces, creo que el enfoque fue tratar de comprender todas esas necesidades diferentes y tratar de obtener un sentido de prioridad entre ellas y comprender cómo podríamos satisfacer todos los diferentes requisitos que las personas tenían a partir de la documentación. No es solo un tipo de cosa que se adapta a todos.

Amy: Entonces, descubrir cómo abordar todas esas necesidades y señalar el contenido realmente bien de una manera que significara que las personas también podrían omitir las partes que no eran relevantes para ellos. Porque cuando estás tratando de servir a una audiencia tan amplia, obviamente terminas brindando mucha información. Así que asegurarme de que esté realmente bien señalizado y organizado creo que fue clave para lo que estábamos haciendo.

Drew: Entonces, ¿tengo razón al entender que los diferentes departamentos dentro del gobierno no están realmente obligados a adoptar el sistema de diseño? ¿Realmente tienes que vendérselo de manera efectiva y persuadirlos para que lo usen?

Amy: Sí, entonces es un poco complicado. Así que en el gobierno hay algo llamado el estándar de servicio del gobierno y es un estándar que todos los servicios del gobierno con más de un cierto número de usuarios deben cumplir para obtener fondos y luego pasar a Alpha y luego a Beta y luego en vivo. Uno de los puntos del estándar de servicio, lo dejé hace tres semanas y ya se me ha olvidado cuál es el número, pero uno de los puntos del estándar de servicio habla de reutilizar patrones y componentes e intentar reutilizar lo que está ahí ya Entonces, en cierto modo, en ese punto se ven obligados a usarlo, pero es flexible y depende de quién sea el asesor. No es una especie de fuerte mandato. Todos siempre abogaríamos por hacer lo mejor en el contexto específico en lugar de simplemente reutilizar patrones listos para usar para marcar un punto en una evaluación de servicio. Así que es difícil forzarlo. Entonces, el enfoque siempre fue mucho más colaborativo y siempre se trató de generar apoyo y generar defensa para el sistema de diseño, no empujarlo por la garganta de las personas.

Drew: Supongo que con ese fin, una de las formas en que lo has logrado es fomentando la contribución. ¿Está bien?

Amy: Sí, definitivamente. Así que soy un gran fanático de la contribución a los sistemas de diseño. Creo que es algo realmente interesante y sí, ciertamente en el equipo hicimos mucho trabajo para que fuera posible contribuir al sistema de diseño de GOV.UK. Uno de los tipos de beneficios reales que vimos fue el aumento de los defensores de la red para el sistema de diseño. Entonces, cuando consigues que alguien contribuya y luego se sienten más involucrados en él y en lo que recibimos, esas personas irían a sus equipos y se convertirían en nuestros mejores vendedores casi porque sentirían que tenían una pequeña parte y tenían algo que mostrarle a la gente y luego alentarían a más personas a contribuir. Entonces ese efecto termina siendo bastante exponencial. Si. Así que nos esforzamos mucho para que eso sea posible.

Drew: ¿Qué tipo de cosas hiciste para fomentar la contribución?

Amy: Empezamos muy temprano. Entonces, mucho antes de que tuviéramos un sistema de diseño público, comenzamos a interactuar con personas que pensamos que estarían interesadas en contribuir. Debo mencionar aquí que teníamos un brillante diseñador de servicios en el equipo. Ella se unió a nosotros, no voy a corregir las fechas de ninguna manera en este momento, pero creo que trabajó con nosotros durante todo el 2018 y su nombre es Ignatia e hizo un trabajo fantástico. y comprometer a la gente. Así que una de las cosas que hizo fue ir e identificar todos los diferentes patrones de gobierno y todas las diferentes variaciones de esos patrones. Así que salir y decir, está bien, hay 10 maneras diferentes de pedir una dirección en el gobierno. Veámoslos todos juntos y decidamos cuál creemos que es el enfoque más apropiado.

Amy: ¿Cómo podemos consolidarlos en uno solo? Dirigió un gran taller para tratar de que la gente los mirara y hiciera ese tipo de consolidación como equipo. Creo que definitivamente su enfoque para construir la colaboración mucho antes de que lanzáramos algo al público realmente ayudó con eso porque significaba que las personas ya tenían ese tipo de conciencia y muchas personas ya habían contribuido de una forma u otra antes de que nosotros en realidad lo hizo público. Así que ponnos unos pasos por delante. Así que creo que eso fue realmente importante. Y solo persistencia, como mucha persistencia de todo el equipo para ayudar a las personas a contribuir. Creo que existe la idea de que si consigues que la gente contribuya a un sistema de diseño, es un trabajo bastante bueno porque puedes hacer que la gente haga todo el trabajo por ti.

Amy: Y simplemente te sientas ahí y arreglas el código de tu nivel y todo el mundo te está dando todas las cosas buenas. Pero en realidad, como sabrá cualquiera que haya trabajado en un sistema de diseño, es increíblemente complejo. Es muy difícil crear una solución centralizada que funcione para varios equipos diferentes y, en realidad, a menos que haya trabajado en un sistema de diseño, no es razonable esperar que nadie entienda realmente lo que se necesita. Así que hay un montón de manos agarradas. Hay mucho trabajo involucrado en apoyar a los contribuyentes para que contribuyan, creo que lo dije antes, pero creo que probablemente lleva más tiempo ayudar a alguien a contribuir a un sistema de diseño que simplemente hacerlo usted mismo en el equipo centralizado. . Pero creo que reconocer el valor que aporta y ser persistente en sus esfuerzos para que las personas se den cuenta de la contribución y ayudarlos a hacerlo, los ayuda a sentirse un poco motivados para hacerlo. Creo, sí, que esa persistencia fue realmente una especie de clave para nuestro éxito en esa área.

Drew: Y prácticamente hablando de administrar esas contribuciones de la comunidad, ¿hubo herramientas o procesos o algo que ayudó con eso?

Amy: Sí, así que tuvimos un proceso bastante estricto, diría yo. Estricto en la medida en que tal vez, estricto es la palabra incorrecta, completo es probablemente una mejor palabra. Así que sí, tenemos un conjunto de criterios de contribución que están en el sistema de diseño. Así que todo está lo más abierto posible para que la gente sepa qué esperar. Entonces, hay un conjunto de criterios que desarrollamos con varias personas de la comunidad gubernamental fuera de nuestro equipo, así que nuevamente, tratar de involucrar a las personas en la creación de estos procesos, creo que es realmente importante. Entonces, hay un conjunto de criterios que todas las contribuciones al sistema de diseño deben cumplir y para asegurarnos de que estábamos siendo bastante imparciales, supongo, y justos en términos de tomar decisiones sobre si las cosas cumplían con esos criterios o no, reclutamos a los apoyo de un grupo de trabajo, que era un panel de representantes de todo el gobierno. Todos de tipo de diferentes departamentos y diferentes disciplinas y personas con diferentes niveles de antigüedad.

Amy: Entonces, todos tendrían una perspectiva ligeramente diferente sobre las contribuciones y nos reuniríamos con ellos una vez al mes y les pediríamos que revisaran las contribuciones nuevas y decidieran si cumplían o no con los criterios. Así que sí, fue una especie de proceso diseñado para tratar de democratizar el diseño del sistema de diseño, supongo, y hacerlo representativo y garantizar que no fuera solo nuestro equipo sentado en el medio tomando todas las decisiones sin entender realmente cómo. afectaría a los equipos que usan esas cosas.

Amy: Sí, ese fue nuestro tipo de proceso. Una publicación más que debo mencionar es que hay un trabajo pendiente de la comunidad en GitHub, que cualquiera puede usar. No tienes que trabajar en el gobierno para ir a verlo. Es accesible desde el sistema de diseño y es básicamente un lugar donde tratamos de albergar toda la investigación y todo el material experimental y los ejemplos que se incluyen en sus componentes y patrones en el sistema de diseño. Entonces, nuevamente, se trata de impulsar esa transparencia y trabajar abiertamente tanto como sea posible para que las personas puedan tener una voz y puedan influir en las cosas antes de que se publiquen.

Drew: ¿Y crees que ese proceso ha funcionado bien? Si volvieras a embarcarte en lo mismo, ¿crees que adoptarías un proceso similar o hay algo que no funcionó?

Amy: Creo que adoptaría un proceso similar, pero tal vez entraría con expectativas ligeramente diferentes. Lo que diría es quizás expectativas un poco más realistas y habiendo dicho lo que dije sobre cómo creemos que contribuir hará que las cosas sean más fáciles y rápidas. Definitivamente estaba en ese campamento. Creo que pensé que habría un aumento de trabajo al principio para que la gente se familiarizara con la contribución y luego, con el tiempo, seríamos capaces de estar más manos a la obra y la gente simplemente entendería y estaría bien. Pero en realidad eso nunca se materializó. Siempre hubo mucho trabajo involucrado en ayudar a las personas a contribuir y, como digo, creo que eso es de esperar. No creo que realmente puedas alejarte de eso, pero sigo pensando que es valioso.

Amy: Sigo pensando que vale la pena invertir ese tiempo, pero tal vez no con la idea de que vas a acelerar las cosas o que vas a poder escalar más rápido o más a partir de una contribución. Así que sí, creo que el proceso funcionó bien. Creo que debe adaptarse a diferentes organizaciones, por lo que, curiosamente, comenzaré un nuevo rol el lunes. Estoy trabajando en otro sistema de diseño y no espero poder retomar ese proceso y simplemente moverme. ahí. Creo que todo tiene que adaptarse a la organización y al contexto con el que se está tratando, pero definitivamente hay elementos que me gustaría probar y traer. Pero sí, con expectativas ligeramente templadas, creo.

Drew: Hablé hace un par de episodios con Hayden Pickering sobre el diseño de componentes, particularmente dentro de un sistema de diseño para que sea accesible. Eso es algo con lo que también tienes mucha experiencia, creo. Obviamente, la accesibilidad es muy, muy crucial cuando se trabaja dentro de un sistema de diseño gubernamental, pero muchos de nosotros diríamos que es muy, muy crucial dondequiera que esté trabajando. ¿Cree que los sistemas de diseño juegan un papel en la accesibilidad de un diseño o la implementación de un diseño?

Amy: Así que hay una charla brillante de Tatiana Mack sobre la construcción de sistemas de diseño inclusivos que toca esto y que fue realmente influyente para mí y habla sobre el tipo de efecto de multiplicación de los sistemas de diseño. Entonces, con los sistemas de diseño, le estamos diciendo a la gente cómo se ve bien y le estamos dando a la gente formas rápidas de implementar lo que le estamos diciendo a la gente que son las mejores prácticas. Entonces eso puede funcionar de cualquier manera. Puede funcionar muy bien si le das a la gente un buen diseño y un buen diseño accesible, entonces tienes el potencial de multiplicar ese diseño accesible y hacer las cosas más accesibles e inclusivas por defecto.

Amy: Si toma decisiones que excluyen a las personas en un sistema de diseño, en ese espacio centralizado, que se convierte en el punto de partida para las personas que diseñan servicios, entonces realmente tiene el potencial de proliferar ese diseño excluyente. Así que definitivamente creo que los sistemas de diseño juegan un papel en la promoción y multiplicación de la accesibilidad. Pero creo que todo comienza con la intención de que los equipos trabajen y usen el sistema de diseño para que eso suceda. Un sistema de diseño es realmente el tipo de vehículo que supongo y la intención debe estar allí para hacer que las cosas sean accesibles.

Drew: Una de las cosas que siempre me fascina, particularmente con los sistemas de diseño que tienen una audiencia tan grande y variada como el sistema de diseño GFI UK, es el proceso de proliferación de cambios en todo el sistema. Entonces, si, por ejemplo, encuentra una mejora de accesibilidad que podría hacer en un patrón particular y la hace en el sistema de diseño, ¿cómo se asegura de que se implemente en una audiencia tan amplia? ¿Es algo con lo que tienes alguna experiencia?

amy: si Entonces, nuevamente, creo que en el equipo de diseño del sistema GOV.UL, consideramos mucho cómo funcionaría. Debo ser honesto, mucho tiene que ver con la forma en que se implementa técnicamente y definitivamente no soy la persona adecuada para hablar tanto sobre el aspecto técnico del equipo. Encuentro que hay una especie de dos campamentos con sistemas de diseño y hay un campamento que es como sacar cosas lo más rápido posible. Hagamos que se abra tan pronto como podamos y eso detendrá la duplicación de esfuerzos y la multiplicación de esfuerzos y luego podremos iterarlo a medida que avanzamos. Entonces creo que hay un poco más de tipo de avance un poco más lento, en el que creo que estoy, que favorece retrasar el lanzamiento de cosas hasta que tengas un cierto nivel de confianza en ellas.

Amy: Y creo que eso es bastante importante porque creo que, en general, si estás diseñando productos y servicios, luego comienzas con lo mínimo y luego iteras sobre la marcha, creo que funciona muy bien, pero creo que cuando estás construyendo algo central que está diseñado para que mucha, mucha gente lo reutilice y se lo entregue a muchas audiencias diferentes, muy rápidamente usas el control de la cosa y la forma en que se usa. Así que creo que tener una cierta cantidad de confianza en algo antes de lanzarlo y tener un tipo de proceso de garantía implementado, eso significa que tienes cierta confianza en que es accesible antes de que salga, es bastante clave y luego, con suerte, el la cosa es un poco más estable y creo que eso es realmente importante para la confianza. Creo que la confianza es bastante importante cuando hablamos de hacer cambios en los sistemas de diseño porque si lanzamos cambios todo el tiempo, eso hace que el sistema sea bastante inestable para usar y creo que eso rompe la confianza y entonces la gente no No es tan probable que instale actualizaciones y cosas.

Amy: Mientras que creo que si puedes demostrar que estás siendo considerado con lo que estás lanzando y estás lanzando cambios solo cuando es necesario, entonces tienes esa buena voluntad y luego la gente está más dispuesta a hacer actualizaciones y esas cosas, creo. Pero sí, quiero decir que se trabajó mucho para asegurarse de que el proceso de actualización fuera bastante fluido y fácil de implementar en el sistema de diseño de GPV.UK. Simplemente no soy la persona adecuada para hablar de eso, creo.

Drew: Hablamos brevemente sobre la documentación. Si estuviera buscando documentar un sistema de diseño y quisiera hacer un buen trabajo, ¿hay algo que me aconsejaría hacer para asegurarme de que estoy documentando bien las cosas?

Amy: Nunca creo que sea posible dar una declaración general aquí porque realmente necesita atender a la audiencia específica con la que estás tratando. Lo mío es intentar siempre ser un poco más inclusivo de lo que tal vez sientas que debes ser. Entonces, si está pensando, especialmente en una organización más pequeña que tal vez esté escalando, creo que debe ser tan considerado con su audiencia futura y su audiencia potencial como su audiencia actual. Entonces, si tiene una organización pequeña y tiene 10 desarrolladores front-end y todos conocen el mismo tipo de cosas y pueden hablar entre ellos y comunicarse con bastante libertad, es posible que su documentación no sea tan completa como dentro de la organización más grande.

Amy: Pero creo que para ayudar a escalar un sistema de diseño y asegurarse de que esté equipado para hacerlo, debe pensar en quién podría unirse a la organización en el futuro y a quién necesita para dejar la puerta abierta. ¿por? ¿A quién necesitas aclararle las cosas? Así que creo que siempre intenta ser un poco más claro de lo que sientes que debes ser en el momento. Creo que realmente probar mucho la documentación es útil, por lo que hay muchas formas diferentes de probar el contenido y la documentación y creo que es muy importante salir y asegurarse de que tenga sentido para otras personas. Creo que Caroline Darret siempre dice que si lo entiendes lo suficientemente bien como para saber que es correcto, entonces sabes demasiado para decir que está claro.

Amy: ¿He dicho eso correctamente? Si lo sabes lo suficientemente bien como para saber que es correcto, entonces lo sabes demasiado bien para decir que está claro, eso es mejor, creo. Y realmente estoy un poco de acuerdo con eso. Creo que para escribir una buena documentación tienes que tener un buen conocimiento de la materia o lo necesitas o terminas desarrollando ese conocimiento de la materia con el tiempo y durante el proceso de escribirlo. En el momento en que tienes el conocimiento del tema, es realmente difícil juzgar si lo has transmitido o no de una manera que sea clara para alguien que no lo sabe. Así que salir y probarlo con personas que no conocen el tema como tú y lograr que realmente lo intenten y lo usen en una tarea práctica, creo que es realmente importante. Sí, ese es mi tipo de cosa número uno. Aprenderás mucho más poniéndolo frente a la gente que leyendo y mirando lo que otras personas han hecho, creo.

Drew: Y al hacer eso, obviamente obtendrás comentarios sobre esa documentación. ¿Tiene alguna sugerencia sobre cómo abordaría arreglar las cosas en función de esos comentarios? 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. Si. 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. ¿Qué? Why did I say that? Just came out, it just came out.