Plan de servicios

Antes de comenzar a rediseñar un servicio, es importante comprender los problemas a resolver. Esto supone detectar, entender y analizar:

• Los usuarios del servicio y sus objetivos.
• Las limitaciones a la hora de hacer cambios en el servicio, por ejemplo, debido a la tecnología o la legislación.
• La principal razón que motiva el rediseño del servicio.
• Oportunidades de mejora en colaboración con otros equipos e incluso posibles sinergias.

Esta fase del proyecto es la que en la metodología SDA se denomina Descubrimiento.

Los hallazgos de esta fase de descubrimiento, determinarán cómo enfocar la fase alfa y las acciones a realizar durante la misma. En esta fase, como su propio nombre indica, se descubre cómo es el servicio actual para detectar las principales áreas de mejora sobre las que construir el nuevo servicio. Es importante tener en mente que esta fase es de definición, la ideación del nuevo servicio tendrá lugar más adelante, en la fase Alfa.

Cuánto dura la fase de descubrimiento

Aunque tenemos una metodología de trabajo muy clara en la que se definen una serie de pautas que puedan aplicarse a los diferentes servicios, cada uno de estos puede presentar particularidades que supongan abordarlos de manera diferente al resto. Por esta razón, aunque la duración de la fase de descubrimiento sea entre 4 y 8 semanas, es necesario adaptarse al tipo de descubrimientos que se hacen en esta fase.

Por ejemplo, si se trabaja en una serie de descubrimientos que no se han investigado antes, quizá sea necesario invertir más tiempo. Por el contrario, si se tiene un conocimiento previo o ya hay antecedentes de investigación que van en la misma dirección que lo que se está trabajando, puede que esta fase sea más corta.

Define el objetivo a cumplir en la fase de descubrimiento

Antes de comenzar con esta fase, resulta muy útil definir qué objetivo se pretende conseguir con esta fase. Esto ayudará a enfocar esta fase de una manera adecuada y adaptada al servicio concreto que se va a rediseñar.

Define el problema

Es común, al comienzo de esta fase, encontrar que las personas involucradas en el mismo ya están trabajando en una solución (provisional o definitiva, desde su punto de vista), de acuerdo a los puntos de mejora que ellos han detectado. También puede ocurrir que la posible solución no venga de personas involucradas en el servicio, sino que sea algo estándar y predefinido que se pretende aplicar a todos los servicios.

En ambos casos, estas soluciones propuestas deben cuestionarse y considerarse como problemas a resolver. Esto ayudará a todo el equipo a alinearse en los objetivos a lograr.

Para definir el problema, es importante descomponer las diferentes hipótesis (incluso cuando los usuarios te las presentan como certezas), hacer muchas preguntas y poner límites al problema, es decir, replantear lo que forma parte del problema y lo que no.

Cuanto mejor definidos estén los problemas, mejores serán las soluciones que se propongan en las fases posteriores. Asimismo, a la hora de considerar los diferentes problemas, es necesario comprender las repercusiones que tienen actualmente y el valor que aporta resolverlos.

Qué descubrir en esta fase

En esta fase, existen varios puntos en los que hay que centrarse para poder detectar oportunidades de mejora en el desarrollo del servicio.

Entender a los usuarios y su contexto

Empieza por aprender de los usuarios y su contexto, lo que intentan conseguir y qué hacen para ello. Es posible que, en estos casos, encuentres que el proceso al que se enfrenta el usuario forma parte de un proceso más grande. Es más, en SDA tratamos de enfocar los diferentes servicios de manera global, no contemplando solamente las acciones del usuario final o el servicio de manera aislada, sino el proceso de inicio a fin, teniendo en cuenta las acciones de todos los actores implicados y los otros servicios con los que pueda existir alguna relación. Por esta razón, dentro de la metodología SDA se decide que la manera óptima de representar el servicio en esta fase es a través de un mapa de experiencia, que permite recoger las acciones de los usuarios, sus puntos de contacto, las acciones de la Administración, procesos de soporte, herramientas o regulaciones, problemas y necesidades detectadas, ideas y oportunidades y los hallazgos correspondientes.

Si bien es importante diseñar servicios accesibles y que existan políticas de accesibilidad definidas para todo el proyecto, algunos de los servicios pueden ser más susceptibles de requerir una mayor atención en este aspecto, no solo por las capacidades de las personas usuarias del servicio sino por otros factores como pueden ser el entorno en el que se desarrolla el servicio, el dispositivo que se tiene que utilizar, el acceso a internet, las capacidades digitales…

Comprender las restricciones

Antes de empezar a proponer soluciones ideales, es importante conocer y comprender las limitaciones o restricciones que afectan al proceso, como pueden ser:

• Legislación
• Contratos
• Tecnología heredada
• Procesos y sistemas existentes

Por supuesto, esto no implica dejar de lado la creatividad o proponer soluciones que quizá no sean factibles a corto plazo, pero sí a medio – largo plazo. Para ello, se determina cuáles de estas restricciones son menos flexibles y cuáles pueden cambiarse fácilmente. Por ejemplo, en el proyecto de rediseño de servicios de SDA la legislación española es un factor que resulta bastante complejo de modificar desde el Gobierno de Aragón. Sin embargo, si un servicio se colapsa en una determinada fase porque hay mucho volumen de trabajo, no hay que limitarse a proponer que se contrate más personal, sino que hay que ofrecer la solución que mejor funcione para todos los usuarios, como podría ser: cambiar la metodología de trabajo en esta fase concreta del proceso.

Entender estas restricciones resulta útil para poder priorizar, en la fase alfa, las soluciones en función de lo limitadas que estén en este sentido. También se puede realizar un estudio de casos similares para analizar cómo estas se enfrentan a estas limitaciones.
Identificar las mejoras que se pueden implementar.

Una de las principales ventajas de esta fase es detectar mejoras que se vayan poder llevar a cabo en fases posteriores del proceso. Por ejemplo, si en esta fase de descubrimiento se identifica que a los usuarios se les está solicitando cierta información que el gobierno ya está pidiendo en otro trámite, quizá en la fase alfa se puede tratar de evaluar las dificultades técnicas y legales de obtener esta información sin tener que solicitarla a los usuarios.

Compartir lo aprendido

Resulta esencial compartir los conocimientos que se van adquiriendo a lo largo del proceso, tanto interna como externamente, siempre respetando la confidencialidad de la información tratada y las personas involucradas.

Esto ayuda a las personas de dentro y fuera de la organización a saber lo que se está haciendo y facilita la colaboración con las otras organizaciones que trabajan en el mismo servicio.

Por este motivo, nace la web de SDA, en la que se puede consultar a lo largo de todo el proyecto, los nuevos servicios y herramientas a las que nos enfrentamos y cómo acometemos los retos de este proyecto. También vamos a ir publicando información sobre algunas de las principales herramientas de trabajo que utilizamos en el día a día de nuestro trabajo.

Cómo saber que la fase de descubrimiento ha terminado

Existen varios factores que ayudan a detectar si es el momento de avanzar a la fase Alfa. Algunos de los indicadores que definen que es buen momento para pasar a la siguiente fase son:

• Se puede construir un servicio viable que ayudaría a los usuarios a hacer las cosas que tienen que hacer de una manera mucho más sencilla.
• Es rentable dedicarse a solucionar o mejorar ese problema. Esto significa hacer una comparación entre lo que costaría y si realmente supone una mejora importante.

Si la investigación demuestra que parar en este momento el servicio es lo mejor que se puede hacer, no es una derrota. De hecho, se ahorrará tiempo y dinero que será mejor invertir en otra cosa.

Si se decide pasar a la fase alfa, será necesario asegurarse de que:

• Se comprenden a la perfección todo el contexto y los otros servicios, equipos y organizaciones que están trabajando en problemas similares.
• Se está trabajando en algo que encaja en el contexto del problema.
• Se tiene una lista de ideas que se quieren testear en la fase alfa y una idea de por cuál sería conveniente empezar.
• Se sabe a ciencia cierta a quién se necesita en el equipo para la fase alfa.
• Se sabe cómo se va a medir si ha sido exitoso.
   

La fase alfa es el momento para generar y probar diferentes propuestas y soluciones a los problemas encontrados durante la fase de descubrimiento y definir cómo debería ser la experiencia futura del servicio.

Desarrollamos grupos focales de ideación, donde se pone en común lo descubierto en la fase anterior y se trabaja conjuntamente en dinámicas creativas con los distintos actores implicados en el servicio. Asimismo, esta fase sirve para construir prototipos e ir testeando diferentes ideas a ver cual funciona mejor. No hay que tener miedo a cuestionar cómo se hacen las cosas por el momento. Precisamente alfa es la fase para explorar nuevas propuestas.

No es necesario crear un prototipo de la experiencia completa, muchas veces tiene sentido prototipar únicamente las áreas que suponen un mayor reto. De esta manera puedes testear los mayores riesgos que asumes, invirtiendo la mínima cantidad posible de esfuerzos y recursos.
Los objetivos concretos de esta fase son:

• Ofrecer servicios digitales accesibles y usables, adaptados a las necesidades de la ciudadanía.
• Simplificar, normalizar y homogeneizar los servicios de tramitación desde el punto de vista del personal de la administración pública.
• Agilizar la definición de nuevas herramientas digitales a través del trabajo conjunto entre departamentos.
• Facilitar la consulta de información por parte de los usuarios, así como fomentar la voz activa de los propios ciudadanos dentro de los servicios diseñados.

Normalmente, la fase alfa dura entre 6 y 8 semanas. Para el final de esta fase, se debería estar en una posición de converger y decidir cuáles de las ideas que se han testeado merece la pena llevarlas a la fase beta.

Centrarse en testear los riesgos que se están asumiendo

Identificar cuales son los riesgos que se están asumiendo y testearlos es una parte esencial. Estos riesgos dependen del servicio en concreto sobre el que se esté trabajando.

Por ejemplo, si estamos intentando resolver un problema de realización de un trámite en el que están involucrados ciertos perfiles de usuarios de avanzada edad o que residen en zonas rurales y se cree que un sistema de tramitación online podría resolver el problema; será necesario investigar si realmente estos usuarios tienen buena predisposición a utilizar esta herramienta online, si tienen conexión a internet y dispositivo para conectarse... entre otras cosas. Porque quizá sea necesario plantear una manera alternativa de realizar el trámite que no suponga la utilización de una herramienta online.

De igual manera, si alguna de las posibles mejoras que se han planteado se basa en encontrar solución a una restricción legal, puede que se quiera dedicar parte de esta fase a investigar cómo de factible resulta.

Cumpliendo los principios de diseño en esta fase

Hay ciertos puntos en los estándares sobre los que será necesario prestar especial atención en la fase alfa.

Resolviendo un problema completo para los usuarios

El segundo principio de diseño de servicios de SDA dice "Diseña servicios de inicio a fin, no procedimientos". En esta fase, este principio supone hacer evidente para los usuarios que:

• Sabemos que el propósito que se plantea para cada proceso es el correcto.
• Hemos tenido en cuenta todo el mapa de experiencia completo del servicio.
• Conocemos lo que tendría que ocurrir para hacer el servicio de la mejor manera posible para los usuarios (ser capaz de hablar de todos los aspectos, incluso otros servicios, que pueden confluir en un servicio concreto y las oportunidades y retos de este).
• Trabajamos en abierto, creando relaciones e involucrando a todos los equipos responsables de cualquier aspecto que influya en el mapa de experiencia (siempre y cuando tenga sentido hacerlo).
• Conocemos y entendemos cualquier restricción de la ley, acuerdo o tecnología que impacta en el servicio.
• Tratamos de reducir el numero de veces que el usuario tiene que presentar la misma información al gobierno.

Tener el propósito correcto durante toda la experiencia del usuario

Tener claro el propósito en cada una de las acciones que realiza el usuario, es probablemente una de las partes más importantes a la hora de hacerlo sencillo de usar. Utiliza esta fase para explorar cuál es el propósito que tendría sentido desde el punto de vista del usuario.

Esto significa decidir qué hace exactamente cada acción y qué no, además del problema que cada una resuelve a los usuarios. Si se pretende que cada acción abarque demasiado y haga muchas cosas, el problema que está resolviendo no será obvio para los usuarios y no serán capaces de ir directos a la tarea que tienen que completar.

Conocer el proceso completo del usuario

No todas los servicios forman parte de un proceso más grande que realiza el usuario. Pero, en el caso de que lo sea, se debe explorar ese proceso completo como parte del descubrimiento.

Se puede hacer un mapa de experiencia mostrando todo el proceso completo que realiza el usuario e indicar en qué momento entra en juego el servicio, las diferentes organizaciones involucradas y los diferentes canales que tienen los usuarios para acceder a ellos.

Lidiar con restricciones

Usa esta fase para explorar si hay alguna restricción inamovible de la ley, acuerdos o tecnología heredada que afecte al servicio. De cara al final de esta fase, se debería ser capaz de explicar:

• Cómo se va a crear un servicio que cumpla las necesidades y expectativas de los usuarios a la vez que con las restricciones.
• Si hay limitaciones que pueden ser superadas o eliminadas, por ejemplo, con el cambio de la plataforma tecnológica , se debe planear hacerlo.

Trabajar en abierto

Siguiendo nuestro principio de diseño de servicios "Sé transparente, comparte y comunica", se debe informar del trabajo, del avance realizado en los prototipos y de las cosas que se ha aprendido de ellos, a todas las partes involucradas en el servicio, además de mostrar a cualquier persona a la que le pueda interesar la metodología y el proceso.

Reutilización de la información de los usuarios cuando sea posible

Esto va de la mano de otro de los principios mencionados, "Dotar al ciudadano de una identidad digital 360º.

Esta fase es buen momento para reflexionar si se puede reutilizar información que el usuario ya haya apotado anteriormente al gobierno y en qué momento hacerlo. Será necesario tener claro cómo se va a compartir este tipo de información.

Asegurarse de que todo el mundo pueda utilizar el servicio

Con un prototipo no se puede aplicar el rango entero de tests de accesibilidad que se utilizaría cuando el servicio ya se encuentra en producción. Pero aún así, en esta fase, se deb​​​​​​eria poder demostrar que:

• Se entienden los principios de accesibilidad. Esto ayudará a identificar y testear algun reto de accesibilidad concreto que se quiera afrontar con el servicio.
• Las personas con capacidades diferentes están incluidas en la investigación.

En esta fase no se tiene obligación de hacer una auditoría de accesibilidad, pero merece la pena tenerlo en cuenta porque puede ser un proceso largo el adoptar estos principios de accesibilidad. Si en este momento se concierta una auditoría, se pueden revisar los diseños o prototipos y detectar problemas potenciales de accesibilidad, teniendo así tiempo de sobra para solventarlos.

De todas formas, para el final de esta fase se debería tener un plan de las acciones a realizar, en cuanto a accesibilidad, en la fase beta.

Cómo sabemos cuando pasar a la siguente fase

La fase alfa termina cuando se tiene un prototipo que muestra, de manera tangible, los hallazgos de la fase de descubrimiento y se considera suficiente para poder pasar a la siguiente fase. Esto supone estar seguro de que:​​​​

• Se puede crear un servicio que satisfaga las necesidades de los usuarios y la relación esfuerzo-eficiencia sea buena.
• Se tiene el presupuesto y la gente necesaria para llevarlo a cabo.

A partir de los datos clave extraídos de la fase de investigación, se tiene que ser capaz de explicar los motivos de las decisiones que se han tomado.

Otros aspectos importantes a considerar en la fase alfa

Algunos puntos que se deben tener en consideración en esta fase son:

• Cómo se indentificarán posibles amenazas al servicio, como se afrontarán y cómo se mantendrá actualizado el servicio con las amenazas.
• Cómo será código abierto y que canal se utilizará para la distribución de los métodos y procesos.
• Cómo se verán afectados los usuarios si la parte online del servicio falla o tiene algún tipo de problema técnico.
• Continuar refinando las métricas que se utilizarán para medir el éxito del servicio.

En esta fase, se selecciona la mejor idea de la fase alfa y se comienza a hacerla realidad. También incluye pensar cómo el servicio que se está trabajando se integrará con el resto de servicios existentes.

La fase beta se estructura de manera que se pueda dar a conocer el servicio a usuarios reales al mismo tiempo que se minimizan los riesgos y se maximizan el potencial de aprender e iterar en el servicio.

En qué centrarse durante la fase beta

Hasta ahora se habrá ido desarrollando un profundo conocimiento de las necesidades y requerimientos de los usuarios, y, al final de la fase alfa, se habrá elegido la manera de satisfacer esas necesidades.

Durante la fase beta, es importante poner el foco en que todas las soluciones elegidas funcionan de la mejor manera posible, llevando a cabo investigación de usuarios y recogiendo datos de las métricas identificadas en la fase anterior para evaluar el éxito del servicio. Se itera en base a lo que se ha ido aprendiendo de esta investigación.

Cumpliendo los principios de diseño en beta

Cada principio puede tener un sentido diferente en cada fase. Los principios mencionados en la fase anterior, implican cosas un poco diferentes en esta fase.

Resolviendo un problema completo para los usuarios

El segundo principio de diseño dice "diseña servicios de inicio a fin, no procedimientos".

Tener el propósito correcto durante toda la experiencia del usuario

En esta fase, se utilizan los comentarios de los tests con usuarios para refinar ese propósito y proponer mejoras.​

Conocer el proceso completo del usuario

En esta fase, será necesario mostrar cómo el servicio que se ha creado se integra con el proceso completo que realiza el usuario.

Lidiar con restricciones

En la fase alfa, se identifican las limitaciones que pudieran afectar al servicio, por lo que, en la fase beta, se debería poder explicar cómo la organización en conjunto está progresando adecuadamente abordando estas limitaciones.

Trabajar en abierto

Es necesario seguir trabajando en abierto en esta fase. Si lo que se está construyendo forma parte de un proceso mucho más amplio que abarca otros servicios de la organización, es de especial importancia mantener informado de los planes y la evolución del proyecto.

Reutilización de la información de los usuarios cuando sea posible

Si se está construyendo un servicio que pueda reutilizar información que los usuarios ya han proporcionado en otro proceso al gobierno, se le tiene que solicitar permiso al usuario para solicitar dicha información o indicarle que esta está siendo compartida de manera segura y estable.

También es necesario saber que cualquier información que se comparta, se hace de manera que protege la privacidad del usuario.

Proporcionar una experiencia conjunta entre diferentes canales

Se debe trabajar de cara a proporcionar un servicio que funcione bien entre los diferentes canales que puede utilizar un usuario para acceder a un servicio.

Habrá que mostrar que se avanza en mejorar la experiencia del usuario en diferentes canales. Por ejemplo, testeando e iterando los contenidos del correo postal para usuarios o mejorando la manera en que los trabajadores de los puntos de ayuda tratan con los usuarios online.

Asimismo, es necesario tener en cuenta que en el proceso organizativo para resolver problemas que aparecen en un canal, necesitan también ser arreglados en otro haciendo cambios.

Asegurarse de que todo el mundo pueda utilizar el servicio

En la valoración de la fase beta, se tendrá que mostrar cómo se han desarrollado los tests de accesibilidad en el servicio y las sesiones de investigación con personas con capacidades diferentes.

Será necesario hablar también de los resultados de la auditoría de accesibilidad y arreglar cualquier cosa antes de hacer público el servicio.

Se tendrá que mostrar que se ha considerado y valorado que el servicio no tenga ningún punto conflictivo que pueda dejar fuera a determinadas tipologías de usuarios y cuáles son los pasos desarrollados para integrarlos.

Otros aspectos importantes a considerar en la fase beta

Algunos puntos que se deben tener en consideración en esta fase son:

• ¿Cómo se ha hecho el servicio seguro para que los datos de los usuarios estén a salvo?
• ¿Cómo se ha trabajado con cookies y tecnologías similares?
• ¿Cómo se ha hecho el código fuente abierto?
• ¿Cómo se está gestionando el límite de espacio de la tecnología seleccionada para el servicio?
• ¿Qué pasaría si el servicio estuviera deshabilitado durante un periodo de tiempo y cómo se está gestionando este supuesto?
• ¿Cómo se está testeando la tecnología?

Esta fase se basa en dar soporte al servicio de una manera sostenible, iterando y mejorando continuamente, además de:

• Continuar abordando cualquier limitación que se haya identificado en la fase beta.
• Seguir desarrollando el servicio y trabajando con otras organizaciones proporcionando otros servicios que forman parte del mismo proceso para el usuario. De esta manera, se itera tratando de resolver el problema completo para los usuarios.
• Poder dar la transición o integración de cualquier operación existente que satisfaga una necesidad similar a la del servicio desarrollado. Es necesario asegurarse de que el resultado final tiene sentido para los usuarios.

Desarrollo del servicio

Es necesario resolver cómo hacer funcionar el servicio de manera sostenible durante su vida. Durante la beta se invierte tiempo resolviendo qué nivel de mejora continua tiene sentido para el mantenimiento y a quién se necesita en ese equipo.

Al igual que en la beta, las mejoras que se realicen una vez el servicio se haya lanzado deberían ser:

• Basadas en la investigación sobre el usuario.
• Tests para asegurar que funciona con diferentes navegadores y dispositivos.
• Test de accesibilidad.
• Calidad asegurada.
• Basadas en análisis de datos y métricas definidas en fases previas para medir el éxito del proyecto.

Debemos asegurarnos de ser claros a la hora de transmitir los efectos que un cambio en el trámite online puede suponer a la hora de hacerlo de manera presencial, así como asegurarse también de que ninguno de los cambios va a tener impacto negativo en ninguna de las dos modalidades.

Cumpliendo los principios de diseño en la fase de servicio

Antes del lanzamiento final del servicio, se deberá mostrar que se ha utilizado la fase beta para construir un servicio que cumpla con las necesidades identificadas en la fase de descubrimiento y alfa: testeando e iterando continuamente sobre lo aprendido.

Resolviendo un problema completo para los usuarios

Una vez el servicio se lance, será necesario continuar desarrollándolo de manera que forme una parte intuitiva del proceso completo de los usuarios.

Esto significa seguir trabajando con los equipos responsables de los servicios relacionados y continuar abordando cualquier restricción que afecte la manera en la que se puede seguir iterando en el servicio.

Durante la publicación del servicio, se comienza creando una hoja de ruta conjunta para el trabajo. Cada elemento de esta hoja de ruta debe ser ambicioso al nivel de cosas como:

• Continuar asegurándose de que las operaciones son observadas de una manera que tengan sentido para los usuarios.
• Continuar abordando cualquier restricción identificada en la fase beta.

Proporcionar una experiencia omnicanal consistente

Antes del lanzamiento, se debe asegurar que la gente que da soporte a los usuarios comprende la parte del servicio online.

Esto puede implicar acciones como actualizar los guiones de los puntos de ayuda, proporcionando formación o encontrando una manera de que el personal se familiarice con el servicio. De esta forma, aseguramos que los usuarios que acceden al servicio tienen una experiencia consistente independientemente del canal que utilicen.

Otros aspectos a considerar antes del lanzamiento del servicio

Debemos asegurarnos de que:

• Se está asegurando la información del servicio.
• Se tienen métricas apropiadas listas para medir el éxito del servicio, basado en lo que se ha aprendido durante la fase beta.
• Se cumplen los requisitos de accesibilidad
• Se mantiene el tiempo de funcionamiento y disponibilidad y se puede monitorizar el estado del servicio.
• Se continúan los tests de vulnerabilidad y entrada.
• Se continúan los tests del desempeño del servicio.
• Ser capaces de mantener la garantía de calidad.
• Ser capaces de abordar, o tener planeado hacerlo, cualquier punto de dolor que pueda dar lugar a personas que decidan no utilizar el servicio.

¿Cuándo es necesario retirar el servicio?

El servicio deberá retirarse cuando el usuario no lo necesite más. Para ello, se realizan revisiones periódicas en las cuales, además de realizar una mejora continua del servicio, se hace un análisis del uso que se le da y, en función de estos hallazgos se toman las decisiones oportunas.