Conversis Consulting – Marketing orientado a resultados para mercados tecnológicos

Entradas de la categoría ‘diseño de productos y negocios’

La velocidad y la colaboración de Agile imponen nuevas condiciones a la práctica del Diseño. Por otra parte, en el desarrollo de productos es imprescindible que un buen diseño de experiencias pueda abrirse paso a través de la ingeniería ágil. ¿Cómo deberían integrarse las prácticas del Diseño y Agile?

Ya vimos en un post anterior que, aunque la ingeniería Ágil y el Diseño de experiencias de usuario implican enfoques originalmente diferentes, la adopción cada vez mayor de ambas filosofías para el desarrollo de nuevos productos está forzando a una convergencia y a una integración de las dos.

Dual track agile design

Una mala integración entre el Diseño y Agile produce problemas como estos:

  • Ineficaz planificación de las iteraciones porque falta una visión del producto y los elementos del backlog están mal definidos
  • Baja velocidad del proceso global porque muchos detalles se están elaborando durante la iteración
  • Despilfarro de recursos y reproceso elevados porque los elementos del backlog no han sido validados con los clientes y otros afectados
  • Productos con funcionalidades correctamente implementadas pero que no coinciden con las que necesita el mercado ni proporcionan una experiencia de usuario adecuada.

Integrando Diseño y Agile

Para evitar estos problemas han ido cristalizando algunas buenas prácticas que ayudan a integrar el desarrollo de experiencias de usuario en entornos de construcción ágil de productos. A continuación os resumo algunas, adaptadas de un muy referenciado post de Jeff Patton “Twelve emerging best practices for adding UX work to Agile development” (un poco antiguo pero de lectura obligada para todos los interesados en este tema):

  • Jefes de producto, diseñadores  e ingenieros deben trabajar integrados en equipos multidisciplinares de gestión y desarrollo de producto. Todos deben colaborar a través de las actividades de descubrimiento, validación y construcción de soluciones para el mercado.
  • Investigar, modelar y diseñar al principio… pero solo lo justo. La idea es realizar al inicio un diseño “suficiente” que proporcione un marco sobre el cual ir construyendo el diseño detallado a medida que el proyecto avanza. Resulta primordial identificar y comunicar las líneas generales de la funcionalidad y la experiencia de usuario para poder trabajar luego en sus partes manteniendo el contexto. Esta actividad debe estar totalmente integrada en nuestros esfuerzos para descubrir el producto: encontrar una solución a nuestro problema de mercado que sea útil, usable, deseable, factible y viable. A pesar de lo que algunos apóstoles agilistas proponían hace algunos años, las empresas que tienen éxito incorporando Diseño y Agile sí hacen un trabajo previo de investigación y modelado que genera personas, escenarios, modelos de flujo, etc. Sin embargo, han aprendido a comprimir la duración de su trabajo mediante las siguientes prácticas:
    • Priorizar el tipo de usuarios a investigar y reducir drásticamente el tiempo dedicado a usuarios de baja prioridad
    • Modelar rápidamente, aplicando métodos ligeros y colaborativos
    • Diferir los trabajos menos urgentes de investigación hasta la fase de implementación
    • Construir escenarios y artefactos (mockups, wireframes) de alto nivel que comuniquen la interacción y look-and-feel generales
    • Estas actividades se suelen realizar en una fase de planificación previa o una “Iteración 0”, junto con otros trabajos de prototipado de arquitectura, puesta en marcha de plataformas, etc.
  • Los diseñadores deben acostumbrarse a trabajar “por partes” y a una cadencia más rápida. En Agile la construcción se realiza por elementos  de funcionalidad (usualmente expresados como “historias de usuario”) que tienen valor y son comprobables desde la perspectiva del cliente. Hay que aprender a dividir el trabajo de especificación y diseño en partes coherentes que puedan ser diseñadas, construidas y validadas independientemente. Asimismo, la velocidad de iteración de Agile puede requerir que los diseñadores trabajen a un ritmo más rápido que el que les podría resultar cómodo. Algunos diseñadores y algunas metodologías de diseño son más compatibles con la filosofía ágil que otros.
  • Utilizar tracks paralelos de diseño e implementación. Los equipos en contacto con el cliente deben trabajar con uno o dos períodos de antelación para definir y diseñar lo que será construido en los futuros períodos. Esto permite validar las features más complejas con tiempo suficiente para mejorarlas. Es primordial evitar que el trabajo de diseño se realice durante el mismo sprint en que está teniendo lugar la implementación. Sin embargo, alguien del equipo de ingeniería debe revisar las ideas y prototipos en cada etapa para aportar feedback sobre factibilidad y costes y proponer mejores soluciones. Cuando el equipo de implementación está trabajando en la iteración T, el equipo de diseño está:
    • Investigando a los clientes sobre lo que se implementará en T+2
    • Validando con clientes prototipos de diseño que se implementarán en T+1
    • Colaborando con el equipo de ingeniería en las implementaciones actuales (T)
    • Validando con clientes lo construido en la iteración anterior (T-1)
  • Utilizar prototipos como especificaciones. En lugar del documento tradicional de especificaciones utilizar prototipos, habitualmente anotados “sobre la marcha” en una discusión con el equipo de implementación.

La adopción de una ingeniería ágil en la construcción de productos puede tener un impacto muy notable sobre cómo se practica el diseño en nuestra empresa:

  • Si la práctica de Diseño en nuestra empresa era débil antes de adoptar Agile, este cambio no le va a favorecer
  • Si la práctica de Diseño en nuestra empresa era fuerte antes de adoptar Agile seguirá siendo fuerte después, pero tendrá que evolucionar y adaptarse.

Aunque la convergencia de Agile y Diseño no está exenta de fricciones, crea muchas oportunidades y mejoras: haciendo que diseñadores e ingenieros trabajen juntos les permite enfocarse en objetivos más claros a corto plazo y eso puede beneficiar a la calidad de nuestros productos y al tiempo de salida  al mercado.

Este post en “Marketing & Innovación”.

[El diseño de producto es mucho más que un barniz estético a posteriori y especialmente en áreas como la experiencia de usuario constituye un gran eje de diferenciación. Descubre en este documento el papel del diseño en el desarrollo de productos.]

6 comentarios

Agile y Diseño tienen orígenes y enfoques muy diferentes. Las prácticas ágiles minimizan el diseño previo y su velocidad de iteración deja poco tiempo para la investigación de clientes y la experimentación de nuevos modelos de interacción con el producto. Pero la necesaria confluencia entre ambos está imponiendo nuevas condiciones a los profesionales de uno y otro lado.

(IMPORTANTE: cuando en este post hablamos de Diseño nos referimos al diseño de experiencias de usuario o UX, no al diseño técnico.)

A primera vista, Agile y Diseño tienen muchos aspectos en común: aplicados al desarrollo de productos ambos ponen su foco en el usuario y aplican un proceso iterativo de refinamiento del producto guiado por el feedback del mercado, que se captura mediante artefactos “provisionales” (mockups, prototipos, versiones preliminares y limitadas del producto…). Los dos enfoques comparten el objetivo último de proporcionar productos dotados de significado para sus clientes.

Fight Agile UX

Agile y Diseño son fundamentalmente diferentes

Pero esas similitudes no nos deben impedir ver las diferencias –en algunos puntos antagónicas– entre ambos enfoques. Especialmente en el desarrollo de productos para un mercado (no de proyectos a medida para un cliente) estamos hablando de filosofías, ámbitos de aplicación y resultados muy diferentes:

  • El diseño de experiencias de usuario consiste en realizar investigación de clientes y en conceptualizar o representar el comportamiento del producto que se va a construir. Y el diseño de experiencias no es algo que se pueda hacer completamente por piezas: hay que considerar la experiencia de usuario holísticamente (si no en profundidad al menos sí en sus líneas generales y su filosofía). Por eso sus partidarios defienden que, análogamente a los planos de un edificio, el diseño de un producto debe realizarse antes de empezar a construirlo.
  • Agile es principalmente implementación (es decir, entrega de versiones funcionales del producto) y generalmente entra en acción cuando hemos decidido que vamos a construir la “unidad cero” de algo. Agile hace énfasis en la entrega rápida e iterativa de productos operativos, lo que en el caso de algunos enfoques anticuados o extremos se consigue a costa de prescindir de una planificación y diseño elaborados.

No olvidemos que Agile se empezó a aplicar en el desarrollo de proyectos a medida (y no tanto en desarrollo de productos replicables), un escenario donde tradicionalmente no se ha concedido una gran importancia a la experiencia de usuario. Cuando el objetivo prioritario es proporcionar una serie de features, la experiencia de usuario suele ser un “subproducto” no muy logrado. Por el contrario, en productos para un mercado la experiencia del usuario es primordial y el Diseño nació para esos escenarios.

A principios de la pasada década, cuando Agile y Diseño empezaron a pasar al primer plano, las diferencias entre ambos eran más patentes. En un debate clásico que tuvo lugar en 2002, Alan Cooper (pionero del diseño de interacción) y Kent Beck (creador de XP) no sólo fueron incapaces de ponerse de acuerdo, sino que ninguno de los dos parecía entender al otro. Reconozcamos que era la “prehistoria” y que desde entonces ambos metodologías han evolucionado, pero la conversación nos da idea de sus diferencias en origen.

Para reducir el riesgo y mejorar la calidad del producto, en Agile una release se divide en varias iteraciones, en cada una de las cuales se implementa un conjunto de “historias de usuario” (u otro artefacto para especificar funcionalidad). Este foco en las features nos puede hacer olvidar que la experiencia del usuario no se puede diseñar por partes: debe tener sentido para ese usuario en cada release. Si en Agile renunciamos a modelar con antelación lo que se va a implementar podemos acabar con un producto fiable y bien construido pero que carezca de una integridad y una interacción coherente. Y es que algunas cosas a las que se deja que “emerjan” terminan resultando criaturas muy feas.

Condenados a entenderse

Tal vez el principal beneficio del diseño de UX es la capacidad para imaginar y representar cómo un conjunto desordenado de funciones y significados se puede sintetizar armoniosamente. Por desgracia, algunas prácticas ágiles extremas relegan su papel al de esfuerzos a corto plazo para diseñar y rediseñar elementos pequeños y aislados. Y aunque en este campo Agile puede mejorar la usabilidad del producto, los resultados tienen a menudo un carácter incremental.

La velocidad de ciclo y la cadencia que impone Agile ha sido uno de los aspectos más difíciles de reconciliar con el Diseño. ¿Con unos ciclos tan cortos tenemos realmente tiempo para entender completamente las necesidades de nuestros usuarios? La respuesta corta es “no”. Pero la respuesta correcta es que si estamos descubriendo las necesidades de los usuarios durante la implementación estamos haciendo algo rematadamente mal. La urgencia por alimentar los ciclos de Agile y por dedicarnos a los “árboles” de la actual iteración nos puede impedir ver el “bosque” de la experiencia holística de usuario y descubrir nuevos y rompedores modelos de interacción que diferencien a nuestro producto de sus rivales.

Además, la falta de un diseño inicial validado con los usuarios puede llevar en fase de construcción a un rediseño o un refactoring excesivo que incremente los costes y retrase la salida al mercado; algo que, paradójicamente, impide alcanzar los objetivos de Agile. Hay que buscar un equilibrio: combinando un esfuerzo inicial con pasos pequeños y constantes que avanzan hacia un producto coherente, el Diseño tiene que abrirse paso. De lo contrario Agile se acaba convirtiendo en una serie de experimentos de diseño de muy alta fidelidad y coste.

Como no podía ser de otra forma, en los últimos años hemos asistido a un acercamiento entre UX y Agile, con prácticas de uno que pasan al otro (y, curiosamente, con primeras figuras de cada una de las corrientes participando en los eventos de la otra). Las prácticas del nuevo Agile Product Management recogen el uso de mockups y prototipos para generar lo que se conoce como “visión” del producto, y que recoge los resultados del análisis de la oportunidad de mercado y de la definición y especificación general del producto. Esta visión se traduce en “épicas” y “temas”, que son los artefactos con los que Agile especifica la funcionalidad a alto nivel. Aún así, queda mucho camino por recorrer en cuanto a la integración del Diseño en Agile.

La adopción de Agile está obligando a cambiar la forma de trabajar de los diseñadores, pero la combinación de Agile y UX abre nuevas oportunidades tanto para los profesionales como de proporcionar mejores productos a los clientes. Y al diseño ágil de experiencias de usuario (lo que se conoce como Agile UX) dedicaremos un próximo post.

Este post en “Marketing & Innovación”.

[El diseño de producto es mucho más que un barniz estético a posteriori y especialmente en áreas como la experiencia de usuario constituye un gran eje de diferenciación. Descubre en este documento el papel del diseño en el desarrollo de productos.]

5 comentarios

La función de Diseño de Producto sirve de engranaje entre las de Definición e Implementación. Pero la clave para un buen funcionamiento está en cómo organizar y coordinar las actividades y en un enfoque iterativo y dinámico que involucre al cliente/usuario desde el primer momento.

En la primera parte de este post comenzamos a hablar de cómo resulta imprescindible crear una función de Diseño de Producto que se encargue de conceptualizar la solución a los problemas de mercado y de especificar el producto desde el punto de vista funcional y de experiencia de usuario. Esa función de Diseño debería servir de engranaje entre los roles de Definición e Implementación a lo largo de las actividades de desarrollo del producto:

  1. Identificar problemas de mercado y evaluar oportunidades
  2. Definir requisitos y validar soluciones
  3. Diseñar la solución y elaborar la especificación
  4. Implementar y probar la solución

En esa primera entrega cubrimos las actividades iniciales; ahora pasamos revista a las dos últimas.

Lineal Iterativo

Diseñar la solución y elaborar la especificación

Desde los primeros momentos del proceso, Diseño colabora con Gestión de Producto en el análisis del mercado y los competidores y realiza estudios de clientes (entrevistas, encuestas, observaciones contextuales) para entender los problemas de negocio y definir enfoques para la interacción del usuario. A continuación, Diseño conceptualiza una solución a los problemas identificados en los requisitos que conjugue la respuesta a dichos problemas/necesidades con una experiencia de usuario satisfactoria. Diseño elabora storyboards, diagramas de flujo, wireframes, prototipos y otros artefactos que se van iterando y validando con los clientes para asegurar que la solución es aceptable desde los puntos de vista funcional y experiencial.

Como beneficio añadido de este proceso, el conocimiento generado durante el análisis y el diseño puede provocar refinamientos y revisiones de los requisitos iniciales. El equipo de Implementación también puede intervenir en esta actividad, proponiendo soluciones y verificando que las propuestas que aparecen serán técnicamente realizables. El objetivo es llegar a una solución útil, usable, deseable, factible y viable.

Diseño de Producto elabora las especificaciones a partir de las cuales el equipo de Implementación construirá la solución real. Se trata de especificaciones funcionales y de experiencia de usuario, no de especificaciones técnicas. La especificación elaborada por Diseño describe cómo funciona el producto desde la perspectiva de cliente y usuario. No entra en cómo se implementan las cosas sino que describe el propósito del producto, su funcionalidad, features, prestaciones, interfaces e interacciones.

Esta especificación puede tomar diversas formas: desde el tradicional Documento de Especificaciones de Producto hasta un prototipo “de alta fidelidad” anotado con historias de uso. Lo importante, sin embargo, no es tanto el formato como su aplicación como artefacto de comunicación y coordinación.

Implementar y probar la solución

El equipo de Implementación construye la solución a partir de los requisitos y las especificaciones generadas durante la Definición y Diseño de producto. Con anterioridad, representantes del equipo han tenido la oportunidad de involucrarse en las actividades previas con vistas a entender de primera mano las necesidades de los clientes, sugerir orientaciones de diseño y en general asegurar la factibilidad de la solución.

Como paso fundamental de esta actividad el equipo crea una especificación técnica que describe la arquitectura y la construcción interna de la solución. El objetivo es llegar a una “unidad cero” del producto que garantice la replicabilidad/fabricabilidad, la calidad, la escalabilidad en las prestaciones, la posibilidad de evolución y la adaptabilidad (en su caso) del producto a diferentes segmentos de clientes.

La implementación del producto se suele instrumentar como uno -o varios- proyectos que se gestionan y ejecutan, dependiendo del escenario, usando métodos faseados/cascada o iterativos/ágiles.

Como parte de esta actividad la función de Aseguramiento de la Calidad realiza pruebas de producto y los errores que se detectan son corregidos.

Conclusiones

Diseño de Producto colabora con las funciones de Definición e Implementación a lo largo de todo el ciclo de desarrollo. Diseño trabaja inicialmente con Definición de Producto para analizar problemas/necesidades y diseñar y validar soluciones; después, Diseño colabora con Implementación para especificar, construir y probar la solución. De este modo Diseño de Producto desempeña el papel de puente entre esas dos funciones.

En cuanto al secuenciamiento de actividades en el desarrollo de productos, hasta hace unos años se consideraba que los enfoques lineales y faseados (como, por ejemplo, Stage-Gate) eran los más indicados para reducir riesgos y aumentar las probabilidades de éxito. Sin embargo, algunas tendencias recientes han ido desplazando el enfoque hacia una mayor iteración y solapamiento entre fases:

  • La posibilidad de construir prototipos de alta fidelidad y de realizar experimentos desde las fases iniciales del desarrollo y las metodologías ágiles de implementación permiten el feedback continuo de los usuarios y la iteración sea cual sea el mercado o la naturaleza del producto.
  • Un desarrollo de producto protagonizado por equipos multidisciplinares y transversales, que se autoorganizan, colaboran y recorren juntos las etapas del proceso “como un equipo de rugby”, en lugar de silos organizativos que se van traspasando el proceso como en una carrera de relevos.

Estos enfoques son tanto más útiles cuanto mayor sea el grado de innovación del producto y sus riegos asociados. No obstante, esta evolución crea nuevas incógnitas sobre cuál puede ser el grado de iteración y solapamiento más adecuado en cada caso (p. ej.: simultanear requisitos con diseño, o diseño con implementación), unos interrogantes de los que nos ocuparemos en futuros posts.

Este post en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

4 comentarios

Muchos productos tecnológicos fracasan porque no obedecen a un concepto claro y carecen de un diseño deliberado. Organizar una función de Diseño que sirva de puente entre la definición y la implementación del producto ayuda a conseguir el objetivo compartido de crear productos que los clientes quieran comprar.

La realidad de muchos productos es que los product managers elaboran listas de features deseadas y el equipo de implementación construye… pero nadie diseña nada. Recordemos que -tal como hemos expuesto en otras entradas- diseño significa conceptualizar y especificar la solución al problema de los clientes, no solo el aspecto externo del producto.

¿Contratarías a un carpintero para construir una casa? Probablemente sería más sensato contratar a un arquitecto. Pues en desarrollo de productos ocurre lo mismo: alguien tiene que ser responsable de su diseño. Es imprescindible crear una función de Diseño de Producto o un rol de Diseñador de Producto que colabore con las funciones de Definición e Implementación de producto para alcanzar el objetivo último del proceso: crear productos que la gente quiera comprar. Aclaremos que no tiene que tratarse necesariamente de una persona o equipo dedicados en exclusiva a la función, sino que esta puede simultanearse con otros roles.

Vamos a intentar describir cómo articular la función de Diseño de Producto aplicando un planteamiento muy influido por dos de mis referencias en product management de productos tecnológicos: Pragmatic Marketing y Silicon Valley Product Group.

Esencialmente el enfoque consiste en que los responsables de la Definición del producto describen el problema de mercado, Diseño elabora un enfoque recomendado para resolver dicho problema, e Implementación lo aplica para construir el producto. De este modo el Diseño sirve de engranaje entre la Definición y la Implementación del producto. Las responsabilidades principales se reparten como sigue:

Definición, Diseño e Implementación de Producto

  • La función de Definición de Producto descubre y cuantifica problemas de mercado, y los articula en forma de requisitos. Este rol suele estar desempeñado por los Product Managers.
  • La función de Diseño de Producto analiza los requisitos, conceptualiza la solución y elabora una especificación funcional que describe cómo el problema puede ser resuelto con el producto.
  • La función de Implementación de Producto elabora una especificación técnica que describe cómo se implementará dicha especificación funcional, construye la solución, realiza pruebas y corrige errores.

A continuación y en la segunda parte de este post vamos a describir las principales actividades del proceso de desarrollo de nuevos productos y el detalle de cómo se implican y colaboran en ellas las funciones/roles mencionados. Estas actividades son:

  1. Identificar problemas de mercado y evaluar oportunidades
  2. Definir requisitos y validar soluciones
  3. Diseñar la solución y elaborar la especificación
  4. Implementar y probar la solución

Hay que resaltar que estas actividades no son necesariamente secuenciales y faseadas sino que en general y dependiendo del escenario constituyen un proceso con más o menos iteraciones y solapamientos.

Identificar problemas de mercado y evaluar oportunidades

Gestión de Producto (Product Management) identifica problemas y necesidades de mercado, realiza análisis y evalúa y cuantifica las oportunidades que se abren para las posibles soluciones a dichos problemas. La evaluación de la oportunidad debe dar respuesta, entre otras, a estas cuestiones:

  • Problema/necesidad a resolver
  • Perfil del consumidor/empresa que lo padece
  • Extensión, importancia y urgencia del problema
  • Tamaño del mercado y su posible evolución
  • “Ventana temporal” del mercado
  • Soluciones alternativas existentes (incluyendo “no hacer nada”)
  • Valor diferencial que podemos aportar
  • Modelo de negocio que deberíamos utilizar para entregar y capturar ese valor
  • Elementos clave de nuestra solución
  • Enfoque go-to-market
  • Estimaciones financieras básicas
  • Recomendación final: Go / No Go

Gestión de Producto debe profundizar en su comprensión de los mercados y los clientes -y sus compradores y usuarios- para construir personas: buyer (o marketing) personas y user personas. Una persona es una representación figurada de un grupo de compradores/usuarios/otros involucrados que comparten objetivos, actitudes y comportamientos. Una vez desarrolladas las personas, se crean escenarios, que son descripciones de la interacción de los usuarios con la solución.

Tanto personas como escenarios son construcciones imprescindibles para entender a los clientes de cara a diseñar la solución, así que Diseño colabora en muchos casos desde el principio investigando clientes, desarrollando insights y aportándolos para la elaboración de ambos. Personas y escenarios son útiles para que Gestión de Producto elabore los casos de negocio y para que Diseño de Producto defina la experiencia de usuario.

Definir requisitos y validar soluciones

Gestión de Producto escribe requisitos que identifican los problemas de mercado. Un requisito bien entendido es esencialmente una descripción del problema/necesidad (no una especificación de cómo resolverlo) y debe ser agnóstico respecto del diseño y la tecnología. Los requisitos que describen la necesidad/problema, junto con la evaluación de la oportunidad de mercado que representa, son los elementos principales del Documento de Requisitos de Mercado -o algún artefacto sustitutivo- que sirva para comunicar esa oportunidad y su valor a la organización.

Diseño ayuda a Gestión de Producto en esos procesos, llevando a cabo entrevistas, encuestas y observaciones y analizándolas. Los datos de esos estudios ayudan a detectar problemas y oportunidades de mercado que se plasman en requisitos.

Durante la actividad de especificación de la solución, Diseño desarrolla prototipos que Gestión de Producto utiliza para obtener feedback de los clientes y validar las posibles soluciones. La elaboración de requisitos y la validación de soluciones conforman un proceso iterativo. El nuevo conocimiento que se adquiere en la validación de la solución obliga a que se actualicen los requisitos, y las soluciones que se derivan de los requisitos actualizados requieren de validación adicional.

En la segunda parte de este post cubriremos las actividades de diseño e implementación de la solución.

Este post en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

12 comentarios

En muchas empresas tecnológicas el diseño (especialmente la experiencia del usuario) suele reducirse a un trabajo final de “embellecimiento” del producto, centrado puramente en sus elementos gráficos. En este post damos algunas ideas sobre cómo diseñar buenas experiencias de usuario.

Decíamos en un post anterior que muchos productos de consumo tienen un “alma” o una “personalidad” de la que carecen la mayoría de productos para el mercado empresarial y que esta alma suele provenir de su diseño.

Uno de los apóstoles del diseño, Alan Cooper, viene a decir en su clásico libro “The Inmates are Running the Asylum” que la mayoría de los productos tecnológicos no están diseñados para los usuarios, sino para los desarrolladores… o -lo que es peor- no parecen diseñados en absoluto.

El buen diseño empieza por las necesidades del nuestros usuarios. Enfoques como el Diseño Centrado en las Personas y el Diseño de Interacción se caracterizan por estar “orientados/dirigidos a objetivos”, es decir, se ocupan principalmente de satisfacer las necesidades y deseos de las personas que van a interactuar con un producto o servicio.

Para conseguirlo, los procesos de diseño suelen tomar como punto de partida los siguientes instrumentos:

  • Personas. Una persona (latín) es un personaje ficticio que representa a una clase de usuarios del producto que tienen los mismos objetivos, actividades y comportamientos. (Nota: en este caso estamos hablando de personas de usuario como representaciones arquetípicas de los participantes en un contexto de uso del producto. No confundir con las personas de comprador, que representan a los participantes en un contexto de compra del producto y que se usan en product management y marketing). Las personas se construyen después del proceso de investigación de usuarios, en el que típicamente se aplican técnicas de observación e inmersión en su contexto, entrevistas,  etc.
  • Objetivos. Lo que los usuarios desean conseguir utilizando el producto. Los usuarios tienen esencialmente dos tipos de objetivos: prácticos (qué resultados desean alcanzar) y emocionales (cómo desean sentirse).
  • Escenarios. Un escenario es una narración ficticia sobre “un día en la vida” de la persona o una secuencia de actividades que deben realizarse cuando se usa el producto.

En particular, el Diseño de Interacción (popularizado por A. Cooper) es un proceso que se enfoca en los usuarios más importantes. A diferencia de los procesos tradicionales de recogida de requisitos y diseño de la solución, el diseño de interacciones se centra en los objetivos de una clase específica de usuarios, que se representa mediante una persona prioritaria.

A partir de la combinación de objetivos y escenarios se trata de diseñar la experiencia de usuario y las especificaciones funcionales mediante un proceso iterativo de generación de ideas y artefactos de diseño (mockups, prototipos, simulaciones) y su validación con los usuarios reales. Sólo así podremos asegurarnos de que después vamos a construir un producto útil (resuelve el problema correcto), usable (los usuarios pueden utilizarlo) y deseable (los usuarios quieren usarlo).

Crear una buena experiencia de usuario (UX, User eXperience) requiere un conjunto de funciones o roles. Estos son las más esenciales:

  • Investigación de clientes. Su objetivo es proporcionar un aprendizaje rápido y continuo sobre los clientes, utilizando técnicas cualitativas y cuantitativas, y basadas tanto en lo que el cliente dice (ej.: entrevistas, encuestas) y como en lo que hace (ej.: etnografía).
  • Diseño de interacción. Su misión es entender los objetivos, escenarios y actividades que el usuario desea realizar y plasmarlos en unas tareas, flujos y operaciones sobre el producto que sean satisfactorios y usables. El diseño de interacción expone y hace accesible la funcionalidad del producto. Habitualmente esta función mapea los requisitos de producto en un modelo de interacción desprovisto de detalles gráficos (p.ej.: wireframe)  que es tomado como input por la función de diseño visual.
  • Diseño visual. Proporciona el look-and-feel de la interfaz: layout, colores… Muchos piensan que la misión del diseño visual es hacer el producto “bonito” o “sexy” pero es mucho más. El diseño visual comunica y evoca emociones y contribuye enormemente a la respuesta que los usuarios tienen ante nuestro producto: puede marcar la diferencia entre un producto que simplemente nos gusta y otro que nos encanta. Pero además de crear emociones para los usuarios el diseño visual aporta consistencia en la presentación y establece elementos de marca.

Además de estas funciones (y dependiendo del tipo de producto) hay otras no menos importantes: testing, arquitectura de información, etc. Todas estas funciones no son necesariamente secuenciales ni tienen que ser desempeñadas por personas/puestos diferentes.

Por último quería dar algunas ideas prácticas sobre cómo crear productos con buen diseño…o al menos crearlos con un diseño menos malo:

  • La funcionalidad y la experiencia de usuario están intrínsecamente entrelazadas. No es solo que “la forma sigue a la función”: podríamos decir que la forma ES función.
  • La experiencia de usuario es tan importante como la funcionalidad, pero habitualmente más difícil de conseguir. Los ingenieros que construyen el producto son (somos) habitualmente unos malos diseñadores de experiencias de usuario, ya que suelen pensar en términos de modelos de implementación mientras que los usuarios piensan utilizando modelos conceptuales.
  • Trabajar en la experiencia de usuario desde el principio: inmediatamente después de capturar y priorizar requisitos de alto nivel hay que empezar con el diseño de interfaz de usuario e interacción. No podemos caer en el típico error de añadir la experiencia al final o -peor aún- dejar que sea un subproducto de la implementación.
  • Los jefes de producto (product managers) deben trabajar en estrecha colaboración con los diseñadores de producto: la comunicación no puede reducirse al traspaso del típico Documento de Requisitos de Mercado/Producto de cien páginas.
  • Utilizar prototipos y experimentar. Presentar pronto y frecuentemente a los usuarios prototipos preliminares de diseño permite entender mejor el problema del cliente y elicitar requisitos. Posteriormente, el prototipo nos permite validar la utilidad, usabilidad  y deseabilidad del producto antes de pasar a su implementación. Finalmente, el prototipo es también la mejor manera de comunicar la experiencia de usuario y la funcionalidad a todo el equipo de producto.
  • Las metodologías ágiles (p.ej.: Scrum, XP) no tienen por qué ser enemigas del diseño, pero el diseño debe poder adaptarse a esa nueva forma de implementar los productos.
  • Lo más sencillo es mejor. Identificar el producto mínimo que cumple los objetivos y proporciona la experiencia de usuario deseada. Diseñar para el escenario del 80% de casos y no caer en la featuritis.
  • Prestar atención a los detalles. Como decía Steve Jobs el diseño consiste en “sudar todos los detalles”. No desdeñar los fallos de interfaz/interacción del producto como algo “cosmético” y no prioritario.
  • Ser valiente. Los buenos productos se diseñan diciendo “No”.

Muchas empresas siguen ancladas en unos procesos de desarrollo de productos que no ponen la experiencia de usuario en primer plano.  Antes o después sus clientes les harán saber que la vida es demasiado corta como para usar malos productos.

Este post en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

12 comentarios

Los productos tecnológicos para clientes empresariales son generalmente anodinos y difíciles de usar. El diseño bien entendido (no como un barniz estético a posteriori) puede aportar grandes posibilidades de diferenciación.

Toda mi carrera ha estado ligada a empresas tecnológicas y durante estos años muchas veces me he preguntado por qué los productos tecnológicos para clientes corporativos son habitualmente tan anodinos e innecesariamente difíciles de usar (cuando no francamente horribles).

Evidentemente, esta característica de los mercados B2B se puede achacar en parte a que se trata de productos complejos (y en muchos casos inmaduros) que implementan procesos o resuelven problemas de negocio inherentemente complicados, y esa complejidad se revela en su interacción con el usuario. Pero también tiene su parte de culpa el hecho de que en productos para empresas la experiencia de usuario generalmente no se considera como algo prioritario. Raramente es un criterio en la evaluación de productos y una vez que la decisión de compra se ha tomado a un nivel gerencial o ejecutivo, la utilización del producto simplemente es impuesta a los usuarios finales. Y si la experiencia de usuario no es una prioridad para el cliente es normal que tampoco lo sea para el proveedor.

Aunque en mercados B2C la situación no es exactamente la contraria debemos reconocer que el éxito de muchos productos de consumo (incluso los de base tecnológica) se puede atribuir en parte a que ofrecen a sus compradores/usuarios una mayor facilidad de uso y una estética superior. Y es que en productos donde usuario y comprador son la misma persona, antes de comprar el usuario no solo tiene que decidir si la funcionalidad es la correcta (utilidad) o si podría/sabría usar el producto (usabilidad), sino si querría usarlo (deseabilidad).

Radio de bolsillo Braun T3 (1958, diseño Dieter Rams)

Ciertamente en productos intrínsecamente más “sencillos” y dirigidos a un público general, donde es difícil (o poco aconsejable) distinguirse por una funcionalidad superior o más amplia, atributos como la usabilidad o la deseabilidad ofrecen grandes oportunidades de diferenciación. La consecuencia es que muchos productos de consumo parecen poseer una “personalidad” o un “alma” de la que carecen los productos corporativos. De modo que ¿cómo podemos insuflar alma a los -habitualmente áridos y complejos- productos para empresa?

Sin duda, uno de los componentes de esa alma -entendida como el significado o la esencia del producto- es su propósito o el objetivo que aspira a cumplir. Pero me atrevería a afirmar que el otro gran ingrediente de la esencia de un producto lo constituye su experiencia de uso y eso es el resultado de su diseño. El ejemplo que inmediatamente nos viene a la cabeza -en este caso en el campo de la informática de consumo- es el de Apple… aunque alguien con más memoria histórica podría sugerir los trabajos de Dieter Rams para Braun en los años sesenta.

Obviamente por “diseño” no nos referimos a esa acepción popular de “hacer que las cosas sean bonitas” o a algo que afecta únicamente a la superficie de las cosas y al aspecto que tienen. El diseño es una actividad mucho más amplia, que va del tradicional diseño industrial (estética, usabilidad, ergonomía, fabricabilidad) a las versiones más evolucionadas del diseño de productos que se aplican en los mercados de electrónica/informática y que le han dado un nuevo significado a la experiencia de usuario.

En el proceso de desarrollo de nuevos productos –y una vez que hemos detectado un problema/necesidad de mercado, validado y cuantificado la oportunidad y definido los requisitos de alto nivel– el diseño de producto crea una especificación de cómo nuestro producto debe resolver dicho problema de mercado. Y lo hace no solo desde el punto de vista de la funcionalidad a aportar, sino también de la experiencia de usuario a proporcionar. En futuros posts analizaremos las relaciones entre las funciones de gestión, diseño y construcción de productos.

El diseño no significa únicamente “deseabilidad” para mercados de consumo. El diseño especifica, expone y hace utilizable la funcionalidad del producto. Respondiendo a la pregunta que da título a este post, Steve Jobs llegó a decir en esta entrevista en Fortune que el “diseño es el alma fundamental de toda creación humana, que termina expresándose en los sucesivos niveles/capas exteriores del producto”. Según Jobs, el gran diseño surge de “sudar todos los detalles” de modo que cuando los usuarios interactúen con el producto su experiencia sea fácil y placentera. Y por “sudar” quiere decir entre otras cosas que las decisiones de diseño funcional y experiencia de usuario pueden tener un impacto enorme en la arquitectura y construcción del producto.

Resumiendo, el diseño permite no solo dar cuerpo, sino también insuflar alma a los productos para empresas y ofrece un enorme potencial de diferenciación. En otro post hablaremos del diseño de experiencias de usuario en el desarrollo de nuevos productos.

Este post en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

8 comentarios

Aun es pronto para saber si el Design Thinking se disolverá como tantas otras modas de gestión. Pero sin duda constituye un enfoque atractivo para aquellos que necesitan resolver problemas complejos y ambiguos en circunstancias de incertidumbre y volatilidad. En este post seguimos hablando (ver primera parte) de cómo los procesos y las técnicas del “pensamiento de diseño” nos ayudan a afrontar los retos del negocio:

  • El design thinking está orientado a la acción. Plantea un enfoque multidisciplinar para la toma de decisiones y la resolución de problemas basado en “aprender mientras se hace”. Una parte importante del Design Thinking es el Design Doing, que consiste en “remangarse y ensuciarse las manos” y probar cosas en lugar de convertirse en un “estratega de sillón”. Para el desarrollo de soluciones el design thinking aplica un proceso constructivo que es iterativo por naturaleza. En “Decisions by Design: Stop Deciding, Start Designing” Raney y Jacoby sostienen que cuanto más ambiguo y abstracto es el problema, el design thinking resulta más aplicable y produce decisiones más eficaces. La razón de fondo es que en un proceso “creativo” no aparece automáticamente un conjunto de opciones a analizar y entre las cuales escoger; por el contrario, el terreno de juego es más amplio y las posibilidades pueden parecer infinitas. Mediante la experimentación y la iteración los diseñadores alcanzan una comprensión más profunda de sus opciones: en realidad, la construcción, el prototipado y la prueba constituyen el propio proceso de toma de decisiones. A veces, construir más prototipos y formular menos estrategias sirve para aprender más rápido, invertir menos y tomar decisiones más informadas.
  • El design thinking integra elementos de imaginación y anticipación. Nos abre el futuro e invita a explorar las incertidumbres. En su esencia está la noción de razonamiento abductivo que -a diferencia de los razonamientos inductivo y deductivo- no busca tanto definir una verdad absoluta como explorar lo que podría ser verdad. Roger Martin (de la Rotman School of Management) lo define como sugerir que algo podría ser y ponerse a explorarlo.
  • El design thinking crea nuevos significados y construye vínculos emocionales. Es provocador por naturaleza y promueve nuevas formas de mirar los problemas, a menudo a través de nuevos prismas. (Como decía Marcel Proust, “le véritable voyage de découverte ne consiste pas à chercher de nouveaux paysages mais à avoir de nouveaux yeux”.) La creación de significados es la parte más difícil del proceso de diseño y las herramientas de comunicación que aplica el design thinking (mapas, modelos, historias) ayudan a capturar y a expresar la información que se requiere para formar y difundir significados. El buen diseño satisface tanto nuestras necesidades como nuestros deseos. Los productos de éxito nos atraen emocionalmente y funcionalmente. El design thinking aspira a cubrir nuestras expectativas de experiencias que nos satisfagan y tengan significado desde un punto de vista emocional.
  • El design thinking asume conscientemente los riesgos y los mitiga sistemáticamente. En el mundo del design thinking reconocer los riesgos es el primer paso para la acción, y con la acción vienen la comprensión, la evidencia y las opciones reales. Según Rodríguez y Jacoby en “Embracing Risk to Learn, Grow and Innovate” los diseñadores no ven el riesgo como algo estático, sino como un elemento dinámico, como una variable más de diseño: amplificar el riesgo es una manera de incrementar la cantidad de información que se recibe de experimentos y prototipos. Sin embargo, la frase “falla pronto y falla a menudo” no debería ser parte de los valores esenciales del design thinking. Aprender de los pequeños fallos tiene muchas ventajas, pero lo esencial es gestionar los riesgos. El design thinking combina de manera única una asunción consciente de riesgos con una mitigación estructurada de dichos riesgos, y para ello utiliza técnicas como la empatía y el prototipado.

En resumen, el design thinking explota capacidades que todos tenemos pero que  han venido siendo desdeñadas por otras prácticas más convencionales de gestión y de resolución de problemas. Aprovechémoslas.

Este post en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

3 comentarios

Algunas voces autorizadas llevan tiempo anunciando el final del Design Thinking  (con mayúscula) como el gran movimiento que iba a institucionalizar la creatividad y la panacea para solucionar los problemas de innovación en las empresas. ¿Qué deberíamos salvar de un eventual naufragio de esta corriente?

Dejemos a un lado por un momento la obvia constatación de que muchas de las técnicas y herramientas del “pensamiento de diseño”  (empatía, prototipado, multidisciplinariedad…) ya se aplicaban mucho antes de que naciera el término y forman parte del bagaje de la creatividad bien entendida. En los últimos meses son varios los expertos en diseño e innovación (algunos, apóstoles iniciales del Design Thinking) que  están poniendo en duda la capacidad de esta corriente para impulsar la innovación en las organizaciones:

  • Don Norman argumenta que si bien el diseño centrado en el usuario es valioso cuando se trata de mejorar categorías de productos existentes, es la tecnología la que genera innovaciones rompedoras (hablamos de ello aquí). Y mantiene que la especial creatividad de los diseñadores es poco más que un mito por demostrar pero del que se han beneficiado generosamente las empresas de diseño (lo comentamos aquí).
  • En “Design Driven Innovation” Roberto Verganti abunda en las carencias del diseño centrado en el usuario y en la importancia del cambio tecnológico para producir innovaciones radicales pero va más allá al proponer que las innovaciones rompedoras pueden provenir también de un cambio en el significado de las cosas/experiencias.
  • Bruce Nussbaum explica que el Design Thinking inicialmente se ofreció al mundo de los negocios como un nuevo proceso que prometía multiplicar la creatividad pero -tal como ha sido implantado en las corporaciones- no ha proporcionado más que una innovación incremental y su porcentaje de éxito ha sido muy bajo (hablamos  de ello aquí).

Fuente: Stanford School of Business Design Thinking Boot Camp

Yo prefiero ver el vaso medio lleno y pensar en cómo el design thinking (¿con minúsculas?) aporta un nuevo estilo a la gestión y al pensamiento estratégico y nos puede ayudar a resolver nuestros problemas en innovación y otros campos. En este y el siguiente post os presento algunas ideas, muy influidas por  los trabajos de Idris Mootee, CEO de Idea Couture (una de mis referencias en este tema y profesor en el curso sobre design thinking en la Harvard School of Design):

En la segunda parte del post seguiremos con este análisis, haciendo énfasis en un par de áreas que habían aparecido menos en el blog pero que son dos favoritas personales: la orientación a la acción y la gestión de riesgos.

Este post en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

6 comentarios

El “método científico” para la creación de modelos de negocio, basado en la validación mediante experimentos en el mercado, puede complementar a los enfoques centrados en el diseño y el análisis. Pero la generación y validación del modelo es solo el principio: después hay que construirlo.

Hace unas semanas, en la primera parte de este post, estuvimos hablando de cómo la creación de modelos de negocio está en auge como método de innovación y de un par de planteamientos “extremos” para concebirlos y generarlos: el enfoque del Arquitecto, basado en “planos” y análisis, y el enfoque del Diseñador, influido por el Design Thinking y basado en ideación, representaciones visuales y “prototipos”.

Sin embargo, como ya sabemos, ningún modelo que concibamos inicialmente para un nuevo negocio va a resistir el contacto con la realidad. Se hace necesario validar el modelo mediante incursiones controladas en el mercado antes de invertir en construirlo y llevarlo a la práctica. Y es aquí donde interviene el método científico.

El Científico y sus experimentos

La versión más formalizada y completa del “enfoque científico” para la creación de modelos de negocio es el Strategy Stack de Steve Blank y Alex Osterwalder, que integra dos herramientas/metodologías que han aparecido repetidamente en este blog: Customer Development y Business Model Canvas.

La idea básica es que el modelo de negocio que hemos visionado inicialmente no es más que un conjunto de suposiciones que hay que validar mediante experimentos en el mercado. Para ello el Strategy Stack utiliza el proceso de Customer Development como metodología de validación y Business Model Canvas como herramienta para describir el modelo de negocio, para estructurar las hipótesis/experimentos y como cuadro de mando para hacer un seguimiento del proceso de validación y de la evolución del modelo. Igual que en el método científico -en el que si los experimentos no corroboran las predicciones de una teoría esta debe ser refutada-  cuando la realidad del mercado no valida una o varias de las suposiciones del modelo de negocio este debe ser reelaborado o sustituido. Así el proceso va avanzando mediante iteraciones (“pivotando”) hasta que se llega a un modelo validado que hay que implementar y escalar.

Combinando los enfoques

En realidad, los tres enfoques “extremos” que hemos descrito (los del Arquitecto, el Diseñador y el Científico) tienen elementos positivos, y utilizar las herramientas adecuadas de cada uno de ellos en el momento oportuno nos puede ayudar a plantear mejores modelos y a reducir costes y riesgos. Lo habitual es combinar técnicas de estos tres planteamientos, en una mezcla de desarrollo top-down y bottom-up:

  1. En lugar de comenzar planteando un único concepto de nuestro modelo de negocio tentativo es muy valioso imaginar varias alternativas, cada una con su respectivo Business Model Canvas. Resulta útil considerar versiones radicales, escenarios extremos, etc. que ayuden a ampliar el “terreno de juego”, a entender el problema y a generar discusión.
  2. Utilizando técnicas sencillas de análisis y simulación (financieras, operativas, comerciales) podemos someter a esos modelos tentativos a unos “experimentos mentales” y pruebas de sensibilidad iniciales -recordemos nuestra idea del Plan Máximo Inviable- que nos permitan descartar algunas alternativas y centrarnos en la/s más prometedora/s. (Alex Osterwalder incluye los dos anteriores puntos en lo que denomina “prototipado de modelos de negocio”, pero tal vez la denominación es un poco exagerada teniendo en cuenta que estos “prototipos” no van mucho más allá de una conceptualización del negocio.)
  3. Finalmente, someteremos al modelo candidato (y a las hipótesis que recoge su Business Model Canvas) a una validación sobre el mercado real, y aplicando Customer Development lo iremos iterando para refinarlo.

¿Y cuando hayamos terminado las iteraciones y tengamos un modelo validado podemos decir que hemos terminado? Pues en realidad, no, porque un modelo validado únicamente es el fin… del principio.

Un modelo de negocio validado es solo el principio

No olvidemos que validar un modelo no es lo mismo que implementar un negocio. Si bien a veces es posible “hacer camino al andar” y construir mientras se va experimentando, lo normal es que aunque culminemos una validación con éxito no tengamos funcionando y ensambladas las piezas de nuestro modelo… por no mencionar que en este campo también se dan los “experimentos destructivos”.

De hecho -según la propia metodología de Customer Development- una vez que se ha validado el modelo y se ha construido un proceso de marketing y ventas replicable queda por delante la generación de demanda y la construcción de una organización más orientada a la ejecución (y menos al aprendizaje). Y en cierto modo este planteamiento está asumiendo un modelo de negocio relativamente innovador en el que lo más novedoso es el producto y donde los retos principales consisten en fabricarlo (y que funcione), conseguir que nos lo compren y construir nuestra empresa.

Sin embargo, para poner en marcha un modelo de negocio realmente nuevo habitualmente hay que  involucrar (y sacar de su statu quo) no solo a los clientes, sino también a distribuidores, partners, proveedores…  y a veces incluso estos agentes ni siquiera existen. Y en mercados con varias caras (productos plataforma) -donde cada lado significa un negocio diferente- este problema se multiplica por N. Sobre este asunto de la movilización inicial de los agentes y de la construcción / implementación de nuevos modelos de negocio nos hemos ocupado repetidamente en nuestro blog:

Espero que en los posts referenciados en los puntos anteriores encontréis pistas para construir y poner en funcionamiento vuestro nuevo modelo de negocio recién validado.

Finalmente, una pequeña digresión: estos símiles arquitectónicos sobre modelos de negocio me han hecho recordar la pasada burbuja inmobiliaria en España, cuando mucha gente invertía en viviendas que se compraban “sobre plano” sin que ni siquiera se hubiera  empezado a construir el edificio.  Ahora hay quien se pregunta si estamos ante una nueva burbuja tecnológica, con nuevos modelos de Negocios 2.0 brotando cada día… Y se me ha ocurrido que una pista para responder puede encontrarse en el comportamiento de los compradores: si sois inversores, business angels, etc. ¿estáis comprando estos negocios sobre plano?

Este post en “Marketing & Innovación”.

[Muchos nuevos productos y tecnologías disruptivas  fracasan porque no se los envuelve en un modelo de negocio que optimice la creación, entrega y captura de valor. Descubre en este documento cómo innovar en modelos de negocio.]

8 comentarios

La arquitectura/diseño de nuevos modelos de negocio es el trabajo de moda. Pero ¿realmente se puede generar un nuevo modelo de negocio aplicando métodos de trabajo análogos a los de un arquitecto o un diseñador?

Tengo algunos amigos americanos en cuya tarjeta profesional se lee el título “Business (Model) Architect”. Esta circunstancia y el renovado interés por la innovación en modelos de negocio que estamos viviendo me hacen temer que dentro de unos meses tendremos por estos lares una epidemia de “autocertificados” en esta especialidad.  Y también me lleva a preguntarme  si en este campo deberíamos hablar de “arquitectura” o más bien de “diseño” (o algún otro término).

Lo que sí parece claro es que este énfasis en el glamuroso mundo de la concepción de modelos de negocio nos está haciendo perder de vista aspectos más prosaicos como su implementación/puesta en marcha/construcción (¿para cuándo el puesto de Albañil de Modelos de Negocio? ;  - ).

De modo que en este y en un próximo post vamos a intentar abrir el diálogo sobre un par de preguntas: ¿Es el modelo de negocio algo que se puede plantear sobre el papel, como en un plano, para luego pasar a construirlo? ¿Cuál es la mejor manera de poner en marcha un nuevo modelo de negocio? En realidad, como veremos, son dos caras de la misma moneda.

Vamos a empezar presentando un par de enfoques “extremos” (y hasta cierto punto, irreales) de generación de nuevos modelos de negocio y en el siguiente post hablaremos de algunas nuevas prácticas que se van definiendo en este campo.

El Arquitecto y sus planos

Teóricamente es posible definir un nuevo modelo de negocio sobre el papel. En muchas ocasiones el proceso parte de analogías y datos acerca de negocios más o menos relacionados; en otras, la experiencia e intuición de un emprendedor visionario dan con un enfoque radicalmente nuevo. A partir de ahí, las técnicas habituales de análisis y simulación (o, en el caso de modelos complejos, herramientas más sofisticadas como la Teoría de Juegos) nos pueden ayudar a configurarlo y optimizarlo, tratando de asegurar su alineamiento con las metas de nuestra empresa, su consistencia, rentabilidad, escalabilidad, etc. En este enfoque top-down, el siguiente paso es implementar el modelo definido.

Sin embargo, ya sabemos lo que suele ocurrir con la primera versión de cualquier nuevo modelo de negocio. Como afirman  J. Mullins y R. Komisar en “Getting to Plan B: Breaking Through to a Better Business Model”, los planes/modelos concebidos inicialmente tienen una cosa en común: TODOS FALLAN. En modelos de negocio mínimamente nuevos y complejos (y, especialmente, en negocios con varias caras) el número de variables y decisiones, las incertidumbres, las interacciones internas y externas, las dinámicas competitivas… son tantas y tan imprevisibles que el enfoque de “pizarra y análisis” en general no va a funcionar.

Posiblemente el único caso de modelo de negocio (relativamente) innovador que puede formularse sobre el papel con ciertos visos de éxito es el que consiste en adaptar, ajustar -o copiar sin mayores miramientos- un negocio que ya esté funcionando en otro segmento/categoría de producto/geografía. Sin embargo, a la hora de llevar el “plano” a la práctica es cuando empiezan las dificultades: ¿Están presentes todos los participantes en el modelo: clientes, suministradores, partners…? ¿Van a querer participar? ¿Cómo mover el statu quo? En estos casos, es la ejecución -y sobre todo, cómo se reacciona cuando las cosas empiezan a ir mal- lo que marca las diferencias.

El Diseñador y sus prototipos

Desde hace algunos años, los practicantes del design thinking  se están postulando como expertos en la generación de nuevos modelos de negocio. Tal como ya hemos explicado en este post, este movimiento propone aplicar la mentalidad y las técnicas del diseño no solo para construir nuevos objetos y productos que sean funcionalmente eficaces y emocionalmente significativos, sino también para concebir nuevos negocios.

Autores como Roger Martin en “The Design of Business: Why Design Thinking is the Next Competitive Advantage” y su colega Heather Fraser en “Designing Business: New Models for Success” abogan por la comprensión profunda de los usuarios, la resolución creativa de tensiones, el prototipado colaborativo y la modificación y mejora continuas de ideas y soluciones como la base para diseñar productos y negocios, en un proceso iterativo de innovación que ya hemos descrito (y alguno de cuyos límites hemos identificado) en este blog.

Sin duda, todas esas técnicas son extraordinariamente útiles para diseñar modelos de negocio realmente nuevos, especialmente por su capacidad para generar nuevas alternativas (y no sólo para escoger entre opciones predefinidas). Tanto por su habilidad para producir nuevas visiones de lo que sería posible como por el uso de prototipos para ir refinando la solución, el design thinking nos puede ayudar a explorar los problemas de una forma creativa y a gestionar riesgos y constricciones.

Sin embargo, resulta evidente que este movimiento todavía no ha desarrollado su faceta de diseño de negocios tanto como la de productos (recordemos que un modelo de negocio es mucho más que el producto o servicio que se ofrece a los clientes). Cuando se diseña un modelo de negocio la comprensión debe ir más allá del usuario y alcanzar a todos los elementos del modelo. Y si bien el “pensamiento de diseño” ha producido una larga lista de productos y experiencias de usuario excepcionales, su historial en generación de negocios realmente nuevos es escaso. Aparentemente, el design thinking ha venido adoleciendo de una incompleta conceptualización y aplicabilidad en el campo de los modelos de negocio.

Y probablemente se debe a que, del mismo modo que el “pensamiento de diseño” aplicado a productos y servicios implica un foco en la deseabilidad y en el significado emocional (algo que contraviene la óptica de muchos gestores tradicionales), el diseño de modelos de negocio debe hacer énfasis en su rentabilidad, consistencia, sostenibilidad y escalabilidad (probablemente, algo ajeno a muchos diseñadores). Y es que -por expresarlo en términos un poco crudos- los modelos de negocio no tienen que ser bellos o “deseables”: tienen que ganar dinero.

La mentalidad y las técnicas del design thinking son útiles, pero en el campo de los modelos de negocio es necesario aplicarlas de otro modo. En esta línea, el “Business Model Generation” de A. Osterwalder e Y. Pigneur es un paso en la dirección correcta hacia la aplicación de una “actitud de diseño” en la generación de nuevos negocios, con su énfasis en la empatía, el storytelling, el pensamiento visual, los escenarios… y algo que los autores llaman (por seguir con la terminología del diseño) “prototipos de modelos de negocio”. Estos prototipos pueden tomar diversas formas: descripciones sobre el papel de modelos de negocio tentativos, simulaciones financieras de su funcionamiento, pruebas parciales del modelo sobre el mercado, etc.

En la segunda parte de este post hablaremos del “método científico” aplicado a la creación de modelos de negocio y de cómo combinar estas diversas filosofías para obtener mejores resultados.

Este post en “Marketing & Innovación”.

[Muchos nuevos productos y tecnologías disruptivas fracasan porque no se los envuelve en un modelo de negocio que optimice la creación, entrega y captura de valor. Descubre en este documento cómo innovar en modelos de negocio.]

14 comentarios
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 480 seguidores

%d personas les gusta esto: