Archivos de la categoría Desarrollo de Producto

Un demo te ahorra o te compra problemas

Para un desarrollador de software es sencillo comprender por qué un proyecto se puede complicar. Entendemos las implicaciones y complejidades de desarrollar soluciones.

En una empresa tradicional, para bien o para mal, las personas que terminan tomando decisiones no siempre tienen el mismo nivel de entendimiento.

Tener el hábito de hacer demostraciones, demos, de tu trabajo ayuda a achicar esta brecha de entendimiento.

Un demo tiene el potencial de comprarte o ahorrarte problemas. Si del demo salen con más preguntas que respuestas, te compraste problemas. Si salen inspirados, con más ideas, te ahorraste problemas.

Es por eso que es importante que tomes los demos con seriedad. Porque a final de cuentas, desde un estricto punto de vista de negocio: si algo no funciona no sirve, y si algo no sirve, ¿para qué lo quiero? Un buen demo es tu oportunidad de evitar que alguien con poder de decisión a nivel negocio se haga esta pregunta.

Por qué deberías invertir en features que deleiten a tus usuarios

Si eres uno de los millones de usuarios de Spotify, seguro compartiste tu Wrapped la semana pasada. Si no fue en tus redes sociales, por lo menos lo comparaste con los de tus amigos y conocidos que sí lo hicieron.

Desarrollar productos que no solamente sean útiles para tus usuarios, sino que también los deleiten, no es tarea fácil. Ni es barato. Para Wrapped, muchísimos equipos dentro de Spotify comienzan a trabajar con meses de antelación. Marketing, datos, ingeniería, diseño — todos trabajando en conjunto para poder ofrecer, al fin de año, lo que muchas personas de la industria considerarían como algo sin valor real: una “simple visualización” de datos.

Las compañías que conocen la importancia de agregar valor a sus usuarios, y crean productos que son mucho más que simples utilidades, son las que terminan ganando. Y no solamente en números brutos, sino en la percepción del público y en el lugar que ocupan en nuestras cabezas.

Una empresa que no reconociera la importancia de ofrecer algo más que una simple utilidad, difícilmente invertiría en una iniciativa como Wrapped. Afortunadamente, Spotify no es esa empresa, y cada año cimientan aún más su valía en la mente de sus usuarios, dejándolos ser parte de una conversación global. Además, virtualmente gratis, reciben una campaña de marketing de primera calidad impulsada por sus mismos usuarios.

Y es así como, un diciembre más, contemplo seriamente la idea de dejar de usar Apple Music para volver a Spotify.

Los mejores Product Managers tienen las peores ideas

Lane Wagner, en qvault.io:

De acuerdo con failory, la razón #1 por la que fallan los startups es porque nunca encontraron product-market fit. 34 % de los emprendimientos fallidos son un resultado de no haber identificardo el problema correcto a resolver. Las segunda y tercera razón, marketing y problemas de administración del personal, representan el 22 % y 18 %, respectivamente.

En otras palabras, en 34 % de los startups que fallan, los Product Managers fallaron en

  • identificar un problema crítico de sus usuarios
  • y diseñar un producto que lo arregle

Si bien el rol de Product Manager existe porque no se puede esperar que todo mundo tenga visión de producto, eso no significa que ellos son los únicos que pueden aportar a la evolución y dirección del mismo. Y es ahí donde todos tenemos que poner de nuestra parte: los contribuidores individuales (diseñadores, programadores, etc.) aportando sus ideas basadas en la construcción del día a día del producto, y los Product Managers tomando esas ideas y convirtiéndolas en hipótesis comprobables.

Lane menciona:

En mi experiencia, las ideas basadas en asunciones que vienen de gente de producto, rara vez son mucho mejores que las que vienen de ingenieros. La diferencia es que un buen Product Manager tiene una necesidad imparable de validar o recahzar cada idea que llega a su cabeza.

De acuerdo.

Creo que el rol del Product Manager no es dictar hacia donde debería de ir el producto, sino funcionar como un catalizador de ideas — moldearlas en hipótesis y validarlas en función de la misión y visión que guían la construcción del producto.

Agregando una opción de ”ninguna de las anteriores” a formularios

El Gobierno de Reino Unido publicó una guía de diseño para agregar “ninguna de las anteriores”  como opción a las formas que usen checkboxes en sitios oficiales.

The ‘Register your trailer to take it abroad’ service on GOV.UK on a laptop

Frankie Roberto explica por qué en el blog de diseño:

A veces, está bien contestar uan pregunta dejando todas los checkboxes vacíos. Sin embargo, algunos equipos en el gobierno han encontrado algunos problemas con esto.

Observaron que:

  • los usuarios podrían estar inseguros si pueden hacer esto — lo cual puede resolverse usando elementos de guía, pero no todos los usuarios los van a ver
  • algunas veces, los usuarios quieren dar una respuesta concreta, especialmente si les preocupa contestar las preguntas con confianza y con la verdad
  • dejar los checkboxes desmarcados significa que los usuarios podrían pasar la pregunta por accidente, tal vez pensando que podrían regresar a ella después

Tengo varios comentarios respecto a esto.

Primero, el hecho de que el Gobierno de Reino Unido tenga un blog dedicado a compartir notas de diseño para sus sistemas internos me voló la cabeza.

Segundo, todos podemos aprender de su razonamiento para resolver este tipo de problemas. Cuando se trata de sistemas internos, o en este caso, de gobierno, los que los producimos debemos de tener en cuenta que el 90 % de las veces, las personas que los van a utilizar quisieran no tener que hacerlo. ¿Cuándo fue la última vez que te dio gusto emplear un sistema de gobierno? Aquí, claramente están poniendo como prioridad crear soluciones que realmente le ayuden a su usuario a reducir su carga cognitiva y, por ende, ayudarles a hacer lo que quieren hacer de una manera más confiable.

Un programador podría argumentar, lógicamente, que la ausencia de un valor podría considerarse como una opción válida. Después de todo, no contestar es, en sí mismo, una respuesta. Por otro lado, el usuario argumenta que un no es en sí también una respuesta explícita, y debería de poder usarla.

Qué bueno que ganó la empatía por el usuario, y no los tecnicismos.

La barra de progreso de Gmail no es real: ¿por qué?

En smitop:

Un poco de investigación revela que la barra de carga de Gmail no es una barra de carga en absoluto! De hecho, el progreso que se muestra es controlado por una animación de CSS que hace que inicie lento, y luego se quede quieta hasta que Gmail termina de cargar. Esto vence el propósito de una barra de carga: dar un estimado del progreso, no llenarse de manera arbitraria.

Este tipo de problemas es donde muchos programadores pueden “meter el pie”. El impulso inicial de las personas técnicas es hacer las cosas técnicamente correctas, aunque no agreguen tanto valor al producto final o aporten a mejorar la experiencia del usuario.

Tomando en cuenta el caso de uso más obvio de una barra de progreso, comunicar progreso, ¿qué debería hacer Gmail para ofrecer información técnicamente correcta? Sin lujo de detalle, y vagamente en el orden adecuado:

  1. Analizar la velocidad de conexión actual
  2. Analizar el tamaño del bundle de JavaScript que hay que cargar desde el servidor
  3. Hacer un cálculo de la transferencia de los datos de manera continua, tomando en cuenta fluctuaciones en la velocidad de la conexión.

Suena relativamente sencillo; son pocos pasos. Pero toma en cuenta a) la escala a la que opera Gmail, y b) el objetivo real de presentar una barra de navegación, que es darle seguridad a tu usuario de que estás haciendo algo. Considera las implicaciones de hacer un cambio “sencillo” a la escala de Google. Además, la idea de que realmente lo que importa es la experiencia de usuario, y no necesariamente la exactitud de la barra del progreso. Te das cuenta de que implementar una barra de progreso que muestre información técnicamente correcta, realmente no vale la pena.

Por si no te habías dado cuenta, muchas de las barras de carga que encuentras en tu día a día son completamente falsas. Hoy en día, los sistemas son tan complejos, impredecibles y con tanta entropía, que hacer una barra de carga que muestre progreso requeriría una inversión de tiempo que muy pronto deja de ser rentable para el producto.