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.

¿Qué se necesita para ser un Diseñador Móvil hoy?

Ésta es la traducción del artículo What Does It Take To Be A Mobile Designer Today?, que publiqué en UX Magazine y que apareció también en Mashable.

Las tecnologías móviles llegaron para quedarse, con su propio set de reglas y limitaciones. Al mismo tiempo, es una plataforma que evoluciona velozmente, saludando cada trimestre a nuevas tecnologías y capacidades. No podemos seguir diseñando para mobile como lo hemos estado haciendo con posters y páginas Web. Entonces, ¿cuál es la caja de herramientas y la actitud que necesita un diseñador mobile para salir airoso?

Desafíos y limitaciones

Todo medio o soporte tiene sus limitaciones, y mobile – siendo uno de los lienzos soñados para cualquier diseñador – no es la excepción:

Demasiados dispositivos distintos

Es imposible contar la cantidad de modelos de smartphones y tablets que andan sueltos, cada uno con su propio tamaño de pantalla, densidad de pixeles y botones físicos (sin mencionar las orientaciones de cada uno). Esto significa que no podemos tomar las dimensiones del iPhone 5 y diseñar tranquilamente en base a eso. En mobile Web, el diseño responsive nos permite planificar las variaciones y hacer que el diseño se ajuste a diferentes pantallas con poco esfuerzo. En las plataformas mobile nativas hay mucha menos flexibilidad, así que necesitamos concebir nuestros diseños como tolerantes a las diferencias de pantalla, y documentar la forma en la que dichas variaciones impactan el layout general.

Demasiados sistemas operativos distintos

A la fecha, tenemos tres sistemas operativos móviles importantes: Android, iOS y Windows Phone, en orden de uso (sin mencionar otros que ya vienen en camino, como Firefox OS o Tizen). Cada uno tiene su propio set de patrones de interfaz, inputs externos y lineamientos… y aún no hemos llegado a la variación entre versiones. Con Android las cosas se ponen aún más complejas: la versión de Android que un dispositivo usa estará influenciada por el fabricante del aparato (que, como por si fuera poco, puede superponer su propia capa de interfaz) y el equipo en sí mismo y sus capacidades de procesamiento (y mejor ni pensemos en el tiempo que corre desde que es lanzada una nueva versión de Android hasta que tu celular Android es realmente actualizado).

Incluso si esta fragmentación no hace variar demasiado el diseño, sí influencia la manera en la que los usuarios experimentan un OS y lo que esperan de sus aplicaciones. De muestra un botón: piensa que la experiencia de Android que tienen la mayoría de los usuarios en realidad son las interfaces creadas por TouchWiz (de Samsung) o Sense (de HTC).

Rendimiento y consumo energético

La manera en la que una aplicación es diseñada puede influir grandemente en la cantidad de energía que consume.  O dicho de otro modo, tu diseño puede dejar a tus usuarios sin batería. Efectos visuales innecesarios o demasiado espectaculares pueden necesitar procesamiento gráfico intensivo para correr; una página Web demasiado intensiva en JavaScript o efectos CSS3 puede consumir un montón de energía. Y mientras nuestro smartphone de alta gama recién comprado puede estar corriendo nuestra app suavemente, un equipo de 2 años de antigüedad puede estar sufriendo con ella.

De la misma forma, un consumo innecesario o absurdo de datos puede dejar a nuestros usuarios sin saldo, o en el peor de los casos, causarles enormes gastos en roaming (me ha sucedido). Por otro lado, si sólo probamos nuestra app con una conexión Wi-Fi de alta velocidad, jamás entenderemos cuál es la experiencia de un usuario que sólo puede acceder a una red EDGE.

Éstos son sólo ejemplos para ilustrar el hecho de que un diseñador mobile necesita entender el impacto que sus decisiones tienen en el rendimiento de una aplicación y el uso de los recursos de un dispositivo.

Costos y tiempos de desarrollo

No porque vimos algo en esa linda aplicación que acabamos de bajarnos, significa que es fácil o rápido de implementar. La manera en que diseñamos una app puede significar la diferencia entre cumplir o fallar con los plazos de desarrollo. Si no entendemos el costo asociado a las decisiones de diseño que tomamos, estamos básicamente poniéndoles esa “mochila” a los desarrolladores, y creando fricción para el futuro.

Cosas que hay que desaprender

Muchos de nosotros fuimos formados como diseñadores en una época donde lo digital era absolutamente experimental e incipiente. Esto, probablemente, ha sido el causante de que nos aproximemos al diseño digital desde un punto de vista estático (como cualquiera que exportó HTML directamente desde Fireworks podrá atestiguar). Este desalineamiento aún sigue siendo enseñado en la mayoría de las escuelas de diseño, tradicionalmente lentas para renovarse y adaptarse. Con la llegada del diseño mobile, la brecha se vuelve aún más amplia: las tecnologías móviles traen un lenguaje, un contexto y una forma de uso para la cual casi todos nuestros viejos métodos y herramientas se quedan cortos.

Es tiempo, entonces, de actualizarnos:

Mobile no es un lienzo

Tal como HTML tampoco es un lienzo, en caso de que no lo hayas reflexionado antes. No puedes llegar y lanzarle objetos como si estuvieras haciendo un afiche o una tapa de libro. Sospecho que diseñar en Photoshop no nos está ayudando mucho, dado que lo hemos estado usando para diseñar afiches y tapas de libros por dos décadas. Aún “pintamos” nuestras interfaces, cuando las diferencias de tamaños de pantalla y la naturaleza dinámica de mobile piden un acercamiento totalmente diferente al diseño.

Deja de pensar en pantallas, comienza a pensar en transiciones

Estamos recién empezando a darnos cuenta que diseñar en “pantallas” no da el ancho cuando se trata de diseño mobile. Gracias a aplicaciones como Facebook Paper o Yahoo! Weather, hemos visto que hay una nueva manera de diseñar, basada en transiciones y estados más que en imágenes estáticas.

Las transiciones, alguna vez vistas como eye candy innecesario, se han vuelto el centro de una experiencia móvil. No sólo le dan un tono vivo a la interfaz: son un elemento de diseño en sí mismos. Las transiciones comunican movimiento, espacio, cambio y jerarquía, y son un gran aliado en comunicarle al usuario la meta-estructura del producto. Todo esto vuelve el diseño basado en “pantallas” totalmente obsoleto.

Deja a un lado tu ego de diseñador

Esto es un poco como dejar la adolescencia: No necesitas ser todo el tiempo único y original, en especial si tu idea de ser “único” consiste en rediseñar un patrón de interfaz probado y conocido sólo porque te dieron ganas de hacerlo diferente.

En la mayoría de los casos, apegarse a los componentes y patrones de UI nativos es la jugada más inteligente para terminar una aplicación a tiempo. En lugar de abogar por tu set de controles diseñados desde cero, enfócate en crear una interfaz simple y efectiva, y ocupa tu talento gráfico en crear un branding que realmente brille.

Para inspirarte usa aplicaciones reales, no sitios de “inspiración para diseñadores”

Muchos diseñadores van a sitios como Behance o Dribbble en búsqueda de inspiración para su próximo proyecto móvil. Y claro, siempre encontrarás diseños hermosamente creados en dichos sitios. El problema es que, a menos que seas un diseñador mobile muy experimentado, estos mockups pueden ser sumamente engañosos. La mayoría son sólo eso: mockups que no han conocido la luz, que no han sido implementados en una aplicación real, usada por personas reales. Y es más, potencian la idea de que tú también deberías crear una interfaz nunca antes vista para estar en este juego (ver punto anterior).

Inspírate por aplicaciones reales. Mientras más exitosas, mejor: ésos son los diseños que ayudaron a un producto a crecer, que han sido probados y mejorados en el mundo real, y tienes la certeza de que pueden ser implementados.

Cosas que sí hay que aprender

Conoce tu plataforma

Tal como necesitas entender HTML/CSS para ser un buen diseñador Web, necesitas entender cómo funcionan y son hechas las aplicaciones móviles nativas. Y caramba que son diferentes a las páginas Web. Por ejemplo, el contenido no “fluye” como en las páginas Web, y eso cambia un montón la manera de pensar una interfaz: estamos acostumbrados a que el contenido se readapte automáticamente, y eso en mobile no sucede. No tendrás tampoco la magia de la herencia CSS para separar la presentación del markup. Ah, y se me olvidaba: no existe tal cosa como markup en móvil.

Tendrás que meterte en la documentación para desarrolladores, leer manuales y entender cómo las aplicaciones móviles son confeccionadas, compiladas y publicadas. Tal vez incluso te convenga aprender algo básico de Objetive-C o Java, que al largo plazo es una inversión de tiempo que vale la pena: podrás aprender el idioma de un desarrollador y diseñarás con eficiencia y factibilidad en mente.

Además, te tocará comprender cómo funcionan los App Stores, el proceso de aprobación y publicación, y tips para optimizar lo mejor posible el posicionamiento de la app en dichos buscadores.

Mira debajo del capó

Necesitas saber y entender cómo funcionan e interactúan las tecnologías móviles, sus partes y piezas y los servicios que un sistema operativo pone a disposición de sus apps. Acá tienes una lista para empezar: servicios de localización (basados en Wi-Fi y GPS), Bluetooth, Low-Energy Bluetooth, beacons, cámaras frontal y trasera, micrófono, giroscopio, acelerómetro, vibrador, lector de huellas digitales, reconocimiento facial, de voz y ojos, detección de taps… y la lista crece cada vez más. Y cada nueva tecnología abre un campo completo de posibilidades para nuevas generaciones de aplicaciones. Tu responsabilidad como diseñador es estar al día con la vanguardia.

Descubre qué tan lejos puedes llegar con componentes nativos

En realidad, si los sabes tratar, los componentes nativos de interfaz pueden darte un montón de libertad… pero necesitas saber exactamente cómo y cuándo. Si puedes realizar la mayor parte de tu interfaz con componentes nativos y un grado razonable de personalización, le salvarás una gran cantidad de tiempo a los desarrolladores, para beneficio de todos.

Conoce el flujo de trabajo de una aplicación móvil

Trabaja como trabajan los desarrolladores. Aprende sobre los distintos SDK’s móviles, instálalos y consigue echarlos a andar. Investiga sobre frameworks de integración mobile, como RubyMotion, Xamarin o Titanium. Conoce las nuevas plataformas de integración horizontal, como Parse, Layer o Stripe para los pagos. Averigua por qué Sencha o jQuery Mobile son una mala idea para la performance de apps nativas. Familiarízate con los IDE’s (lo cual probablemente implica que sueltes de una buena vez el Dreamweaver), las carpetas donde los assets gráficos están ubicados, los nombres que deben tener, etc.

Vuélvete un experto en sistemas de control de versiones, pull requests y en cómo usar correctamente sistemas tracker como Pivotal o Jira.

Apréndete los patrones de interfaz móvil, y úsalos

Los tres sistemas operativos móviles más importantes tienen similitudes y diferencias profundas en su modo de entender la interacción con un dispositivo móvil. Sus usuarios esperan distintas cosas de cada uno. Como un diseñador móvil, deberías estar completamente al tanto de dichas diferencias y detectarlas al vuelo (por ejemplo: ¿en qué se nota que el nuevo Skype para iOS toma elementos de UI de Windows Phone?).

No te quedes pegad@ con una sola plataforma móvil. Pruébalas todas, o al menos usa Android e iOS como tu teléfono principal durante 6 meses cada uno. Yo lo hice, y es fantástico: entiendes cosas de cada plataforma que jamás entenderás con el uso casual o mirando pantallazos. Además, cambiar te hará bien: los fanboys son los peores diseñadores mobile.

Documenta y explica tu UI

Ahora que sabemos que las pantallas no cuentan toda la historia, tendrás que documentar diferentes estados, transiciones y animaciones, así como la forma en que la app reacciona a los datos (o la falta de ellos) y al entorno en general. Llena tus mockups con notas y comentarios, entrega ejemplos de animación, y planifica para la orientación del dispositivo.

Adopta Lean UX en la fase de diseño

Un diseñador moderno debería ser un diseñador estratégico. Así que tu meta, más que simplemente “hacer algo bonito”, es asegurarte de que el diseño refleje todo lo que el equipo ha aprendido acerca del producto. Prioriza los prototipos rápidos para tener insights tempranos de lo que quieren los usuarios. Guarda el trabajo artístico detallado para más adelante. Asegúrate de que todo lo que se diseña está alineado con la propuesta de valor central y con las necesidades de tus usuarios.

En Continuum tenemos una metodología para Lean UX que tú también puedes usar en tu proyecto.

Adopta Agile UX a la hora de implementar

No puedes entregarle tus mockups al desarrollador y luego olvidarte del asunto, dado que la mayor cantidad de requerimientos de diseño surgirán a la hora de desarrollar. Siempre hay pantallas que no fueron consideradas previamente, nuevas transiciones y cambios de estado que requieren nuevos assets gráficos, o como mínimo una validación de diseño para asegurarse que todo está en orden. Ello requiere que estés presente y respondas en tiempo real.

Así que siéntate al lado de los desarrolladores, preparado para intervenir en el diseño cuando se necesite. De esta forma, los desarrolladores sólo tendrán su mente puesta en desarrollar, y no tendrán que tomar decisiones de UX para llenar tus vacíos.

Algunos tips extra para Mobile Web

Responsive no es la panacea

Por más que queramos creerlo, el diseño responsive no es la solución milagrosa para adaptar cualquier diseño a mobile. En algunos casos tiene sentido, en otros no. Es tu responsabilidad saber los escenarios en los que se requiere una solución móvil dedicada, y dónde un par de ajustes responsive permiten mantener una sola base de código. ¿Y si estás diseñando solamente para Web tradicional? CUEEEC, ya no existe la “Web tradicional”. Tu página será vista por dispositivos móviles de todas formas. Planifica tu layout para que se adapte armónicamente a diferentes tamaños de pantalla (mal que mal, responsive no es sólo para móviles). Y fíjate bien en los tamaños de assets: como ya dijimos antes, esa linda imagen de 1Mb que se te ocurrió poner de fondo puede significarle un gasto de datos, tiempo y plata a tus usuarios móviles.

Usa CSS y JS con precaución

Yo sé. Es lindo poder usar todas esas gradientes, animaciones, transiciones y sombritas de CSS3. Es lindo usar parallax. El problema es que estos elementos pueden estrujar la batería de un teléfono móvil, y te puedo asegurar que tu página no es más importante que la capacidad de realizar llamadas o enviar mensajes.  Mientras más efectos acumules, más trabada se sentirá la interacción y más energía consumirá.

Incluso los (aparentemente inocentes) selectores CSS3 pueden impactar la performance en equipos de gama baja. Prefiere siempre ID’s y clases, y trata de mantener baja la jerarquía de selectores. Así que, si te las puedes arreglar con #submit en vez de .main .container .form:first-child > div .submit, mucho mejor.

Usa las herramientas correctas

Esto de ninguna manera es una lista definitiva, y encontrarás alternativas fantásticas para muchas de ellas, pero aquí van varias herramientas realmente apropiadas para diseño móvil (algunas son gratis, algunas son basadas en Web, y muchas de ellas son sólo para Mac):

  • Sketch para diseño gráfico y exportar en alta resolución (@2x). Sketch es probablemente el heredero del ahora descontinuado y obsoleto Adobe Fireworks, y ha sido construido con mobile en mente.
  • LiveView y Sketch Mirror (un complemento de Sketch) para poder visualizar tu pantalla de computador en tu teléfono. Las cosas se ven y se sienten bastante distintas en un dispositivo móvil. Además, podrás fácilmente probar el tamaño de controles y áreas de interacción,
  • Origami (de Facebook) y Quartz Composer para interacción móvil y prototipado de animación. Esto es lo más cerca que podrás llegar a simular una interfaz nativa sin escribir código, y aunque es difícil de manejar al principio, te dará una buena idea del tipo de pensamiento lógico que deben usar los programadores.
  • PaintCode para crear gráficos e interfaces que pueden ser exportados directamente a código nativo Objective-C.
  • Software Web para mockups. Hay montones: Balsamiq Mockups, Axure, UXPin, Moqups, Proto.io, etc.
  • Flinto o Proto.io para crear mockups interactivos instalables en tu iPhone. Ofrecen una simulación bastante convincente de aplicaciones reales (aprovechando la capacidad de Safari de añadir botones Web a la pantalla de inicio).
  • ImageOptim para comprimir (en algunos casos, dramáticamente) tus archivos PNG y JPG sin perder calidad.
  • Software de control de versiones, Git o Mercurial dependiendo del entorno de trabajo de los desarrolladores. En lugar de enviarle un ZIP a los programadores, envía directamente tus imágenes como commits.

Todo esto ya está obsoleto

En realidad no tanto, pero el ritmo al cual avanza la tecnología móvil volverá todo este artículo sumamente incompleto, en un tiempo muy corto. A la vuelta de la esquina están ya los desafíos de diseñar para wearables, dispositivos inteligentes, hogares inteligentes, sensores… Si hay un talento que un buen diseñador mobile debe tener por sobre todos los demás, es el ser dinámico, flexible, proactivo y sumamente curioso. Ésta debería ser la última guía que leas antes de salir a aprender en terreno. Es la única forma de que te asegures un asiento en esta montaña rusa.

Si estás interesado en aprender más sobre el proceso de diseño para mobile, consulta la presentación de nuestro workshop de UX para móviles.

¿Cómo funciona el simulador de impuestos?

Este post es una explicación de como funciona el Simulador de Impuestos que creamos para que cualquier PYME pueda calcular el calcular el impacto aproximado de la reforma tributaria para su caso particular. Si eres socio de una empresa o tienes curiosidad para ver el impacto de la reforma en las empresas, debieras darle una mirada.

Supuestos

Si hiciéramos un simulador que funcione para todos los casos de manera precisa, terminaríamos con el equivalente del formulario de declaración de impuestos y tendrías que pedirle ayuda a tu contador para llenarlo. Por tanto, fuimos prácticos y creamos una herramienta simple que aproxima tu caso usando los siguientes supuestos:

  • La empresa tiene uno o mas socios, quienes participan de formas iguales en retiros de utilidades y quienes se pagan el mismo sueldo.
  • La empresa NO está acogida al regímenes tributario 14ter, ni a la renta presunta.
  • No se considera el impuesto de segunda categoría pagado por cada socio (en realidad descontado en su liquidación de sueldo, tal como le ocurre a todo el mundo que trabaja de manera dependiente).
  • Se considera el impuesto de primera categoría pagado por la empresa (20% de las utilidades este año 2014).
  • Se considera el diferencial en el global complementario de los socios producido por los retiros. Esto asumiendo que los socios pedirán a la empresa que cubra estos impuestos extras que pudieran producirse por haber retirado utilidades.

Para calcular la diferencia en el resultado, se consideran los cambios de la reforma en el siguiente orden:

  1. Eliminación de regímenes especiales 14bis y 14quater.
  2. Aumento de tasa de primera categoría del 20% al 25%.
  3. Incremento (o decremento) en el diferencial del global complementario producido por la renta atribuida (eliminación del FUT).

Los cálculos

Luego de ingresar la información el resultado se muestra gráficamente como en este ejemplo:

Continuum___ASECH_____Simulador_de_Impuestos__Reforma_tributaria_2014_Chile_

En primer lugar se calculan los impuestos hoy (“2014”)  considerando el 20% sobre utilidades más los pagos del global complementario de los socios, si es que se declaran retiros. Ese valor es el que aparece como “Impuestos hoy (2014) antes de la reforma”

Luego, en caso que el escenario incluya el uso del 14bis o el 14quater, se suma el efecto de retirar estas franquicias (es decir, de revertir el ahorro de impuestos que estas herramientas le generan hoy a la empresa). Esto aparece en la barra “…más impuestos por la eliminación del 14bis/quater” si es que aplica a tu caso (En el ejemplo de más arriba no aplica y por ende no aparece dicha barra).

Lo siguiente es calcular el 5% adicional sobre utilidades que pagará la empresa, por el aumento del 20% al 25% de la tasa de primera categoría.  Este valor es representado por la barra “…más el incremento del 20% a 25% (tasa de 1ra cat.)”

Por último se calcula el impacto en el global complementario de los socios bajo la modalidad de renta atribuida que incluye la reforma, que es el corazón de la eliminación del FUT. Este impacto puede ser favorable (devolución de impuestos) o desfavorable (impuesto adicional a pagar).

En el caso que hayan devoluciones, se representa por la barra “…menos la devolución automática (por eliminación del FUT)”. En el caso que haya impuesto adicional a pagar, se representa por la barra de “…más la tributación por utilidad atribuida (por eliminación del FUT)”. En el ejemplo el efecto es mínimamente favorable y puede verse en la barra verde correspondiente.

Todas las barras sumadas generan la última barra correspondiente a los impuestos a pagar con reforma. De esta forma se puede saber si la reforma afecta o no a la empresa y también se puede y apreciar muy rápidamente cuáles son los factures que más afectan.

Más información

Todo lo anterior es una descripción general de todos los cálculos, pero muchos de ellos tienen su propia complejidad. Por ejemplo, el cálculo del global complementario depende en qué tramo de ingresos, sumando sueldo y retiros (o renta atribuida en el caso con reforma) caen los socios. A cada tramo de ingreso de corresponde una tasa marginal, pero el cálculo no es tan fácil como llegar y multiplicar, pues también se debe descontar un monto  (que básicamente representa el impuesto de la porción de la renta que cae en tramos anteriores y por tanto se grava con tasas menores que la tasa marginal).  De igual forma funciona el impuesto de segunda categoría.  Por otra parte, el 14bis y el 14quater no tienen efecto sobre utilidades retiradas. También hay que considerar que el 14quater tiene un límite máximo de ingresos para los que aplica la franquicia (1440 UTM) y mas allá de eso se aplica el impuesto de primera categoría de manera normal. Todos esos son detalles que están incluidos en los cálculos descritos más arriba.

Para informate de todos estos detalles te recomendamos consultar con tu contador y/o asesor tributario. O si eres curioso y/o puedes leer código CoffeeScript puedes mirar el corazón del simulador, que está publicado en el github de Continuum.