Repository for versions of GDS Standards and guidance translated and/ or internationalised
View the Project on GitHub alphagov/gdmp-translated-standards
Procure entender bien a sus usuarios y el problema que está intentando resolver por ellos.
Considere todo el contexto para entender qué intentan lograr los usuarios y no solo la parte donde tienen que interactuar con el gobierno.
Entender todo el contexto posible le permite satisfacer mejor las necesidades de los usuarios de una manera sencilla y rentable.
Enfocarse en el usuario y el problema que están intentando resolver a menudo significa que descubra aspectos inesperados sobre sus necesidades. You will miss this important information if you only focus on a certain solution.
El problema real quizás no sea el primero que se presentó para resolver. Probar sus ideas desde el principio y con frecuencia reduce el riesgo de continuar avanzando sobre algo equivocado.
Lo que los equipos de servicio deben hacer para comprender tanto como puedan sobre el problema que los usuarios necesitan resolver:
Trabajar para crear un servicio que resuelva un problema específico para el usuario. . Debe colaborar con los demás departamentos del gobierno si es necesario.
Es difícil usar servicios fragmentados porque los usuarios tienen que esforzarse mucho para asegurarse de que estén bien encaminados. Por ejemplo, si están eligiendo el formulario correcto para completar, entre varias opciones muy similares.
Eso no significa desarrollar interacciones amplias y complicadas que no sean intuitivas para usar porque tratan de abarcar demasiado. Tampoco significa intentar arreglar todo de una sola vez.
Comience con algo pequeño y ofrezca valor a los usuarios mediante cambios menores que se proponen con frecuencia.
Simplemente asegúrese de que los cambios sean parte de un plan para agrupar el contenido y las transacciones que se relacionan en un proceso que tenga sentido para los usuarios, independientemente de la organización a la que “pertenecen”. Los usuarios no deberían tener que entender cómo funciona el gobierno para poder usar los servicios públicos.
Los equipos de servicio deben hacer lo siguiente:
Considerar alternativas para crear un servicio, por ejemplo, publicar contenido para un sitio web, llevar adelante una campaña, asociarse con una organización no gubernamental o poner datos o una API a disposición de terceros
Entender las limitaciones genuinas que afectan el servicio (por ejemplo, las leyes) y trabajar con los colegas encargados de las políticas para resolver los problemas que están causando esas restricciones
Asegurarse de que los servicios estén scoped according to how users think, que no sea un servicio muy amplio o muy limitado
Ser capaces de explicar cómo la transacción en la que están trabajando se asociará con otros elementos en un proceso que resuelva un problema completo para los usuarios (estudio de caso): come to the UK to study)
Asumir la responsabilidad de acordar cómo será este proceso del usuario con las organizaciones responsables de las diferentes secciones
Hacer que todas las tareas sean de conocimiento público para que las personas fuera de la organización sepan qué están haciendo, aumentando la posibilidad de colaboración y reduciendo el esfuerzo doble (por ejemplo, publicando casos comerciales, declaraciones de la misión, hallazgos de investigaciones, mapas de experiencia del usuario, mapas de los servicios actuales y la roadmaps de los productos que muestren los planes para desarrollar nuevas características)
Trabajar para reducir la cantidad de veces que los usuarios deben brindar la misma información al gobierno (mientras se respeta la privacidad de los usuarios)
work across organisational lines, si es necesario, para resolver un problema completo para los usuarios
Trabaje para crear un servicio que satisfaga las necesidades de los usuarios en todos los canales, es decir, en línea, por teléfono, en papel y en persona.
La integración de los diferentes canales significa que pueden diseñar una experiencia que tenga sentido para el usuario, sin importar cómo usen el servicio. Los usuarios no deben ser excluidos ni tener una experiencia poco satisfactoria porque no tienen acceso a la tecnología o las habilidades para usarla.
Las personas que trabajan en el servicio están autorizados a solucionar los problemas en cualquier canal que los usuarios decidan usar. Pueden pasar menos tiempo atendiendo las “demandas fallidas” * y más tiempo con los usuarios que necesitan su ayuda.
La “demanda fallida” se define como la demanda causada por no poder hacer algo o no poder hacer algo bien para ayudar al usuario. Esto se debe evitar, ya que implica que los usuarios regresen para presentar más demandas, consumiendo innecesariamente así los recursos de la organización porque el servicio que reciben es ineficaz.
Los equipos de servicio deben poder demostrar lo siguiente:
El equipo de servicio tiene la capacidad para encontrar la mejor manera de resolver el problema.
El personal de atención al público y las personas encargadas de las políticas están invitados a asistir a la investigación del usuario y contribuir con las decisiones de priorización.
Los diseñadores y los investigadores del usuario trabajan con el personal de atención al público.
Están haciendo pruebas y pueden hacer cambios en la experiencia del usuario tanto en los canales en línea como fuera de línea (por ejemplo, cartas y guiones para el centro de llamadas).
Los datos y la investigación del usuario en la parte en línea del servicio se usan para mejorar los canales fuera de línea, and the other way around.
El personal de atención al público responsable de responder las preguntas de los usuarios sabe cómo funciona el servicio en línea y existe un proceso para mantenerlos actualizados sobre los cambios.
Trabajan con colegas en las operaciones para entender cómo los cambios en la parte en línea del servicio afectarán los canales fuera de línea y también cómo esos canales fuera de línea afectan la parte en línea del servicio.
plans to increase digital take up no implican que sea más difícil encontrar los detalles de los canales por teléfono, en papel o en persona.
Los equipos de servicio deben poder identificar los problemas con los procesos, los sistemas o las estructuras internos que dificultan más de lo necesario que se diseñe y opere un servicio vinculado.
Además, deben demostrar que existe un plan para solucionarlos. Por ejemplo, deben contar con un procedimiento acordado para resolver los problemas con el servicio en línea que están causando problemas en los canales fuera de línea, o viceversa.
Cree un servicio que sea simple, natural y fácil de entender para el usuario. Pruébelo con los usuarios para asegurarse de que les resulte útil.
Las personas esperan que los servicios funcionen, y lo mismo se aplica a los servicios gubernamentales. Al gobierno le cuesta tiempo y dinero lidiar con los errores que se producen cuando los servicios no funcionan bien. Además, hacer que el proceso sea más complicado de lo que tendría que ser menoscaba la confianza en el gobierno.
Los equipos de servicio deben hacer lo siguiente:
Asegurarse de que el servicio helps the user to do the thing they need to do as simply as possible, para que pueda resolver su problema en el primer intento, con la ayuda mínima
Probar frecuentemente la facilidad de uso con usuarios actuales y con potenciales usuarios, utilizando research techniques
Probar todas las partes del servicio con las que el usuario interactúa, por ejemplo, las partes en línea y las partes fuera de línea (como las cartas)
Diseñar el servicio para que funcione en línea with a range of devices that reflects users’ behaviour
Los servicios también deben brindarles a los usuarios una experiencia uniforme de principio a fin.
Brinde un servicio que todos puedan usar, incluidas las personas con discapacidad y las personas que no tienen acceso a internet ni las habilidades (o la confianza) para usarlo. Esto garantiza que los servicios sean eficientes y sea más fácil administrarlos.
Los servicios gubernamentales deberían estar al alcance para todos los que necesiten usarlos. Las organizaciones del sector público tienen el deber de considerar las necesidades de todos cuando están diseñando y ofreciendo sus servicios.
Los servicios inclusivos y accesibles son mejores para todos. Por ejemplo, usar palabras sencillas ayuda a las personas que tiene prisa y a las que tienen una discapacidad de aprendizaje.
Los equipos de servicio deben hacer lo siguiente:
Cumplir con los accessibility standards, incluidas las partes en línea y fuera de línea
Evitar excluding any groups within the audience they’re intended to serve
Llevar a cabo investigaciones con los participantes que represent the potential audience for the service, incluidas las personas con discapacidad
Asegúrese de que las personas no queden excluidas de usar el servicio porque carecen de habilidades digitales o acceso a internet, y brinde el assisted digital support adecuado para cubrir cualquier deficiencia
Organice un equipo multidisciplinario que pueda crear y operar el servicio de una manera sustentable.
Necesitará un equipo formado por personas con una combinación diversa de habilidades y conocimiento.
Es importante que las personas que participan en la toma de decisiones sean parte del equipo para que puedan asumir la responsabilidad, y todo el equipo pueda responder rápido a lo que descubren sobre los usuarios y sus necesidades.
Los servicios deben tener las siguientes características:
Deben estar formados por un multidisciplinary team que sea apropiado para lo que necesitan lograr durante la fase relevante del desarrollo del servicio y se encuentre en las mismas instalaciones lo más alejados posible.
Deben incluir personas en el equipo con experiencia en cómo se ofrecen los servicios en todos los canales fuera de línea y los sistemas administración relevantes con los que el servicio necesitará integrarse.
Deben brindar al equipo acceso al conocimiento especialista que necesita (por ejemplo, análisis legal, de políticas o específico de la industria, desde dentro o fuera de la organización).
Si el equipo está working with contractors and outside suppliers, deben asegurarse de que sea de una manera sustentable.
Es probable que su equipo se forme según lo que debe ofrecer en cada parte del desarrollo del servicio. Por eso al principio quizás necesite más ayuda de los investigadores del usuario, los diseñadores del servicio, más desarrolladores y personas con habilidades técnicas cuando comienza a estructurar el servicio.
Sin embargo, comience desde la suposición de que necesitará una amplia variedad de funciones. Un equipo con diferentes perspectivas tiene más probabilidades de pensar la mejor solución.
Crea el servicio usando métodos ágiles e interactivos, centrados en el usuario.
Usar los métodos ágiles significa que llevará el servicio a los usuarios reales lo antes posible. Luego, observe y genere datos sobre cómo lo usan, y repita el servicio según lo que ha descubierto.
Como no está especificando todo desde el comienzo antes de que haya entendido lo que los usuarios necesitan, los métodos ágiles reducen el riesgo de ofrecer un servicio incorrecto.
Los equipos de servicio deben hacer lo siguiente:
Usar agile ways of working- inspeccionando, descubriendo y adaptando el servicio sobre la marcha
Tener acuerdos gubernamentales que sean coherentes con los agile governance principles y asegurarse de que las personas sepan lo que está sucediendo con el servicio, con el nivel de detalle adecuado (incluido, por ejemplo, el ministro o el director ejecutivo)
Si corresponde y es proporcional, pruebe el servicio con el ministro o la parte interesada senior que corresponda
Asegúrese de tener la capacidad, los recursos y la flexibilidad técnica para repetir y mejorar el servicio con frecuencia.
Trabaje con su organización para ver que pueda enfocarse en las mejoras que ofrecen el mayor valor.
Los servicios nunca están “acabados”. Usar los métodos ágiles significa tener personas que usen sus servicios lo más pronto posible. Luego, implemente mejoras durante la vigencia del servicio.
Hacer mejoras significa más que solo encargarse del mantenimiento como arreglar errores en los códigos, emplear parches de seguridad y mantener actualizados los guiones del centro de llamadas. Con esto, estará arreglando síntomas en lugar de problemas subyacentes y, con el tiempo, el servicio dejará de satisfacer las necesidades de los usuarios.
Las mejoras continuas significan que pueda responder a los cambios en las necesidades de los usuarios, la tecnología o la política gubernamental durante toda la vigencia del servicio. Entonces, en lugar de tener que reemplazarlo, el servicio sigue siendo relevante hasta que está listo para retirarlo.
La iteración no es solo para las primeras etapas en el desarrollo del servicio.
No es necesario que, para administrar un servicio en vivo, deba tener todo el equipo trabajando en el servicio el 100 % del tiempo durante la etapa de activación. Pero sí significa being able to make substantial improvements durante la vigencia del servicio.
Evalúe qué datos del servicio recolectará, almacenará y brindará.
Entienda cómo el gobierno clasifica los datos, las responsabilidades legales de la organización y los riesgos de seguridad asociados con el servicio. Consulte a los expertos si es necesario.
Los servicios gubernamentales suelen implicar el manejo de información personal y confidencial sobre los usuarios. El gobierno tiene el deber legal de proteger esta información. No cumplir con esto afectaría la confianza del público en los servicios gubernamentales.
Los equipos de servicio deben hacer lo siguiente:
Identificar activamente las amenazas de seguridad y privacidad al servicio, y contar con un enfoque sólido y proporcional para securing information y managing fraud risks
Contar con un plan y un presupuesto que les permita administrar la seguridad mientras el servicio está vigente (por ejemplo, respondiendo a nuevas amenazas, implementando controles y aplicando códigos de seguridad al software)
collect and process users’ personal information de una manera que sea segura y respete su privacidad
Usar un enfoque para la gestión y autenticación de la identidad que equilibre los riesgos de una manera proporcional (para los servicios que necesitan gestión o autenticación de la identidad)
Trabajar con los equipos de riesgo comercial y de información (por ejemplo, propietarios seniores de riesgos de información, propietarios de activos de información y custodias de datos) para garantizar que el servicio cumpla con los requisitos y las normas de seguridad sin afectar el funcionamiento del servicio
Determine qué significa obtener buenos resultados para su servicio e identifique medidas que le indiquen qué está funcionando y qué puede mejorarse, combinado con la investigación del usuario.
Recopile y use los datos de desempeño de todos los canales (en línea y fuera de línea).
Repita los servicios y mejore las medidas y las prácticas de recopilación de datos mientras vaya descubriendo más sobre las necesidades de los usuarios.
Definir qué entendemos por buenos resultados e identificar las medidas apropiadas significa que sabrá si el servicio está resolviendo el problema para el que está diseñado.
Recopilar los datos correctos de desempeño significa que estará al tanto de los posibles problemas con su servicio. Además, cuando se hace un cambio en el servicio, podrá decir si tuvo el efecto que se esperaba.
Publicar los datos de desempeño significa que está siendo transparente sobre el éxito de los servicios financiados con fondos públicos, y las personas pueden comparar los diferentes servicios gubernamentales.
Los equipos de servicio deben hacer lo siguiente:
Identificar las measurements which will indicate how well the service is solving the problem it’s meant to solve, y hacer un seguimiento a partir de estas
Usar los datos de desempeño para tomar decisiones sobre cómo solucionar los problemas y mejorar el servicio
Elija las herramientas y la tecnología que le permitan crear un servicio de buena calidad de una manera rentable. Minimice el costo de cambiar la dirección en el futuro.
Cuando toma una decisión sobre la tecnología, está haciendo una inversión importante. Las decisiones que tome tendrán un gran efecto en su capacidad de crear, iterar y dirigir el servicio de una manera sustentable.
Cuando se considera la arquitectura técnica, los lenguajes de programación, las herramientas de desarrollo y otras opciones de tecnología, los equipos de servicio deben hacer lo siguiente:
Usar tools and technologies apropiadas para crear y dirigir un buen servicio de una manera rentable (por ejemplo, automatizando algunos aspectos si es posible)
Poder demostrar que han tomado good decisions sobre qué tecnología crear y qué comprar
Entender el costo total de la propiedad de la tecnología y seguir pudiendo tomar diferentes decisiones en el futuro (por ejemplo, reducir las posibilidades de quedar atrapados en contratos para herramientas y proveedores específicos using open standards
Contar con un enfoque eficaz para managing any legacy technology con las que se integra el servicio o de las que depende
Haga que todos los códigos fuente nuevos sean abiertos y reutilizables, y publíquelos bajo las licencias apropiadas.
Si esto no es posible, ofrezca una explicación convincente de por qué no se puede realizar así para los subconjuntos específicos de los códigos fuente.
Los servicios públicos se crean con fondos públicos. Por lo tanto, a menos que haya una buena razón para no hacerlo, los códigos sobre los que se basan deberían estar disponibles para que se vuelvan a usar y se amplíen.
Los códigos fuente abiertos pueden ser reutilizados por los desarrolladores que trabajan en el gobierno para evitar el trabajo doble y reducir los costos en general para el gobierno. Además, publicar los códigos fuente bajo una licencia abierta reduce la posibilidad de tener que limitarse a trabajar con un solo proveedor.
Los equipos de servicio deben hacer lo siguiente:
Escribir códigos abiertos desde el principio y publicarlos en un repositorio abierto (salvo la información confidencial, como las claves y credenciales secretas)
Mantener la titularidad de la propiedad intelectual de los códigos fuente nuevos que se crean como parte del servicio y permitir su reutilización bajo una licencia abierta
Existen algunos casos when you should not publish code in the open; por ejemplo, el código que se relaciona con una política gubernamental confidencial que aún no se ha anunciado.
Amplíe los estándares abiertos y los componentes y patrones comunes desde dentro y fuera del gobierno.
Si desarrolla sus propios patrones o componentes, compártalos públicamente para que otros puedan usarlos.
Usar componentes y patrones comunes significa que no tiene que resolver los problemas que ya se han resuelto. Al usar un componente o un patrón común que ya se ha probado, puede brindarles a los usuarios una buena experiencia de una manera rentable. Si desarrolla sus propios componentes o patrones, compártalos para que otros puedan beneficiarse de su trabajo.
Los estándares abiertos ayudan a que los servicios funcionen de modo uniforme para que no deba perder tiempo intentando hacer que los sistemas “se entiendan” entre sí. Además, no tiene que limitarse a un proveedor o a una tecnología en particular, por lo que, cuando se producen cambios, puede cambiar su enfoque.
Los equipos de servicio deben hacer lo siguiente:
Usar open standards y proponer un nuevo estándar abierto si no hay ninguno aún que satisfaga sus necesidades
Usar los standard government technology components si es posible (por ejemplo, GOV.UK Common Components)
Maximizar la flexibilidad en el uso de la tecnología (por ejemplo, usando y creando application programming interfaces (APIs) y, si es posible, fuentes de datos confiables como los registers
Usar componentes y patrones comunes, y compartir los detalles de los componentes o patrones nuevos que creen o adapten
Cuando los servicios crean datos que podrían servirles a otros dentro o fuera del gobierno, deberían publicarlos en un machine readable format bajo una Open Government Licence
Esto no se aplica a los datos que contienen información de identificación personal, información confidencial (por ejemplo, debido a que podría afectar la seguridad nacional) o si la publicación de los datos infringiría los derechos de propiedad intelectual de alguien externo al gobierno.
Minimice el tiempo de inactividad del servicio y tenga un plan para tratar esto cuando ocurra.
Los usuarios esperan poder usar los servicios en línea las 24 horas, los 365 días el año.
Muchos usuarios tienen poca opción sobre cómo y cuándo acceden a los servicios gubernamentales. Por ejemplo, puede ser el caso de a carer who only has time to apply for benefits in the early hours of the morning. Si el servicio no está disponible o está lento, significa que esos usuarios no pueden obtener la ayuda que necesitan.
Los equipos de servicio deben hacer lo siguiente:
maximise uptime and speed of response for the online part of the service
Poder deploy software changes regularly, sin que esto afecte el funcionamiento del servicio (por ejemplo, minimizando el esfuerzo que implica crear nuevos entornos y llenar los entornos de preproducción con datos de prueba)
Llevar a cabo quality assurance testing regularmente
Probar el servicio en un entorno que sea lo más parecido al servicio activo como sea posible
Contar con appropriate monitoring in place, además de un plan proporcional y sustentable para responder a los problemas identificados en los controles (dado el impacto de los problemas sobre los usuarios y el gobierno)
Trabajar activamente para solucionar los problemas organizativos y contractuales que dificultan la posibilidad de maximizar la disponibilidad (por ejemplo, acordar un conjunto común de lenguajes, herramientas y maneras de trabajar para el personal técnico, ya sea informalmente o a través de algo más formal como the GDS way)