HKS Case 2106.

0
August 18, 2017

Servicio digital del gobierno del Reino Unido:

Ir más allá de un sitio web

A finales de 2012, Mike Bracken se sentó en un café de Londres mientras esperaba su reunión.
Poco más de dos años antes, Bracken había sido nombrado líder del Servicio Digital del Gobierno
del Reino Unido (GDS), una nueva agencia empresarial del gobierno del Reino Unido. GDS había
sido acusado de "defender una ‘cultura digital’" en el gobierno, y Bracken esperaba que pudiera
desencadenar una ola de innovación que hiciera que los servicios gubernamentales cotidianos,
como renovar un pasaporte o solicitar un beneficio de asistencia social, fueran más eficientes,
equitativos y fáciles de usar simpático.

Bracken se estaba preparando para reunirse con Tom Loosemore, Director Adjunto de GDS y
compañero veterano de la industria tecnológica, para discutir su plan estratégico. Mientras
Bracken esperaba, reflexionó sobre su progreso hasta la fecha. Bracken y su equipo en GDS
tuvieron éxitos significativos de los cuales estaban orgullosos. GDS ya había ayudado a ahorrar
miles de millones de libras con mejores sistemas de tecnología de la información, y había
centralizado la presencia web del gobierno en un solo dominio (llamado GOV.UK) donde los
ciudadanos podían hacer todo, desde programar una prueba de manejo hasta registrarse para
recibir beneficios del gobierno. Rohan Silva, asesor de políticas en la oficina del Primer Ministro,
elogió a GDS como el "centro de la reforma del servicio público en el Reino Unido hoy", y Tim
O'Reilly, el famoso escritor de tecnología y fundador de O'Reilly Media, tuiteó que el plan de acción
y los principios de diseño de GDS fueron "los más significativos desde los de Apple". Bracken sintió
que el éxito de su equipo, por primera vez, había reunido un importante capital político dentro del
gobierno.

Este reconocimiento fue especialmente importante para Bracken porque dio crédito a sus
creencias poco convencionales, y a menudo controvertidas, sobre cómo debería funcionar el
gobierno. Para él, el servicio civil del Reino Unido estaba demasiado concentrado en crear políticas
complejas y muy poco preocupado con el trabajo de implementación de bajo glamour. El enfoque
de Bracken, que denominó "la estrategia es la entrega", se basó en la idea de que simplemente
implementando mejoras en los servicios gubernamentales (incluso si fueran imperfectos), podría
aprender de los usuarios, ahorrar dinero y proporcionar servicios mejorados con una velocidad
significativa.

A pesar del éxito de GOV.UK, Bracken sabía que tenía más trabajo que hacer para hacer realidad su
visión de un servicio civil orientado a la implementación, centrado en los usuarios y fluido en la
prestación de servicios digitales. Después de todo, GOV.UK era solo un sitio web. Debajo de la
buena prensa de GDS, también se estaba gestando descontento entre algunos funcionarios: para
ellos, GDS era ingenuo e inexperto, y sus ideas representaban una ruptura peligrosa del statu quo.
Los grandes contratistas de TI del gobierno, en particular, estaban comenzando a rechazar la
creciente influencia de GDS.

Para Bracken, estas críticas subrayaron tanto el desafío como la oportunidad que enfrentó GDS.
Cuando Loosemore llegó al café para su reunión, se preguntó: ¿cómo aprovecharían su éxito para
rehacer el gobierno para ser más eficientes y centrados en el usuario? Sabía que tendrían que
actuar rápidamente, antes de que su capital político desapareciera y la inercia del statu quo se
apoderara de nuevo.

Fondo

Historia del gobierno de TI en el Reino Unido

La década de 2000 fue una época de enorme innovación tecnológica en el Reino Unido y en todo el
mundo. Durante esos años, las grandes empresas de tecnología como Facebook y Google crecieron
rápidamente, mientras que proliferaron nuevos sitios web, aplicaciones y servicios en línea. Sin
embargo, durante ese mismo período, el ritmo de innovación dentro del gobierno del Reino Unido
fue mucho más lento. Según Bracken, esto se debió al menos en parte a que el gobierno del Reino
Unido generalmente adquiría herramientas digitales en ciclos de varios años, que eran demasiado
largos para mantenerse al día con la innovación en el sector privado. La brecha entre el nivel de
servicio que los ciudadanos esperaban al trabajar con empresas privadas y al trabajar con el
gobierno se amplió dramáticamente.

Tradicionalmente, la TI del gobierno en el Reino Unido había sido tratada de manera similar a un
problema de política, con la adquisición de tecnología siguiendo los mismos patrones que el
desarrollo de políticas. La adquisición de TI implicó un largo proceso legislativo, en el que los
requisitos de TI a menudo se determinaban. Después de que se aprobó la ley, el departamento
correspondiente generalmente continuó planificando la tecnología requerida, antes de finalmente
implementarla. Después del despliegue, era relativamente poco común que se modificaran
significativamente los requisitos de política o tecnología.

Debido a que la mayoría de los funcionarios públicos tenían conocimientos de política pero no
expertos en tecnología, casi todo el desarrollo de tecnología se subcontrató a un pequeño número
de contratistas conocidos como integradores de sistemas (SI), que incluían compañías como
Accenture, HP, Microsoft, Capgemini y otras . El número de contratistas típicos del gobierno era
pequeño: un informe encargado por la Cámara de los Comunes descubrió que "el gobierno
actualmente depende demasiado de un pequeño ‘oligopolio’ de grandes proveedores, al que
algunos [expertos] se refirieron como un ‘cartel’. Ya sea que esto constituya o no un cartel en
términos legales, los acuerdos actuales han llevado a una situación perversa en la que los
gobiernos han desperdiciado una cantidad obscena de dinero público". En general, el proceso de
redacción de leyes, requisitos y contratos requeridos entre varios meses y Varios años de
planificación e implementación.
Este proceso tradicional para la adquisición de TI tuvo muchos defensores dentro del gobierno.
Lara Sampson, una funcionaria del Departamento de Trabajo y Pensiones, señaló que este enfoque
de gestión de proyectos tuvo algunos éxitos significativos, tanto en TI como en otros lugares, como
el lanzamiento exitoso de varios cientos de oficinas por parte del Departamento de Trabajo y
Pensiones. El sistema fue particularmente exitoso para problemas que, aunque altamente
complicados, podrían resolverse de una manera conocida y lineal.

Sin embargo, este proceso tradicional también tenía muchos detractores, particularmente cuando
se aplicaba a problemas más complejos donde la solución no se conocía de antemano, como en la
tecnología. Como recordó Sampson, si bien este proceso podría usarse para la adquisición de TI,
"Nueve de cada diez veces lo que se entregó no era lo que originalmente se concibió, y se tardó
más y costó más de lo que se pretendía originalmente". No solo los excesos en el costo y el tiempo
eran comunes, sino que el proceso también fue lento para adaptarse a las necesidades cambiantes
de los ciudadanos. Las frecuentes noticias sobre proyectos de TI fallidos habían dejado al público
con poca confianza en la capacidad del gobierno para ofrecer servicios digitales.

En respuesta a este desafío, ha habido una corta historia de esfuerzos para "modernizar" el
enfoque del gobierno para proporcionar servicios digitales, que se remonta a principios de la
década de 1990. La mayoría de los primeros esfuerzos se centraron en crear un sitio web del
gobierno central. Los primeros intentos, como open.gov.uk y UK Online, fueron esencialmente
directorios de sitios web de otros departamentos. Los visitantes pueden buscar información y ser
dirigidos al portal de información de los departamentos correspondientes. Se había digitalizado un
pequeño número de servicios, como la posibilidad de solicitar un pasaporte o registrarse para
votar en línea, pero solo estaban disponibles en el sitio web de cada departamento. En 2004, el
gobierno del Reino Unido lanzó Directgov y su contraparte centrada en los negocios, Business Link,
para centralizar aún más la presencia del gobierno en Internet. Sin embargo, en la práctica, la gran
mayoría de las transacciones aún se realizaron a través de cientos de sitios web separados para
departamentos y agencias individuales. Aunque Directgov recibió millones de visitas únicas cada
mes, también recibió críticas de bloggers de tecnología que argumentaron que el sitio web podría
mejorarse al reemplazarlo con una búsqueda personalizada en Google por una fracción del costo.

Impulso por el cambio

Para 2010, una serie de factores habían convergido para elevar el perfil de la reforma tecnológica
dentro del gobierno del Reino Unido. "Sentí que había una serie de fuerzas que actuaban sobre el
gobierno en el Reino Unido en ese momento que nunca habían estado sincronizadas en mi vida",
dijo Bracken. Entre esos factores se encuentran varias fallas de TI de alto perfil, "una oleada de
personas de la industria con habilidades digitales en el Reino Unido" y la presencia de un gobierno
de coalición entre los principales partidos conservadores y liberales, "lo que significaba que era
mucho más probable obtener apoyo entre partidos porque tenías dos de los tres partidos
principales en el poder ", dijo Bracken.

Quizás el ímpetu más inmediato para el cambio fue una aguda crisis financiera que obligó al
gobierno a buscar recortes dramáticos en el gasto del servicio civil. Como recordó Francis Maude,
Ministro de la Oficina del Gabinete, “Tuvimos un déficit presupuestario del 11% del PIB. Teníamos
la mitad de Europa en crisis de deuda soberana, y estábamos a punto de estar allí. Por lo tanto,
teníamos que demostrar que estábamos haciendo algo diferente”. El partido conservador hizo
campaña con la promesa de reducir el tamaño del gobierno, y al asumir el poder en un gobierno
de coalición con los demócratas liberales, se comprometió a hacer grandes recortes de gastos.
Como Mike Bracken analizó, el Partido Conservador (del cual Maude era parte) "quería dinero
fuera del sistema, y felizmente habría privatizado los servicios si eso fuera posible, pero la
combinación de tener a los Demócratas Liberales en una coalición y que el gran cosas (servicios
públicos, telecomunicaciones) que ya se habían privatizado hace mucho tiempo significaban que
era necesaria una serie de reformas”. Para Maude, la reforma de la estrategia digital del gobierno
era un enfoque entre muchos. Sin embargo, fue atractivo: "Cuando eres un partido de oposición,
usas más la tecnología", dijo Maude. “Te conviertes en uno de los primeros en adoptar la
tecnología porque no tienes mucho dinero o recursos. Luego nos metimos en el gobierno y
descubrimos cuán increíblemente mala era la tecnología que se esperaba que usaran el servicio
civil y los ministros”. Según esta experiencia, Maude se convirtió en un importante defensor del
uso de la tecnología para reducir costos y mejorar los servicios gubernamentales.

Con estos objetivos en mente, Maude encargó un informe para revisar la presencia en la web del
gobierno por Martha Lane Fox, una empresaria de Internet que había sido nombrada "Campeona
Digital" del gobierno. En el informe resultante (titulado, “Directgov 2010 y más allá: revolución no
Evolución”), Fox recomendó reformas no solo a Directgov sino a todo el enfoque del gobierno
hacia la prestación de servicios digitales. Fox escribió: "Ha habido una reinvención de Internet y el
comportamiento de los usuarios en los últimos años. Los servicios digitales ahora son más ágiles,
abiertos y más baratos. Para aprovechar estos cambios, el gobierno necesita pasar a una "cultura
de servicio". Fox recomendó fortalecer y centralizar significativamente la presencia digital del
gobierno, así como designar un "CEO digital" para el gobierno. (Consulte el Anexo 1 para obtener
una lista completa de las recomendaciones de Martha Lane Fox).

Maude tomó en serio las recomendaciones de Fox, y en unos pocos meses creó un nuevo equipo
llamado "Servicio digital del gobierno". Él nombró a Chris Chant para servir como Director
Ejecutivo interino, y Tom Loosemore como su adjunto. Poco después, Mike Bracken fue nombrado
Director Ejecutivo permanente del gobierno para Digital.

Mike Bracken y Tom Loosemore

Incluso antes de que Mike Bracken se uniera a Tom Loosemore en GDS, los dos habían liderado
carreras ampliamente similares, liderando esfuerzos de transformación digital en los sectores
público y privado. (Ver Anexo 3 para currículums de líderes clave de GDS).

Bracken comenzó su carrera como escritor y editor de tecnología en varias publicaciones, entre
ellas The Guardian y EMAP, una editorial dirigida a empresas. Con el tiempo, Bracken pasó de
escribir sobre tecnología a liderar esfuerzos tecnológicos en varias compañías de medios. En un
momento en que los periódicos luchaban por adaptarse al mundo digital, Bracken dirigió los
esfuerzos de transformación digital en Chello (de 1999 a 2003) y en The Guardian (de 2008 a
2011). En The Guardian, fue responsable de administrar todos los sitios web, aplicaciones y otros
productos digitales del periódico. Entre papeles en periódicos, Bracken también fue director en
varias compañías importantes de TI (incluidas Wavex y Chello), centrándose en la prestación de
servicios.

Durante el mismo período de tiempo, Tom Loosemore tuvo una carrera paralela como escritor y
editor de varias publicaciones de tecnología, incluida la revista Wired. Después de eso, Loosemore
dirigió varias transformaciones tecnológicas en las principales editoriales, incluidas la BBC, Ofcom y
Channel 4.

Desde 2002, Bracken y Loosemore trabajaron juntos para explorar cómo la tecnología digital
podría transformar los servicios gubernamentales. Ambos estuvieron involucrados con mySociety,
una organización dedicada al uso de herramientas digitales para mejorar los gobiernos, como el
desarrollo de aplicaciones web para informar sobre baches y monitorear el Parlamento. Según
Bracken, mySociety era parte de un "número asombrosamente pequeño de personas que se
dieron cuenta de que la tecnología y la cultura de Internet tendrían profundas implicaciones para
nuestro estado y nuestro gobierno". (Ver Anexo 2 para ver las primeras fotos de los miembros de
mySociety). Bracken y Loosemore también habían asesorado a funcionarios del gobierno de
manera informal, y habían escrito sobre servicios y tecnología del gobierno.

Cuando Bracken y Loosemore volvieron a estar juntos en GDS, tenían una larga historia de trabajo
conjunto y un pequeño equipo que los había seguido de proyecto en proyecto. Como Loosemore
comentó: "Todos habíamos estado en un viaje juntos durante 15 años y éramos un clan bastante
apretado".

Fundando GDS
Francis Maude ubicó a GDS en el centro del Gobierno, como parte de la Oficina del Gabinete (de la
cual Maude era ministro). Actuando como la sede corporativa del gobierno, la Oficina del Gabinete
apoya al Primer Ministro y garantiza el funcionamiento efectivo del gobierno. En ese momento,
también incluía un Grupo de Eficiencia y Reforma creado por Maude para impulsar la
transformación en todo el gobierno.

Desde el principio, GDS fue diferente a la mayoría de las otras agencias gubernamentales. Aunque
GDS tenía un personal de aproximadamente 200, la mayoría de ellos nunca antes había trabajado
en el servicio civil. La oficina de GDS era un conjunto de grandes espacios abiertos, decorados con
cintas y banderas, llenos de pantallas y paredes cubiertas con notas adhesivas. Sheila Bennett, una
funcionaria pública que fue reclutada para trabajar en GDS, describió su reacción cuando ingresó
por primera vez a la oficina: “Había buscado GDS antes y me gustó lo que vi, pero nada me preparó
para entrar realmente a las oficinas, lo cual era bastante diferente a cualquier oficina de servicio
público en la que había trabajado. Tenía un aspecto técnico bastante estereotípicamente
inconformista, con los jeans, las barbas, los post-it”. Para Bennett, la sensación de GDS era nueva,
energizante y emocionante. .

Para Bracken y otros líderes del GDS, reclutar funcionarios públicos no tradicionales era una
estrategia consciente. Su objetivo era desarrollar la alfabetización digital en todo el servicio civil,
permitiendo al gobierno gestionar mejor a los contratistas de TI, desarrollar tecnología
internamente y proporcionar un nuevo conjunto de perspectivas sobre problemas comunes. Sin
embargo, para los críticos, los funcionarios públicos no tradicionales reclutados por GDS no tenían
experiencia en los difíciles desafíos de trabajar en el gobierno y proporcionar servicios públicos.
Esta inexperiencia no solo fue cierta para el personal de GDS, sino también para su liderazgo: Kathy
Settle, una antigua empleada de GDS y funcionaria experimentada, describió su papel en GDS
como consistente en gran medida en entrenar a Bracken y Loosemore sobre "todo, desde cómo se
hace reunirse con personas de la tercera edad, el tipo de lenguaje y tono que usa, los procesos de
aprobación por los que tiene que pasar, esencialmente, todas las cosas básicas sobre el trabajo en
esta organización que simplemente no entendieron”. Además, a los críticos no les gustó tanto
talento digital se centralizó en una agencia gubernamental, prefiriendo en cambio distribuir la
experiencia digital dentro de los departamentos, que según ellos tenían una mejor comprensión de
las necesidades y desafíos de sus electores.

Introducir controles de gasto

Debido a que la reducción del gasto público era una de las principales prioridades del gobierno de
coalición en 2010, y de hecho una de las principales razones para fundar GDS, identificar el ahorro
de costos se convirtió en uno de los primeros y más importantes desafíos de GDS. Sin embargo,
Bracken convenció con éxito a Francis Maude de que, a diferencia de muchos otros gobiernos, a
GDS no se le debe dar un objetivo explícito para ahorrar costos. Como Bracken recordó, su
argumento con Maude fue: "Vas a obtener más dinero de esto si nuestra motivación es hacer
grandes servicios. Si hacemos lo correcto, el dinero se derramará por el otro extremo. Si lo
hacemos buscando dinero, nuestros incentivos estarán completamente mal". Maude consintió, a
pesar de que señala que "GDS siempre fue muy frustrante para mi gente de datos porque no dirían
lo que iban a entregar... Porque yo confiaba en Mike y sabía que ofrecería grandes ahorros, dejé
que se saliera con la suya como una pequeña indulgencia”. Bracken creía que enfocar el trabajo en
la mejora del servicio en lugar de los ahorros de costos era crucial no solo para brindar a su
personal los incentivos adecuados, pero también porque hizo que GDS parezca mucho menos
amenazante para los departamentos con los que necesitaría trabajar.

La intuición de Bracken de que identificar ahorros sería fácil resultó estar bien fundada. En los
primeros años, los ahorros provenían principalmente de los controles de gastos: Maude instituyó
una regla que él personalmente necesitaría para aprobar cualquier compra de TI por encima de £ 1
millón, y utilizó GDS como asesor clave. (Las estimaciones ubicaron el gasto anual total del
gobierno en servicios de TI de hasta £ 20 mil millones). Bracken recordó una reunión en la que un
departamento "había llegado a la etapa de adquisición, listo para gastar £ 200 millones en una
tecnología de servicio de identidad1, un a pesar de que teníamos uno que ya habíamos pasado un
año y medio creando y que era perfectamente bueno”. La tecnología producida por el proveedor
finalmente no fue aprobada para la compra. Otra táctica que empleó Bracken fue pedirles a los
ingenieros de software, empleados por GDS, que se reunieran con los principales contratistas de TI.
A diferencia de la mayoría de los oficiales de adquisiciones, el ingeniero podría rechazar a los

1 Una "tecnología de servicio de identidad" es un sistema de herramientas y procedimientos para verificar la

identidad de alguien que realiza una transacción en línea.
contratistas cuando discuta por qué un cambio costaría tanto o tomaría tanto tiempo. En general,
Bracken recordó que encontrar grandes ahorros de costos no era un desafío en absoluto: como él
lo expresa, "No era como pescar en un barril; Era como el pescado en todas partes. Fue fácil.
Simplemente no podía faltar". GDS estimó que había aproximadamente £ 1.8 mil millones en
ahorros disponibles de los servicios de digitalización. (Consulte el Anexo 4 para obtener una
descripción general de los ahorros estimados del cambio a digital).

El uso de los controles de gasto por parte de GDS sí generó cierta fricción con otros departamentos
gubernamentales. Como Lara Sampson, una empleada del Departamento de Trabajo y Pensiones,
recordó: “Esa cantidad de poder definitivamente hizo que GDS fuera impopular. Había una
sensación de que no solo tenían mucho poder, sino que la situación no lo justificaba. No tenían la
experiencia de una entrega transaccional complicada y de extremo a extremo que los justificaba."
Sin embargo, GDS era popular entre Francis Maude y varios otros políticos de alto rango, que
proporcionaron cobertura política cuando GDS recibió una devolución.

Otra razón importante para identificar los ahorros tempranos fue crucial para GDS, ya que puso a la
organización misma en una posición financiera firme. Loosemore recordó que gran parte de los
primeros fondos de GDS provenían directamente de los ahorros que identificó: “Hicimos este trato
con el Tesoro, donde dijimos que cerraríamos un sitio web que costaba decenas de millones de
libras por año, y mantendríamos el dinero. El Tesoro estaba lo suficientemente feliz como para
obligarlo, dado que no tenían nada que perder. El resultado fue que no tuvimos que luchar por
dinero durante los primeros años".

Desarrollando GOV.UK: la puerta de entrada al gobierno

Además de instituir controles de gastos, GDS debía construir una nueva presencia en la web para el
gobierno del Reino Unido. Esto surgió directamente del informe de Martha Lane Fox, que
recomendaba la creación de un "sitio web [front-end] para los servicios transaccionales en línea de
todos los departamentos para ciudadanos y empresas". GDS decidió reemplazar los sitios web
existentes del gobierno central, Directgov y sus negocios. Contrapartida centrada Business Link,
con un único sitio web conocido como GOV.UK.

Bracken tenía al menos dos objetivos generales con la creación de GOV.UK. El primero fue alinear
la presencia web del gobierno con las necesidades de los usuarios. "GOV.UK pone las necesidades
del usuario por encima de todo lo demás", escribió Bracken. Esto no solo significaba que los
servicios debían estar en línea (y, por lo tanto, accesibles siempre que fuera más conveniente para
los usuarios), sino también que los usuarios no deberían necesitar saber qué departamento (o
departamentos) era responsable de un servicio en particular para encontrarlo en línea. Como
Loosemore tuiteó: "Cada página superflua que creamos es un callejón sin salida más para un
usuario enojado, frustrado y confundido". GOV.UK se construiría con las necesidades del usuario,
en lugar de los límites del departamento, como el principio de organización.

Un segundo objetivo de GOV.UK era financiero. Debido a que los servicios gubernamentales rara
vez se digitalizaban, cada vez que un usuario interactuaba con el gobierno, mediante una visita en
persona, el envío de formularios en papel o una llamada telefónica, era costoso. Todos los años, el
gobierno recibió millones de llamadas de ciudadanos para obtener respuestas a preguntas o ayuda
con servicios que podrían haberse completado en línea. Según Maude, "las transacciones en línea
pueden ser 20 veces más baratas que por teléfono, 30 veces más baratas que cara a cara y hasta 50
veces más baratas que por correo". 2 Al trasladar más servicios gubernamentales en línea, Bracken
sintió que él no solo podría mejorar los servicios, sino también ahorrar dinero en el proceso.

Una vez que GDS comenzó a construir GOV.UK, el proceso fue una lección para muchos
funcionarios sobre lo que significaba funcionar como una empresa de tecnología. GDS estableció
varias reglas para sí mismo en el proceso, incluyendo "Comenzar con las necesidades del usuario"
e "Iterar. Luego, repita nuevamente”. (Consulte el Anexo 5 para obtener una lista completa de los
principios de diseño de GDS). Para muchos funcionarios, la noción de iterar constantemente (un
enfoque para el desarrollo tecnológico conocido como enfoque “ágil”) fue un cambio difícil en el
estilo de trabajo, en comparación con su enfoque anterior de planificación meticulosa seguido de
un despliegue dedicado. Sin embargo, el equipo de GDS creía firmemente que el enfoque ágil
aumentaba la probabilidad de éxito de un proyecto de TI, ya que permitía a los ingenieros,
diseñadores y formuladores de políticas determinar rápidamente las necesidades de los usuarios y
adaptarse a ellas en tiempo casi real.

En la práctica, la aplicación de estos principios al diseño de GOV.UK significaba comenzar

diseñando un prototipo (conocido como "alfa"). El equipo de GDS catalogó todos los artículos en
línea existentes de los sitios web de varios departamentos, agrupándolos en aproximadamente
1.800 "necesidades" distintas de usuarios, que incluían cosas como "Necesito informar un
pasaporte perdido" y "Necesito saber qué implica el Servicio de Jurado". A partir de ahí, el equipo
de GDS los priorizó en aproximadamente 600 necesidades de usuarios que abordarían en su
prototipo inicial.

El prototipo fue un espacio para probar una variedad de diseños diferentes para cada una de las
cientos de necesidades de los usuarios. Los ensayos a menudo comenzaron como bocetos
dibujados a mano sobre el aspecto de una página web, basados en entrevistas con usuarios. Para
algunos servicios, el prototipo incluía un árbol de decisiones, mientras que para otros incluía una
página de respuestas, una guía práctica, una calculadora u otro servicio. Inusualmente para una
empresa de tecnología, este prototipo estaba abierto al público (alojado en el sitio web
alpha.gov.uk), para obtener la mayor cantidad de comentarios posible de los usuarios reales. Hubo
más de 100,000 visitas a alpha.gov.uk, y casi 1,000 personas dejaron comentarios directos.

El sitio web se lanzó en 12 semanas y por £ 261,000.29 Aunque Bracken y Loosemore, veteranos
de procesos ágiles de desarrollo de Internet, confiaban en su éxito, incluso los defensores fuertes
como Francis Maude estaban un poco aprensivos. Como recordó Maude, "no sabía mucho sobre
este territorio. No soy técnico Me habían convencido de que este era el camino correcto, pero
había mucha gente que había lanzado cosas en el gobierno con muchas buenas conversaciones
que no resultaron”. Sin embargo, cuando se lanzó el sitio web y Maude vio cuánto mejoró el status
quo, se convirtió en un feroz defensor. Cuando otros departamentos expresaron escepticismo,

2 Los costos estimados de cada transacción variaron. Una estimación sugiere que el costo promedio de una
transacción completada por correo fue de £ 6.62, el costo promedio de las transacciones por teléfono fue de
£ 4.11 y el costo promedio por transacción digital fue de £ 0.22. Otras estimaciones colocaron el costo de
una transacción por correo tan alto como £ 8.62.
Maude fue uno de los primeros en defender a GOV.UK: “Hubo muchas críticas de diferentes
departamentos sobre GOV.UK. La gente dijo que la búsqueda no funciona, o algo así. Y tuvimos
que explicar: ‘Este es un trabajo en progreso. No estamos en el viejo mundo de contratar a un gran
integrador de sistemas, y cualquier cambio costará toneladas de dinero. Se repetirá
constantemente y se mejorará constantemente en función de la experiencia del usuario". Si bien
algunos veteranos entendieron de inmediato el nuevo proceso, otros requirieron un
entrenamiento y una capacitación más activos.

Reacciones del público

El lanzamiento de GOV.UK fue la primera introducción importante de GDS al resto de Gran Bretaña,
y recibió un gran aplauso. Particularmente dentro de la industria de la tecnología, los periodistas
elogiaron el diseño limpio de GOV.UK, la experiencia simplificada del usuario y la arquitectura
simple. (Ver Anexo 6 para capturas de pantalla de GOV.UK beta.) Los espectadores esperaban que
el sitio web fuera un presagio de mejoras aún más profundas en el enfoque del gobierno hacia la
TI. Dentro de la comunidad tecnológica, GDS fue especialmente elogiado por su enfoque en el
usuario: Tim O’Reilly comentó que "esta es la revolución que estamos viendo aquí: esta estrategia
es la nueva biblia para los sistemas gubernamentales".

Un grupo de interesados públicos tuvo una recepción mucho más helada para GOV.UK: los
principales contratistas de TI. Debido a GDS, el gobierno del Reino Unido estaba empleando por
primera vez directamente a cientos de desarrolladores de software, disminuyendo
significativamente la necesidad de contratar grandes trabajos de TI y aumentando la presión sobre
los contratistas cuando lo hizo. Además, el gobierno había comenzado un esfuerzo concertado
para desviar los contratos de los integradores de sistemas grandes hacia empresas más pequeñas y
medianas. En un discurso ante los profesionales de TI, Maude observó: “Sorprendentemente,
cuando llegamos a la oficina, las PYME [pequeñas y medianas empresas], a pesar de representar la
mitad de la facturación en la economía del Reino Unido, estaban ganando solo alrededor del 6,5%
del gasto en adquisiciones del gobierno central. Este gobierno ha establecido la aspiración de que
una cuarta parte de nuestro negocio vaya, directa o indirectamente, a las PYME”. En algunos casos,
los grandes contratistas rechazaron, alegando que el gobierno estaba adoptando un enfoque
innecesariamente adversario y amenazando con mirar fuera Gobierno del Reino Unido para los
negocios. Cuando se adjudicaron grandes proyectos a vendedores pequeños y no probados,
algunos integradores de sistemas importantes también advirtieron sobre la posibilidad de fallas
catastróficas. Dentro de GDS, declaraciones como esta fueron rechazadas principalmente: como
recordó Francis Maude, “Todos los principales proveedores del gobierno solían gemir como un
infierno sobre mí. Fue porque quitamos la tetina del gobierno que habían estado amamantando
durante mucho, mucho tiempo”. Sin embargo, casi todos estuvieron de acuerdo en que,
independientemente de sus motivos, estos proveedores gubernamentales importantes ejercían
una gran influencia de poder e influencia, y algunos temen que un cambio tan dramático lejos de
ellos pueda producir una reacción violenta contra GDS.

Reacciones de los departamentos gubernamentales

Las reacciones iniciales al GDS desde dentro del servicio civil fueron incluso más variadas que las
del gobierno externo. Mientras que muchos estaban animados por GDS y su enfoque de trabajo
centrado en el usuario, otros estaban confundidos, escépticos u opuestos.

Uno de los hallazgos sorprendentes para muchos de los primeros empleados de GDS fue cuán
entusiastamente tantos empleados del gobierno saludaron los cambios que trajo GDS. Como
Andrew Greenway, uno de los primeros empleados de GDS que había trabajado anteriormente en
otros lugares de la administración pública, recordó:

Una cosa que encontré bastante sorprendente fue la cantidad de personas en los
departamentos que sabían perfectamente cómo hacer una investigación adecuada de los
usuarios, la necesidad de crear servicios inclusivos, quién reconoció cuán roto estaba el
mercado de adquisiciones, etc. No necesitaban que se les explicara eso; lo que necesitaban
de GDS era esencialmente la cubierta superior y el permiso para superar a los
bloqueadores en sus propios departamentos. Por lo tanto, los partidarios más fuertes de
GDS eran, de hecho, funcionarios de carrera que habían estado enfadados por lo que
estaba sucediendo en sus departamentos y nunca habían tenido un respaldo poderoso y el
mandato de continuar y solucionarlo ... No necesitábamos crear aliados en cierto sentido,
solo necesitábamos encontrarlos.

Sheila Bennett, otra empleada temprana de GDS que vino de otra parte del servicio público,
recordó su sentimiento al unirse al equipo de GDS: "Se sintió como una liberación ser alentada a
trabajar de esa manera". Muchos funcionarios se convencieron más lentamente de que
necesitaban la ayuda de GDS, a menudo alentados por la realidad de los grandes recortes de
gastos, que GDS prometió ayudarles a navegar sin sacrificar la calidad de su servicio.

Mientras que algunos miembros del personal se sintieron liberados por el enfoque de GDS, un
número significativo de personal de mayor rango tomó un enfoque hostil hacia GDS. Neil Williams,
quien en 2010 era el jefe de comunicaciones digitales para el Departamento de Negocios,
Innovación y Habilidades, recordó su reacción inicial al informe de Martha Lane Fox: “Pensé,
'¿quién cree ella que es?' ... ¿Cómo podría ¿hacer esta sugerencia de manera tan frívola? Williams
acababa de terminar una importante revisión de la presencia en la web de su departamento, y
estaba recibiendo una gran aceptación, incluso se le pidió que ayudara a otros departamentos a
hacer lo mismo. Mientras Williams reflexionaba más, se dio cuenta de que había consecuencias
negativas potencialmente aún mayores para su organización:

¿Qué pasaría con nuestra capacidad como organización para comunicar nuestro mensaje a
nuestros usuarios? ¿Qué pasaría con nuestro control sobre nuestro mensaje? ¿Cómo podría reunir
todos [estos sitios web dispares del gobierno] y todavía tiene sentido y ser localizable y navegable?
... ¿Y qué haría yo con todas estas cosas que están en tren, todos estos proyectos que tengo en
marcha? ¿Qué les diría a todas estas personas que actualmente están gastando dinero y tiempo
haciendo cosas que ahora serán una pérdida de tiempo?

Como Sheila Bennett, una funcionaria reclutada para formar parte de GDS, resumió su opinión
sobre la resistencia a GDS: “Las personas con las que tuvimos más problemas eran personas
mayores y personas con experiencia en tecnología. Para ellos, éramos mucho más una amenaza.
Porque efectivamente nos percibieron como diciendo que la forma en que usted personalmente ha
estado haciendo las cosas no es lo suficientemente buena y le diremos cómo hacerlo mejor. Y si
nuestra solución funcionaba, significaba que tal vez ellos o su equipo podrían estar sin trabajo”.

A menudo, esta resistencia nació de la lealtad a diferentes departamentos gubernamentales. Como

recordó Neil Williams, "Fue mi trabajo escribir [mis] pensamientos y decir por qué [GOV.UK] no
debería suceder. No estaba en la organización [i.e. intereses del departamento], y como jefe de
comunicaciones digitales para esa organización, mi trabajo consistía en escribir informes... sobre
por qué eso no debería suceder”. Entre los funcionarios de carrera, tal lealtad a los intereses de los
departamentos era generalizada, a pesar de que era considerada provincial por algunas figuras
políticas: Francis Maude recordó haber descubierto un documento, escrito alrededor de 2008,
sobre qué buscar al contratar Secretarios Permanentes: “Uno de los criterios que especificó fue
que debe poder equilibrar las necesidades del departamento con los deseos de los ministros.
Bueno, eso me pareció profundamente, profundamente impactante. Lo que básicamente decía es
que tienes carta blanca para no hacer lo que los ministros quieren si crees que no es del interés del
departamento”. En cada departamento, una variedad de reglas y normas alentó a los funcionarios
a resistir los cambios en los procesos del departamento que tenían establecido desde hace mucho
tiempo, y había demostrado ser exitoso en el pasado. El resultado, según Maude, fue que "en cada
etapa, las personas intentaban encontrar el fracaso con GDS".

En términos más generales, los líderes de GDS sintieron que estaban nadando contra una fuerte
corriente cultural que requería una profunda reeducación de casi todos en el gobierno. Los hábitos
simples, como el deseo de decirles a los ministros cuándo podrían esperar ver un servicio digital,
se volvieron imposibles al emplear un enfoque más ágil. Cuando los funcionarios intentaron
explicar que no podían dar certeza porque era una falsedad, fueron etiquetados como "hippies" o
incompetentes. Del mismo modo, cuando los líderes del departamento apoyaban el trabajo de
GDS, a menudo ofrecían prestarle a GDS más personal, a pesar de que los líderes de GDS preferían
menos personal con más poder para tomar decisiones rápidas. En cada etapa, el personal de GDS
sintió que pequeños malentendidos como estos constantemente reforzaban el status quo e incluso
dificultaban las colaboraciones simples.

Ir más allá de un sitio web

A pesar de los primeros éxitos de GDS, Bracken y Loosemore sintieron que apenas habían
comenzado la transformación digital del gobierno. Su visión, articulada por primera vez por el
escritor de tecnología Tim O’Reilly y comúnmente llamada "gobierno como plataforma", era un
gobierno que hiciera mucho más para empoderar a las personas dentro y fuera del gobierno para
que innovaran. A través de herramientas como los datos abiertos, los servicios comunes que
atraviesan los departamentos, la reforma de adquisiciones y el reclutamiento de talento digital en
el gobierno, Bracken y Loosemore esperaban crear una forma de gobierno radicalmente
simplificada, más eficiente y más centrada en el usuario. Vieron GOV.UK como solo el comienzo de
"un nuevo enfoque para la entrega digital de servicios públicos en el Reino Unido. Es el comienzo
de un nuevo enfoque para todo lo digital en el gobierno central".
En muchos sentidos, el trabajo de crear GOV.UK solo ilustraba exactamente cuánto más trabajo
creían que Bracken y Loosemore tenían que hacer. Hacer mejoras cosméticas en el sitio web puso
de manifiesto cuán rudimentaria era a menudo la TI de fondo de los servicios gubernamentales.
Por ejemplo, un servicio que se digitalizó en GOV.UK fue la posibilidad de reservar una visita para
ver a alguien en prisión. Bracken y Loosemore esperaban que facilitar la visita de amigos en prisión
ayudaría a rehabilitar a los reclusos y reduciría las tasas de reincidencia. Sin embargo, aprendieron
que detrás del escenario el personal de la prisión se vio obligado a copiar manualmente las
reservas del nuevo servicio digital en su antiguo software. También se dieron cuenta de que estos
servicios de TI de back-end también debían actualizarse.

Cuanto más profundo en la burocracia intentaba influir GDS, más fuerte era a menudo el rechazo.
Como Lara Sampson, funcionaria del Departamento de Trabajo y Pensiones, recordó: “Una frase
muy común en todo el gobierno dirigida a GDS fue: ‘Construyeron un buen sitio web. ¿Quiénes son
ellos para saber cuán difícil es el resto de esto?’ "

Los cambios en los sistemas de TI más profundos también reforzaron las mismas dificultades
políticas que GDS encontró por primera vez al construir GOV.UK. Por ejemplo, cada departamento
tradicionalmente mantuvo su propio conjunto de servicios básicos de TI, incluso para funciones
que eran comunes en casi todos los departamentos, como verificación de identidad, pagos,
búsqueda de direcciones, etc. Esto condujo a gastos de TI enormes y duplicados; Bracken esperaba
desarrollar plataformas comunes para estos servicios compartidos como una solución más
rentable. Sin embargo, para muchos departamentos, esto era anatema: ya habían gastado millones
(si no cientos de millones) de libras desarrollando un sistema personalizado que sabían que
funcionaba para sus propias necesidades particulares. Loosemore recordó algunos de los
retrocesos que recibió de otros departamentos. “Los departamentos podrían decir: realizamos un
gran esfuerzo para asegurarnos de que nuestros sistemas se conectan entre sí. Es torpe, pero está
funcionando. Me costó mucho hacer que funcionara. ¿Y quiere que asumamos todo el riesgo de
realizar una cirugía a corazón abierto en nuestro servicio que está funcionando en este momento
solo para ahorrar un 20%? Debes estar bromeando”. Además de preocuparse por las implicaciones
para su servicio, algunos líderes de departamento también temían que si GDS controlara servicios
básicos como pagos y verificación de identidad, podría, de hecho, controlar lo que el
departamento podría y podría no lo haga regulando el acceso a estos servicios esenciales.

Si bien la idea de desarrollar plataformas comunes amenazaba a muchos departamentos, a

Bracken le parecía sentido común. Bracken recordó una conversación temprana que sugería la idea
a un colega: “Sugeriría una plataforma común en la fontanería más básica, como los sistemas de
pago, que es un producto completo. Y la gente decía "No, debo tener la mía". Y yo decía: "Es todo
lo mismo, no existe la tuya". Recuerdo haberle dicho a alguien: "¿Necesitas tu propia electricidad?"
el tipo dijo: "Bueno, yo administraría mi propio proveedor de electricidad". Esa fue la profundidad
de este sentimiento". Para los departamentos, impulsar cambios más profundos en TI no estaba
probado, posiblemente era peligroso y carecía de poder. Sin embargo, para Bracken su resistencia
era enloquecedora e ineficiente: "¡No ha habido ninguna función hacia la colaboración y el
consenso en nuestro gobierno desde la segunda guerra mundial!", se quejó.
Próximos pasos
Con la cálida recepción de GOV.UK, y con la buena voluntad política que GDS había ganado al
reducir con éxito los costos de TI, Bracken y Loosemore sintieron que tenían una rara oportunidad
para avanzar en su visión del "gobierno como plataforma". Su poder sobre el gasto en TI y el firme
apoyo político de Francis Maude también les dio suficiente influencia para hacer cambios
importantes. Sin embargo, dada la fuerte resistencia que ya se estaba formando dentro del servicio
civil y de la industria establecida, también sabían que tendrían que tener cuidado al elegir hacerlo.

Mientras Bracken y Loosemore se sentaban en el café para su reunión sobre estrategia, había una
serie de preguntas en sus mentes. GOV.UK todavía era un trabajo inacabado: aunque habían
transferido contenido de 25 sitios web principales del departamento (centrándose en las
necesidades de los usuarios más grandes), todavía había cientos de agencias por valor para traer a
GOV.UK, un total de aproximadamente 150,000 páginas web nuevas cada uno necesitaría migrarse,
actualizarse y hacerse coherente con el nuevo estilo GOV.UK. Más allá de GOV.UK, Bracken y
Loosemore habían estado considerando varios cursos de acción diferentes, incluido integrarse en
los departamentos para ayudar a digitalizar las transacciones, crear servicios comunes que
pudieran ser compartidos por los departamentos (como la verificación de identidad y los pagos),
desarrollando gastos más estrictos controles, seguimiento de indicadores clave de rendimiento en
cada una de las transacciones en GOV.UK, capacitación de líderes del departamento en la
prestación de servicios digitales y otras vías.

Además de trabajar con los departamentos, Bracken y Loosemore también sabían que tendrían
que encontrar algunas formas de ganarse el favor de los líderes políticos del gobierno. A pesar del
tremendo apoyo que Francis Maude les brindó, Bracken y Loosemore sabían que era posible que
estos líderes fueran eliminados en la próxima elección. El dúo se preguntó si deberían estar
presionando a los líderes políticos dentro del gobierno, así como a otros agentes de poder
institucionales como el Tesoro.

Todos estos diferentes proyectos y enfoques tenían el mismo objetivo: un servicio civil nativo
digital que se centró en las necesidades del usuario y en la entrega. Sin embargo, Bracken y
Loosemore sabían que ningún enfoque llegaría lo suficientemente lejos como para transformar el
gobierno de la manera que quisieran. Con tantos esfuerzos en marcha, tendrían que decidir: ¿qué
enfoques deberían priorizarse? ¿Cómo deberían garantizar la aceptación y el apoyo del resto de la
administración pública? ¿Cuáles fueron las mejores formas de garantizar un apoyo político
duradero, incluso más allá de las próximas elecciones? ¿Cuándo deberían ser audaces y cuándo
deberían ser complacientes? ¿Cuánto fue demasiado para su pequeño pero creciente equipo?
Cuando Loosemore se sentó, los dos comenzaron a discutir.
Anexo 1: Resumen de recomendaciones clave del informe de Martha Lane Fox
"Directgov 2010 y más allá: revolución no evolución"

1. Convierta a Directgov en el front-end gubernamental para los servicios transaccionales en

línea de todos los departamentos para ciudadanos y empresas, con los dientes necesarios
para exigir soluciones gubernamentales cruzadas, establecer estándares y obligar a los
departamentos a mejorar la experiencia de los ciudadanos en transacciones clave.
2. Convierta a Directgov en un mayorista, así como en la tienda minorista de servicios y
contenido del gobierno, ordenando el desarrollo y la apertura de interfaces de programas
de aplicación (APls) a terceros.
3. Cambie el modelo de publicación gubernamental en línea, al poner un nuevo equipo
central en la Oficina del Gabinete en control absoluto de la experiencia general del usuario
en todos los canales digitales, encargando toda la información en línea del gobierno de
otros departamentos.
4. Nombrar un nuevo CEO para Digital en la Oficina del Gabinete con autoridad absoluta
sobre la experiencia del usuario en todos los servicios en línea del gobierno (sitios web y
APls) y el poder de dirigir todo el gasto en línea del gobierno.

Fuente: Martha Lane, "Directgov 2010 y más allá: revolución no evolución",

https://www.gov.uk/government/publications/directgov-2010-and-beyond-revolution-not-evolution-a-
report-by- Martha-Lane-Fox.
Anexo 2: foto temprana de MySociety

Source: Tom Loosemore

Anexo 3: Curriculum vitae abreviado de Francis Maude, Mike Bracken y Tom
Loosemore
Anexo 4: Ahorro estimado del cambio a digital

Ejemplos de ahorro de costos al convertir a digital:

• “La Agencia de Normas de Conducción comenzó a ofrecer un canal en línea para reservar
exámenes de manejo prácticos en 2003. Más de las tres cuartas partes de casi 2 millones
de transacciones ahora son digitales, con solo el 23% de las personas que aún reservan por
teléfono. A medida que las personas migraron a lo digital, los costos cayeron. Las
principales fuentes de ahorro han sido las reducciones en el número de empleados y los
costos de alojamiento. Uno de los 2 centros de contacto dedicados cerró en 2008, mientras
que el número total de empleados que trabajan en la transacción se redujo de 400 en
2003 a 75 en 2012. Los costos de papelería y franqueo también se han eliminado del canal
digital".

• “HMRC ofreció por primera vez la presentación de declaraciones de impuestos en línea en

2000, con el ritmo de la aceleración de la recogida luego de la Revisión de Carter en 2006.
El año pasado, la aceptación digital de los 4 principales impuestos comerciales
(Autoevaluación, PAYE, Impuesto sobre sociedades e IVA) fue superior al 80%, equivalente
a decenas de millones de transacciones. Los volúmenes dramáticamente reducidos de
solicitudes en papel han significado que se requiera menos gente para procesarlos (lo que
resulta en una reducción equivalente a tiempo completo (FTE) de más de 2,700 en los
 últimos 5 años), una reducción correspondiente en la necesidad de su alojamiento, menos
espacio para guarde los formularios en papel (ahorros acumulados de casi £ 5 millones),
menos papelería (ahorros acumulados de £ 34 millones) y un gasto menor en franqueo”.
Source: Gov.uk, Digital Efficiency Report, November 6, 2012, https://www.gov.uk/government/publications/digital-
efficiency- report/digital-efficiency-report

Anexo 5: Principios de diseño de GDS

1. Comience con las necesidades del usuario: el diseño del servicio comienza con la
identificación de las necesidades del usuario. Si no sabe cuáles son las necesidades del
usuario, no creará lo correcto. Investigue, analice datos, hable con los usuarios. No hagas
suposiciones. Tenga empatía con los usuarios y recuerde que lo que piden no siempre es lo
que necesitan.

2. Hacer menos: el gobierno solo debe hacer lo que solo el gobierno puede hacer. Si hemos
encontrado una manera de hacer algo que funcione, deberíamos hacerlo reutilizable y
compartible en lugar de reinventar la rueda cada vez. Esto significa construir plataformas y
registros sobre los que otros pueden construir, proporcionando recursos (como API) que
otros pueden usar y vinculando el trabajo de otros. Deberíamos concentrarnos en el
núcleo irreducible.

3. Diseño con datos: en la mayoría de los casos, podemos aprender del comportamiento del
mundo real al observar cómo se utilizan los servicios existentes. Deje que los datos
impulsen la toma de decisiones, no corazonadas ni conjeturas. Siga haciendo eso después
de poner en funcionamiento su servicio, crear prototipos y probar con los usuarios y luego
repetir en respuesta. El análisis debe estar integrado, siempre activado y fácil de leer. Son
una herramienta esencial.

4. Haz el trabajo duro para hacerlo simple: hacer que algo parezca simple es fácil. Hacer que
algo sea fácil de usar es mucho más difícil, especialmente cuando los sistemas subyacentes
son complejos, pero eso es lo que deberíamos estar haciendo. No tome "siempre ha sido
así" como respuesta. Por lo general, es más y más difícil hacer las cosas simples, pero es lo
correcto.

5. Iterar. Luego, repita de nuevo: la mejor manera de crear buenos servicios es comenzar de a
poco e iterar de manera salvaje. Lanza Productos Viables Mínimos temprano, pruébalos
con usuarios reales, pasa de Alpha a Beta a Live agregando funciones, eliminando cosas
que no funcionan y haciendo mejoras basadas en los comentarios. La iteración reduce el
riesgo. Hace improbables las fallas grandes y convierte las fallas pequeñas en lecciones Si
un prototipo no funciona, no tenga miedo de desecharlo y comenzar de nuevo.

6. Esto es para todos: el diseño accesible es un buen diseño. Todo lo que construimos debe
ser lo más inclusivo, legible y legible posible. Si tenemos que sacrificar la elegancia, que así
sea. Fueron construyendo para las necesidades, no para el público. Estamos diseñando
para todo el país, no solo para los que están acostumbrados a usar la web. Las personas
que más necesitan nuestros servicios son a menudo las personas que los encuentran más
difíciles de usar. Pensemos en esas personas desde el principio.
 7. Comprender el contexto: no estamos diseñando para una pantalla, estamos diseñando
para personas. Tenemos que pensar mucho sobre el contexto en el que utilizan nuestros
servicios. ¿Están en una biblioteca? ¿Están en un teléfono? ¿Están realmente
familiarizados con Facebook? ¿Nunca han usado la web antes?

8. Cree servicios digitales, no sitios web: un servicio es algo que ayuda a las personas a hacer
algo. Nuestro trabajo es descubrir las necesidades de los usuarios y crear el servicio que
satisfaga esas necesidades. Por supuesto, gran parte de eso serán páginas en la web, pero
no estamos aquí para crear sitios web. El mundo digital tiene que conectarse con el mundo
real, por lo que debemos pensar en todos los aspectos de un servicio y asegurarnos de que
se sumen a algo que satisfaga las necesidades del usuario.

9. Sea consistente, no uniforme: debemos usar el mismo lenguaje y los mismos patrones de
diseño siempre que sea posible. Esto ayuda a las personas a familiarizarse con nuestros
servicios, pero cuando esto no sea posible, debemos asegurarnos de que nuestro enfoque
sea coherente. Esto no es una camisa de fuerza o un libro de reglas. Cada circunstancia es
diferente. Cuando encontremos patrones que funcionen, deberíamos compartirlos y
hablar sobre por qué los usamos. Pero eso no debería impedirnos mejorarlos o cambiarlos
en el futuro cuando encontremos mejores formas de hacer las cosas o las necesidades de
los usuarios cambien.

10. Haga que las cosas se abran: mejora las cosas: debemos compartir lo que estamos
haciendo siempre que podamos. Con colegas, con usuarios, con el mundo. Comparta
código, comparta diseños, comparta ideas, comparta intenciones, comparta fallas. Cuantos
más ojos hay en un servicio, mejor se pone: se ven aulladores, se señalan mejores
alternativas y se eleva la barra. Gran parte de lo que estamos haciendo solo es posible
debido al código fuente abierto y la generosidad de la comunidad de diseño web.
Deberíamos devolver eso.

Source: GOV.UK, Government Digital Service Design Principles, https://www.gov.uk/design-principles.

Anexo 6: Capturas de pantalla de GOV.UK Beta
Source: GDS, GOV.UK in less than a minute, https://www.youtube.com/watch?v=kvVaUBEibXo&feature=youtu.be .