UX, negocio y tecnología en un solo equipo

¿Cómo llegamos a esto?

Alguien me dijo por ahí: “A veces el sentido común no es tan común como supone ser” lo que me pareció muy cierto. Lo recordé cuando quise empezar a escribir este post, cuyo objetivo es contar como ha evolucionado el proceso de UX que realizamos en Continuum.

En un inicio, nuestros primeros procesos UX no eran tan conectados con lo técnico (qué loco ¿no? si más de la mitad de Continuum son desarrolladores). Algunos del equipo UX que si escribían código eran capaces de aterrizar el diseño en aquello que es factible de implementar; al menos en lo web, donde los frameworks como bootstrap son un gran aliado. Sin embargo, cuando nos pasábamos al lado de diseños nativos para dispositivos móviles, venía el problema.

Por otro lado, a veces nos piden estimar desarrollos para aplicaciones cuyo diseño ya está hecho. Y nos encontramos con que en el diseño de aplicaciones Android se usaron componentes y transiciones que son típicos de un iPhone. Aquí claramente los involucrados en el proyecto eran fans Apple, el diseñador también lo era, o simplemente cuando diseñaron, aún no estaban tan difundidas e interiorizadas las guías gráficas para cada sistema operativo. No se pensó que el usuario Android iba a odiar que lo obligaran a aprender de nuevo algo que él estaba acostumbrado a hacer de otra forma en su celular. Y esto nos pasó también con nuestros propios diseñadores (oh sí, quien esté libre de pecado que tire la primera piedra).

¿Por qué? Porque por un lado, el diseñador no quiere que su creatividad esté limitada por lo técnico y busca replicar aquello que identifica/cree que está bien resuelto en algún lado. Por otro, el técnico no quiere que el diseñador se vaya en volada diseñando algo que es muy complejo, se puede hacer de una forma más simple, no es factible de implementar, no está acorde a las guías gráficas de cada sistema operativo.

Entonces esta tensión entre el diseño de la interfaz y la implementación comenzó a generar fricción, gracias a los problemas de comunicación. Llegar con una pregunta de ¿Se puede? sin dar mayor contexto a un desarrollador, es tomarlo por sorpresa, le preguntan algo puntual y no entiende el valor que la funcionalidad prestaría al cliente final. Sobre todo si el mismo desarrollador no fue parte del proceso de UX. Ello impidió que sugiriera alguna alternativa en el momento apropiado y casi siempre el diseño estaba bien adelantado cuando llegaba a ser validado técnicamente y se intentaba marcar el check de “es factible”.

Tuvimos que pasar por proyectos UX terminados (con clientes contentos y nosotros también) que al llegar a la fase de estimación/implementación, detectábamos que en el diseño habían quedado cosas afuera y otras que explotaban en la cara del desarrollador (les aparecían sorpresas de diseño que sonaban más a capricho que algo con verdadero valor), para llegar a concluir que de ahora en adelante, incluiremos dentro de nuestro proceso UX a un desarrollador, siempre.

Y así, comenzamos a hacer procesos de experiencia de usuario, con un diseñador UX/líder del equipo más un desarrollador (por nuestra parte). Dependiendo de la naturaleza del proyecto invitamos a uno o más compañeros desarrolladores a participar de las reuniones clave, para que se empapen del por qué se necesita qué y a quien esto hará feliz. Cuando los diseñadores están creando, validan inmediatamente con el desarrollador y éste les aporta feedback valioso de como hacer lo mismo con un menor esfuerzo de implementación, o llegan juntos a encontrar un punto intermedio. Al conectar estos perfiles el equipo se potenció: tanto diseñadores como desarrolladores comenzaron a aprender unos de otros (incluso descubrimos desarrolladores con talento natural para procesos UX) y las ventajas que generó esta unión han sido muchas. Por ejemplo, al estar dentro del proceso tanto los técnicos del cliente como mis compañeros, se logra identificar rápidamente, si la data necesaria para alimentar una vista existe, dónde y cómo está, o saber si es posible proveerla de manera diferente, etc. Es decir, que empiezas a levantar tempranamente qué necesitas antes de siquiera terminar la fase de diseño de interfaz. Y lo que levantas por adelantado va más allá de qué servicios o de qué data vas a necesitar.

La tensión natural entre el diseño y el desarrollo se relajó. Nuestros compañeros desarrolladores se convirtieron en el cable a tierra cuando el diseño era muy soñador. Pero no sólo eso. Los desarrolladores también aprendieron a soñar y a tener la habilidad de ser flexibles, tomándolo como un desafío técnico, comprendiendo aquello que cubre una necesidad, tiene una razón y hace feliz a un usuario de nuestro producto. Si a esto sumamos que en nuestro proceso de UX deben ser partícipes representantes del negocio, entonces ya podrán imaginar el resultado: Negocio, diseño experiencia de usuario y tecnología, todos trabajando juntos para conocer a clientes y sus necesidades, brindando soluciones factibles y que realmente encanten, dando valor al usuario final.

Es así, que descubrimos en la práctica que el trabajo de equipo mejora (nosotros, el cliente e incluso con sus proveedores), se genera espacio para la innovación y los integrantes del equipo crecen al tener acceso a diferentes puntos de vista. Estoy segura continuaremos descubriendo otras ventajas de esta unión; porque seguimos mejorando nuestra forma de hacer las cosas.

¿Por qué no se nos ocurrió antes? ¡si era obvio! –debía haber un desarrollador siendo parte de los procesos de UX–. Simplemente porque a veces el sentido común, no es tan común como supone ser 🙂

El valor de los usuarios

Cuando empecé profesionalmente esta carrera, hace más de 10 años, pocas veces escuché la palabra usuario con la misma fuerza que hoy se escucha. Corrían otros tiempos, cuando internet recién cumplía un poco más de una década en la vida de las personas y empezaban a aparecer las primeras “redes sociales”. Se hablaba bastante de la web 2.0 aún con tono futurista, cuando en realidad estábamos ad portas del lanzamiento del primer iPhone que abriría el paso definitivo a todo lo que hoy nos parece tan cotidiano y natural.

Pareciera ser entonces que en ese tiempo, los diseñadores que nos habíamos metido a este atractivo mundo digital, era sólo para hacer más bonitas las cosas y aportar con nuestro “buen gusto”. Porque haciendo un poco de memoria, los diseñadores parecíamos estar enfrascados en una competencia sin sentido entre quién hacía el botón más brillante y realista o quién hacía la mejor sombra, y otros tantos desafíos estéticos inútiles. También porque tanto los líderes de proyecto, como los mismos clientes estaban convencidos de que el éxito de su portal o sitio web dependía en gran parte de eso. Quizás no estaban tan equivocados (lo “bonito” algo ayuda), pero en gran parte sí lo estaban, porque la estética no es más que un atributo de lo que hoy entendemos como engagement, pero vacío. Y precisamente no es ese el aspecto que más importa, sino que muchos otros.

Luego empezamos a escuchar de usabilidad, navegabilidad, accesibilidad, funcionalidad y un largo etcétera. Nielsen y Norman fueron los pioneros, pues llevaban un buen tiempo estudiando sobre esto para sentar las bases sobre todos estos temas. Aspectos y atributos fundamentales que hoy son claves para lograr una buena experiencia de usuario.

¿Pero para quién hacíamos y hacemos esto? Para las personas, es decir para los usuarios. ¿Y conocíamos realmente a los usuarios, nos preocupábamos verdaderamente de ellos?

Hoy, cuando las posibilidades de interacción humano-máquina se han ampliado notablemente (las que antes dependían casi sólo de un computador), hemos potenciado nuestra creatividad y conocimiento. En estos tiempos en que contamos con múltiples dispositivos para interactuar y consumir información, por fin estamos logrando ver que allá al final, en el resultado de lo que hacemos, hay una persona esperando por una ayuda o solución para su problema, una persona igual que nosotros, que tiene una vida, una familia, amigos, una rutina y una ocupación, que tiene limitaciones, frustraciones y preocupaciones como también sueños y esperanzas. Hoy por fin, nos estamos preocupando por todos los aspectos que influyen en la experiencia que esa persona tiene con respecto a un producto digital (de hecho, así lo llamamos hoy porque ya no es sólo un sitio web, ahora es un producto que tiene un fin mucho más preciso). Nos enfocamos en diseñar y poner nuestro talento en cosas que sirven, cosas que entretienen, cosas que cambian la vida de las personas o buscan hacerlas mejores, porque están hechas y pensadas para las personas, en esas personas que los diseñadores tenemos la misión de entender y conocer bien.

Por otra parte en un ámbito comercial, el mercado ya había empezado a darse cuenta desde mucho antes, de la importancia que tiene la satisfacción del consumidor. En la venta de productos y sobre todo de servicios han resaltado los negocios y marcas exitosas a nivel mundial, por el esfuerzo que han puesto constantemente en la felicidad de sus clientes, optimizando el tiempo, mejorando el trato cordial y cercano, la dedicación especial, la transparencia, es decir la preocupación absoluta en ellos. Porque al final, todo lo que invierten y se preocupan, por consecuencia forma fuertes lazos de fidelidad y preferencia, sobre todo porque más allá del éxito económico –lógico– como retorno a la inversión, el enfoque en las personas se nota y sólo puede traducirse en éxito.

De eso mismo entonces nos preocupamos cuando hacemos diseño centrado en el usuario. Apuntamos a maximizar sus experiencias positivas y recoger lo negativo para mejorarlo constantemente.

Por lo tanto sugiero que antes de tomar un lápiz y tirar una línea sobre un papel, identifiquemos y conozcamos a los usuarios para quien vamos a diseñar. Y eso lo podemos hacer a través de las diversas técnicas de user research que existen en UX como los mapas de empatía, la construcción de user personas, las entrevistas etnográficas o los focus groups, que nos sirven para determinar sus necesidades y técnicas como las encuestas de satisfacción, las evaluaciones heurísticas, las pruebas de usabilidad, los tests de guerrilla o los a/b testings para medir la experiencia.

Sin embargo, más allá de las técnicas que utilicemos, lo importante es: salir a la calle, acercarse a los usuarios, escucharlos, estudiarlos, comprenderlos, conocer que los motiva y entender como se comportan, porque diseñar sin conocer bien para quién lo hacemos no tiene sentido.

Por qué lanzamos Residence, nuestro programa especial para Startups

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?

Continuum Residence