Get best of the week

El diseñador no es el que pinta maravillosamente, es el que ayuda a la empresa a entender al usuario

imagen

En la última publicación, dije en números que un buen diseño vale la pena, que las métricas pueden y deben implementarse en el proceso de diseño y desarrollo, los comentarios deben recopilarse con más frecuencia y el diseñador no debe considerarse la persona que dibuja las imágenes.

La práctica muestra que si necesita discutir algo sustantivamente en TI (y en otras áreas también), entonces estamos hablando de enfoques de diseño clásicos con User Flow y CJM. Es decir, muchos procesos de desarrollo se aceleran al construir el proceso desde el usuario final hasta el producto, y no al revés.

A lo largo de los años de construcción de tales procesos, en McKinsey comenzamos a usar un marco basado en el pensamiento de diseño, el diseño basado en cero y los paradigmas de diseño de servicios. Ahora recomendamos usarlo al reconstruir la empresa hacia personas centradas en el ser humano.

El primer postulado es olvidarse de los desarrollos existentes y evaluar una vez más qué es exactamente lo que necesita el usuario y cómo resuelve sus tareas en el momento actual. A menudo se administra con mayor dolor, porque a menudo es más fácil desarrollar un producto existente y no pensar en la posibilidad de uno o dos años.


La diferencia en ingresos y retorno de la inversión para el cuartil superior de empresas con procesos de diseño bien establecidos en promedio en bienes de consumo, medicina y banca minorista. Como puede ver, en medicina, el diseño es inesperadamente crítico.

Los principales pasos de implementación para los pasos del marco


Analizamos la situación "tal cual", entendemos las necesidades de los clientes, las empresas, etc.

El equipo del cliente debe tener una idea de la ruta del cliente objetivo, es decir, cómo se verá el producto a largo plazo, así como el MVP prototipo (producto mínimo viable), en otras palabras, la parte de la ruta del cliente que el equipo lanzará en primer lugar. Lo que hacemos para llegar a esto:

  • Preparamos y realizamos investigaciones; Como regla general, se trata de entrevistas en profundidad en las que el propietario del producto y los miembros clave del equipo se reúnen cara a cara con sus usuarios para conocer sus problemas y necesidades.
  • Entendemos cómo funcionan los procesos y servicios existentes, por ejemplo, nos reunimos con los empleados de la sucursal de un banco y descubrimos cómo se ve realmente un préstamo a los clientes, qué funciona y qué no.
  • , , , .
  • , , .
  • ; , , , , , . — .
  • , , . , , : , , .

En cada etapa, transferimos al cliente las habilidades del enfoque correcto para crear el producto. Nuestra tarea es establecer el vector de movimiento, mostrar las herramientas y luego asegurarnos de que el equipo haga todo por su cuenta: para que los participantes realicen entrevistas con los usuarios, el propietario del producto recopile los mapas de ruta del cliente, el diseñador realice los prototipos y las pruebas.

Por ejemplo, pasamos por ese proceso en un banco, que decidió introducir cuentas de corretaje para individuos. Ahora, esta característica se encuentra en casi todas las aplicaciones móviles principales, cuando puede hacer con unos pocos clics lo que se hizo anteriormente en dos o tres viajes al departamento y completar un montón de formularios.

El proceso más simple que un banco haría de acuerdo con un marco tradicional es transferir una operación física regular en línea. Sin embargo, los postulados de nuestro estudio dicen que no es tan importante cómo se realiza la operación en otro lugar, si puede simplificarlo para el usuario en este canal o en este medio. Esta es una consecuencia directa del enfoque basado en cero: nada se hereda. Como dijo Torsten Dirks (CEO de Telefónica): "Cuando digitalizas un proceso de mierda, tienes un proceso digital de mierda" . El proceso debe desmontarse a cero, repensarse y volverse a montar de forma simplificada. Los diseñadores lo llaman desde la posición del cliente.

Lo primero que recopilamos es una lista de requisitos, restricciones y necesidades de los clientes según cómo vean el proceso en un mundo ideal.

Luego, tenemos una visión objetivo de cómo queremos ver un producto o servicio en el futuro. Es decir, cruzamos restricciones, estándares, capacidades técnicas, etc., con lo que parece el proceso ideal. En el caso de una cuenta de corretaje, por ejemplo, procesos como "necesitamos un pasaporte, y lo tenemos desde el momento de abrir una cuenta", "necesitamos tres consentimientos, reunámoslos todos en una sola marca", "necesita obtener tal y tal información, puede ofrecer introdúcelos manualmente o tómalos de las redes sociales ", etc.

Luego tomamos la meta y construimos una secuencia de acciones que conducen a ella. Es como un problema con una tetera, cuando "apagamos la estufa y la solución se reduce a resolver el problema anterior": no debemos tratar de usar los logros existentes, sino decidir cómo llegaremos a la meta y si se puede usar algo. La reutilización es secundaria en comparación con la importancia de resolver un problema.

En esta etapa, las tareas específicas ya están escritas. Solo que no preparamos conocimientos tradicionales durante seis meses, sino que las ramas "hipótesis - experimento", es decir, suponemos que algo saldrá mal. Y piensa en la reacción a eso.

El primer paso es siempre MVP.

El postulado básico dice que cuanto antes aparezcan los prototipos, más posibilidades hay de hacer un producto rápidamente para el cliente y no para sí mismo. Por lo tanto, estamos trabajando constantemente con un prototipo de diversos grados de desarrollo, desde Wireframe en el primer paso hasta el lanzamiento en el paso de lanzamiento del producto (seguimos apoyando el lanzamiento).

Ejemplo


Ayudamos a establecer los procesos en el banco, hago diseño de negocios (esto es cuando los diseñadores ayudan a tomar decisiones comerciales). Más precisamente, ayudo a la empresa a tomar decisiones más informadas (debido a más información sobre las necesidades de los usuarios, herramientas para analizar la situación actual y diseñar la situación objetivo, herramientas para la comunicación, etc.).

La nueva estructura de la empresa cuenta con equipos de productos autónomos. De hecho, antes no existían: la empresa anotó los requisitos para el producto, los envió a los diseñadores, los diseñadores dibujaron el diseño y se lo entregaron a los desarrolladores, y desarrollaron el producto y lo lanzaron.

Ahora hay equipos autónomos donde hay diseño y desarrollo, y una comprensión de la arquitectura de TI y los negocios. Después de varias iteraciones de preguntas: "¿Por qué estamos haciendo exactamente eso?" - Resulta que el software, los desarrolladores y otros miembros del equipo tienen ideas completamente diferentes sobre lo que los clientes necesitan. Por "diferentes puntos de vista" me refiero a los datos de hecho, no intuitivos. Intuitivamente, todos tienen su propia opinión sobre lo mejor: para el software, a menudo es la velocidad de lanzamiento del producto, para el desarrollador (código limpio, para el diseñador) los gustos en la cartera.

Imagen típica: el producto tiene 10 años, "ya lo sabemos todo". Realizamos entrevistas con clientes, y allí, en general, todo es diferente.

Nuestra tarea es mostrar que el dinero se encuentra donde se satisfacen las necesidades del cliente. Y cuanto mejor comprendamos al cliente, mayor será la probabilidad de que una empresa gane más. Por lo tanto, es necesario reorientar gradualmente la recepción constante de retroalimentación y un enfoque científico para el desarrollo. En nuestro caso bancario, realice entrevistas en profundidad, sintetice ideas y pruebe diferentes soluciones. Habiendo entendido las necesidades del cliente, ayudamos al equipo a mirar hacia el futuro: estimar la visión a largo plazo del producto o, como lo llamamos, construir la ruta del cliente objetivo.

Luego ayudamos a elevar una visión de tres a cuatro meses a uno o dos años. Esto es muy importante, porque la imagen, al menos en la perspectiva del año, permite tomar decisiones estratégicas. Si vives constantemente en el contexto de tres o cuatro meses, entonces solo puedes responder rápidamente a los cambios, pero nunca ser el primero. Y si anticipa la situación y comienza a vender y promocionar ahora lo que será importante para cuando la información llegue al cliente, entonces puede convertirse en un líder.

Antes de la reconstrucción de los procesos, funcionaba así: el propietario del producto entendió que algo en el mundo circundante había cambiado y que sería necesario cambiar el producto en esta dirección. Tomó tres meses pasar de la solicitud al diseño, porque el diseñador estaba sentado en algún lugar del departamento de diseño distante, y ya tenía un turno de tareas de tareas técnicas de extraños de todo el banco.

Los propios equipos de productos han reducido el tiempo de creación de prototipos para nuevas soluciones a dos días hábiles. Es decir, ayudamos a crear un modelo de una pequeña empresa autónoma que funciona en torno al producto.

Los prototipos obtenidos rápidamente comenzaron a usarse como base para las reuniones. Anteriormente, las empresas tomaban decisiones en un nivel especulativo, pero ahora, mirando CJM y pantallas ya hechas, es posible comprender qué se supone que se debe hacer exactamente.

La discusión se ha vuelto más fácil. Las decisiones comenzaron a hacerse sustantivas: "Aquí, demos tres aranceles, no dos", "Hay mucho texto aquí, pero lo que queremos es incomprensible", "Aquí, se está obteniendo demasiado consentimiento, no es necesario". Desde la reunión, ahora puede llamar a abogados para averiguar si se puede eliminar este consentimiento innecesario. La brecha entre las iteraciones se redujo a veces, porque el diseño era lo más cercano posible al negocio, tanto físicamente como en el sentido de la estructura organizacional.

Según los estándares de las grandes organizaciones, que existen desde hace más de una docena de años, esto suena a ciencia ficción.

¿Por qué los procesos de diseño se han convertido en la base para la toma de decisiones del producto? Porque hubo reuniones sin un diseñador, donde las soluciones complejas de productos se discuten en palabras. Esto lleva muchas horas, se repite cada pocos días y el equipo no puede llegar a un acuerdo.

El diseñador llega, dibuja un prototipo en la reunión, la discusión se vuelve más sustantiva, el equipo negocia rápidamente y sigue adelante. Es decir, fue en esta situación que la creación rápida de prototipos por medios visuales (al menos a mano en papel) ayudó a acordar más rápidamente.

El propietario del producto en el banco está acostumbrado a trabajar en la estructura de la cascada cuando el diseñador se sienta en un equipo separado al que se envía la solicitud para crear diseños. Tarda varios meses en completarse, y el resultado solo se puede cambiar al nivel de "cambiemos la imagen en el banner", y no al nivel de "pensemos en la lógica de las pantallas y el número de campos para llenar". El diseñador apareció en el equipo, comenzó el trabajo iterativo, traduciendo las necesidades de los clientes en el propietario del producto y el equipo en su conjunto. El diseñador destaca y explica razonablemente las áreas problemáticas de la versión actual del diseño, el software y el equipo buscan más rápidamente soluciones para mejorarlo.

Resultado: formulaciones simplificadas, el banco habla el idioma del cliente, una ruta de cliente más corta y más comprensible, menos campos para completar, tarifas claras.

Principios básicos


El diseñador no es el que pinta maravillosamente, es el que ayuda a la empresa a comprender al cliente (usuario) , mirar el producto de extremo a extremo que se está creando, crear una visión colectiva unificada (compartida) del producto utilizando herramientas de diseño (tarjetas, prototipos) . Es decir, un diseñador es un diseñador que puede visualizar el proceso de creación de un producto. Un miembro del equipo de pleno derecho, defensor de los usuarios y facilitador de todas las discusiones en curso.

El diseñador dice:
— , « ». . , , 2. . , . , . User Story Map. , CJM. ? . ? . ? ? , , , , . — . 20 — , .

Entonces, los primeros auxilios para el diseño es acelerar las discusiones sobre el producto. Y luego ya hay un cambio de pensamiento para "las necesidades del usuario", y no "aquí lo tenemos".

Resolvemos el problema, comenzando por una comprensión de las necesidades del usuario.

El diseño se juzga por la satisfacción del cliente y las conversiones. En la mayoría de los casos, se trata de la efectividad de resolver el problema. Cuanto más rápido y con menos esfuerzo el usuario resuelve sus tareas con la ayuda del producto, más conveniente lo considera. Esto a menudo significa que los productos "buenos" ya conocidos son subjetivamente mejores, y el usuario considera que los productos más simples con una funcionalidad mínima son más flexibles en comparación con la funcionalidad rica (pero desconocida para él).

Por lo tanto, cualquier producto no solo se crea teniendo en cuenta las ideas previamente identificadas, sino que también se supervisa constantemente.

En nuestro ejemplo, el diseñador en el banco aparece en el equipo y luego es responsable de las pruebas periódicas con los usuarios al menos una vez por sprint. El equipo y la gerencia ven la reacción de los clientes y entienden que el proyecto se está moviendo en la dirección correcta. Todavía no hay estudios cuantitativos, pero ya cualitativos. Está claro en qué se destina el dinero al diseño.

Un nuevo enfoque al trabajo cambia la cultura de la empresa, desarrolla el enfoque humano y hace que la experiencia del cliente sea una responsabilidad de todos.Sin un diseñador, un banco se comunica con los clientes solo a través de agencias de marketing, recibiendo información sobre la investigación a través de informes. Esta información no da lugar a la empatía. El diseñador organiza entrevistas periódicas en profundidad con los clientes, enseña software para realizar estas entrevistas, muestra aspectos destacados (cortes de hallazgos interesantes) en una demostración. La empatía con el cliente se desarrolla gradualmente en el banco, en las discusiones las personas comienzan a apelar a lo que han escuchado / visto en la entrevista, utilizando estas observaciones como una textura adicional para tomar decisiones.

Estamos buscando los problemas correctos para resolver o problemas que deben resolverse en primer lugar (nuevamente, a través de la comprensión de las necesidades del usuario).

Es necesario decidir qué es lo que más afecta la satisfacción. En algún lugar, este es un píxel sesgado contra una característica con una implementación de dos meses, en algún lugar, por el contrario. Y en algún lugar, como en una broma, es inútil mover las camas y debes cambiar el producto.

Creamos soluciones en un equipo interdisciplinario (diseño + negocio + tecnología).

La división en tales equipos (para el desarrollo, idealmente al menos para la discusión) es también la base del marco. Cada uno de los que influyen en el proyecto debe ver lo que está sucediendo en el interior para poder hablar inmediatamente sobre esto. El diseñador generalmente dice: "Me gustaría así", y el resto explica por qué esto no es posible o por qué es posible. El diálogo entre el diseñador y el desarrollador a veces se parece a este cómic de XKCD:



Además, esto funciona en ambos sentidos: algo muy complicado para un diseñador puede llegar a ser algo muy simple, porque las tecnologías han cambiado un poco durante el año.

Cuanto más cerca esté el diseñador del negocio, más eficiente será el proceso de creación del producto y el resultado final: este es nuestro nuevo informe de diseño. Los principios son los mismos en todos los niveles .

Creamos prototipos y visualizamos las soluciones inventadas para alinear al equipo y comenzar a recibir comentarios.

Esto es importante tanto en el desarrollo de software como en el desarrollo de dispositivos. Si hace una aspiradora, un prototipo hecho a tiempo puede salvarlo de la indignación de los usuarios debido a un centro de gravedad incorrecto o problemas de mantenimiento que surgen demasiado tarde.

Cuanto más cerca esté el diseñador de los negocios, más fácil será para él transmitir el conocimiento sobre las necesidades del cliente y acelerar la toma de decisiones en relación con estas necesidades. La buena práctica es en la transparencia del proceso . El diseñador del banco involucra a todo el equipo y líderes en el proceso desde el principio. Todas las tarjetas CJM y las opciones de trabajo están a la vista (se cuelgan en las paredes, están disponibles en línea, se presentan en días de demostración). Todos, incluidos los líderes, entienden de qué manera se está desarrollando el producto, pueden hacer comentarios y hacer preguntas en cualquier momento. Cuando el proceso es transparente, todos están más tranquilos.

Cuanto mejor se integre el diseñador en el equipo, mayor será la participación y el sentido de propiedad para el diseño del producto de todos los miembros del equipo (todos participan en el diseño, todos se sienten dueños). Aquí surge la pregunta: "¿Por qué no puede ser más rojo?", Y la tarea del diseñador no le responderá "porque lo dije", sino que lo justifica. Si no funciona, ya es necesario llegar a un compromiso. Desde algún punto, las discusiones sobre "más rojo" desaparecen por completo, a medida que el enfoque cambia para resolver los problemas del usuario. ¿Funciona para el usuario o no? Al usuario no le importa, más rojo o más verde. La pregunta es si es notable o imperceptible, claro o incomprensible, si hay valor o no.

Los prototipos (imágenes) hacen que la comunicación con los abogados, el cumplimiento y la seguridad sean más fáciles y más eficientes. Mucho mejor que comunicarse con cartas. Como regla, surgen demandas increíbles que rompen mucho la experiencia del cliente. Cuando esto simplemente se indica en las cartas, no es obvio para todos cuando se dibuja en el prototipo, queda claro que uno no puede vivir así. El líder ve esto y comienza la búsqueda de un compromiso.

Referencias


More articles:


All Articles