Diseñar para la caída
Muchos productos digitales siguen pensándose para un escenario ideal: conexión estable, servidor…
Ahora que ya conoces la importancia de la empatía en el mundo del desarrollo de software, creo que es un buen momento para entender un poco más qué es EDD (Empathy-Driven Development) y cómo funciona.
En el artículo sobre 3 principios para la empatía y el desarrollo web vimos la definición de EDD. Dijimos algo más o menos así:
Definición de EDD
Empathy-Driven Development (EDD) o Desarrollo Guiado/Impulsado por Empatía es un enfoque para desarrollar software en el que los miembros de un equipo toman decisiones basadas en la empatía hacia los demás stakeholders.
¿Cómo funciona EDD?
Seguimos aprendiendo de Andrea Goulet, y nos adentramos a su framework avanzado que permite elevar tu empatía.
La primera característica interesante de EDD es que, como hemos dicho antes, es un framework, y a la mayoría de nosotros nos gustan los frameworks. En el Desarrollo Guiado por Empatía de Andrea se desglosa un “modelo procedimental de empatía cognitiva, creando una especie de algoritmo que los equipos pueden integrar en su flujo de trabajo.”
Por tanto, si conoces TDD (Test-Driven Development), sabes que se puede describir como “rojo, verde, y refactor”, EDD se describiría como “audiencia y acción”, por ello, para que tenga más probabilidades de funcionar, Andrea dice que primero debes “considerar tu audiencia, las personas que interactuarán con tu contenido, incluyendo tu código y los artefactos de comunicación. Después, actúa.”
Parece sencillo, ¿verdad? La idea es “pensar cómo puedes anticipar sus necesidades de forma proactiva.”
Ejemplo práctico para el EDD
Andrea nos proporciona un ejemplo práctico para entender el framework, y tener una idea de cómo funciona: “Imagínate que tu tarea es escribir un mensaje de error para una aplicación de contabilidad. ¿Cómo puedes aplicar empatía en esta situación?”. El objetivo pasa por dejar un artefacto de comunicación primario, en este caso el mensaje de error para tu audiencia.
Siguiendo el framework, tendrás la siguiente situación:
Considerando la audiencia:
- Identifica a los individuos. “Haz una lista de las personas que crees que encontrarán tu producto, además del usuario final. Lo más probable es que tu audiencia sea diversa.” Según Andrea, “en este ejemplo, tu audiencia puede incluir un usuario que es un artista independiente, o tu yo futuro.”
- Considera el contexto. Andrea cree que después de identificar las personas, debes “Pensar de dónde vienen y dónde están ahora”. “El artista usa una aplicación en su teléfono; tu yo futuro está leyendo tu propio código mientras corrige un error, seis meses después.”
- Define sus necesidades. Finalmente, Andrea propone que consideres los desafíos y las necesidades de cada individuo, ya que “los puntos débiles no siempre son evidentes. Haz preguntas, lee artículos — haz todo lo que puedas para averiguar sobre ellos.” ¿Qué necesita una persona que usa la aplicación? ¿Qué necesitará tu yo futuro?
Actuando:
- ¿Cuál es la mejor acción a tomar? Andrea dice también que “así que has reunido información valiosa sobre tu audiencia. Utiliza ese nuevo conocimiento para pensar en lo que se puede hacer para ayudar. Quieres validar la frustración del usuario con el mensaje de error. Para tu yo futuro, es posible que desees corregir todos los errores ahora mismo”.
- ¿Qué es factible? “No siempre estarás en condiciones de hacer lo mejor para ayudar, así que considera lo que realmente puedes hacer. ¿Qué tiempo y recursos tienes para ejecutar, para mejorar un poco sus vidas? Casi siempre hay algo que puedes hacer. Piensa pequeño y atómico. Incluso las acciones más pequeñas suman”, según Adrea.
- Crea artefactos secundarios. Andrea dice que “Una vez hayas creado tu artefacto de comunicación principal — un gran y claro mensaje de error — tu trabajo no ha terminado. Incluye artefactos secundarios en tu definición de terminado”. “Los artefactos secundarios son una evidencia duradera de tus ideas, fundamentos y limitaciones que han surgido mientras trabajabas en el artefacto principal, y pueden tomar muchas formas”. “Hay muchos lugares donde existe el lenguaje natural en un sistema de software.” Para Andrea “no se trata de una documentación pesada. Se trata de hacer lo que ya haces con más intención.”
Conclusión
La práctica hace al maestro, por tanto “con tiempo y práctica suficiente” los pasos recomendados por Andrea te serán intuitivos. El proceso puede ser lento y pesado al principio, pero Andrea te anima a seguir.
Lo mismo pasa con TDD o BDD, y puedes pensar que dejar “artefactos de comunicación no es importante, o no hay tiempo. Pero muchos artefactos necesitan solamente treinta segundos extra, unos minutos como máximo, para completar un pensamiento para un futuro lector. Las ganancias marginales que logras al dejar regularmente los artefactos de comunicación terminan superando con creces la inversión de tiempo a corto plazo.”
¿Qué te parece? Te animo a seguir leyendo la entrevista de Andrea Goulet en First Round y a visitar también el sitio web de CorgiBytes para saber más sobre el Desarrollo Impulsado por Empatía.
¿Has implementado EDD con tus equipos de desarrollo de software? ¿Qué tal la experiencia? ¡Coméntalo abajo!
Hazte miembro
Recibe las últimas novedades directamente en tu correo. Sin spam.
Fuentes:
Comentarios