0

6 problemas típicos en proyectos UX – Parte 1: Feature Creep, por Sergio Nouvel

En los años que llevamos en Continuum desarrollando proyectos de experiencia de usuario para una amplia variedad de clientes y necesidades, es imposible no notar algunos patrones comunes en la manera en que dichos proyectos evolucionan, sin importar el tamaño del proyecto, del equipo, de la empresa o incluso el tiempo y el presupuesto disponibles.

Con el tiempo, hemos aprendido a lidiar con ellos, con algunos de mejor manera que con otros. Probablemente el lector los reconozca también en su propia realidad. Hemos preparado una serie de 6 posts, cada uno identificando un problema en particular y algunas estrategias que hemos desarrollado para evitarlo o solucionarlo:

    1. Feature Creep
    2. Deadline Creep
    3. Productos que no le sirven a nadie
    4. Mala investigación
    5. Brecha entre diseño y desarrollo
    6. Waterfall UX

En este post en particular hablaremos de Feature Creep; una expresión difícil de traducir al español, pero que hace referencia al acto en el que las cosas se inflan o expanden sin control.

Feature Creep, o la ansiedad por tener más que el vecino

Es fácil identificar el feature creep en un producto: son esos “barriles sin fondo” donde la intención de satisfacer absolutamente todos los casos de uso posibles termina con productos atestados de funcionalidades, servicios y opciones.

Es un problema bastante común y tiene varios causantes: demasiados stakeholderscon similares posiciones de poder intentan inyectarle al proyecto su propia visión; inseguridad y miedo de ser el “rival más débil”; falta de priorización y el “diseño por comité”, que intenta buscar el consenso dándoles a todos la razón.

El resultado del feature creep son productos complicados, ambiguos, excesivamente ambiciosos y glotones, que intentan ser todo para todos. El razonamiento de fondo es que “si está en el producto, los usuarios lo encontrarán”. Pero si esto fuera cierto, sería tan simple como hacer mejores productos metiéndole más funcionalidades (y así, de hecho, fue la manera en la que Microsoft Office se convirtió en el mastodonte que es hoy).

En cambio, cuando las limitaciones y el desinterés de nuestros usuarios están presentes en el equipo, sientes la dolorosa necesidad de priorizar y simplfiicar. Google Docs entendió esto, y básicamente ofrecen menos funcionalidad que Office, pero con dos combos ganadores: el precio (gratis) y la edición en tiempo real. Así es como Google Docs se convirtió en la primera amenaza real que Office ha enfrentado en dos décadas.

Combatiendo el feature creep

¿Cómo vences la inseguridad de un equipo que siente que necesita una carrera armamentista para competir en el mercado? Conectándolo directamente con las necesidades de los usuarios. El golpe inicial de este feedback es doloroso, porque sin importar la experiencia y el conocimiento del negocio del equipo, los puntos ciegos (necesidades insatisfechas, suposiciones infundadas, estrategias erróneas) surgen de inmediato.

Pero la siguiente sensación es refrescante: el contacto continuo con los usuarios comienza a traer una nueva seguridad, basada en la evidencia y en el ensayo/error. Desarrollar la empatía con los usuarios y sus necesidades hace que priorizar sea fácil: cuando entiendes dónde les aprieta el zapato, las discusiones teóricas muestran rápidamente su irrelevancia.

Minimizar

Una segunda estrategia, que complementa la anterior, consiste en enfocar el trabajo hacia un producto mínimo viable. Cuando el equipo tiene como meta lanzar — y lanzar pronto —, las conversaciones se orientan hacia priorizar y ser pragmáticos. Ahora bien, el dilema que inmediatamente surge es: ¿qué tan mínimo tiene que ser el producto? ¿Y si nos excedemos y terminamos sacando al mercado un producto demasiado pobre? ¿Y si terminamos lanzando el set equivocado de funcionalidades?

¿Cómo sabemos?

Prototipa la historia

Una buena técnica es prototipar la historia de tus usuarios en relación al producto. Hay varias maneras de hacerlo: en forma de cómic, representación con títeres, radioteatro o role playing, entre otras.

Una vez que el equipo escogió una forma de contar la historia, hay cuatro cosas de las que preocuparse:

  • Contexto: Sitúa al usuario en medio de su realidad, en el lugar y momento en el que ocurrirá el problema.
  • Problema: Retrata el dolor del usuario.
  • Solución: Sitúa la idea del producto en acción, resolviendo el problema.
  • Desenlace feliz: Muestra el efecto posterior del producto y cómo el contexto ha mejorado gracias a éste.

Ejemplo del prototipado de una historia.

Este ejercicio por sí solo tiene el poder de mostrar qué es lo prioritario en nuestro producto, precisamente gracias a que lo muestra en el contexto de los usuarios y sus problemas. También es útil para probar diferentes soluciones o distintas estrategias, aunque en nuestra experiencia suele ser el mismo contexto el que te insinúa la solución.

***

Combatir el feature creep priorizando y reconectando al equipo con los usuarios finales aliviana notablemente los proyectos y los flujos de trabajo. Sin importar qué tan “clara y definida” parezca estar la estrategia, siempre hay espacio para afilar un poco más la propuesta de valor y asegurarse de que el beneficio del producto llegue de manera cristalina a quienes lo necesitan.


Post original de Sergio Nouvel (@sesho) en el blog de Continuum, que nos ha permitido reproducirlo aquí.


Tags:
Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /web/htdocs/www.uxinperu.com/home/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273