Por qué lanzamos Residence, nuestro programa especial para Startups

TL;DR: Lanzamos Residence porque nos apasiona trabajar con startups. Y el modelo típico, en que nos contratas para hacer un cierto desarrollo acotado y/o por un valor hora determinado, no funciona bien. Hay excepciones, pero creemos que para la mayoría de las startups, podemos ofrecer algo mucho mejor. Y eso es Residence. Postula acá para ser la startup seleccionada de esta generación.

Para entender mejor por qué Residence es genial, empecemos con las razones de por qué el modelo típico no funciona. En general estamos hablando de una startup que aún no tiene formado su propio equipo técnico.

Mala idea #1: Mandar a hacer un MVP en base a features

Ya hablamos de este error hace unos años:

Muchas startups llegan a nosotros y parten de la misma forma que la industria tradicional: Con un “request for proposal” o equivalente, que describe (en mayor o menor detalle) tooodo lo que quieren que diseñemos y construyamos.

Lo que es pésima idea, porque:

Por muy buena que sea la visión inicial de una startup, lo primero que hay que hacer es transformar el cerro de hipótesis y suposiciones iniciales en conocimiento y aprendizaje validado. Y construir un MVP es el medio para llegar allí, no el fin en sí mismo. Lamentablemente muchas startups deciden hacer un MVP “big-bang”, que toma un par de meses en desarrollarse y donde se ponen a prueba una docena de hipótesis de una sola vez. En vez de probar hipótesis de a poco, se opta por “construir la app y ver qué pasa”

El consejo acá es que una startup debe preocuparse de cuánto aprendizaje acumula y no de cuántas features se desarrollan. Lamentablemente, no es un consejo fácil de seguir. Es infinitamente más fácil cotizar “desarróllame una app que haga X, Y y Z” que “validemos si mis supuestos son ciertos”. En general, ni el emprendedor ni las empresas de desarrollo saben como resolver lo segundo.

Mala idea #2: Tener tu core tecnológico fuera de tu startup

Supongamos por un momento que resuelves el punto anterior (De hecho en Continuum hemos desarrollado metodologías como Lean UX y herramientas como el Scope Canvas para eso). Igual es mala idea que incluso Continuum sea el encargado de tu core tecnológico. En parte, porque es uno de tus activos más preciados, si lo que tienes es una startup tecnológica. Y también porque las startups tienen un ritmo que simplemente no encaja con la dinámica de una consultora. ¿Acabas de cerrar un nuevo e importante cliente pero tienes que implementar un cambio antes del 1 de Marzo y estás a mediados de febrero?

— “Aló PartnerTecnológico, hagamos este cambio, cuando partimos y cuanto me cuesta”

— “Hola EstimadoClienteStartup. Por supuesto. Tenemos disponibilidad para empezar en 3 semanas más”.

— “Uhm, la verdad necesito esto terminado para 2 semanas más”,

— “Claro. Podríamos reasignar gente que está trabajando en otro proyecto o que está libre. Pero vamos a tener que explicarles todo el contexto porque no tienen idea de tu negocio, ni de la solución tecnológica que implementamos hace algunos meses.”

Ugh.

Resumiendo: No quieres correr una maratón conectado a un balón de oxígeno externo. Por bueno que sea el balón de oxígeno, es preferible que uses y desarrolles tus propios pulmones.

Mala idea #3: Acortar tu pista de despegue (‘runway‘)

De nuevo, supongamos que el punto anterior no es problema. En Continuum aún no encontramos como resolverlo, pero tal vez hay alguna fórmula. Como sea, tu buen PartnerTecnológico te cobrará precios de mercado para buena calidad y velocidad (porque, si tiene un buen equipo y con lo escaso que es el talento, sus desarrolladores y diseñadores también estarán cobrando sueldos de mercado). Digamos que tuviste suerte y encontraste un buen partner por 45 USD/hora. Y digamos que te ganaste un Startup Chile y dedicas dos tercios del presupuesto (es decir, unos USD 20.000) en diseño y desarrollo de tu tecnología

20.000[USD] / 45[USD/hora] = 444 horas.

Esas son aproximadamente 11 semanas. Tu pista de despegue para conseguir que tu producto vuele ha sido reducida dramáticamente a menos de 3 meses.

Residence al rescate

Diseñamos Residence para resolver estos problemas:

Tan pronto inicia el programa, hacemos el mismo proceso de Lean UX contigo que el que ofrecemos a nuestros clientes. El mismo que hemos aplicado como partners de Wayra, en forma abreviada en talleres para S-Factory, o con startups reconocidas de la talla de ArchDaily. Le daremos claridad y prioridad a tus hipótesis y las validaremos lo mejor posible antes de escribir una sola línea de código. Luego nos tendrás literalmente al lado para acompañarte en mejoras y re-diseños por los 6 meses que estés con nosotros. Y más que obsesionarnos inmediatamente con el crecimiento, la masividad y salir en la prensa, partiremos por ver qué estamos haciendo, por qué y para quién.

In the first few weeks of a startup’s life, the founders really need to figure out what they’re doing and why.  Then they need to build a product some users really love.  Only after that they should focus on growth above all else.

A startup that prematurely targets a growth goal often ends up making a nebulous product that some users sort of like and papering over this with ‘growth hacking’.  That sort of works—at least, it will fool investors for awhile until they start digging into retention numbers—but eventually the music stops.

I think the right initial metric is “do any users love our product so much they spontaneously tell other people to use it?”  Until that’s a “yes”, founders are generally better off focusing on this instead of a growth target.

— Sam Altman, YCombinator partner: “Before Growth”

En realidad no se trata sólo de construir un producto en 6 meses. Se trata también de construir un equipo y una cultura de ingeniería y de producto que tenga la capacidad de construir, pivotar, rediseñar, mantener, soportar y escalar. Las bases de ese equipo, de esa cultura, se forman en las primeras semanas o meses de vida de tu startup. Nosotros te ayudamos a encontrar a tu equipo (como mínimo un desarrollador, que se proyecte para cumplir el rol de CTO a futuro). Le contagiamos a tu equipo, de primera fuente, la cultura que en Continuum nos preciamos de tener y que se refleja en nuestro trabajo y en la satisfacción de nuestros clientes. Tu equipo estará rodeado de expertos en iOS, Android, Rails, Java, front-end, IoT, UX, etc, etc, etc. Pero más importante: de excelentes personas.

Why is culture so important to a business? Here is a simple way to frame it. The stronger the culture, the less corporate process a company needs. When the culture is strong, you can trust everyone to do the right thing. People can be independent and autonomous. They can be entrepreneurial. And if we have a company that is entrepreneurial in spirit, we will be able to take our next “(wo)man on the moon” leap. Ever notice how families or tribes don’t require much process? That is because there is such a strong trust and culture that it supersedes any process. In organizations (or even in a society) where culture is weak, you need an abundance of heavy, precise rules and processes.

— Brian Chesky, co-founder AirBnB: “Don’t Fuck Up The Culture”

Y sobre el runway, la única manera de no acortarla es no pedirte tu escaso cash a cambio de nuestro apoyo. Si bien sueldo de tu equipo residente y tu infraestructura tecnológica la tienes que costear tú, calculamos que muchas startups pueden funcionar por los 6 meses de residencia con USD 20.000. ¿Te acuerdas cuanto runway calculamos más arriba para 20K? 11 semanas. Acá tienes para 6 meses.

Nuestro apoyo (recruiting, Lean UX, residencia dentro de la oficina de Continuum, apoyo del equipo) lo valoramos en USD 30.000, pero en lugar de cobrártelo te pedimos una nota convertible que nos convertirá en tus socios minoritarios en tu siguiente ronda de inversión. Aún estamos afinando los detalles sobre dicha nota (son comunes en EEUU, pero no tanto en Latam) pero la esencia es que queremos tener una participación menor en varias startups con gran potencial.

¿Track record?

Es cierto que recién estamos lanzando abiertamente el programa. Aún así tenemos un track record:

  • GetOnBoard es el prototipo interno y orgánico de este programa, compuesto de miembros del propio equipo de Continuum. Líder en su nicho, GetOnBoard ha generado en ingresos más de lo que se consigue en el fondo público promedio y ha crecido sustentablemente durante años.  Y ha sido cash-flow positive desde el fin de su residencia.
  • Haus, la solución de seguridad vecinal fue nuestro primer prototipo de Residence el año 2015 (hay que practicar lo que se predica, y Residence tenía supuestos que había que validar). Hoy Haus tiene comunidades activas en Chile, México, Brasil, Colombia, Perú, Uruguay y Argentina. Ha sido destacado en diversos medios de prensa nacional. Como resultado de la residencia levantó más de USD 100.000 entre fondos públicos y privados y su equipo ya incluye dos desarrolladores y una diseñadora UX. Además, el desarrollador inicial reclutado por Continuum cumplió y superó todas las expectativas, convirtiéndose en el CTO de Haus.

A Continuum llegamos con un PowerPoint y hoy nos vamos como un Emprendimiento competitivo. Lo recomiendo a ojos cerrados

— Andres Gallardo, CEO de Haus

¡Postula!

Buscamos a los mejores founders que aún no hayan formado su equipo tecnológico. Con ideas y proyectos ambiciosos, de alcance mundial o cuando menos latinoamericano. Que sepan que las ideas son sólo un multiplicador y que la ejecución vale millones de dólares y estén dispuestos a jugársela en su ejecución. Que se encarguen desde el día 1 de levantar fondos, desarrollar el negocio, y desarrollar sus clientes, porque son parte clave de la vida de su startup.

Fuera de eso, no hay reglas. ¿Te animas?

Se da inicio a la temporada de Charlas 2015

Como todos saben, en Continuum no sólo nos dedicamos a tomar cerveza desarrollar y diseñar pensando en el usuario, además compartimos conocimiento. Por eso, algunas de nuestras mentes más brillantes participarán como charlistas de los eventos que se vienen para el último trimestre del 2015. Así que si algo te ha sonado el Latinity o estás esperando la StarTechConf (no olvides comprar tu entrada), presta atención para que no te pierdas nada.

Taller “Innovación de Guerrilla” por Sergio Nouvel.

Fecha y hora: 29 de septiembre, 11 AM (GMT-5).
Lugar: Pontificia Universidad Católica del Perú (Lima).

¿De qué va?
¿Cómo logran pequeñas startups sacudir el negocio de gigantes en una industria con innovaciones radicales e inesperadas? Innovar no tiene por qué ser costoso. Al contrario: las restricciones de tiempo y dinero hacen aparecer mejores ideas. La espontaneidad y la tolerancia al caos estimulan mucho más la innovación que procesos complejos o conceptos rimbombantes.
En este taller, Sergio entregará lineamientos, herramientas y trucos sencillos, basados en su experiencia directa como fundador de startups y como consultor de empresas, para despertar el hambre de innovación en cualquier organización.
¿Por qué es imperdible?
Si eres alguien interesado en estimular la innovación en tu organización, tendrás ejemplos y trucos basados en experiencias directas (no-bullshit conceptual) para poder aplicar en forma efectiva.

Charla “Scope Canvas: Cómo empezar un proyecto de UX” por Sergio Nouvel.

Fecha y hora: Por definir (6 o 7 de noviembre).
Lugar: StarTechConf (USM, sede San Joaquín).

¿De qué va?
¿Cómo empiezas un proyecto de UX y reduces la brecha que separa a tu equipo entre la idea y una experiencia impecable? Scope Canvas es la herramienta que hemos diseñado en Continuum para darle impulso a los proyectos de Lean UX, con énfasis en tender el puente entre las necesidades de negocio y los objetivos de usuario.
En la charla, Sergio contará cómo hemos usado Scope Canvas para proyectos y entornos de trabajo muy diversos, desde startups hasta empresas consolidadas, pasando por ONG’s e intra-emprendimientos.

¿Por qué es imperdible?
¿Quieres comenzar a llevar a tu equipo hacia el sendero de la UX? ¿Necesitas manejar mejor los proyectos UX con tus clientes?, esta charla te ayudará a visualizar los típicos problemas de empezar un proyecto centrado en el usuario y cómo salvarlo usando Scope Canvas.

Charla “Polígrafo: Estudiando el consumo energético de apps” por Rodrigo Araya.

Fecha y hora: Por definir (6 o 7 de noviembre).
Lugar: StarTechConf (USM, sede San Joaquín).

¿De qué va?
Rodrigo nos mostrará el comportamiento de los smartphones desde el punto de vista de consumo energético bajo los distintos escenarios que día a día enfrentan sufren nuestros dispositivos con las aplicaciones. Además, nos recomendará las claves de un desarrollo optimizado para disminuir el gasto de energía en smartphones.

¿Por qué es imperdible?
El impacto energético de las aplicaciones, dentro de los dispositivos móviles, es un tema que estuvo olvidado por bastante tiempo.  En el último año, los desarrolladores de sistemas operativos (Apple y Google) han agregado herramientas para obtener de forma imprecisa y aproximada el consumo que posee las aplicaciones instaladas dentro del teléfono.  Lo que verán en esta presentación es el resultado de un experimento que se convirtió en un estudio, analizando el consumo energético directamente desde el hardware del dispositivo, modificando el teléfono para lograr utilizar un “Polígrafo”, midiendo verdaderamente el consumo energético con un Multímetro.

😮

Charla “Coordinador de Servicios” por Liliana Reyes y Carolina Rojas (de nuestro cliente, Previred).

Fecha y hora: Por definir (9 o 10 de noviembre).
Lugar: Latinity (Universidad Mayor, campus Manuel Mont).

¿De qué va?
Liliana y Carolina nos contarán cómo la superintendencia de AFP al lanzar la normativa NCG-115 generó el gran desafío: Que un cotizante pueda cambiarse de una AFP a otra a través del portal web de la AFP destino.
Para poner en práctica el proyecto, cada AFP debía crear una aplicación web a exponer en su portal, la cual debía consultar a las otras por la información del trabajador que está intentando su traspaso. El coordinador de servicios de Previred consolida la información y la entrega como una única respuesta para la AFP de destino.

¿Por qué es imperdible?
Un desafío técnico importante, la puesta en práctica patrones de diseño de Arquitecturas orientadas a servicios y un gran desafío en la gestión: ¿Cómo coordinar y poner de acuerdo a los comités de 6 AFP? ¿Cómo trabajar y colaborar activamente con tu proveedor, para que éste no sea “uno” de los cuellos de botella?
Durante la ejecución del proyecto, pusimos en práctica metodologías ágiles de desarrollo y gestión, logrando que PreviRed y Continuum funcionaran como un sólo equipo y no existiera brecha entre proveedor-cliente (nivel: “Daremos una charla juntos”) . Tenemos anécdotas y tips dignos de compartir.

Bikeshedding y Branding — Parte 1: De Plantas Nucleares y Cobertizos de Bicicletas

¿Qué pueden tener que ver una planta nuclear y un cobertizo de bicicletas con la toma de decisiones de tu organización y la forma de diseñar tu marca?

¡Muchísimo! En esta serie de posts voy a comentarles como un insight formulado el 1957 explica mucha de la confusión y frustración que suele ocurrir cuando te enfrentas al desafío de diseñar tu marca (y muchas otras decisiones complejas, por cierto).

Partamos entonces por esta historia de plantas nucleares y cobertizos de bicicletas.

Cyril Northcote Parkinson era un marino e historiador, pero la mayor parte de su fama viene de su Ley de Parkinson, surgida de los estudios que hizo mirando la práctica de la gestión y toma de decisiones en organizaciones. Pues bien, hay otra ley más importante descubierta por Parkinson en esa época, mientras estudiaba la toma de decisiones del comité encargado de aprobar los planes de una planta nuclear.

Naturalmente, una planta nuclear es un tema serio que requiere cuidadosa deliberación y estudio. El problema es que Parkinson advirtió que la mayor parte de la deliberación, discusión y tiempo del comité se gastaba en cosas triviales, como los materiales para usar en el cobertizo de las bicicletas ¡Y no en el diseño de la planta nuclear misma!

¿Por qué?

La explicación principal: No todos tenemos los conocimientos o experiencia para criticar constructivamente los planes de una central nuclear ¡Pero opinar sobre el cobertizo de bicicletas es pan comido!

Por cierto, como en inglés cobertizo-de-bicicletas se dice bikeshed, en el mundo del desarrollo opensource se ha popularizado el termino bikeshedding. Así se pueden interrumpir de manera rápida esos interminables detalles superfluos donde todo el mundo tiene una opinión diferente diciendo, esencialmente, “cortémosla con el bikeshedding y enfoquémonos en lo más importante”. Y todos entienden.

De vuelta a Parkinson, recuerden que el tipo estaba estudiando como se comportaba el comité en sus reuniones. Por ende, la manera en que Parkinson formuló su Ley de Trivialidad es la siguiente:

El tiempo gastado en cualquier item de la agenda de una reunión será en proporción inversa a la cantidad de dinero involucrada.

Como en general las cosas que cuestan mucho dinero (como las centrales nucleares) son complejas, el tiempo y la atención se van a las cosas triviales y baratas.

En el siguiente artículo de esta serie veremos como esta ley aplica al proceso de diseño de marca/branding/personalidad, de acuerdo a nuestra experiencia en múltiples proyectos en Continuum. Después de todo, diseñar tu marca no es precisamente barato, pero igual todo el mundo tiene una opinión que dar al respecto.

¿Qué creen ustedes que diría Parkinson si nos viera en esas reuniones en que discutimos el diseño de marca, logos y/o look & feel?

Por qué estamos cambiando los precios en Get on Board

A partir del 4 de Abril de 2015, desbloquear empleos en Get on Board cambiará de 45 USD a 99 USD, que era el precio original al cual lanzamos la funcionalidad. Los precios de las suscripciones cambiarán también: el plan Startup de 99 a 199 USD, el plan Básico de 250 a 499 USD, y el plan Pro se mantiene en 990 USD, pero su cuota bajará de 100 a 50 anuncios.

¿Por qué?

Podríamos citar razones de costo (la infraestructura donde vive la plataforma cada vez cuesta más a medida que añadimos funcionalidad y los usuarios suben), pero la verdadera razón es otra: Queremos quedarnos sólo con las empresas que valoran y quieren trabajar con los mejores.

¿Cuál es realmente el valor de encontrar a la persona indicada para tu equipo? Depende de cuánto valor tiene para ti tu equipo. Si tu razón para estar en el mercado es generar valor, talento y conocimiento, sabes que el equipo lo es todo. Si te interesa marcar una diferencia, innovar y crear productos y servicio de excelencia, lo tienes clarísimo: el equipo lo es todo.

Si eres una empresa que trabaja con “recursos humanos” en vez de personas y los consideras engranajes intercambiables de una gran máquina, entonces 99 USD te parecerá caro… hey, probablemente el precio de 45 USD ya te parecía caro. Y ésa es la idea precisamente: queremos que Get on Board te parezca demasiado caro si eres una empresa que no está dispuesta a invertir en su equipo.

Creamos Get on Board porque las mejores empresas tecnológicas tenían problemas encontrando a los mejores talentos, y esa situación era un absurdo, porque ambos existían sin conocerse el uno al otro. Y sin lugar a dudas, con el cambio de precio muchas empresas volverán a sus redes sociales para buscar a sus profesionales, o tal vez paguen un aviso en algún otro portal más barato. Y está bien. Existimos para solucionar problemas, no para crearlos.

Pero contratar es difícil. Y si realmente te interesa tu equipo, contratar es doblemente difícil. Pasa a ser como encontrar pareja. Hicimos Get on Board pensando en ese tipo de empresas, porque en Continuum somos también así, y sabemos que cuando realmente te importa, la inversión de tiempo en encontrar, evaluar, entrevistar y filtrar es enorme. Te preocupas por cada candidato; sabes que detrás de cada postulación hay una persona con expectativas y talentos esperando tu respuesta.

Cuando eres esa empresa, Get on Board le quita un montón de complejidad al proceso de encontrar a la persona correcta. Y cuando esa persona aparece, te das cuenta que ni 99, ni 200, ni 1000 dólares son tan caros (y te devolvemos el dinero si no te sientes contento con los postulantes que recibas). Si eres esa empresa, bienvenido a Get on Board. Es un grupo pequeño, pero te sentirás en casa.

Subir precios es siempre un riesgo, pero queremos tomarlo: nos compromete doblemente con lo que viene. Estamos trabajando en un sistema para administrar todo el flujo de postulaciones, full-stack, de principio a fin. Seguimos día a día añadiendo mejoras y nuevas funcionalidades para que validar postulantes y conversar con ellos sea cada día más fácil.

Nos hemos vuelto un poco adictos al feedback (¡incluso este cambio de precios ha venido desde ahí!). Nos encanta tener input directo de empresas y Web Pros y mejorar Get on Board en tiempo real. Escríbenos a team@getonbrd.com o chatea con nosotros desde el portal si es que quieres hacernos llegar sugerencias, dudas o críticas constructivas.

— Sergio y Jorge

6 problemas típicos en proyectos UX — parte 6: Waterfall UX

1deef76

Éste es el capítulo final de la serie sobre los 6 problemas típicos en proyectos UXque hemos encontrado en Continuum.

A veces, el principal obstáculo para una mejor experiencia de usuario somos nosotros mismos, los profesionales encargados del tema. La forma en la que concebimos nuestro trabajo tal vez no haga la diferencia a la hora de ganar clientes, pero sí definirá la calidad de la experiencia final.

El principal culpable es el exceso de énfasis en el proceso UX en sí mismo. Tendemos a vender nuestras metodologías y las herramientas como el factor clave en una mejor experiencia de usuario, independiente de cómo y cuándo son aplicadas. Los clientes, cada vez más ávidos de diferenciarse de su competencia, se abrazan a este salvavidas que los reencauzará en la senda de la innovación y la vanguardia. Meses más tarde, a la hora de lanzar, el producto final es más o menos lo mismo que hacen todos los demás, pero con un look&feel un poquito más actualizado a este año.

Waterfall UX es como denominamos a la práctica de experiencia de usuario que, siguiendo el tradicional modelo de cascada, se pierde entre documentación, procesos y cartas Gantt. El foco pasa a ser el cumplimiento de hitos más que la obtención de calidad. La gente es recompensada por su apego a los plazos y a los presupuestos, en lugar del éxito del proyecto con sus usuarios finales.

¿Cómo es que se llega a algo así?

Waterfall UX, o la falacia que con el proceso es suficiente

El modelo de desarrollo de software “en cascada”, o waterfall, es una herencia directa del proceso de línea de ensamblaje (ver parte 5 de esta serie). La famosa cascada no es más que una alusión a cómo el software va “cayendo” de silo en silo, no pasando al siguiente hasta que el actual tenga todo resuelto y definido.

Todo este aparataje existe por la obsesión gerencial de eliminar la incertidumbre. Tiene sentido para crear objetos físicos complejos, dado que permite manufacturar con eficiencia y a una velocidad predecible. El diseño del producto ha sido pensado por completo en una fase inicial, y en ella se generan especificaciones que luego el área de producción tendrá que implementar al pie de la letra.

Pero —nuevamente— el software no es un objeto físico. En primer lugar, el software no sólo se usa (como usamos un martillo o un auto), sino también se consume semántica y emocionalmente, de acuerdo al contenido que trae dentro (como un programa de televisión).  La construcción de sentido y de experiencias queda pobremente incluida dentro del esquema de cascada. Y en segundo lugar, la naturaleza abstracta del software permite mucha más flexibilidad en los procesos.

La manera en que los departamentos de IT trabajan actualmente, [aplicada a la construcción de experiencias omnipresentes], resulta en una inaceptablemente mala experiencia de usuario.

— Adam Greenfield, Everyware: The Dawning Age of Ubiquitous Computing

Sin embargo, el foco sigue girando en torno a lo mismo: al proceso. Se asume que la construcción de experiencias es un proceso análogo al de fabricar un objeto: predecible, tangible y finito. Desde esa perspectiva, si yo llego con un mejor proceso, obtendré mejores resultados. Causa y consecuencia. Y es así como se están vendiendo muchos proyectos de UX: tenemos un mejor proceso, que te garantizará mejores resultados.

Muy por el contrario, las experiencias son caóticas, impredecibles, sujetas a sutilezas y con límites continuamente cambiantes. La experiencia no ocurre en el producto, ocurre en la mente de la persona que lo consume. La única manera de enfrentar dicho caos es con flexibilidad, es decir, con menos proceso.

Por supuesto, esto funciona perfecto cuando es nuestra plata y nuestro tiempo. Pero necesitamos responderle a nuestros clientes/partners/inversionistas de alguna forma, y no es poco usual que ésa sea la razón principal por la que caemos en Waterfall UX.

El problema de (intentar) planificar un proyecto de UX

Diseñar experiencias de usuario significa lanzarse de cabeza al caos e intentar extraer orden de él. ¿Cómo sabes, al principio del proyecto, en qué momento el equipo llegará a un diseño (no sólo visual, sino de información, canales, flujos, servicios y contenido) coherente y sólido? No lo sabes.

Pero “no sé” no es una respuesta viable, porque se nos exige trabajar con límites, principalmente de tiempo, talento y dinero. Por otro lado, estimar y planificar el proyecto no es trivial, porque de eso depende la viabilidad de tu negocio, en especial en los proyectos T&M. No te puedes dar el lujo de estimar demasiado a la baja (y salir perdiendo plata en el proceso) o demasiado al alza (y volverte alguien ineficientemente caro).

Entonces recurrimos al set de herramientas y prácticas que hemos estado desarrollando durante nuestros años de experiencia, y nos aproximamos a los proyectos de UX describiendo las actividades en las que esperamos encontrar las respuestas a nuestras interrogantes.

Cuando le preguntas a un experto en UX acerca de su flujo de trabajo típico, te dirá probablemente algo como:

  • Brief
  • Investigación y contextualización
  • Mockups y prototipos de baja fidelidad
  • Arquitectura de información
  • Wireframes
  • Diseño final
  • Producción y control de calidad

Para la mayoría de los proyectos, este plan tiene sentido. Por lo mismo, podemos poner un cierto grado de confianza en él, y le asignamos plazos a cada fase. Y eso mismo es lo que derivaremos luego a una estimación, en forma de un plan de trabajo.

El “pero” de este esquema es que genera una cierta expectativa en los clientes: que es una secuencia estándar y predecible de actividades y entregables que terminará, inevitablemente, en una experiencia bien diseñada. Y dado que una gran mayoría de las empresas (con excepción de las startups) están acostumbradas a trabajar bajo el modelo de cascada, el resultado es que dichas actividades y entregables se nos cobrarán exactamente según la planificación.

Esto, a su vez, desvía el foco del proyecto en los entregables y los hitos, en lugar de en la experiencia y en el aprendizaje. Como mencionaba al principio, diseñar experiencias que otras personas tendrán es inevitablemente impredecible. Y aún cuando una planificación nos permita entregar cosas (diseños, documentos y registros) a tiempo, nada garantiza que dicho diseño gatillará efectivamente la experiencia que queremos lograr en nuestros usuarios.

Más práctica, menos proceso

El proceso, por sí solo, no asegura nada. Ésta es sólo una de las muchas razones por las que en Continuum adoptamos un sabor propio de Lean UX (enriquecido por herramientas hechas en casa, como Validation Onion y Scope Canvas) como el approach más adecuado para lidiar con la incertidumbre que es inherente en los proyectos de experiencia de usuario.

Más que un proceso, Lean UX es una actitud que nos entrega valores que guían el avance del proyecto. Entre ellos:

  • Todos en la misma mesa. Todos los que toman las decisiones importantes participan del proyecto desde el primer día. Esto no sólo incluye a clientes y stakeholders, sino también al equipo de desarrollo.
  • Las cosas abstractas también pueden (y deben) ser prototipadas. Prototipamos ideas de negocio, propuestas de valor, flujos de usuario, taxonomías de contenido, vocabulario… la lista es larga.
  • Microvalidaciones con usuarios. Aquí es donde se rompe la cascada. Hacemos lo posible por sumar feedback de usuarios desde el principio y dejamos que esto informe las siguientes decisiones.
  • Las decisiones más importantes se toman primero. A la inversa de lo que suele suceder en los entornos corporativos (donde los proyectos van “escalando” y la persona más importante es la última en visarlos), buscamos que las decisiones importantes en relación al rumbo del proyecto sean tomadas al principio. Esto disminuye enormemente el riesgo de las decisiones posteriores, así como el ida-y-vuelta que ocasiona el Deadline Creep (ver parte 2 de esta serie).

Además, Lean UX nos entrega un orden lógico de jerarquía, que nos da la flexibilidad suficiente para dejar que el mismo proyecto, y su avance, nos vaya dictando los lugares sobre los que es necesario poner foco.

Conclusión de esta serie

Creo que estamos recién empezando a entender la complejidad de diseñar experiencias de usuario. Hasta el momento, se ha visto como un “diseño web con apellido”, una manera fancy de hacer lo de siempre y cobrar más plata por ello.

Muy por el contrario, los desafíos de UX que están a la vuelta de la esquina son desconocidos para muchos diseñadores de hoy. Entre ellos, el desafío de reducir información y alivianar la carga cognitiva en una sociedad que está absolutamente saturada por el ruido; el desafío de integrar múltiples canales, sistemas y touchpoints en una experiencia que sea realmente coherente y usable, independiente del medio; el desafío de desarrollar nuevos productos y encontrar necesidades insatisfechas en un mercado cada vez más saturado; y por último, el desafío de mantenernos a la par de un desarrollo tecnológico que día a día abre ventanas nuevas con implicancias sociales, culturales e incluso demográficas.

Es una locura. Pero para quienes gustamos de hallar orden en el caos, es de las locuras en las que vale la pena sumergirse :)

Seguimos en contacto!

6 problemas típicos en proyectos UX — parte 5: Brecha entre diseño y desarrollo

2b2c965

Éste es el quinto capítulo de la serie sobre los 6 problemas típicos en proyectos UX que hemos encontrado en Continuum.

Al igual que el problema #4 (investigación deficiente), éste es un problema que, al menos parcialmente, es responsabilidad de los diseñadores a la hora de desarrollar productos digitales en equipo. En Continuum nos hemos dado cuenta una y otra vez que la separación entre equipos de diseño y equipos de desarrollo fractura los productos, vuelve tediosos los proyectos y genera mucha más fricción que la necesaria. Veamos por qué.

Trabajar en silos, como si estuviéramos armando autos

Henry Ford es conocido por haber desarrollado el automóvil moderno. Sin embargo, hizo otra contribución igualmente trascendental para la industria moderna: la línea de ensamblaje. Hasta entonces, las fábricas e industrias tendían a estar organizadas en torno a la figura del artesano, dominador de su oficio y capaz de crear un producto de principio a fin.

La innovación de Ford fue crear un proceso lineal compuesto de varios operarios, cada cual especializado en una tarea puntual sobre el producto y encargado de entregárselo al siguiente. Un silo ensambla el motor, otro pone la carrocería, otro los asientos, otro lo pinta. El proceso demostró ser mucho más eficiente y requerir menor mano de obra calificada. Nadie es irremplazable, dado que todos sólo hacen una parte del trabajo. Lo realmente central pasa a ser el proceso productivo. Los automóviles se fabrican de esa forma hasta el día de hoy.

La idea de que la línea de ensamblaje mejoraba la eficiencia industrial fue tan trascendente que impregnó toda la cultura empresarial, incluyendo la de procesos que no necesariamente se beneficiarían de la división de roles. El término “fábrica de software” tiene que ver precisamente con esta cultura: tienes un silo de analistas funcionales, otro de arquitectos de software, otro de programadores back-end, luego de front-end, otro de Quality Assurance y otro de DevOps. Cada uno se va pasando el software, en un orden lineal, como si estuvieran armando un automóvil.

Cuando le tocó a las empresas asumir la necesidad de integrar la Experiencia de Usuario a sus productos digitales (estamos hablando del 2005 para las empresas pioneras y del 2019 para las más rezagadas), sus gerentes de TI vieron que la solución era sencilla y constaba de dos pasos:

  • Incorporar a los expertos de UX al principio del proceso, en el silo del análisis funcional. De esta forma, los UXers procesarían los requerimientos y generarían un conjunto de especificaciones que luego pasarían a manos de los arquitectos de software, y de alguna forma validarían con sus conocimientos e investigación el trabajo de los analistas funcionales.
  • Potenciar el silo de front-end con diseñadores que tuviesen conocimientos de usabilidad. Así, el producto tendría una mejor usabilidad, se vería más moderno e integraría efectos visuales que lo harían más atractivo.

Todo esto suena maravilloso… en teoría. En la práctica, ha resultado pésimo.

Jugando al teléfono (malogrado)

El approach que les acabo de describir tiene las siguientes fallas estructurales:

  • Asume que el software pasa limpiamente de un silo al siguiente. Nuevamente hay que recordar que este proceso fue pensado para producir autos; funciona bien cuando trabajas sobre objetos físicos. El software no es un objeto físico, y en el mundo de lo abstracto, el concepto de “una buena experiencia de usuario” es una de las que se degrada más rápidamente. Cuando el estratega de UX entrega sus diseños y no vuelve a saber del producto hasta que ha sido lanzado, el ruido que provoca el hand-off se va amplificando de silo en silo.
  • Como lo anterior nunca resulta cierto, se cubre la brecha con documentación. Un montón de documentación. OK, tenemos el problema de que el producto digital se va degradando a medida que pasa de mano en mano. ¿Cuál es el problema aquí? Para el mindset de la línea de producción, la respuesta es simple: es porque el producto no se ha especificado lo suficiente. Si la documentación es clara y exhaustiva, nadie tendrá por qué malinterpretar nada. Y así, amigos, es como surgieron las documentaciones técnicas de tomos y tomos que toman meses en escribirse y meses en leerse (cuando son leídos).
  • Asume que sólo una parte del equipo es la responsable de la experiencia de usuario. Y ésta es sin duda la falla más grave. Asumiendo que los desarrolladores de software son más productivos cuando trabajan en un entorno aséptico, se los aísla totalmente del contacto con usuarios y se les pide optimizar en torno a la robustez y la performance como única meta. El contenido, realmente, no importa. Y es así como llegamos a mensajes de error como el siguiente:

User-friendly.

Y en este punto es donde empieza la pelea entre diseñadores y desarrolladores. Los diseñadores sienten que los desarrolladores no escuchan sus requerimientos y no entienden lo que significa una buena experiencia de usuario, y éstos a su vez piensan que los diseñadores no entienden el costo de implementar sus sugerencias, y no le ven sentido a agregar “adornos” que retrasan el proyecto.

Ambos tienen la razón

La división entre diseñadores y desarrolladores es artificial y dañina. Ambos son parte clave del mismo producto. Es el diseñador quien planifica e idea una experiencia de usuario, pero es el desarrollador el encargado de hacerla realidad.Desde el punto de vista del usuario, ambas partes son indistinguibles en la forma en cómo lo experimenta. Ningún usuario final piensa “este producto está bien diseñado, pero mal implementado” o “este producto tiene súper buena performance, pero le faltó diseño”. Simplemente piensa “este producto está mal hecho”.

Esto implica que cada parte debe aprender algo sobre la otra:

  • Los diseñadores necesitan entender que sus decisiones tienen costos de implementación y un potencial impacto en la performance. Es responsabilidad de un diseñador conocer su soporte. Independiente de si el diseñador sabe o no de programación, es su deber entender cómo funciona el medio en el cual está diseñando. Más al respecto en este artículo.
  • Los desarrolladores necesitan entender que el código que construyen será usado por seres humanos, y que lo que hagan determinará la experiencia final. No es necesario que el desarrollador “sepa diseñar” ni que se sepa al dedillo los patrones de interacción; pero sí es primordial que esté tan conectado con los usuarios finales como lo está el diseñador.

Diseñadores y desarrolladores necesitan un lenguaje unificado. Y esto, a su vez, requiere que ambos trabajen juntos y cooperen en tiempo real. Es por esto que, desde la primera reunión de nuestros procesos de Lean UX, pedimos a los desarrolladores que sean parte de la mesa de trabajo y participen en definir la propuesta de valor y en conocer las necesidades de usuario.

Hay un valor enorme en que el equipo desarrollador sea partícipe del feedback de los usuarios tempranamente. Súbitamente, lo que hace ya no se va a una caja negra en medio de la nada; va dirigido a otras personas, que lo experimentarán, lo usarán y opinarán sobre él. Sentir que estamos haciendo algo importante para otros es potente para la motivación, sin importar el tipo de trabajo.

Con un cliente en particular, un jefe de desarrollo nos preguntó:

¿Qué saco con estar presente en estas reuniones? Son de diseño, no de desarrollo. Lo que a mí me compete es que las cosas queden bien hechas, que logren alta disponibilidad y que sean robustas. Estar acá me hace perder tiempo valioso.

Como imaginarán, este desarrollador nació y fue criado en la mentalidad de silos. Nuestra respuesta fue la siguiente:

Si estás presente, podrás en primer lugar tener voz y voto sobre las cosas que luego tú mismo tendrás que desarrollar. Si no estás, corremos el riesgo de tomar decisiones de diseño que impacten directamente los tiempos de desarrollo de tu equipo. En segundo lugar, serás partícipe de las necesidades de usuario que hacen surgir este producto, y eso te permitirá trabajar con más autonomía, porque entenderás mejor lo que necesitan los usuarios, y por ende el diseñador deberá intervenir menos. Y por último, ayudarás a crear un mejor producto, que te hará sentir más orgulloso y que recibirá menos tickets de soporte por fallas de usabilidad.

Al parecer la respuesta lo convenció, porque continuó yendo al resto de las reuniones.

Agile UX: La UX es responsabilidad de todos

En Continuum es requerimiento que los diseñadores de UX sepamos además escribir código, como mínimo HTML/CSS/JS (hemos tenido que dejar fuera UXers talentosísimos sólo por esta razón). Esto no sólo es para hablar un lenguaje común con los desarrolladores, sino para actuar directamente como uno de ellos en la parte front-end.

De eso se trata Agile UX: de compartir la responsabilidad a la hora de la implementación. La mezcla de que ambos lados entiendan el trabajo del otro, y que a su vez cada uno pueda concentrarse en lo que es más eficiente, trae como resultado velocidades altas y un equipo sumamente satisfecho y que requiere mucha menos documentación y gestión.

Personalmente me gusta mucho programar en Ruby on Rails, y el poder estar metido directamente entre modelos, vistas y controladores me permite asegurarme que la experiencia de usuario final es exactamente la diseñada. Lo mismo ocurre con JavaScript y la interactividad que le agrega a los productos Web. Y lo mismo ocurre con entender las implicancias de performance de los dispositivos móviles, así como sus capacidades.

Los profesionales de UX que se quedan demasiado pegados en las tareas más proyectuales y no meten las manos a la implementación de aquello que diseñan le hacen un flaco favor a sus productos. En primer lugar, hacen necesaria toda la burocracia de documentación y papeleos que ralentiza el proyecto y desgasta al equipo, y en segundo lugar pierden contacto con el producto final, aquel que realmente experimentan los usuarios.

La gente no usa wireframes ni usa prototipos clickeables: usa productos reales. En la medida que estemos más integrados con la manera en la que se hacen los productos reales y finales, tendremos mejores experiencias para nuestros usuarios, y una experiencia más rica de trabajo para nosotros mismos y para el equipo.

¡No te desconectes!

Próximo capítulo y final: Waterfall UX.

6 problemas típicos en proyectos UX — parte 4: Mala investigación

Éste es el cuarto capítulo de la serie sobre los 6 problemas típicos en proyectos UX que hemos encontrado en Continuum.

Siempre podemos torcer las investigaciones para que digan exactamente lo que queremos.

Siempre podemos torcer las investigaciones para que digan exactamente lo que queremos.

En los posts anteriores de esta serie hemos estado revisando situaciones que tienden a estar presentes en el equipo y contra los cuales el líder de UX, de alguna forma, tiene que luchar.

Pero en esta ocasión hablaremos de un problema que nos afecta a nosotros mismos como gestores de experiencia de usuario: realizar una investigación de usuarios deficiente, o no realizarla en absoluto.

Pero hey, ¿por qué investigar?

Investigar, con todas sus actividades asociadas (buscar, entrevistar, testear, tomar notas, tabular, reportar, etc.), puede ser sumamente tedioso, y la flojera, o la ansiedad de querer pasarse al producto real lo antes posible, suele ser una causa muy común de saltarnos la investigación como corresponde. Esta flojera en realidad viene de algo más profundo: el hecho de que no siempre sabemos cuál es el valor que la investigación de usuarios le puede aportar a un proyecto. Si no le vemos utilidad evidente, ¿cuál es la gracia de perder tiempo en hacerlo?

Para que el lector se motive con la idea, aquí van 3 razones para hacer investigación de usuarios:

Razón 1: No, con nuestra experiencia (o con la experiencia de otros) no basta

Como seres humanos, estamos hechos para aplicar nuestra experiencia previa a las nuevas situaciones inciertas: esto nos permite tomar decisiones más rápida y eficientemente. Y cuando nos toca ser líderes o diseñadores de UX en proyectos con clientes — 10 años en mi caso —, nos exponemos a una variedad muy amplia de contextos, usuarios, necesidades, tecnologías y desafíos. Esto genera un corpusde experiencia enorme, del cual obviamente nos servimos para proyectos futuros, y que de hecho aumenta exponencialmente el valor que el estratega de UX es capaz de entregar.

El detalle es que de toda esta experiencia previa, hay algunas cosas que son reutilizables y otras que definitivamente no. Entre estas últimas, la premisa más dañina es asumir que ya conocemos cómo piensan y se comportan los usuarios en general, sin importar el contexto. Desde luego, (casi) nadie es tan arrogante como para creerse esto conscientemente; lo que hacemos es actuar en base a dicha creencia, y esto se manifiesta en un montón de decisiones, especialmente las pequeñas, en las que asumimos ciertas cosas de los usuarios que no nos molestamos en validar.

Uno de los ejemplos más frecuentes, y especialmente tramposo, es el uso de los patrones de interfaz. Damos por hecho que si tiene sentido semántico usar radio buttons en lugar de un combo-box, la gente lo entenderá igual que nosotros.

La trampa radica, precisamente, en el hecho de que nosotros sí hemos estudiadoun montón acerca de patrones de interacción y de cuándo tiene sentido usar uno u otro (espero que el lector también. Si no, ¡deje este post y váyase a estudiar!). Nuestros usuarios, en cambio, simplemente usan las cosas, y las usan en la medida que las entienden. Y no siempre lo más coherente con un lenguaje de diseño es necesariamente lo que mejor entienden los usuarios. Que un usuarioentienda una herramienta no sólo depende del sistema, sino mayormente de su contexto cultural y social.

Por ende, ni el cumplimiento más estricto de los lineamientos de UI te puede salvar de probar y validar tu interfaz con personas reales, que no tengan conocimientos de usabilidad.

Razón 2: El tándem entre investigación e intuición es mucho más eficiente

He observado dos grandes grupos de opinión respecto a la investigación de usuarios:

  • Quienes consideran que todo debe ser investigado y validado previamente, y que nada puede ser dado por hecho a priori. Este grupo privilegia enormemente la investigación previa para sustentar cada decisión estratégica o de diseño y no dejar nada al azar.
  • Quienes consideran que hay que salir a lanzar lo antes que se pueda, sin importar lo imperfecto que resulte. Este grupo considera que es mucho mejor equivocarse en el mundo real, porque incluso si fracasamos, aprenderemos lecciones valiosas y basadas en la evidencia que podremos aplicar luego.

Desde luego, es el mundo de los proyectos de software el que permite que existan estas dos visiones (si estuviésemos construyendo equipamiento médico, eso de “equivocarnos en el mundo real” no sonaría muy gracioso). En nuestra experiencia, lo que mejor funciona al desarrollar productos digitales es una mezcla de ambas. No es necesario tomar partido.

Lo explicaré con una metáfora:

Imagina que estás en una ciudad desconocida, necesitas llegar a un lugar, estás atrasado y todo lo que tienes es un mapa GPS. ¿Qué haces?

¿Te lanzas a correr para moverte lo antes posible, confiando en que tu intuición te llevará al destino correcto? Ciertamente no, arriesgas demasiado. ¿Dejas de mirar a la calle y te guías exclusivamente por el imparcial y objetivo GPS para no perder el rumbo? Tampoco, porque te pierdes de todo lo que tus sentidos te pueden ofrecer, como un atajo o un imprevisto en el camino que el mapa no tenía considerado.

La solución es apoyarse en ambas: usas el GPS para las indicaciones precisas y ubicarte correctamente, y tus sentidos para sortear imprevistos y tomar decisiones alternativas con rapidez.

Mi punto con esto es que ambos extremos se están perdiendo de algo: los que investigan y validan todo previamente se pierden de la agilidad, y los que quieren fallar lo antes posible se pierden del sustento que les hará fallar menos, en primer lugar.

Efectivamente, mientras más podamos validar en el mundo real es mejor; pero al mismo tiempo, si nos tomamos un tiempo inicial para planificar, podemos ir alternando la validación en el mundo real con saltos de intuición o de experiencia aplicada que nos harán ahorrar tiempo.

Esto va dirigido especialmente al segundo grupo, al que piensa que investigar a priori es perder tiempo. Echarte a correr sin dirección alguna, esperando encontrarte en el camino con la vía correcta, es potencialmente más lento y caro que tomarse un poco de tiempo para planificar, salir a continuación y corregir el plan sobre la marcha.

Por eso en Continuum creemos que es necesario empezar los proyectos digitales con Lean UX. Una fase breve de planificación e investigación, lejos de ser una traba a lanzar rápido y temprano, te da una dirección en la cual apuntar y te permite validar ciertas cosas básicas para las que hacer un prototipo es ineficiente.

Razón 3: Sí, prototipar a veces puede ser ineficiente

La razón por la cual los prototipos existen es que te permiten probar antes de lanzarte a producir con todo. Y usualmente esto es cierto: al construir una versión básica, barata o ficticia del producto final, compruebas cosas con menos riesgo que si esperas a construir la versión final.

Pero hay cosas para las cuales construir un prototipo es ineficiente. ¿Necesitas realmente construir todo un prototipo para determinar cómo se deben llamar las secciones de tu producto? Si esperas a ese momento, ya es demasiado tarde. Irónicamente, si no te preocupas de validar estas cosas antes de construir el prototipo, efectivamente estarás haciendo “saltos de fe” que pueden tardar mucho en mostrar sus falencias.

Y hay asuntos que, sin una investigación previa, estarás jugando a las adivinanzas por mucho tiempo antes de dar en el clavo. Es el caso cuando necesitas construir la versión digital de una tarea que los usuarios ya realizan en el mundo físico. Si no te pones en contexto de tus usuarios y observas qué hacen y cómo lo hacen, tu prototipo estará basado precisamente en lo que estás intentando evitar: tincadas e intuiciones vagas.

Es por eso que en Continuum hablamos de microvalidaciones para describir los aspectos del desarrollo de un producto digital que no requieren construir un prototipo (y mucho menos el producto final) para validarlos. El ícono de tu aplicación, el esquema de colores o el vocabulario son sólo ejemplos de cosas que puedes validar de manera paralela.

Y aquí es donde la investigación juega un rol importante: provee al equipo de contexto y base para tomar decisiones con eficiencia y que reducen el riesgo de tener que rehacer desde cero. A pesar de que la idea de “fracasar, partir nuevamente desde cero y entonces triunfar” suena épica y apasionante, en la realidad es un esquema bastante destructivo; y a menos que seas Google y tengas bolsillos sin fondo, la mayor parte de las organizaciones e inversionistas no tienen los recursos para darse el lujo de fallar y partir desde cero una y otra vez hasta aprender lo necesario. Es una escuela demasiado cara.

Cómo investigas

Siempre me ha llamado la atención lo originales que pueden llegar a ser los científicos para experimentar y probar sus hipótesis. En muchos casos, el éxito de un experimento depende de un acto puramente creativo (o genial) del científico, que diseña un procedimiento para aislar precisamente la variable que necesitaba comprobar o refutar. El pensamiento científico es uno de los dos hemisferios que el líder de UX necesita tener equilibrados; el otro es la capacidad de conectarse emocionalmente con sus usuarios.

Ambos entran en juego a la hora de determinar ciertas preguntas básicas: ¿Qué es lo que quieren nuestros usuarios? ¿Qué les importa? ¿Qué valoran? ¿Dónde sufren o les aprieta el zapato? ¿Qué características de su cultura o contexto influirán en el diseño del producto?

Existen técnicas cualitativas, como las entrevistas y la observación directa, que requieren empatía, capacidad de generar rapport y la capacidad de extraer insightsemocionales y culturales desde un número limitado de casos; éstas deben ser equilibradas con las cuantitativas, como el análisis de datos, encuestas, A/B testing o la observación de métricas de uso, que te agrandan el panorama y te permiten detectar tendencias de uso sobre una muestra de público mayor. Ambas son igualmente importantes para el profesional de UX (y, como el lector notará, reflejan también el equilibrio entre la capacidad de empatía y el rigor científico).

***

En este capítulo, la palabra clave es equilibrio. La manera de llegar a la dosis correcta de investigación que requiere un producto en un momento determinado involucra estar con una oreja pegada al equipo, sus aprendizajes e incertidumbres, y con la otra pegada a los usuarios y a cualquier indicio de que podamos necesitar corregir el rumbo.

No es una tarea fácil, pero diseñar productos para seres humanos en sí es una tarea compleja. Requerimos tener conciencia y dominio sobre nuestras propias tendencias como seres humanos, en especial la de tomar atajos y asumir que ya sabemos todo lo necesario. Pero la recompensa será invaluable: un producto que, incluso antes de existir, ya está mejorándose y evolucionando.

Próximo capítulo: Brecha entre diseño y desarrollo.

6 problemas típicos en proyectos UX – Parte 3: Productos Inútiles

Segway_Police_(2529167270)

Segway: un producto que quería cambiar el transporte de personas en un mercado masivo, fracasó espectacularmente en ello, y finalmente encontró un nicho en el personal de seguridad.

Éste es el tercer capítulo de la serie sobre los 6 problemas típicos en proyectos UX que hemos encontrado en Continuum.

Ya hemos revisado cómo el Feature creep y el Deadline creep arruinan proyectos de UX y terminan convirtiendo buenas ideas en proyectos fallidos o desfigurados. Ambos problemas hacen que las energías se gasten en tiras y alojas internos, en lugar de estar mejorando el producto para sus usuarios.

Pero nos ha tocado enfrentar proyectos que padecen un problema mucho más de raíz: la idea, en sí misma, es pésima. ¿Qué haces cuando te encargan (y te pagan por) trabajar en un proyecto que sabes que está destinado a morir? Y de hecho, hay una pregunta anterior que hacerse: ¿cómo sabes cuando una idea es realmente mala?

La ilusión de que si insistes lo suficiente, también podrás ser Steve Jobs

El lector estará familiarizado con esas historias donde un genio visionario (Steve Jobs, Henry Ford, Gastón Acurio, etc.) tiene una idea que todos en un principio encuentran estúpida, hasta que el obsesivo y tenaz genio termina haciendo realidad su visión, cambiando toda una industria y generando un par de frases para el bronce que luego nosotros compartiremos en redes sociales.

El problema con estas historias es que son sumamente engañosas: nos hacen creer que cada vez que el resto del mundo encuentra estúpida nuestra idea, es porque nuestra idea en realidad es genial. Y la mayoría de los seres humanos, cuando nos dan a elegir entre considerarnos estúpidos o considerarnos unos genios, vamos a elegir la opción que nos deja mejor parados. Y vamos metiendo plata, esfuerzos y recursos a una idea, bajo la premisa de que “si no funciona aún es porque no hemos insistido lo suficiente”.

El otro problema con estas leyendas es que ocultan la cantidad de veces que estos genios visionarios han fracasado o han tenido que modificar su idea original hasta convertirla en lo que realmente funcionó. Y acá la línea que divide al perseverante del obstinado es delgadísima: mientras que el primero modifica y cuestiona su idea mil veces en pos de llegar a algo realmente útil, el segundo da por hecho que su idea ya es perfecta y que tan sólo basta que el mundo se dé cuenta.

Y eso definirá si nos estamos embarcando en un proyecto destinado a alcanzar nuevos horizontes, o si nos tocará, cual camareros del Titanic, hacer de comparsas mientras todo se hunde.

Las buenas ideas están conectadas, las malas ideas están desconectadas

Como líderes de UX, muy a menudo somos los primeros en tomar contacto con la idea del cliente y evaluarla. Y nos corresponde tener la disciplina para resistir el impulso de correr al Photoshop, y en cambio hacer una pausa para preguntarnos,¿es ésta la idea correcta?

Supongamos que es 2007 y Google se acerca a ti, consultor de UX, para pedirte ayuda con un proyecto ambicioso, que promete reemplazar al e-mail: Google Wave. La idea, en el papel, suena increíble. Hoy sabemos que fue un completo fracaso.

¿Qué le habrías dicho tú a Google acerca de su idea?

En Continuum ideamos un canvas especialmente para esto: se llama el Scope Canvas. Usándolo buscamos que el contexto de la idea, por sí sola, muestre si está conectada o no con las necesidades de algún usuario. Una de las ideas básicas del Scope Canvas es que todo, al principio, se encuentra en estado hipotético; por muy convencidos que estemos de que esta idea es absolutamente genial y que el mundo la amará, necesitamos validarlo en el mundo real.

Google Wave falló, entre otras razones, porque no estaba conectado con ningún problema de sus usuarios objetivos. Efectivamente, era una mejora al e-mail; pero la gente se las arreglaba (y aún lo hace) bastante bien con el e-mail y sus imperfecciones. ¿Qué razón tengo yo para dejar de hacer lo que hago actualmente y adoptar este producto nuevo? El equipo de Wave nunca se hizo esa pregunta, y una vez que pasó el efecto de la novedad, el público abandonó la plataforma a su suerte.

Como ven, la palabra clave para separar buenos y malos productos es conexión.Cuando una idea de producto parece estar flotando en un limbo y en el Scope Canvas no se ve ninguna relación con motivadores o necesidades de usuarios, es hora de intentar conectarla para salvarla.

Se puede arreglar una mala idea, conectándola

Hay dos maneras de conectar un producto con las necesidades de un grupo de usuarios: refinando la idea o refinando el grupo objetivo.

En la primera estrategia, el doloroso pero educativo feedback de usuarios —obtenido mediante prototipos, entrevistas, tests de usuario y análisis de datos— irá moldeando gradualmente la idea, aumentando el foco en algunos aspectos, descartando otros, agregando nuevos, hasta que logramos llegar a un modelo de producto que tenga una necesidad clara y concreta a la cual satisfacer.

Por el contrario, en la segunda estrategia partimos de la base que la idea es potencialmente buena, pero que está apuntando al grupo equivocado. Tanteamos nuevos segmentos de usuarios con necesidades afines al producto, intentando identificar el que mejor resuena con la idea del producto y con el core de negocio del equipo. Esto es lo que ocurrió con el Segway: fracasó como medio de transporte masivo, pero encontró un nicho en el personal de seguridad y ayuda en centros comerciales y lugares públicos.

En realidad, lo que solemos hacer es una mezcla de ambas: a medida que refinamos la idea, refinamos también la necesidad que estará satisfaciendo. Como profesionales de UX, nuestro negocio es la creación y la transmisión de valor. Si el valor no está inmediatamente presente en el proyecto o en el equipo, haremos lo mejor que podamos para develarlo.

Pero eso no siempre es posible.

Cuando ya no hay salida

A veces, incluso después de refinar una idea y su conexión con una necesidad, es el mismo equipo quien se mantiene desconectado de sus usuarios. En ocasiones es por ego, y en otras es por apatía. Y hay casos donde la idea es genuinamente buena (y el equipo lo sabe), pero el timing es el incorrecto (y el equipo no lo quiere ver). El resultado es el mismo: no hay voluntad de enmendar el rumbo de un proyecto sin utilidad real o potencial.

Podemos decir “el cliente tiene la razón” y pasar por caja a cobrar nuestro cheque, y es válido. Pero personalmente creo que tenemos una responsabilidad un poco mayor como diseñadores de experiencia de usuario; estamos para crear productos útiles, y debemos avisarle al equipo cuando no lo estamos logrando.

Decir “lo lamento, pero creemos que este producto, así como lo han pensado, está destinado a fallar” requiere mucho valor; generará fricción y tensión, e incluso arriesgamos quedarnos afuera del proyecto.

Pero tal como con rayarle la cancha al cliente, no hacerlo tiene un costo mayor: nos veremos trabajando en un proyecto que sabemos que no tiene sentido. Esto impactará la motivación de todos, y con ello se terminan las esperanzas de corregir la marcha. Aún peor, si el producto es realmente un fracaso sonoro, arriesgamos ver nuestro nombre anclado a él, con la reputación negativa que eso acarrea. Y después de todo, hay veces donde esa inyección de honestidad era lo que el equipo necesitaba para salir adelante. La transparencia tiende a ser muy valorada y respetada, y en varios casos la relación termina saliendo más fortalecida.

Dar la voz de alarma no es fácil y muchas veces es un trabajo ingrato. Pero mientras antes, como líderes de UX, sepamos reconocer esa desconexión tempranamente y creemos las estrategias para solucionarla, más fácil se nos volverá luego desenterrar y comunicar el valor que crea productos satisfactorios para todos: usuarios y equipo.

6 problemas típicos en proyectos UX – Parte 2: Deadline Creep

Éste es el segundo capítulo de la serie sobre los 6 problemas típicos en proyectos UX que hemos encontrado en Continuum

En esta ocasión hablaremos del Deadline creep, o cómo los plazos (y los costos) de un proyecto se desbordan, muchas veces agotando todos los recursos disponibles sin llegar a tener un producto lanzado.

Deadline creep, o la fantasía de que tenemos todo el tiempo del mundo

La Sagrada Familia de Gaudí: el ejemplo por excelencia de un proyecto tan ambicioso y complejo que lleva 133 años construyéndose.

La Sagrada Familia de Gaudí: el ejemplo por excelencia de un proyecto tan ambicioso y complejo que lleva 133 años construyéndose y aún no termina.

La manera en la que los proyectos se salen de cauce y terminan durando el doble, el triple o diez veces más de lo originalmente planteado está bastante documentada (irónicamente, el exceso de documentación suele tener que ver con el problema).

La primera y más obvia causa de que los proyectos se estiren como chicle en verano es el feature creep, del que ya hablamos en el artículo anterior de esta serie. La ansiedad de “agregar un par de cositas más antes de salir” va prolongando el tiempo en el que se invierte en un proyecto sin tener feedback de usuarios.

La segunda causa, no tan obvia, es cuando el equipo cree que “este momento es tan bueno como cualquier otro para plantear mi idea y hacer cambios”. Esto trae un continuo tira y afloja, donde la ansiedad de que todo quede perfecto ocasiona que las decisiones se deshagan y rehagan una y otra vez. Otros actores se suman tarde a la mesa, y usualmente son quienes tienen más poder dentro del equipo y por ende son capaces de descarrilar un trabajo completo.

El Deadline creep agota al equipo

Además de las consecuencias obvias (fallar en los plazos y gastarse más plata de la presupuestada), el Deadline creep deja tras de sí a un equipo exhausto, que se ha pasado los últimos meses en:

  • Pelear porque no se sigan añadiendo funcionalidades antes de lanzar
  • Perder la pelea por no tener el poder de decisión suficiente
  • Implementar esas funcionalidades a toda prisa
  • Sufrir la presión del project manager o del cliente, que (por supuesto) sigue trabajando con los plazos originales
  • Correr en círculos solucionando las quejas de usuario por las funcionalidades mal implementadas
  • Perder plata (y por ende motivación) en el proceso

¿Cómo evitas esta espiral?

Mostrar la guagua fea

En Continuum tenemos el dicho de “no tenerle miedo a mostrar la guagua fea”. Esto significa que necesitamos reconocer que, en realidad, nunca nos sacaremos del todo la sensación de que el producto no está perfecto, en especial cuando es un producto digital que en teoría puede evolucionar eternamente.

Decidirse a lanzar requiere carácter y disposición a “dejar ir” una discusión o una idea en pos de obtener feedback de usuarios más temprano. La imperfección no tiene nada de malo; al contrario, muchas veces se convierte en el motor que mantiene un producto vivo. El problema es el estancamiento y el exceso de perfeccionismo que bloquea las mejoras.

Pragmatismo versus perfeccionismo

¿Cómo concilias entonces pragmatismo con perfeccionismo? ¿Cuándo sabes si es demasiado temprano o demasiado tarde para lanzar? Si lanzamos productos imperfectos al mercado, ¿esto significa que nunca los mejoraremos realmente?

La clave está en pintar las cosas claras al principio del proyecto: las ideas y suposiciones que traemos en la cabeza al empezar son sólo eso, suposiciones, y debemos deshacernos de ellas lo más pronto posible. Esto quiere decir que hay una cierta ventana de tiempo en la que podemos darnos el lujo de divagar, hacer brainstormings y debatir ideas; esa ventana se cierra y debe darle paso a las decisiones sustentadas en la experiencia en terreno, ya sea directamente de usuarios o a través de datos (analytics, métricas de negocio, etc).

Cuando entendemos que no tenemos todo el tiempo del mundo para divagar, nuestra misma mente se ordena y prioriza. Los seres humanos funcionamos mejor cuando tenemos la cancha rayada.

Cómo rayamos la cancha

Cuando comenzamos un proyecto de Lean UX en Continuum, lo primero que hacemos es explicarle al cliente la dinámica del proceso y comunicarle la necesidad de efectuar due dilligence. Las reglas son sencillas:

  • Como mencioné arriba, las decisiones tienen un cierto tiempo límite de ser tomadas si queremos cumplir con los plazos. Pasados esos límites, cualquier cambio de rumbo queda postergado hasta después de lanzar y obtener feedback de usuarios.
  • Además, las decisiones se toman en vivo en la mesa de trabajo. Esto requiere que estén las personas que realmente toman las decisiones en la mesa. Si la persona que toma la decisión es alguien que acostumbra ausentarse de las sesiones y delegar con sus subalternos, dejamos en claro que las decisiones de ese subalterno serán consideradas como definitivas.

Este último punto es especialmente delicado, dado que muchos clientes acostumbran a dejar a sus subalternos a cargo de asistir a las reuniones y tomar las decisiones; y cuando el cliente original llega a chequear todo al final del proyecto, se encuentra con cosas que no le gustan, y —dado que es quien manda— intenta cambiarlas. Y así volvemos a fojas cero.

En muchas empresas es costumbre que los proyectos vayan pasando por etapas de aprobación sucesivas, de creciente autoridad. De esta forma, la persona con el verdadero poder de decisión termina siendo la última en enterarse del proyecto. Nosotros hacemos exactamente lo inverso: las personas clave toman las decisiones importantes al principio y señalan el rumbo general del proyecto. Una vez que el proyecto está encauzado, las decisiones menores pueden efectivamente ser delegadas.

La técnica del aikido

Una de las bases del aikido y artes marciales similares es que nunca opones tu fuerza a la del atacante; por el contrario, rediriges la fuerza del ataque a un lugar en el que no pueda hacer daño. ¿Qué tiene que ver esto con evitar el Deadline Creep?

La idea es que cuando el cliente plantea “hey, pero sería bueno si añadimos esta última cosa antes de lanzar”, en lugar de oponernos respondiendo “no, no lo haremos” (que con toda seguridad comenzará una pelea), replicamos con: “Es una idea interesante, considerémosla para implementarla en la próxima iteración, cuando ya tengamos feedback de nuestros usuarios”.

No hemos dicho que no será implementada; sólo estamos diciendo que no todavía. Esto permite que ideas que surgen tarde en el proceso — ¡y que muchas veces son valiosas!— no se pierdan en el camino, evitamos que alguien sienta que sus ideas no son escuchadas, y al mismo tiempo reforzamos la idea de que tenemos un plazo que cumplir si queremos que esto avance.

***

Rayar la cancha requiere mucha confianza con el cliente… y también requiere mucha autoconfianza. No es fácil, pero el costo de no hacerlo a tiempo es perder la capacidad de cobrar estos acuerdos más tarde. Ésta es sólo una de las razones por las que un Líder de UX requiere carácter, diplomacia y habilidades de negociación.

Pero dejar claras las reglas del juego (con respeto, humildad y buena onda) es impagable, dado que construimos una dinámica de trabajo que va en favor de los mismos intereses del cliente: el proyecto se termina a tiempo, dentro de los costos, listo para ser hecho realidad. Las fricciones se minimizan: muchas veces el cliente sugiere ideas o cambios al final del proyecto porque nunca nadie le explicó que ya era demasiado tarde. Comunicarse en tiempo real y trabajar codo a codo reduce la cantidad de documentación y registros del proceso y permite que el equipo se enfoque en lo que realmente importa: crear valor.

Próximo artículo de la serie: Productos que no le sirven a nadie.

6 problemas típicos en proyectos UX – Parte 1: Feature Creep

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 stakeholders con 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.
low-fi_prototip016

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.

Siguiente post: Deadline Creep.