Diseño continuo en desarrollo: metodología y principio

En la práctica, sucede que usted desarrolló un producto y, después del lanzamiento, los clientes no lo usan según lo previsto. Luego resulta que las tareas del usuario son diferentes y van en contra del desarrollo del producto planificado y su visión del proyecto. Por qué

De hecho, está trabajando con una tarea de usuario que no se comprende completamente y que cambia bajo la influencia del producto. Esto sugiere que el producto necesita ser finalizado, además, emparejado con el cliente. Por lo tanto, se protege inmediatamente de la creación de soluciones innecesarias basadas solo en hipótesis.

Creo que es mejor construir comunicación con el usuario de acuerdo con el principio de diseño continuo, que se discutirá en el artículo.

Querido y dudoso caos informático

La mayoría de los productos y funciones suministrados por TI no encuentran aplicación práctica. Recursos, aplicaciones, software permanecen sin reclamar. No todas las empresas piensan si sus productos son realmente necesarios.

Una prueba vívida es el mercado de desarrollo móvil, que tiene indicadores medibles. Aunque las mejores prácticas se concentran aquí, las estadísticas dejan mucho que desear: en 2017, la compañía analítica Localytics publicó un estudio SQL , del que se deduce que el 24% de las aplicaciones se abren solo una vez por los usuarios.

Esto tiene en cuenta el hecho de que el porcentaje de usuarios que abrieron la aplicación menos de 10 veces no supera el 63% . Si tomamos en cuenta la "estabilidad" de las estadísticas, queda claro que no se sacan conclusiones. Las personas saben cómo desarrollarse, pero pierden el aspecto de cómo el producto entra en la vida de una persona, es decir, no utilizan el modelo centrado en el ser humano. Esto último implica interacción a largo plazo con el cliente; generalmente por varios años.

Esto nos lleva a la conclusión: en un enfoque centrado en el cliente, debe recurrir a prácticas de desarrollo existentes como DevOps, ágil o scrum, que generalmente se aplican por separado. Pero si los combinamos, obtenemos algo más llamado diseño continuo. Consiste en los principios clásicos de DevOps y el pensamiento de diseño. Proponemos considerarlo y adoptarlo, pero para implementar el principio en el desarrollo, debe reconsiderar la relación entre los dos componentes: diseño y operaciones.

Introductorio desde operaciones y diseño

Las operaciones son lo que está sucediendo ahora. Esto puede ser administración del sistema, soporte al usuario, procesos comerciales. Las operaciones se basan en diferentes modelos, por ejemplo, utilizando los DevOps mencionados. Proporciona un proceso continuo de retroalimentación, mejoras y entrega de soluciones. Se crea un "bucle" a partir de los comentarios, la planificación, la búsqueda de soluciones y su presentación. Y para cada una de las etapas hay herramientas que ayudan en el trabajo, automatizan los procesos y proporcionan un intercambio constante de información y soluciones.

El diseño es todo lo que está involucrado en la definición de acciones, métodos de construcción y formas de empacar un producto para el consumidor. Por lo general, abordamos el diseño como una solución a un problema. Si entendemos la esencia del problema, podemos ofrecer la solución correcta.

Este es un enfoque tradicional.

4 circunstancias que el enfoque tradicional no tiene en cuenta

Pero al combinar diseño y operaciones, salen a la luz 4 factores que anteriormente funcionaban por separado para los equipos. Y para estos aspectos, el diseño continuo se convierte en la solución:

# 1 El problema no se puede entender completamente.

Con la ayuda de análisis e investigación, formulamos la hipótesis de cómo las personas usarán el producto, pero dan una idea incompleta del problema, ya que no podemos cubrir todos sus aspectos. Solo cuando el producto cae en manos del consumidor, vemos cuán útil fue para el consumidor, qué tareas ayudó a resolver o qué cambió.

Un ejemplo simple: en los jeans hay un pequeño bolsillo para un reloj. Fue inventado por Levi Strauss en 1873. Desde entonces, nadie ha usado el bolsillo para su propósito previsto. La compañía incluso lanzó un video completo dedicado a esto.

# 2 El producto cambia al consumidor

La experiencia activa que interactúa con el producto cambia al usuario. Y esto transforma el problema que resuelve el producto, lo que crea nuevas dificultades para usted y el cliente.

Recuerde cómo pedimos un taxi hace 5 a 6 años: el operador del otro lado del cable aceptó el pedido y dijo que el auto sería atendido en 20-30 minutos. Y estábamos listos para esperar. Con el lanzamiento de servicios como Uber, Gett y Yandex.Taxi, nuestra percepción ha cambiado: en 2018, el tiempo óptimo para entregar un automóvil es de 2-3 minutos para nosotros. Si esperamos más, comienza a ponerse molesto. Y el punto no está en la digitalización o la uberización, sino en cambiar nuestro modelo de consumo.

# 3 El valor es algo creado juntos

El valor de un producto no se puede imaginar en el momento de su creación. Después del lanzamiento, el servicio comienza a vivir su propia vida y gana un nuevo valor, que se forma durante el uso. Algunas funciones tendrán demanda, mientras que otras no. Y el valor creado por usted y el consumidor madura. Por lo tanto, a menudo la utilidad no se ve hasta que se utiliza un bien o servicio.

Recordemos la AppStore, que parecía contraria a la percepción de valor de Apple. En 2007, Steve Jobs presentó al iPhone con las palabras: "No es necesario escribir programas. Es inútil: tienes html5 ". Esto no detuvo a los usuarios: piratearon dispositivos y escribieron su software, distribuido a través de la aplicación de software Cydia. Fue lanzado en marzo de 2008, y ya el 10 de junio de ese año, los chicos de Cupertino adoptaron la experiencia exitosa y lanzaron la AppStore, cambiando la situación a su favor y convirtiéndose en el jugador número 1 en el mercado móvil.

Esta tesis nos lleva a la conclusión de que el desarrollador y el consumidor son parte del problema y la solución.

# 4 La dificultad elimina el control

Estamos constantemente creando sistemas complejos que no se pueden controlar por completo. Y esto lleva a fallas y errores inevitables en ellos. Uno de los principales problemas al trabajar con tales sistemas es el intento de controlar en demasiados niveles, cuando se piensa cuidadosamente sobre lo que sucederá o puede suceder.

Estoy seguro de que todos llamamos al servicio de atención al cliente, donde fuimos redirigidos muchas veces a diferentes operadores. Y una y otra vez describimos el problema y esperamos una respuesta a la música de fondo de la compañía. Estos son casos en los que el servicio, los operadores, se considera con mucho cuidado. Los empleados tienen algoritmos de comunicación con el cliente que se corresponden y detallan constantemente. En lugar de servir al beneficio de los intereses del usuario, solo complican y confunden el sistema. Debido a la política de la compañía, un solo operador no puede resolver su problema, incluso si es simple. Simplemente tiene que redirigirte a otra persona.

Software de digitalización

Mira la evolución del iPod

Estos factores no contabilizados afectan no solo al mundo digital sino también al físico. Cada vez es más difícil adquirir experiencia que no incluye un componente de software intermedio. El entorno en el que vivimos está verificado por software, y esto cambia la percepción de las cosas y la forma en que las usamos.

Por ejemplo, Tesla ha lanzado una actualización de software que aumenta la duración de la batería del automóvil. Al mismo tiempo, se mejoran sus características físicas: ahora puede ir no solo al supermercado o al trabajo, sino también a la ciudad vecina. No ha cambiado la cantidad de viajes ni la duración del viaje, sino la calidad del automóvil y, con ellos, la comprensión de las tareas y los propósitos de su uso. Ahora no necesita gastar dinero en un taxi o poner otras restricciones, porque la batería dura 2 veces más. Una máquina cierra todas las tareas de su propietario.

Brand se aleja de la promesa al diálogo

Si todo se ha aclarado con las operaciones y el diseño, queda un concepto más amplio y abstracto de la marca. También trabaja en un montón de diseño continuo.

Solíamos tomar la marca como una promesa. Por ejemplo, estabilidad o inmutabilidad. Pero ahora su base está cambiando hacia el diálogo, porque vivimos en un paradigma de valores cambiantes. Y el diálogo con el usuario no debe ser unilateral, está vinculado a una comunicación constante, es exactamente el entorno en el que esto se hace más rápidamente. Después de todo, tenemos herramientas para proporcionar comentarios constantes a diferentes niveles: desde servicios analíticos externos hasta métodos DevOps.

TI se convierte en un entorno de diálogo continuo

Comenzamos a cambiar el producto sin parar gracias a los comentarios de los clientes, que observamos y cuyas acciones analizamos. Por lo tanto, el bucle DevOps se cierra al infinito cuando las operaciones, el desarrollo, el diseño y el marketing están involucrados en este proceso: seleccionamos una solución entre muchas, la implementamos y vemos cómo se comporta en la práctica. Es de esta forma que funciona el diseño continuo.

Paradigma de diseño continuo

Y para que el diseño se convierta en un diálogo fascinante, hay 4 recomendaciones:

# 1 Diseñar interacciones cliente-empleado en los puntos de contacto.

Diseñe una experiencia de usuario antes de lanzar un producto. Y es necesario estudiarlo no solo en condiciones ideales cuando el producto o servicio se usa correctamente, sino también cuando el cliente entra en contacto con procesos comerciales: una oficina administrativa o una arquitectura de TI. El diseño de la experiencia basada en el entorno externo y en el estilo de vida del usuario ayuda a identificar cómo el producto y los empleados con los que interactúa encajarán en la vida de la persona. También aclarará cuál será el terreno común con las divisiones de la empresa y en qué condiciones. Puede utilizar CJM y clientes y colegas de trabajos por hacer para esto.

# 2 Minimizar retraso, maximizar comentarios

Las metodologías de desarrollo flexibles como la práctica ágil y DevOps proporcionan más que velocidad y entrega de actualizaciones o versiones beta. Utilizándolos, podemos obtener rápidamente comentarios, probar hipótesis y ajustar acciones para mejorar aún más el producto. Aprendemos de cada sprint de trabajo o actualización de producto y exprimimos el conocimiento a lo largo del ciclo de vida del servicio.

# 3 Diseño para errores. Hacer para estudiar

Convierta las inmersiones en información que satisfaga sus intereses y los de sus usuarios. Los errores son inevitables en todas las etapas, ya sea diseñando funciones o desarrollando una campaña de marketing. Pero debe estar preparado para ellos y construir un diseño continuo para poder notar el error a tiempo y sacar conclusiones. Es importante utilizar prácticas Lean UX como pruebas UX, pruebas AV, hipótesis, etc.

Al final, se forma una cultura de trabajar con errores y las herramientas que crea: como Chaos Monkey o Blameless post mortems.

# 4 El concepto de "hecho" no existe

Estamos en una situación en la que el problema no se puede entender completamente, y la solución al mismo tiempo lo cambia. Por lo tanto, el equipo no puede simplemente seguir las hipótesis sobre el valor del producto y diseñar aún más la arquitectura y el servicio de TI. En cambio, debe observar cómo funcionan los productos y servicios cuando quedan fuera de control. La retroalimentación en el bucle DevOps no tiene sentido hasta que las operaciones y el mundo exterior influyan en el proceso de mejora del producto. Y en este caso se excluye el concepto de "hecho". Estás cambiando constantemente el producto. Esto significa que el proceso continúa aún más en el sistema DevOps y el pensamiento de diseño.

Trabajar en el paradigma del diseño continuo le enseña a responder rápidamente a los errores, es más fácil relacionarse con ellos y no hacer un trabajo inútil. Su ventaja es que, paso a paso, se cierran más y más tareas del cliente, lo que genera ganancias adicionales y tiene un efecto beneficioso en el negocio.

ps En este escrito, que se inspiró en el desempeño de Jeff Sassna.