Kambrica nos aportó gran valor al ayudarnos a ponernos en el lugar de los clientes e incorporar la lógica de UX en la transformación de nuestra forma de dar servicio.

Gerente Propuesta de Valor

Compañía multinacional de seguros y servicios financieros

* Este proyecto se presenta de forma anonimizada, en el marco de acuerdos de confidencialidad corporativa.

Cuando el proyecto entra a una reunión y sale convertido en una máquina de quemar presupuesto

Cuando una organización corporativa inicia un proyecto digital, el problema entra a una reunión y sale convertido en una estructura enorme de recursos, plataformas y meses de desarrollo. No porque sea realmente necesario, sino porque los incentivos de la industria están puestos ahí.

Las software factories facturan crecimiento del proyecto: más equipos, más horas, más complejidad. Nunca menos. En este caso, la organización empezaba las reuniones con una conclusión tomada: “necesitamos una App”. Los usuarios llamaban para consultar información de sus productos financieros y no utilizaban el sitio web existente, que “había quedado viejo”.

Ante este pedido, los comerciales de las agencias se frotaban las manos: “¡Claro que necesitás una App!”. Y tiene que ser para iPhone, Android y tablets. Con un backend moderno, QA, DevOps, múltiples equipos y varios meses de ejecución. En minutos, una idea se había transformado en un equipo de 12–14 personas.

Nosotros hicimos algo distinto: redujimos el problema antes de escalar la estructura. Porque ejecutar rápido la primer interpretación que se tiene del problema, no es agilidad: es desperdicio a gran velocidad. Y evitarlo, nos llevó tan solo una hora.

Una sola reunión alcanza para desenredar el proyecto

Aplicando nuestra metodología XDM (Experience Decision Making), trabajamos separando tres capas que en la mayoría de los proyectos aparecen mezcladas desde el inicio: hechos, interpretaciones, y propuestas de solución.

Ese análisis reveló un dato que nadie había considerado: la frecuencia de consulta de los usuarios estaba entre seis meses y dos años. Eso invalidaba la hipótesis de desarrollar una App: los datos mostraban que a los usuarios se les “llenaba” el teléfono cada tres meses… proponiéndoles eliminar las Apps que no usaban.

El proyecto tenía que contemplar entonces una primer etapa de investigación UX estratégica para entender por qué los usuarios rechazaban el sitio existente y preferían llamar. Sin esa información, cualquier iniciativa era una apuesta a ciegas.

El cliente pensaba que el sitio era “viejo” y “feo”. Quizás tenía razón. Pero las verdaderas respuestas estaban delante de las pantallas.

Mientras que la interfaz (UI) vive dentro de las pantallas, lo que los usuarios experimentan (UX) es lo que sucede delante de ellas.

Ese fue el foco de la investigación estratégica que en tan sólo dos semanas, reveló el problema de fondo: el sitio mostraba menos de la mitad de la información que los usuarios necesitaban para sus procesos de toma de decisiones. Por eso los usuarios llamaban.

La interfaz no estaba fallando por cuestiones tecnológicas o estéticas.
Sino porque no respondía las preguntas que tenían los clientes.

Algo que ninguna agencia se había propuesto atender, perpetuando la trampa de todo RFP.
Después de 4 a 6 meses, el cliente habría recibido exactamente lo que pidió. Pero que no era lo que realmente necesitaba.

Reducir complejidad e incertidumbre antes empezar la ejecución

Nuestra metodología parte de un hecho: los grandes proyectos no fracasan por razones técnicas. Fracasan porque las complejidades se revelan y atienden recién cuando toda la estructura ya está en movimiento.

Por eso trabajamos despejando complejidades de UX, institucionales y tecnológicas desde el inicio del proyecto.

Porque verdadera agilidad no es ejecutar apurados el primer plan que parece tener sentido: es tener la cintura para cambiar dirección cuando aparece nueva evidencia.

1. Complejidades UX: la distancia entre el Negocio y las personas

Para identificar y reducir esta distancia, trabajamos relevando procesos reales de toma de decisiones, entendiendo qué información necesitan los usuarios, cómo la interpretan, y a qué procesos o herramientas de soporte terminan acudiendo.

Eso permite redefinir la arquitectura de información, los criterios de visualización y las prioridades del producto antes de cristalizar decisiones de diseño UI y desarrollo.

2. Complejidades institucionales y políticas

En proyectos corporativos, gran parte del desgaste aparece cuando la solución ya está avanzada y comienzan los rechazos internos: branding, marketing, compliance, stakeholders.

Por eso desde el primer día, realizamos un mapa político de todas las áreas afectadas. Las incorporamos tempranamente en el proyecto en tracks paralelos, despejando todos los riesgos (tales como inconsistencias entre manuales y criterios internos) antes de que impacten en el proyecto.

Nuestro resultado son proyectos sin retrabajos políticos ni ciclos interminables de aprobación.

3. Complejidades IT: factibilidad técnica

En la industria de Banca, Finanzas y Seguros, existe una capa tecnológica crítica de sistemas legados, cuyos responsables deben estar involucrados desde el primer momento. En este caso, la cantidad de información financiera involucrada generaba esperas incompatibles con la experiencia que el producto necesitaba entregar.

Nuestra solución fue construir un motor de front-end inteligente y agnóstico, capaz de reutilizar información ya obtenida, reducir roundtrips innecesarios y realizar carga progresiva de datos sin bloquear la navegación y uso del sistema.

Eso permitió resolver performance sin degradar experiencia, ni sumar más arquitecturas a un stack de por sí sumamente complejo.

Resultados

Mientras las agencias proponían estructuras enormes y costosas para “cumplir con el pedido”, Kambrica superó los objetivos con un equipo reducido, foco estratégico y dirección clara.

Porque nuestros incentivos no están puestos en colocar gente ni vender horas, sino en resolver el problema correcto.

En este caso, el proyecto no necesitaba una App, ni una plataforma tecnológica de punta. Necesitaba entender qué estaba fallando entre la organización y sus clientes.

Sin diagnóstico y dirección, la velocidad solo escala el error.

La mayoría de las organizaciones no necesita más velocidad.
Necesita mejores diagnósticos antes de escalar estructuras, presupuesto y complejidad. Eso es lo que hacemos.

Si sos responsable del éxito de productos o proyectos y sospechás que el problema que tienen entre manos está siendo interpretado de forma incorrecta, hablemos.

Podemos ayudarte a verlo antes de que el costo, la complejidad y el riesgo político sigan creciendo.

La entrada Banca, Finanzas & Seguros se publicó primero en Kambrica.

Un argentino en Helsinki

Allá por marzo de 2016, tuve la suerte de poder participar de la conferencia Interaction 16 en Helsinki, Finlandia. Ya al bajar del avión, tuve mi primer choque cultural: la organización del evento había logrado poner un stand en el aeropuerto. Algo que habíamos soñado cuando organizamos Interaction South America 2014 en Buenos Aires, pero que requería de un apoyo oficial concreto, en lugar del simbólico que recibimos. En Helsinki, en cambio, la ciudad apoyó al evento a tal punto que en el stand entregaban tarjetas precargadas para transporte público, de manera que pudiéramos recorrer y conocer la ciudad durante una semana entera.

Mi segundo choque cultural fue cuando llegué a la parada del colectivo. No había nadie. Después de esperar un par de minutos, empecé a dudar de si esa era la parada correcta. El cartel coincidía con la línea que tenía que tomar, pero la situación me resultaba sospechosa. Entonces recorrí el resto de la dársena, acostumbrado –como en Buenos Aires– a que a veces los carteles queden como resto arqueológico luego de que la línea haya mudado su parada.

No habiendo encontrado otra parada de la línea, volví a la original. Y después de un ratito llegó una persona muy abrigada, a quien le pregunté si la línea pasaba por ahí. Miró el cartel, me miró como si fuera imbécil, y me dijo: “Sí, claro. Ahí dice que pasa”.

“¿Y tarda mucho?”, pregunté. Me volvió dedicar la misma mirada, abrió en su teléfono la aplicación de Google Maps – que mostraba los horarios oficiales– y me dijo: “Pasa en cinco minutos”.

Y cuatro minutos y medio después, llegó desde el aeropuerto un enorme contingente de gente calentita, que había estado esperando a resguardo el horario del colectivo. Porque en Finlandia, los transportes siguen la grilla de horarios. Cosa que me pareció surreal: en Argentina, las tablas de horarios son meras sugerencias, y es habitual estar esperando media hora un colectivo que supuestamente pasa cada tres minutos.

El último choque cultural que tuve fue cuando, ya en el bus, otro pasajero notó mi ansiedad tratando de ver las paradas por las que pasábamos y contrastarlas con las instrucciones que llevaba anotadas. Me preguntó si me podía ayudar, y después de un par de veces accedí. Le conté adónde iba y me dijo que iba para el mismo lado, y que me iba a acompañar.

“Cuando nos bajamos, el gordo me asalta”, pensé. Pero no. Resultó que era una excelente persona que quería que yo tuviera una muy buena primera experiencia en su ciudad.

Me contó que se llamaba Toti, y que era docente de atención al cliente en el secundario. Porque el sistema educativo finlandés tiene que preparar a la gente para la vida real, y entiende que hay gente que no va a seguir la universidad después del secundario. Por ejemplo, va a trabajar en una peluquería. Y un peluquero tiene que saber atender a la gente.

Yo empecé mi carrera como diseñador de interacción en 1996, diseñando simuladores de negocios para formación gerencial. Atención al cliente era un tema recurrente, y teníamos cursos para gente que ya estaba trabajando (en ocasiones hacía años) sin formación alguna. En Finlandia me vine a enterar de que era parte del programa educativo oficial. Mientras que en estas pampas, todavía seguimos discutiendo sobre programas educativos que ya cuando éramos chicos olían a naftalina.

Toti me contó la razón por la que se dedica a hacer este esfuerzo para cuidar la experiencia que tienen los turistas recién llegados a Helsinki. Según él, hay dos tipos de países: los países donde todo funciona, pero nada se puede cambiar; y los países donde nada funciona, pero todo se puede conversar. Me explicó que Finlandia pertenece a la primera categoría: si sabés cómo entrar en el sistema, el sistema te lleva solo. Pero si no conocés el sistema, quedás afuera. Entonces, cuando ve a un turista perdido subirse al bus en el que él viaja, se toma con alegría la oportunidad de ayudarlo a entrar en el sistema.

El Modelo de Lewis

La muy acertada observación de Toti, tiene su reflejo académico en el Modelo de Lewis de Comunicación Intercultural, que clasifica las culturas del mundo en tres grandes estilos de comportamiento:

• Lineal‑activo: personas que planifican paso a paso, hacen una sola tarea a la vez, siguen cronogramas, valoran la puntualidad y la lógica. Es el estilo típico de países nórdicos y aquellos que impulsaron la industria informática.
• Multi‑activo: culturas más emocionales, relacionales, improvisadoras. Realizan varias tareas simultáneamente; priorizan las personas por sobre los procesos formales. Promueven la sociabilidad, la flexibilidad, la persuasión, y una gestión del tiempo policrónica. Alrededor de este polo encontramos a los países latinoamericanos, así como a los que más peso han tenido en definir nuestra cultura: España, Portugal e Italia.
• Reactivo: personas que primero escuchan y luego responden; evitan confrontaciones, valoran la armonía y el respeto. Predomina en Asia oriental.

Esta distinción entre culturas nos puede ayudar a entender por qué las construcciones que funcionan en una cultura lineal, pueden estar destinadas a fallar en una cultura multi‑activa. Como es el caso de las recetas que se suelen aplicar para la transformación digital.

Cuando nada funciona y nada se puede cambiar

En Finlandia, los colectivos cumplen el horario. Todo funciona como un reloj, pero nada se puede acomodar. En cambio, en nuestros países iberoamericanos, los transportes no cumplen el horario, nada funciona del todo… pero todo se puede charlar.

Excepto las cosas que tuvieron la desgracia de ser automatizadas.

Porque los procesos son producto de la cultura que los parió. Y en culturas donde nada funciona pero todo se conversa, informatizar un proceso “formal” cristaliza la parte menos funcional del sistema, justo esa que nunca se seguía. El resultado: sistemas que no funcionan… y que tampoco se pueden cambiar.

Es la peor parte de nuestra cultura, traducida a procesos y codificada con rigidez, la peor parte de la cultura que inventó la informática.

El mundo según la informática

La informática nació en culturas lineales. Culturas en donde el tiempo se entiende como una secuencia ordenada de eventos. En donde entre lo que tengo y lo que quiero, hay pasos que se recorren en orden.

Para nosotros, eso no es evidente. En nuestra forma de ver las cosas:

• las prioridades cambian según la ansiedad del momento,
• entre hoy y mañana puede pasar cualquier cosa,
• el horizonte máximo de planificación es hasta las próximas elecciones,
• y el trámite depende de la persona con quien hablaste.

En nuestro mundo, los procesos no existen realmente hasta que alguien los necesita. Y cuando surge la necesidad, el verdadero proceso se activa: con una llamada, un contacto, un favor, un atajo.

Es algo muy común en nuestros países: el proceso documentado suele ser una abstracción que no describe toda la complejidad del proceso real. Lo que realmente funciona está en la cabeza de cada empleado, que fue armando su parte a fuerza de prueba, error y supervivencia laboral. Los empleados no ejecutan los procesos del sistema: ellos son el sistema.

Cuando el procedimiento es ficción

El problema es que los sistemas informáticos que se proyectan en este contexto, suelen tomar el procedimiento formal como todos los “requerimientos” que hay que considerar para el desarrollo.

Pero el procedimiento que ha documentado el Negocio, muchas veces es más bien un mandato aspiracional: un “deber ser” que no contempla atajos, decisiones informales ni las negociaciones constantes que hacen que el proceso realmente funcione.

El verdadero proceso nace en las personas que tienen que ejecutarlo. Cada una, a su manera, va aprendiendo qué se puede hacer, qué no y cómo compensar los huecos. Lo ajustan con la práctica, con llamadas, con anotaciones en papeles, con “hablá con Marta que ella sabe”.

Aunque una organización tenga una “cabeza”, en nuestras culturas, la verdadera inteligencia que mantiene todo funcionando está distribuida e invisible. Es un poco como el sistema nervioso del pulpo, donde los tentáculos poseen su propia inteligencia: la mayoría de las neuronas (aproximadamente el 60 %) está en los brazos, no en el cerebro central, lo que les permite actuar con autonomía y tomar decisiones locales.

El mayor desafío de la transformación digital, es que las máquinas no pueden improvisar

La mayoría de las organizaciones latinoamericanas no se gestionan con objetivos, sino con declaraciones nebulosas: “hay que terminar esto para mañana”, sin sujeto, sin responsables, sin consecuencias claras.

Nosotros, los humanos, podemos navegar ese mundo. Las máquinas no. Las máquinas necesitan precisión, claridad, estructura. Por eso, los intentos de transformación digital en culturas que viven de la improvisación terminan en sistemas que no sirven, y en personas que buscan cómo rodearlos.

El primer paso de una transformación digital real no es técnico, es cultural. Y requiere sinceramiento: relevar cómo funcionan realmente las cosas, no cómo nos gustaría que funcionaran. Reconocer el proceso real, no el ideal. Entender la red informal de inteligencia que permite que algo tan disfuncional… funcione.

La UX interna y la transformación cultural

Las gerencias construyen en su visión un mundo coherente, que por necesidad no es el que existe hoy: es la visión del futuro. Declaran objetivos, empujan iniciativas, y cuando llegan resultados, consideran que son producto de su visión.

Pero los resultados no vienen de lo que se declara. Vienen del esfuerzo de la organización por hacer algo con eso. Viene de las experiencias, vivencias y decisiones de las personas que trabajan en la organización. Vienen de la UX interna: de lo que los usuarios internos experimentan.

Y ahí entra nuestro rol como consultores de Experiencia de Usuario estratégica. No solo diseñamos sistemas: diseñamos comprensión, y como dice Jorge Arango, somos generadores de coherencia. Construimos puentes entre lo que la gerencia quiere que pase, lo que cree que pasa, y lo que realmente pasa. Ayudamos a ver la inteligencia que fluye por debajo del organigrama. A ver el valor humano y de negocio en la improvisación, en la flexibilidad, en la capacidad de adaptación.

El primer paso de la transformación digital no es “pasar el proceso a la app”. Es conocer y entender los procesos reales. Es mapear cómo realmente funcionan las cosas. Es reconocer que las máquinas necesitan instrucciones claras, y las personas necesitan ser escuchadas.

La transformación digital sólo es posible si se encara como parte de una transformación cultural. Y nosotros, desde la experiencia de usuario estratégica, estamos en una posición única para ayudar a iniciarla.

Santiago Bustelo
Julio 2025

La entrada Transformación digital en Iberoamérica: por qué fallan los modelos del norte se publicó primero en Kambrica.

Errores comunes en la incorporación de talento UX: los 10 fallos más frecuentes

Estos errores pueden afectar directamente la calidad de los resultados, retrasando el impacto positivo que UX puede generar en productos, servicios y en el negocio en general. Sin embargo, son completamente evitables si se cuenta con el apoyo adecuado y una estrategia de UX bien definida.

¿Estás seguro de que tu empresa está evitando los errores más comunes al contratar UX?

Errores comunes al contratar y gestionar perfiles UX:

1. Asignar a una sola persona todas las responsabilidades UX.
2. Contratar perfiles sin la experiencia adecuada por desconocer los roles y niveles de seniority.
3. Reducir UX a diseño visual o de interfaces.
4. Integrar UX sin una estrategia clara ni objetivos de negocio razonables.
5. Colocar UX bajo IT o Marketing.
6. No haber adoptado metodologías ágiles en IT antes de incorporar UX.
7. Tratar a UX como un silo, sin conexión con otras áreas.
8. Intentar “evangelizar” sin experiencia suficiente ni respaldo organizacional.
9. Esperar resultados inmediatos sin entender la evolución del proceso.
10. No contar con apoyo experto.

Si tu empresa está en el proceso de incorporar e integrar recursos UX, te invitamos a revisar esta lista. ¿Te reconoces en alguno de estos puntos? No estás solo: son errores comunes cuando desde áreas de negocio, como Recursos Humanos, se aborda la integración de UX sin la guía técnica experta necesaria.

¿Te gustaría optimizar tu estrategia UX?

Si querés diferenciarte de tu competencia, aprovechar mejor la iniciativa estratégica de incorporar UX, y optimizar tu inversión en recursos humanos, pongámonos en contacto para agendar una reunión. Podemos ayudarte a sacar el máximo provecho de tu estrategia UX y evitar los errores que frenan el crecimiento de tu negocio.

Los 10 errores más frecuentes, en detalle

1. Asignar a una sola persona todas las responsabilidades UX.

Muchas empresas buscan un perfil que se encargue de todo: desde research, ideación, Design Thinking, pruebas de usabilidad, wireframes, prototipado, diseño UI pixel-perfect, maquetado HTML y CSS responsive, desarrollo front-end JavaScript, redacción, documentación, hasta evangelización, metodologías ágiles, gestión y estrategia UX.

Eso no es un perfil UX, sino un equipo de varias personas. Y una de esas personas debe ser alguien con competencia técnica, experiencia, visión estratégica y habilidades de gestión para liderar ese equipo. Sin dirección propia, el equipo UX terminará desmembrado por los intereses de las distintas áreas de la organización.

2. Contratar perfiles sin la experiencia adecuada por desconocer los niveles de seniority.

Muchas organizaciones cometen el error de contratar perfiles sin comprender adecuadamente los diferentes niveles de seniority UX, y qué le cabe a cada uno. Esto suele resultar en una falta de alineación entre lo que la empresa necesita y lo que el profesional UX puede ofrecer.

Perfiles junior o semi senior, por ejemplo, a menudo son contratados para tareas que los exceden, o que requieren de la supervisión de un profesional de mayor experiencia en UX. Contratar el perfil adecuado según el nivel de seniority es crucial para evitar errores que afecten el rumbo de los proyectos.

3. Reducir “UX” a diseño visual o de interfaces.

Limitar UX exclusivamente al diseño visual es un error común que ha surgido con la popularización de la disciplina, que no siempre ha estado acompañada de la difusión de su verdadero alcance y fundamentos.

Aunque la creación de artefactos visuales es una de las funciones más evidentes de UX, es sólo la punta del iceberg. La norma ISO 9241–210, que define el término “experiencia de usuario”, subraya que abarca mucho más que el diseño visual: incluye la efectividad, eficiencia y satisfacción del usuario al realizar tareas. Esto requiere comprender y cuantificar lo que los usuarios experimentan al interactuar con un sistema.

Reducir UX a lo visual es una mala inversión, ya que no logrará soluciones efectivas ni alineadas con los objetivos de negocio.

4. Integrar UX sin una estrategia clara ni objetivos de negocio razonables.

Cuando las áreas de negocio definen “objetivos” para UX sin una estrategia UX clara, ni un marco racional de decisiones de diseño como Experience Decision Making (XDM), el resultado suelen ser metas poco realistas que confunden objetivos con requisitos o deseos.

Para generar un impacto real, UX debe estar alineada con los objetivos empresariales — no sólo como una función operativa, sino como un motor estratégico en la toma de decisiones y el rendimiento del negocio.

5. Colocar UX bajo Marketing o IT.

Marketing se enfoca en atraer clientes, y IT en la viabilidad técnica. UX tiene un rol distinto y complementario a ambas: garantizar que las soluciones sean efectivas, eficientes y satisfactorias para las personas.

Si UX depende de Marketing, se limitará a diseñar campañas y landing pages; si depende de IT, terminará resolviendo tickets.

UX necesita tener su propio espacio y autoridad para aportar desde la estrategia.

6. No haber adoptado metodologías ágiles en IT antes de incorporar UX.

Si una organización sigue operando con una mentalidad de cascada, es probable que vea el UX Research como un obstáculo, partiendo de la falsa premisa de que el plan ya está cerrado y solo falta ejecutarlo.

Para que UX sea efectivo, el proceso de desarrollo de software debe estar basado en metodologías ágiles que permitan iterar y tomar decisiones fundamentadas en evidencia. Sin este cambio de enfoque, el diseño terminará siendo solo una capa estética final sin impacto real en la experiencia del usuario.

7. Tratar a UX como un silo, sin conexión con otras áreas.

La experiencia de usuario no es un “producto del área de UX”, sino lo que el usuario final experimenta: el resultado de todas las decisiones tomadas por las diferentes áreas involucradas. Si el producto surge de una mala política comercial, ningún “diseño de pantallas” podrá solucionar la desconexión entre lo que se ofrece y lo que los clientes están dispuestos a aceptar.

“Tener un área de UX” no mejora automáticamente la experiencia del usuario final, especialmente si esta área se limita a ser un equipo de “delivery”, que se dedica únicamente a ejecutar decisiones sin cuestionarlas.

Para que UX tenga un impacto real, debe estar presente en todas las fases del proceso, influyendo en las decisiones comerciales, tecnológicas y estratégicas desde el principio. Solo así se garantiza una experiencia de usuario coherente y alineada con los objetivos de negocio.

8. Intentar “evangelizar” sin experiencia suficiente ni respaldo organizacional.

Pedirle a alguien con poca experiencia que “evangelice” sobre UX dentro de la empresa es una iniciativa bien intencionada, pero condenada al fracaso.

Para que UX gane espacio y se establezca de manera efectiva, la “evangelización” debe provenir de una persona con autoridad, trayectoria y la capacidad de dialogar de igual a igual con las áreas clave.

Sin una base conceptual sólida, experiencia ni respaldo organizacional, las ideas de UX no tendrán el impacto necesario para ser tomadas en cuenta de manera significativa.

9. Esperar resultados inmediatos sin entender la evolución del proceso.

UX no es magia. No es contratar a alguien hoy y ver resultados al día siguiente. Como toda disciplina estratégica, requiere tiempo para diagnosticar, comprender el negocio y generar cambios reales.

Además, gran parte de esos cambios son culturales: impactan el enfoque y los procesos de las áreas existentes. Al igual que ocurre con la incorporación de áreas como Seguridad o Ética, el éxito de UX no depende solo de su implementación, sino de su integración y adopción dentro de la organización.

10. No contar con apoyo experto.

Muchas empresas intentan buscar, seleccionar e incorporar profesionales UX sin contar con el asesoramiento estratégico suficiente, ni programas de capacitación y mentoría proporcionados por profesionales con experiencia en los desafíos específicos que enfrenta la organización.

Sin las distinciones adecuadas, los esfuerzos no sólo fracasan en generar resultados, sino que los problemas suelen detectarse recién cuando ya son demasiado grandes para ignorarlos, haciendo que su solución sea aún más compleja y costosa.

¿Querés evitar estos errores al contratar talento UX?

Si tu empresa enfrenta alguno de estos problemas en sus iniciativas de contratar talento UX, podemos ayudarte a solucionarlos. En Kambrica ofrecemos consultoría estratégica, capacitación y mentoría para incorporar profesionales e integrar UX de manera efectiva en tu organización, acompañándote en su crecimiento, evitando errores comunes y maximizando el impacto en los resultados de negocio.

¿Te identificaste con alguno de estos puntos? ¿Tu empresa también ha atravesado estas dificultades? Te ofrecemos un enfoque estratégico y personalizado, para entender tus necesidades específicas, sin propuestas genéricas enlatadas.

¿Nos ponemos en contacto para hablar de cómo incorporar y proyectar UX en tu organización?

La entrada Los 10 errores más comunes al contratar UX en una organización se publicó primero en Kambrica.

¿Por qué todo eso? Porque las metodologías las suele empujar el área de IT, que no sólo no tiene porqué entender lo que hacemos ni cómo encaminarlo exitosamente, sino que además nos suele traer muchas veces las cosas ya contaminadas: por ejemplo, confundiendo agilidad con apuro, o los espacios de investigación y de toma de decisiones de diseño como “Big design up front”. 

No hay forma de sumarnos exitosamente a algo que ya empezó mal antes.

El manifiesto ágil declara: valoramos “software funcionando”, por sobre “documentación exhaustiva”.

Para UX, esto significa: nuestros entregables no son valor si no se traducen en funcionalidad aprobada, en atributos visibles en el producto final.

¿Podemos identificar en qué medida total o parcial, un entregable nuestro NO aporta valor? ¿Podemos señalar qué cosas NO valen la pena hacer?

Por ejemplo, ¿entendemos y podemos explicar qué decisiones debe alimentar un customer journey? En función de ello, ¿tenemos las herramientas para argumentar y demostrar que sería suficiente hacerlo en una simple tabla de Excel, en lugar de toda esa decoración que queda tan linda en dribbble pero que no moverá la aguja en el proyecto?

UX ágil parte de entender el Manifiesto Ágil

Si no entendemos y no podemos poner en práctica la filosofía ágil, no hay manera de “hacer UX ágil”. Sólo estaremos generando entregables sin valor, sin ningún aporte a la agilidad del proyecto … pero eso sí, cumpliendo a rajatabla la burocracia de las ceremonias y los sprints.

En el resumen de mi charla en el evento “La Medida del Diseño 2018: Métodos lentos en tiempos ágiles”, organizado por IxDA Viña del Mar, profundizo sobre estos temas.

Santiago Bustelo
Julio 2024

La entrada ¿Cómo integrar UX research y diseño UX sobre metodologías ágiles? se publicó primero en Kambrica.

Esta misma mentalidad se refleja en algunos gerentes que pretenden contratar barato a agencias que ejecuten decisiones de diseño y desarrollo que ya han tomado, negándose a incorporar procesos que puedan mejorar la calidad de esas decisiones para evitar el escenario más habitual en el software: el fracaso.

Es así como en este momento, hay en algún lugar del mundo un gerente de compras presionando a una agencia para que acepte diseñar y desarrollar “la App” casi al costo. Ignorando que, de los más de 3 millones de apps publicadas, el usuario promedio sólo tiene instaladas unas 80.

“La App” pasará a sumarse al 80% de las Apps que no llegan a las 10.000 descargas. Y que los usuarios eliminarán la próxima vez que se les llene el teléfono: es decir, a más tardar a fin de mes.

Eso no es ahorrar: es “invertir” tiempo, esfuerzo y dinero para, a cambio, obtener un retorno negativo.

El valor de una buena inversión en dirección de UX & IT

Las empresas que buscan soluciones baratas y rápidas para ejecutar ideas sin dirección ni validación experta, terminan perdiendo más de lo que ganan.

Contratar agencias que puedan cometer UX y desarrollo al costo más bajo, seleccionados por departamentos de compras que negocian agresivamente, resulta en proyectos mal concebidos, en productos que no cumplen con las necesidades reales de los usuarios y que, en última instancia, serán ignorados o en el mejor caso, resistidos.

Esta estrategia de “ahorro” es, en realidad, una forma de desperdicio. En lugar de construir soluciones que realmente funcionen, aporten valor y puedan aspirar a tener alguna adopción por el mercado, se pierde tiempo y dinero en hacer pantallas lindas y baratas que le gusten a los decisores, y cuyo destino inevitable será, tarde o temprano, el descarte que dé lugar a otro proyecto. Porque en un mercado competitivo, las cosas se hacen bien, o se hacen de vuelta.

Visión vs. espejismos

Muchos gerentes consideran sus ideas como una “visión”, y a los diseñadores y desarrolladores como meros albañiles a quienes hay que decirles lo que tienen que hacer. Pero si esa visión de producto que espera el éxito no está informada por la evidencia, no será más que un espejismo.

El problema es que no es lo mismo tener ideas (que validamos nosotros mismos), que tener ofertas (que validan los clientes). Para un producto exitoso, no alcanza con una “buena” idea. Hay que madurarla en una buena oferta. Ésa es la función del Diseño como disciplina estratégica: la arquitectura, en lugar de la decoración.

Una consultoría experta que aplique procesos maduros de creatividad y toma de decisiones basada en evidencia, es una excelente forma de lograr esa maduración. Pero a menudo, los decisores consideran estos servicios “caros”, sin conocer los riesgos que les evitan ni entender el valor que aportan.

Porque sus pareceres y decisiones se fundan en la idea culturalmente instalada de que “ahorrar” es comprar barato, en lugar de invertir racionalmente.

La filosofía Lean y el diseño basado en objetivos

Existen diversas “escuelas” de pensamiento de diseño.

Una, basada en entender al diseño sólo como disciplina visual y como el establecimiento de una filosofía de cómo lograr “impacto”, se enfoca en crear interfaces que le gusten al comitente — la persona que paga por el proyecto.

Otra, que entiende al Diseño como disciplina proyectual y estratégica siguiendo las definiciones de Don Norman, la norma ISO 9241 y la filosofía Lean que ayudó a reconstruir la industria japonesa, es la que realmente da resultados — porque ése es precisamente su foco.

Ésa es nuestra escuela de pensamiento de diseño que impulsa la Dirección UX como disciplina para lograr software funcionando, aceptado y adoptado por usuarios reales, cumpliendo objetivos de Negocio.

Para la Dirección UX, la pregunta “¿qué tan crítico es un buen diseño de UX para incrementar uso y conversiones?” se responde por definición: si el diseño UX no incrementa uso y conversiones, no es bueno.

La escuela de la Dirección UX no sólo considera los factores estéticos: reconoce factores críticos de éxito como la funcionalidad, la eficiencia y la satisfacción del usuario final. Es una inversión sólida que, aunque pueda parecer más costosa inicialmente, resulta en productos exitosos, robustos, y que resisten el paso del tiempo: inversiones que resultan en verdaderos ahorros – en lugar de costo hundido y deuda técnica.

Conclusión

Comprar barato cosas que no son necesarias ni se van a usar no es ahorrar: es desperdiciar. Lo mismo ocurre en las empresas que contratan equipos de UX baratos para ejecutar proyectos que no resultarán en productos aceptados por los usuarios finales.

Para realmente ahorrar y obtener resultados, es fundamental invertir en equipos de UX bien dirigidos y capacitados, y darles los recursos y la autoridad necesarios para hacer su trabajo.

Solo así se pueden crear productos que satisfagan las necesidades del mercado y generen un retorno positivo sobre la inversión.

La entrada Comprar barato cosas que no necesitás, no es ahorrar. ¿Estás haciendo lo mismo en tus contrataciones de UX & IT? se publicó primero en Kambrica.

Un prototipo no es una versión preliminar del diseño: es una herramienta económica para lograr respuestas. De qué estará hecho, cómo y con qué nivel de detalle, dependerá de las preguntas que tengan sentido en ese momento del proyecto.

Les comparto algunos ejemplos de cómo prototipando con código, podemos hacer y responder mejores preguntas de UX Research, tanto en procesos de evaluación interna, como con personas usuarias reales.

Prototipos HTML5: formularios, sacar selfies…

Por ejemplo, cuando las preguntas que necesitamos hacernos tienen que ver con la usabilidad de un formulario, no servirá de nada un “prototipo” estático en Figma, donde haciendo click mágicamente se completen los campos y los usuarios puedan avanzar manoteando el mouse y sin mirar la pantalla.

Para evaluar la usabilidad de un formulario, necesitaremos poner a prueba un prototipo operable del formulario.

Puede alcanzar con unas pocas líneas de HTML que nos permitan ver la experiencia de los usuarios completando los datos que les pedimos:

<label for="cuil">Número de CUIL:</label><br>
<input id="cuil" type="number" name="cuil" size="11" min="20000000000">
<br><br>
<input type="reset">
<input type="submit" value="Continuar">

Sólo así podremos hacer y contestar preguntas sobre los usuarios como:

• ¿Se saben el dato de memoria, o necesitan buscarlo?
• ¿Lo tipean, o lo copian y lo pegan?
• ¿Lo ingresan sin guiones, como quiere IT? ¿O podemos demostrar que esa restricción es innecesaria y perjudicial?
• ¿Hace sentido la validación que estamos usando?
• ¿Cuál teclado es mejor para completar este dato en móvil? ¿El que presenta INPUT type=”number”, o el de type=”tel”?
• ¿Tiene sentido el “stepper” que muestra el INPUT type=”number” en la versión desktop?
• ¿Es necesario el botón “restablecer” que insisten en poner los de sistemas? ¿O podemos demostrar al Negocio que es una pésima idea, y lograr que IT deje de opinar sobre este tema?

Con este enfoque, en Kambrica pudimos no sólo resolver casos de ingreso de información, sino también prototipar el uso de cámara en móvil – y así identificar los verdaderos problemas que tenían los usuarios para registrarse en una App financiera. Problemas que sólo se manifestaban al usar las cámaras del celular, una de las tantas cosas que se pueden hacer con HTML5:

<!--
// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

El elemento HTML5 para la cámara es INPUT:file. 
Como es MUY diferente al elemento que necesitamos mostrar en el prototipo,
y no podemos maquillarlo con CSS, usaremos un botón común para la acción.
Ese botón hará click en el INPUT:file invisible.
-->

<!-- Usar cámara para selfies -->
<button
 onclick="document.getElementById('camara-selfie').click()"
 >Sacar selfie</button>
<input
 style="visibility:hidden;"
 id="camara-selfie" 
 type="file" accept="image/*, video/*" capture="user">

<br><br>

<!-- Usar cámara para tomar fotos: -->
<button
 onclick="document.getElementById('camara-principal').click()"
 >Sacar foto al DNI</button>
<input
 style="visibility:hidden;"
 id="camara-principal" 
 type="file" accept="image/*, video/*" capture="environment">

Prototipando datos… un montón de datos

Cuando las preguntas que nos queremos hacer tienen que ver con cómo nuestros usuarios visualizan y manejan grandes volúmenes de datos, no podemos mostrarles un “lorem ipsum” repetido 100 veces.

Inventar un volumen de datos grande y variado no sólo resulta tedioso – es muy complicado mantenerlos de forma consistente en todas las pantallas que tengamos que prototipar. Y si necesitamos mostrar muchos datos distintos sobre una misma vista (por ejemplo, mostrar diversas combinaciones de datos sobre la plantilla “ficha del cliente”), crear las variantes a mano puede resultar absurdo.

Resulta mucho mejor generar estos datos de manera mecánica.

Por ejemplo, podemos crear números de teléfono (entre 1000–0000 y 5999–9999) como números aleatorios. En una planilla de cálculo, podrímos usar la fórmula RANDBETWEEN( mínimo, máximo ):

HTML no tiene esa funcionalidad. Pero sirviendo nuestro prototipo desde un entorno local como MAMP o un hosting Apache del montón, es bastante sencillo “inyectar” funcionalidad PHP en medio del código HTML:

<!-- HTML original: 100 filas y números a mano -->
<table>
 <tr><td>1</td><td>28828534</td></tr>
 <tr><td>2</td><td>46326679</td></tr>
 <tr><td>3</td><td>24144353</td></tr>
…
 <tr><td>100</td><td>24464010</td></tr>
</table>


<!-- Versión PHP, generando 100 filas y números de forma mecánica -->
<table>
<?php for ($i = 1; $i <= 100; $i++) { ?>
 <tr><td><?= $i ?></td><td><?= rand( 10000000, 59999999 ) ?></td></tr>
<?php } ?>
</table>

Con muy poco esfuerzo, habremos logrado 100 filas de “números de teléfono”… que nos deberían inspirar a ponerles un guión en el medio para hacerlos más legibles.

Aquí, antes y después:

Para crear el ejemplo de la derecha, generamos dos números aleatorios con un guión en el medio: <?= rand( 1000, 5999 ) ?>-<?= rand( 1000, 9999 ) ?>

Este enfoque aplica muy bien cuando los datos para prototipar son numéricos, y es verosímil que cambien cada vez que volvemos a cargar la página.

Pero… ¿Qué sucede cuando los datos que queremos prototipar no son numéricos? ¿Y qué pasa si necesitamos que sean siempre los mismos cada vez que se visita la misma pantalla?

Prototipando datos pseudo aleatorios

Vamos a empezar con la pseudo-aleatoriedad: generar los datos de una manera mecánica no predecible, y que sea siempre la misma. Es decir, en lugar de “1,2,3,4”, mostrar por ejemplo “21,6,89,53” cada vez que presentemos los primeros cuatro números de la lista.

En lugar de una función rand() que nos devuelva un número distinto cada vez que la llamamos, necesitamos una función noTanRand($i) que nos devuelva un valor “raro” para el $i que le pasamos, siendo $i el número de item: el que en el código de ejemplo anterior, usamos en for( $i… ).

Esa función que necesitamos, la podemos construir con un algoritmo de hash. Usando la función nativa de PHP, podemos tomar un string cualquiera, y devolver un número entre 0 y 1 (como haría rand() sin argumentos):

<?php

// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

function noTanRand($seed){
 $hash = md5($seed); //Obtenemos hash hexadecimal, ej. "cfcd208495d565ef66e7dff9f98764da">
 $result = hexdec(substr($hash, 0, 8)) //tomamos los primeros 8 caracteres, de string a número: 4 bytes (2 ^ 8 * 4 )
           / (pow(2, 32) - 1); //y dividimos por el máximo posible para obtener nuestro número entre 0 y 1
 return $result;
}

// Probamos la función:
for( $i = 0; $i <= 10; $i++) {
    echo ( noTanRand($i).", " );
}

// Resultado:
// 0.81172374002908, 0.76871122251468, 0.78171459161251, 0.92498448466067, 0.65820255727931, 0.8939549624673, 0.087784356458062, 0.5589125378893, 0.78883317620233, 0.27253036533308, 0.82753398474947,

?>

Eso está bastante bien. Aunque para prototipar, quizás nos vendría aún mejor una función que, desde PHP o JavaScript, nos devolviera el mismo resultado. A la que podamos pasarle un string, un número, o cualquier cosa. Y a la que podamos opcionalmente definirle un número mínimo y un máximo.

Como en JavaScript no disponemos de la misma función nativa que en PHP, necesitamos construir un algoritmo de hash para las dos versiones. Después de algunas pruebas, logramos el siguiente código adaptando el algoritmo ‘times 33’ de Daniel J. Bernstein implementado por Matt Barker. En honor a D.J., llamaramos a nuestra función… djash:

<?php
/* djash - Versión PHP: */

// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

function djash($input,$desde=0,$hasta=1) {
    $salt = "Salt para darle gusto al hash";

    // Convierte el input a una cadena si no lo es
    if (!is_string($input)) {
        if (is_object($input)) {
            $input = json_encode($input);
        } else {
            $input = strval($input);
        }
    }

    // Agrega el salt al input
    $input .= $salt;

    $hashValue = 5381;
    for ($i = 0; $i < strlen($input); $i++) {
        $char = ord($input[$i]);
        $hashValue = ($hashValue * 33) ^ $char;       
  $hashValue = $hashValue & 0xFFFFFFFF; // Recorta el número a 32 bits
    }

   // Normalizamos el número al rango [0, 1] y aplicamos desde/hasta:
   $resultado = ( $hashValue / (pow(2, 32) - 1) ) * ($hasta - $desde) + $desde;
   if( $desde != 0 || $hasta != 1){ $resultado = floor ( $resultado ); }
   return $resultado;
}
?>

<script>
/* djash - Versión JavaScript: */

// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

function djash(input, desde = 0, hasta = 1) {
  const salt = "Salt para darle gusto al hash";

  // Convierte el input a una cadena si no lo es
  if (typeof input !== "string") {
    if (typeof input === "object") {
      input = JSON.stringify(input);
    } else {
      input = input.toString();
    }
  }

  // Agrega el salt al input
  input += salt;

  let hashValue = 5381;
  for (let i = 0; i < input.length; i++) {
    const char = input.charCodeAt(i);
    hashValue = (hashValue * 33)  ^ char;
    hashValue = hashValue  >>> 0; // Convertir a 32 bits
  }

  // Normalizamos el número al rango [0, 1] y aplicamos desde/hasta:
    let resultado = (hashValue / (Math.pow(2, 32) - 1)) * (hasta - desde) + desde;
    if (desde !== 0 || hasta !== 1) { 
        resultado = Math.floor(resultado);
    }
    return resultado;
}
</script>

Después de algún que otro bug, comprobamos que –dígito más, dígito menos– las dos funciones nos dan el mismo valor para cada $i:

Bueno, ya tenemos nuestra función para armar datos numéricos. Podemos usarla para pedirle nos devuelva un elemento pseudo-aleatorio de un array:

<?php
/* djitem - Versión PHP: */

// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

function djitem( $array, $ix ) {
 //$ix: admite un número entre 0 y 1; caso contrario obtenemos djash de $ix 
 if ($ix <= 0 || $ix >= 1) { $ix = djash($ix); }

 $totalItems = count($array);
 $weightedIndex = floor($ix * $totalItems);
 return $array[$weightedIndex];
}

/* djitem - Versión JavaScript: */

// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

function djitem(array, ix) {
    // Si ix está fuera del rango [0, 1], calculamos djash de ix
    if (ix <= 0 || ix >= 1) { ix = djash(ix); }

    var totalItems = array.length;
    var weightedIndex = Math.floor(ix * totalItems);
    return array[weightedIndex];
}
?>

Ese array puede ser una lista de provincias, apellidos… Por ejemplo, si tomamos una lista de 100 apellidos, y usamos dos para cada item variando el $ix en el segundo (concatenándole algún texto cualquiera), podemos lograr 10.000 combinaciones:

Resultados para ( djitem($DB_apellidos, ($i)). “ “ . djitem( $DB_apellidos, ($i.” dos”)) );

Y usando doble nombre y apellido, podríamos generar millones de clientes ficticios para un sistema de gestión:

Y podemos hacer que el link nos lleve a la ficha del cliente, con más datos. Datos que generaremos en base al índice del cliente, por lo que serán siempre consistentes para el mismo link.

Como la dirección, que creamos con un apellido y un número, más piso y departamento. Y cuidando, para que sea bien verosímil, de llamar “PB” al piso “0”. Así como de usar letras para el departamento en el 70% de los casos, y números en el resto.

También podemos mostrar planes de pagos para los clientes con balance negativo. O hasta una serie de muestras de color basadas en el ID del cliente:

O sea, podemos hacer cualquier cosa que necesitemos, siguiendo la lógica de cada caso. Cosas como:

• Establecer diferentes condiciones según su probabilidad (ej. “Roaming activado” para el 63% de los clientes, “Sin 4G” para el 7.5%, etc.)
• Fechas de nacimiento, números de DNI y CUIL verosímiles para la demografía de nuestros usuarios,
• Productos en sus últimas compras (tomados de nuestro catálogo),
• Calcular series numéricas y balances financieros,
• Mostrar imágenes aleatorias de una lista,
• Poner un punto en el mapa con latitud y longitud (dentro de un rango definido, para evitar caer en el medio del mar),
• Mostrar textos (ej. mensajes enviados por el cliente) en base a una o más listas de modelos de frases… según probabilidad de las casuísticas de consulta / gestión / reclamo.

Aplicando estos criterios, en Kambrica logramos prototipar un sistema con más de 50.000 clientes y reglas de negocio sumamente complejas. Ajustando el prototipo de manera iterativa en base a las observaciones con usuarios, encontramos formas más claras de presentar la información y flujos de operación más eficientes – al punto de que los usuarios pudieron empezar a ver y resolver casos que llevaban meses sin haber detectado.

Demo y código PHP del ejemplo

Pueden ver este prototipo de ejemplo funcionando en: https://demos.kambrica.com/djash

Para que puedan incorporar este enfoque en sus proyectos, les dejo más abajo el código de estos últimos ejemplos.

Espero les resulte útil y no duden en escribirnos si necesitan apoyo o quieren llegar más lejos: en Kambrica llevamos más de 10 años trabajando procesos de capacitación, consultoría y mentoría con equipos de UX, IT y Producto para mejorar sus procesos y resultados :)

<?php
// *** _funciones.php ***

// Funciones para prototipar datos en gran volumen.
// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional
// https://creativecommons.org/licenses/by-sa/4.0/deed.es


$DB_nombres = [
 "M" => [ /* Masculinos: primeros por frecuencia en Argentina según https://forebears.io/argentina/forename, corregidos (no tenían acentos)s */
  "Juan","José","Carlos","Jorge","Luis","Miguel","Héctor","Ramón","Roberto","Oscar","Daniel","Mario","Pedro","Ricardo","Raúl","Pablo","Eduardo","Sergio","Marcelo","Julio","Hugo","Alberto","Rubén","Gustavo","Antonio","Víctor","Francisco","Diego","Ángel","Alejandro","Claudio","Walter","Fernando","Néstor","Guillermo","Manuel","Cristian","Martín","Alfredo","Enrique","Osvaldo","Javier","Gabriel","Horacio","César","Rodolfo","Omar","Andrés","Ariel","Ernesto","Leonardo","Domingo","Marcos","Nicolás","Sebastián","Adrián","Norberto","Mariano","Esteban","Darío","Fabián","Edgardo","Rafael","Vicente","Orlando","Gerardo","Jesús","Hernán","Federico","Félix","Aldo","Armando","Adolfo","David","Emilio","Germán","Aníbal","Lucas","Mauricio","Humberto","Ignacio","Agustín","Felipe","Leandro","Tomás","Abel","Gregorio","Luciano","Segundo","Rolando","Gastón","Nelson","Maximiliano","Salvador","Lorenzo","Christian","Silvio","Arturo","Rodrigo","Mauro","Dante","Bernardo","Gonzalo","Rogelio","Julián","Eugenio","Ismael","Marcelino","Santiago"
  ],
 "F" => [ /* Femeninos, primeros por frecuencia en Argentina según https://forebears.io/argentina/forenames, corregidos (no tenían acentos) */
  "María","Ana","Silvia","Rosa","Norma","Marta","Claudia","Graciela","Mónica","Susana","Mirta","Alicia","Patricia","Nélida","Juana","Liliana","Sandra","Laura","Olga","Andrea","Elsa","Ramona","Adriana","Marcela","Carmen","Lidia","Teresa","Gabriela","Gladys","Verónica","Blanca","Natalia","Margarita","Irma","Beatriz","Mercedes","Alejandra","Dora","Elena","Ángela","Cristina","Lorena","Delia","Isabel","Stella","Mariana","Mariela","Nilda","Estela","Nancy","Sara","Nora","Viviana","Lucía","Analía","Julia","Luisa","Miriam","Karina","Antonia","Paola","Carolina","Cecilia","Sonia","Hilda","Mabel","Elba","Valeria","Rosana","Silvana","Silvina","Paula","Carina","Yolanda","Francisca","Noemí","Elvira","Romina","Celia","Marisa","Gloria","Clara","Angélica","Inés","Daniela","Josefa","Catalina","Eva","Raquel","Martha","Marina","Élida","Rita","Roxana","Griselda","Haidé","Vanesa","Esther","Amalia","Elisa","Amelia","Victoria","Zulema"
  ]
 ];

$DB_apellidos = [ /* primeros por frecuencia en Argentina según https://forebears.io/argentina/surnames, corregidos (no tenían acentos) */
"González","Rodríguez","Gómez","Fernández","López","Díaz","Martínez","Pérez","García","Sánchez","Romero","Sosa","Torres","Álvarez","Ruiz","Ramírez","Flores","Benítez","Acosta","Medina","Herrera","Suárez","Aguirre","Giménez","Gutiérrez","Pereyra","Rojas","Molina","Castro","Ortiz","Silva","Núñez","Luna","Juárez","Cabrera","Ríos","Morales","Godoy","Moreno","Ferreyra","Domínguez","Carrizo","Peralta","Castillo","Ledesma","Quiroga","Vega","Vera","Muñoz","Ojeda","Ponce","Villalba","Cardozo","Navarro","Coronel","Vázquez","Ramos","Vargas","Cáceres","Arias","Figueroa","Córdoba","Correa","Maldonado","Paz","Rivero","Miranda","Mansilla","Farías","Roldán","Méndez","Guzmán","Agüero","Hernández","Lucero","Cruz","Páez","Escobar","Mendoza","Barrios","Bustos","Ávila","Ayala","Blanco","Soria","Maidana","Acuña","Leiva","Duarte","Moyano","Campos","Soto","Martín","Valdez","Bravo","Chávez","Velázquez","Olivera","Toledo","Franco","Ibañez","Leguizamón","Montenegro","Delgado","Arce","Ibarra","Gallardo","Santillán"
];


// Aprovecharemos función nativa PHP para mostrar currency
$formatUSD = new NumberFormatter('en_US', NumberFormatter::CURRENCY);



function djash($input) { 
// Devuelve un número entre 0 y 1, siempre el mismo para el mismo $input.

    // Salt hardcodeado
    $salt = "Salt para darle gusto al hash";

    if (!is_string($input)) {
        if (is_object($input)) {
            $input = json_encode($input);
        } else {
            $input = strval($input);
        }
    }

    // Agrega el salt al input
    $input .= $salt;

    // Función de hash básica basada en el algoritmo 'times 33' de Daniel J. Bernstein.
    $hashValue = 5381;
    for ($i = 0; $i < strlen($input); $i++) {
        $char = ord($input[$i]);
        $hashValue = ($hashValue * 33) ^ $char;       
  $hashValue = $hashValue & 0xFFFFFFFF; // Recorta el número a 32 bits
    }

 // Normalizamos el número al rango [0, 1]
   return $hashValue / (pow(2, 32) - 1);
}



function djitem( $array, $ix ) {
// Devuelve un item ($ix: djash) de un $array.
// $ix puede ser: djash entre 0 y 1, o un string/número/objeto del cual obtener un djash.

 //$ix: admite un número entre 0 y 1; caso contrario obtenemos djash de $ix
 if ( !is_numeric($ix) || ( $ix <= 0 || $ix >= 1) ) { $ix = djash($ix); }
 
    $totalItems = count($array);
    $weightedIndex = floor($ix * $totalItems);
    return $array[$weightedIndex];
}



function djnombre( $seed, $what = "N A" ){
// Devuelve un string según djash $seed, siguiendo instrucciones de $what
// Ejemplo de uso: djnombre( "0", "[s] n n a a: (11) dddd-dddd" );

// $seed = string para alimentar djash.
// $what =  cada caracter codifica un térmono a devolver:
//  D: dígito.
//  M: nombre masculino.
//  F: nombre femenino.
//  N: nombre masculino o femenino (50% de probabilidad inicial; siguientes usos en $what tendrán mismo género).
//  A: apellido.
//  S: devuelve literalmente "m" o "f" (50% de probabilidad cada opción, ), para uso en funciones.
//  Cualquier otro caracter se devuelve como se recibió.
//  Default: "n a" (nombre, espacio, apellido).

 global $DB_nombres ;
 global $DB_apellidos ;

 $result = "";
 $what = str_split( $what );
 $whatix = 0;
 $sexo = djash($seed) > .5 ? "M" : "F" ; //Calculamos M/F al azar 50/50 chances.


 foreach( $what as $whatChar ){
  $pr = djash( $seed . $whatix . $result ); //Para cada caracter usaremos un seed distinto.

  switch ( $whatChar ) {
  
   case "D": //digito entre 0 y 9
    $result .= floor( $pr * 10 );
    $whatix++;
    break;

   case "S": //imprimimos el $sexo generado por djash (con break)
   case "N": //…o solo lo usamos para continuar en los casos m/f: (no hacemos break)
    if(  $whatChar == "s" ){
     $result .= $sexo;
     break;
     }
       
     case "M":
     case "F":
    //nombre masculino o femenino
    //estos dos casos toman $sexo de $whatChar:
    if( $whatChar == "M" || $whatChar == "F" ){
     $sexo = $whatChar;
     }
    $result .= djitem( $DB_nombres[ $sexo ], $pr);
    $whatix++;
    break;

     case "A":
    //apellido
    $result .= djitem( $DB_apellidos, $pr);
    $whatix++;
    break;
   
     default:
    //si no es un caracter codificado, lo concatenamos en output como vino.
    $result .= $whatChar ;
    //no afectamos $whatix
      
    };

 };

 return ( $result );
}

?>

<?php // *** clientes.php ***

include_once('_funciones.php');

?><!DOCTYPE html>
<html>
<head>
 <meta charset="utf-8">
 <title></title>
 <meta name="viewport" content="width=360, initial-scale=1" />

<style>
BODY{
 font-family: arial,sans-serif;
 font-size:14pt;
 line-height:140%
 }
</style>

</head>


<body>


<ol>

<?php
 
 // Loop
 for ($i = 0; $i <= 1000; $i++) {
 
  //calculamos balance del cliente, puede ser negativo:
  $balance =  ( djash($i)*100000 ) - 30000;
  $balanceColor = $balance < 0 ? "red" : "#999";
 ?>

 <li style="float:left; width:380px" id="cliente-<?= $i ?>">
  <!-- Pasamos el $i como id del cliente por URL (variable $_GET de PHP) -->
  <a href="cliente.php?id=<?= $i ?>"><?= djnombre( $i, "N&nbsp;N A&nbsp;A"  ) ?></a><br>
  <?= djnombre( $i, "11 DDDD-DDDD"  ) ?><br>
  <span style="color:<?= $balanceColor ?>"><?=  $formatUSD->formatCurrency( $balance , 'USD' ) ?></span><br>
  &nbsp;
 </li>

<?php
 } // Fin loop
 ?>

</ol>


</body>
</html>

<?php //*** cliente.php ***

include_once('_funciones.php');

// Tomamos $id del URL (variable de $_GET):
$id = $_GET['id'] ?? 0;


?><!DOCTYPE html>
<html>
<head>
 <meta charset="utf-8">
 <title></title>
 <meta name="viewport" content="width=360, initial-scale=1" />

<style>
BODY{
 font-family: arial,sans-serif;
 font-size:14pt;
 line-height:140%
 }
</style>
</head>

<body>


<?php

 //calculamos balance del cliente, puede ser negativo:
 $balance =  ( djash($id)*100000 ) - 30000;
 $balanceColor = $balance < 0 ? "red" : "#999";
 
 //calculamos piso y departamento para la dirección. 
 $direccion_depto = //el depto puede ser numerico (30% de los casos) o una letra (resto) 
  djash( $id." salt-piso-numerico" ) < 0.3 ?
   floor( djash($id." salt-piso")*9 * 3 + 1 ) //hasta 3 deptos por piso
   :
   djitem( [ "A","B","C","D" ] , ( $id . " salt-piso") )
   ;
 
 $direccion_piso = floor( djash($id." salt-piso")*9 );
 
 //creamos el string de Piso y depto:
 $direccion_pisodepto = "Piso " . $direccion_piso . " Depto. " . $direccion_depto;
 // … excepto en casos de Planta Baja.
 if( $direccion_piso == 0 ){
  $direccion_pisodepto = "PB Depto. " . $direccion_depto;
  }

?> 

<p>
 <span style="float:right">
  Cliente #<?= $id ?>
  <a href="?id=<?= intval($id) -1 ?>">&laquo; anterior</a>
  |
  <a href="?id=<?= intval($id) +1 ?>">siguiente &raquo;</a>
 </span>
 <span><a href="clientes.php#cliente-<?=$id?>">&laquo; volver</a></span>
</p>

<hr>

<h1 style="width:480px;line-height:100%"><?= djnombre( $id, "N&nbsp;N A&nbsp;A"  ) ?></h1>

<p>
 <b>Balance:</b> <span style="color:<?= $balanceColor ?>"><?=  $formatUSD->formatCurrency( $balance , 'USD' ) ?></span>
</p>

<?php //si el balance es negativo, planteamos planes de pagos de 3, 6 o 12 cuotas, con 10%, 20% o 30% de recargo
 if( $balance <0){
  $cuota3 = $balance * -1 / 3 * 1.1;
  $cuota6 = $balance * -1 / 6 * 1.2;
  $cuota12 = $balance * -1 / 12 * 1.3;
 ?>
 <h4>Plan de pagos:</h4>
 <ul>
  <li>
   <?= $formatUSD->formatCurrency( $cuota3, 'USD' ) ?>
   x 3 cuotas =
   <?= $formatUSD->formatCurrency( $cuota3 * 3, 'USD' ) ?>
  </li>
   
  <li>
   <?= $formatUSD->formatCurrency( $cuota6, 'USD' ) ?>
   x 6 cuotas =
   <?= $formatUSD->formatCurrency( $cuota6 * 6, 'USD' ) ?>
  </li>
  
  <li>
   <?= $formatUSD->formatCurrency( $cuota12, 'USD' ) ?>
   x 12 cuotas =
   <?= $formatUSD->formatCurrency( $cuota12 * 12, 'USD' )  ?>
  </li>
  
 </ul>
<?php
 } //endif balance negativo
 ?>


<h2>Datos del Cliente</h2>
<ul>
 <li><b>Teléfono:</b> <?= djnombre( $id, "11 DDDD-DDDD"  ) ?></li>
 <li><b>Dirección:</b> <?=
  djnombre( $id." salt-calle" , "A " ) .
  floor( djash($id)*5000 ) . " " .
  $direccion_pisodepto 
  ?></li>
</ul>


<h2>Muestras de color:</h2>

<?php
 for ($i = 1; $i <= 5; $i++) {
  // Creamos un color hex basado en $id y $i:
  $djcolor = dechex( intval( djash( $id . " color " . $i) * hexdec( "ffffff") ) ); // intval() hace la conversión implícita para evitar Warning "PHP Deprecated: Implicit conversion from float to int loses precision"
 ?><div style="display:inline-block; width:80px; height:80px; border:1px solid #ccc; margin:0 5px 5px 0; background-color: #<?= $djcolor ?>"></div><?php
 } //end for
 ?>

</body>
</html>

La entrada Prototipando con código para pruebas con usuarios se publicó primero en Kambrica.

Clínica online: 9 encuentros en vivo. PRÓXIMAMENTE

Acerca de este curso

El primer paso para iniciarse en UX es conocer las técnicas, como pueden ser realizar análisis de usabilidad o producir wireframes. Eso es suficiente para empezar como “UX Junior“, pero, ¿qué hace falta para ser un “UX Senior” o “UX Lead”?

En este taller, podrás entender tu situación respecto a los diferentes caminos y dimensiones posibles en este mundo profesional, reconocer tus propias condiciones, motivaciones y oportunidades, y cómo cultivar tus competencias para abrirte paso.

A quién está dirigido

Profesionales UX (diseño, research, content) de nivel Junior, semi Senior o Senior, que quieran asentar su nivel y proyectar su carrera. 

¿Por qué hacer este curso?

Este curso te ayudará a posicionarte en el mundo laboral de UX en un nivel de mayor solidez y respeto profesional. Los empleadores buscan cada vez más profesionales con autonomía y líderes creativos que puedan trabajar más allá de los límites, en lugar de reproducir ideas ya existentes.

Temario

Módulo 1: Cómo crear tu propio plan de carrera UX

¿Qué diferencia hay entre cada nivel de seniority? Hacer un correcto diagnóstico de tu nivel es fundamental para poder desarrollar las competencias correctas para impulsar tu carrera.

• Niveles de Seniority UX: ¿Qué diferencia hay entre un UX Junior, Semi Senior o Senior?. Dimensiones UX y planes de carrera. Competencias centrales que debemos desarrollar: Más allá de las competencias técnicas. Cómo lograr las horas de observación que hacen la diferencia para un profesional UX.

• Cómo desarrollar una “carrera a tu medida”: UX no es una sola carrera lineal, es un universo complejo en el cual podemos combinar elementos para construir nuestra oferta diferencial. Veremos modelos de personalidad y desarrollo profesional, y cómo conocer tus virtudes para sacar provecho en el desarrollo de tu carrera.

• Auto diagnóstico y proyección: Cómo crear tu propio plan de carrera.

Módulo 2: Productividad y proactividad: Cómo proteger y potenciar nuestro tiempo

El tiempo es quizás el recurso más valioso para un profesional. En la facultad se nos “premia” por sacar tiempo de la galera: Largas entregas que a veces hacen que terminemos sin dormir. En la vida profesional debemos conocer y dominar otros métodos, mejores en sus resultados y sustentables en su aplicación.

• Cómo sacar mejor provecho de nuestro tiempo: Trucos para optimizar el uso de todas nuestras herramientas. Gestión del tiempo personal. Modelos de productividad de Lean Software Development: Reconocer los ladrones de nuestro tiempo y nuestra productividad.
  
• Desarrollo de la capacidad analítica: Cómo el uso de técnicas y herramientas nos permiten procesar la información para tomar buenas decisiones y obtener mejores resultados.
  
• De cocinero a Gourmet: Pasar de cumplir requerimientos a solucionar problemas de diseño y negocio. Comprender la necesidad del cliente: Lo que pide vs. lo que quiere, vs. lo que necesita. Cómo lograr decisiones formales sólidas que sobreviven el paso del tiempo y nos evitan repasar los pasos ya dados.
  
• Gestión de proyectos: Ofertas vs. pedidos. Priorización y planificación: Kanban, Gantts y camino crítico. Adelantarse a riesgos e impedimentos. La triple restricción como marco de un proyecto.

Módulo 3: Cómo nos relacionamos con nuestro trabajo, nuestros clientes y nuestro equipo

Nuestro nivel de seniority está relacionado con la calidad de nuestras decisiones. Un excelente profesional es capaz de entender todas las variables que hacen al proyecto, a las conversaciones y relaciones con los demás para llevarlo adelante.

• Manejo de presión y gestión del tiempo personal: Manejar la presión requiere de competencias tanto emocionales como de gestión. No solo necesitamos despejar nuestra mente para ser productivos sino también manejar responsablemente nuestra propia asignación para mantener un equilibrio responsable.

• Niveles de decisión: Cómo tomamos mejores decisiones personalmente y en equipo. Los cuatro niveles de decisión y los 7 niveles de delegación.

• Sobre ganarnos el respeto profesional: La negociación como herramienta para superar obstáculos frecuentes. Técnicas para “manejar” interlocutores difíciles. Tercerizar el conflicto.
  
• Comunicación efectiva y profesional: Comunicación (oral, escrita) para coordinar acciones. Niveles de delegación. Priorizar los canales y los tiempos de respuesta.
  
• Cómo presentar diseño: Lo que diseñamos es importante. Cómo lo presentamos lo es aún más. Técnicas reales basadas en años de experiencia.
  
• Manejo de objeciones y conflictos: En toda situación conflictiva podemos encontrar que faltó una conversación. Algunas de estas situaciones podemos aprender a preverlas y otras a manejarlas mejor cuando se presentan.

Módulo 4: Metodologías y procesos

En los equipos los ingenieros suelen definir las metodologías de trabajo a pesar de que el diseño y la ingeniería son disciplinas distintas, con naturaleza y procesos diferentes. Lograr una excelente articulación de diseño con las demás áreas requiere de conocer los aspectos en común y complementarios de los distintos actores.

• Métodos y metodologías: Así como los métodos nos ayudan a reducir riesgos en los entregables, las metodologías nos ayudan a reducir riesgos en el proceso. Veremos riesgos usuales en los proyectos, y cómo aprender de ellos para mejorar nuestro proceso de trabajo.
  
• Procesos lineales vs. iterativos: No existen procesos perfectos y únicos para todo tipo de problema. Conoceremos los diferentes modelos de trabajo necesarios para poder aplicar el más adecuado.
  
• Metodologías ágiles y diseño: Incorporar metodologías ágiles al proceso de diseño, e interactuar con equipos de producto e ingeniería, requiere conocer los fundamentos y procesos comunes para esas áreas, y cómo podemos responder a ellos. Scrum, pair-programming y Lean Software Development tienen correspondencias con Dual Track Agile, Pair design y Lean UX.

Módulo 5: Conocimientos de Negocio para profesionales UX

Cuando las decisiones de diseño responden a decisiones de Negocio, se traducen en objetivos. Y nuestro trabajo toma más valor.

• Cómo hacer que el negocio valore el diseño: Para el negocio, todo se traduce en dinero. Veremos principios básicos de marketing y economía. Cómo al reducir el desperdicio se gana en productividad. Y la importancia de diferenciar correctamente la inversión de costo.
  
• Cómo decide el negocio: Modelos de negocio. Tableros de comando. Experience Decision Making: Niveles en la toma de decisiones. Modelos de priorización de negocio. Modelos de toma de decisiones cuantificados. Diagrama de Pareto.
  
• Conocimientos de dominio en UX: Qué foco necesitamos para ayudar a nuestros clientes. Análisis de procesos, GOMS.

Modalidad

• 100% virtual.
• Cada módulo se ofrece por separado para mayor flexibilidad.
• Duración: El curso tiene una duración de 9 clases de 3 hs. c/u distribuidas en 5 módulos.
• Las clases son en vivo para hacer preguntas y aprovechar la experiencia del docente.
• Los cupos son limitados para acercarnos lo más posible a la dinámica de una clase presencial y tener una experiencia lo más personalizada posible. Finalizando cada clase se ofrecerá un espacio de consultas grupales.
• Luego de cada clase se enviará PDF del material visto, y registro en video con transcripción automática para poder buscar y repasar todo lo desarrollado en clase.
• Se emiten certificados de asistencia.
• El curso cuenta con transcripción en tiempo real para hipoacúsicos.

Docente

Santiago Bustelo

User Experience Director en Kambrica.

Se inició como diseñador de Interacción en 1996, desarrollando simuladores de negocios para formación gerencial de empresas líderes en el Cono Sur. Desde entonces, ha trabajado en más de 1000 proyectos para empresas de todo tipo y tamaño de Argentina, Chile, Uruguay, Brasil, Estados Unidos, España e Inglaterra, entre otros.

Fundador y Coordinador 2009-2019 del capítulo local de la Asociación de Diseño de Interacción (IxDA). Coordinador Regional de IxDA para América Latina (2010-2015). Chair de Interaction South America 2014. Jurado de conferencias y competencias internacionales de innovación (Interaction Awards, Interaction Latin America y MIT Technology Review).

Desde 2001 ha dictado más de 90 conferencias en América Latina, Norteamérica y Europa, y se ha desempeñado como docente en 11 universidades de Argentina, Chile, Colombia y Estados Unidos.

¡Sumate a la próxima edición!

Si querés recibir novedades y enterarte antes que nadie cuando abramos las inscripciones, dejanos un mensaje y te avisaremos por mail en cuanto tengamos más información!

La entrada Seniority UX: Llevá tu carrera a otro nivel se publicó primero en Kambrica.

Experience Decision Making (XDM): el eslabón faltante entre “design thinking” y “doing business”.

Proyectar, operar y mantener experiencias, implica nuevas formas de emprender proyectos y negocios. Este desafío ha sido terreno fértil para nuevas metodologías de trabajo, todas ellas prometiendo el éxito que escapa a las demás. Aunque útiles, todas comparten la misma limitación: una metodología de trabajo propone una forma de organizar personas y procesos. No reemplaza a las personas, ni a sus procesos de toma de decisiones.

Experience Decision Making (XDM) nace de reconocer esa pieza faltante. Es un sistema de modelos y métodos para lograr mejores procesos de toma de decisiones en la industria de las experiencias, integrando elementos de teoría de la decisión, psicología conductual, negociación y gestión.

Recibí gratis el ebook “XDM en 30 minutos” »

La entrada Nuevos frameworks para mejores decisiones en ILA19 se publicó primero en Kambrica.

Si desde el software impartimos instrucciones u órdenes directas a los usuarios (ej. “Ingrese número de tarjeta sin guiones ni espacios”), entonces estamos tratando de programar gente, lo cual no suele terminar bien.

Cuando esto pasa, lo conveniente es volver al trabajo de programar computadoras, con el objetivo de que se adapten a la gente.

Por ejemplo, usando una expresión regular para que sólo se tomen los caracteres numéricos. En pseudocódigo: find( /[^\d]/ ).replace("").

Esa instrucción para la computadora requiere de menos caracteres que la instrucción para el usuario, no falla nunca, y hace que todo el mundo quede contento.

A las computadoras, las programamos. A la gente, la entendemos.

Todo resulta mucho mejor si aplicamos las herramientas que dominamos, a los dominios a los que corresponden. A las computadoras, las programamos. A la gente, la entendemos.

La entrada El trabajo de un programador es programar computadoras. No gente. se publicó primero en Kambrica.

La falta de estándares en lo que hace a la descripción de seniority, es casi tan extendida en nuestra industria como la confusión entre UX y UI. Ello afecta a todos los involucrados en las conversaciones profesionales:

• diseñadores e investigadores que necesitan preparar su CV,
• profesionales que necesitan entender qué competencias necesitan desarrollar para avanzar su carrera,
• comerciales que necesitan presentar al equipo de forma responsable,
• clientes que necesitan evaluar y comparar las diferentes propuestas que reciben.

Una de las primeras voces que conocí ofreciendo definiciones útiles dentro de la industria del software fue la de Diego Salama, en un artículo muy claro que publicó allá por 2008 detallando cuáles son, a su criterio, las principales diferencias entre un programador Junior, un Semi Senior y un Senior.

Sus definiciones no sólo han resistido el paso del tiempo, sino que han tenido… réplicas, por así decirlo. Los ejes que plantea Diego, perfectamente generalizables a UX y a los que agrego el nivel Consultor (al igual que demás agregados míos, en itálicas), son:

Experiencia laboral

Cantidad de años de experiencia laboral en el campo, sin considerar trabajos prácticos, ni trabajos dentro de otras actividades.

• Junior: menos de 2 años de experiencia.
• Semi Senior: al menos, de 2 a 6 años de experiencia.
• Senior: al menos, 6 años de experiencia.
• A estas definiciones, agrego Consultor: al menos, 10 años de experiencia.

La cantidad de años en el campo, desde luego, es sólo una de varias dimensiones. Por ello, aplico en todos los casos “al menos”.

La simplificación, divulgada por Malcolm Gladwell, de que invertir 10.000 horas en un campo es el factor que hace la diferencia, ha sido largamente criticada, incluso por el autor original de la métrica, como lo que es – una simplificación. Lo valioso de los criterios que elaboró Diego Salama, es el aporte de las demás dimensiones, de las cuales resulta que una persona puede tener características de Senior en un aspecto y de Junior en otro:

Conocimientos técnicos

Herramientas, paradigmas, etc. que deba utilizar para cumplir sus labores.

• Junior: Suele requerir acompañamiento.
• Semi Senior: Técnicamente autosuficiente.
• Senior: Es referente técnico dentro del equipo.
• Consultor: Es referente técnico para su comunidad profesional.

Conocimientos funcionales

Metodologías, estándares, circuitos requeridos para cumplir sus labores.

• Junior: No conoce todos los procesos, ni los estándares.
• Semi Senior: Maneja los circuitos lo suficiente como para desempeñarse. Respeta los estándares y metodologías.
• Senior: Ayuda a definir procesos, metodologías, estándares y circuitos. Por supuesto, cumple los existentes.
• Consultor: Es referente técnico y estratégico, capaz de crear nuevas metodologías y siempre buscando mejorar las que se aplican.

Proactividad

Indica si la persona espera a que le asignen sus tareas, o si por el contrario toma una actitud de mayor iniciativa.

• Junior: Necesita que frecuentemente le definan su trabajo. Está a la espera del siguiente pedido. Cuando tiene tiempo libre no sabe con qué seguir. Depende de otros para avanzar con sus tareas.
• Semi Senior: Se preocupa por aprovechar mejor su tiempo. Pide nuevas asignaciones cuando tiene tiempo disponible y es autosuficiente para llevar adelante una gran parte de sus tareas.
• Senior: No solamente recibe requerimientos, sino que los busca y genera. En muchas oportunidades es quien genera asignaciones nuevas a su superior.
• Consultor: Genera objetivos y requerimientos no sólo para su equipo, sino también para su cliente.

Seguimiento requerido

Atención que requiere de su superior inmediato.

• Junior: Requiere seguimiento diario a nivel detallado.
• Semi Senior: Requiere seguimiento semanal y a nivel general.
• Senior: Proactivamente reporta el estado y avance de sus tareas.
• Consultor: Genera visión para el equipo y traza la dirección sobre la que se realiza el seguimiento.

Indicadores de productividad

Indicadores varios relacionados con el trabajo que realiza.

• Junior: Calidad: Baja/Media; Productividad: Baja/Media; Innovación: Poca o Nula.
• Semi Senior: Calidad: Media; Productividad: Media; Innovación: Poca.
• Senior: Calidad: Alta; Productividad: Alta; Innovación: Media/Alta. (Aquí Diego salta de “poca” para Semi Senior, a “alta” para Senior. Contar con un nivel más permite descomprimir esa escala).
• Consultor: El mayor seniority no sólo se traduce en calidad, productividad e innovación altas o muy altas, sino en el avance propio y del equipo a nuevos terrenos. El foco del Consultor ya no está en la correcta ejecución, sino en el planteo de qué es lo que se está haciendo. Un Consultor no se distingue por trabajar más rápido que un Senior, sino por lograr mayor valor en sus preguntas y en sus decisiones.

Cumplimiento de fechas

Cumplimiento de las fechas de entrega pautadas.

Aquí cabe aclarar que un profesional no puede tomar las estimaciones de otra persona, sea un compañero de equipo o el cliente. Es la responsabilidad del profesional realizar estimaciones sobre las cuales establecer y cumplir con sus compromisos.

• Junior: La mayoría de las veces no cumple con sus estimaciones.
• Semi Senior: A veces cumple, a veces no.
• Senior: Cuando surge un desvío (inevitablemente) lo informa adecuadamente y con anticipación.
• Consultor: Es responsable de la priorización y cumplimiento de estimaciones de plazo de todo el equipo; cuando surge un desvío inevitable, ayuda al resto para superarse y cumplir con los plazos.

Respuesta bajo presión

Referido a situaciones extremas… no a la corrida semanal.

• Junior: Ante la presión se bloquea, se angustia, se confunde, se estresa… El resultado de su trabajo en una situación de presión no es bueno.
• Semi Senior: Ante la presión se enoja, se defiende, se distancia, se resigna… El resultado de su trabajo en una situación de presión, a pesar de todo, es bueno.
• Senior: Ante la presión se entusiasma, se compromete, se hace cargo, se inspira e inspira a otros… El resultado de su trabajo en una situación de presión puede llegar a ser asombroso.
• Consultor: tiene la capacidad de anticiparse a los riesgos y factores de presión, de mantener la calma y de ayudar a ver el camino, convirtiendo esas situaciones en experiencias de las que el equipo sale fortalecido.

Relación interpersonal

La habilidad de comunicarse con su entorno (mención de Javier Scavino).

• Junior: Puede tener dificultades para transmitir sus ideas con claridad. No logra arribar a conclusiones concretables. No siempre sabe interactuar con otras personas de forma colaborativa y profesional.
• Semi Senior: Se hace entender pero no logra ganarse la simpatía ni despierta la vocación de sus colaboradores para acompañarlo en sus sugerencias. Se permite escuchar otros puntos de vista pero sigue intentando que sean sus ideas (buenas y malas) las que prevalecen.
• Senior: Es bueno comunicando, pero principalmente escuchando. Puede participar en decisiones de alto nivel y colaborar si es necesario en actividades más operativas, privilegiando el resultado y la calidad de las relaciones por sobre su autoría en las ideas.
• Consultor: aplica herramientas de mentoría y coaching para desarrollar al equipo y stakeholders, facilita los proyectos como un proceso de co-creación, atiende a la mejora continua en las relaciones y en los resultados.

Dimensiones UX

Sobre las dimensiones que propone Diego, considero las siguientes para nuestra disciplina:

Horas de observación

Una característica fundamental, que distingue a la práctica UX del diseño de interfaces (UI), es la observación de usuarios en contexto de uso por parte de todos los involucrados en el proyecto, dimensión documentada por Jared Spool en 2011 y Jakob Nielsen en 2014.

• Al inicio de su carrera (Junior), un profesional tendrá por definición cero horas de observación directa acumuladas.
• Un Semi Senior estará dentro del mínimo propuesto por Jared Spool: 2 horas cada no más de 6 semanas (aproximadamente, 16 horas al año).
• Un Senior se encontrará avanzando hacia las metas propuestas por Jakob Nielsen para su rol: entre 50 horas anuales (para diseño UI) y 200 (investigador UX).
• Un Consultor cumple o supera las metas propuestas para su rol.

Quizás esta variable sea la más clara para separar a quienes se dedican a informar y tomar decisiones de diseño con foco en lo que experimentan los usuarios (UX), de quienes (en muchos casos, con gran uso del arte y las mejores intenciones) se encuentran en una carrera distinta: la de ejecutar las decisiones de diseño que ya tomaron los clientes.

¿Qué sucede cuando se revela que un profesional que se considera a sí mismo un Diseñador UX Senior (con mayúsculas), lleva acumuladas muchas menos horas que las que serían propias a su nivel (o ninguna)? Claramente, se trata de un síntoma de que su experiencia laboral no está ocurriendo dentro del campo. Si es tu caso, quizás pueda interesarte sumarte a nuestro equipo – o a cualquier otro en donde tu trabajo no sólo sea recompensado, sino también resulte una inversión en tu carrera.

Conocimientos de Negocio

En su modelo, Diego considera el conocimiento de Negocio dentro de Conocimientos funcionales. Por lo menos para el caso de UX, encuentro más apropiado distinguir el conocimiento de Negocio en su propia dimensión, siguiendo el modelo OpenUP/MMU-ISO de Andrés Rodríguez que separa en un rol al líder técnico de dominio.

• Junior: Su foco y desafío diarios están más en los aspectos formales de la ejecución, que en la validez de la solución para el Negocio.
• Semi Senior: Entiende buena parte de los procesos del negocio.
• Senior: Se basa en conocimientos de Negocio para informar y lograr buenas decisiones de Diseño.
• Consultor: Su conocimiento de dominio le permite ayudar a los clientes a tomar mejores decisiones de Negocio.

Utilitas, Firmitas, Venustas

Para tratar aspectos propios de las disciplinas de diseño, encuentro muy interesante la clásica tríada originada hace veinte siglos en el tratado sobre arquitectura de Vitrubio.

Y encuentro que estos criterios aplican aún más cuando hablamos a UX, donde resulta central el establecimiento de métricas en dimensiones de diseño, usabilidad y negocio:

• Utilitas (utilidad): el trabajo del profesional, ¿ha cumplido la función que tenía encomendada?
  El trabajo de un Junior tendrá problemas para satisfacer este criterio. Un Semi Senior debería lograr una solución adecuada a la definición del proyecto. El trabajo de un Senior debería, además, poder ser adaptado a nuevas necesidades sin necesidad de demoler lo construido.
  Y podemos identificar a un Consultor por su capacidad de adelantarse recurrentemente a situaciones no consideradas inicialmente… pero cuya satisfacción años más tarde resulte un patrón para la industria.
• Firmitas (solidez): en el caso de UX, se traduce en la consistencia formal de los entregables.
  Un diseñador Junior producirá piezas en las que definiciones que tendrían que ser idénticas entre ellas (medidas, colores), difieren en pequeñas medidas que se revelan al comparar las piezas entre ellas. Un investigador Junior generará métricas de difícil o imposible comparación a lo largo del proyecto.
  Un profesional Semi Senior muestra una consistencia alta en los entregables que produce. El trabajo de un Senior se destaca por ser impecable. El de un Consultor, por ser referencia más allá del proyecto.
• Venustas (belleza): ¿en qué medida los aspectos formales han sobrevivido el paso del tiempo?
  Un Junior mostrará caprichos y vacilaciones propias de lo que está descubriendo en el momento, al punto de revelar dificultades para lograr un nivel satisfactorio ya para el mismo momento en el que la obra fue realizada.
  Un nivel Semi Senior puede manejar el lenguaje del momento. Un Senior, lograr una obra que resista el paso del tiempo. Y un Consultor, adelantarse además a la tendencia por venir.

Estas tres dimensiones clásicas sólo pueden ser evaluadas con el paso del tiempo. Al igual que una carrera profesional.

No es una coincidencia :)

Santiago Bustelo

¿Querés conocer y proyectar tu Seniority UX?

Autoevaluación

Test de Seniority UX

Completá el test de Seniority UX y empezá a proyectar tu carrera! »

Curso online en vivo

Seniority UX: Llevá tu carrera a otro nivel

Un curso para entender qué necesitás para proyectarte como UX Senior, y cómo lograrlo.

¡Sumate a la próxima edición!

La entrada Niveles de seniority UX se publicó primero en Kambrica.

Cuando nos planteamos integrar Experiencia de Usuario y Metodologías Ágiles, el encuadre nos condiciona a pensar que una vez que identifiquemos el punto de encuentro, tendremos todas las respuestas que necesitamos.

Esto sería acertado y suficiente, si no hubiéramos tenido desencuentros antes de la aparición de las metodologías ágiles. Aplicaría si hubiéramos venido trabajando fenómeno hasta que en el año 2001 fuera publicado el Manifiesto Ágil; la realidad es un poco más compleja.

Las metodologías ágiles suelen ser propuestas o impuestas por el área de Ingeniería, y allí es cuando podemos ver que el universo “metodologías ágiles” está compuesto por dos dimensiones: Ingeniería y Gestión. La relación entre Diseño e Ingeniería viene siendo el marco del problema ya no antes del 2001, sino desde tiempos inmemoriales: arquitectos e ingenieros llevan siglos hablando mal unos de los otros.

El primer paso para lograr una convivencia sana, es resolver la relación entre Diseño e Ingeniería. Para eso, me gusta mucho esta definición que conocí por Bret Victor: “La tecnología satisface necesidades humanas, amplificando capacidades humanas”.

Esta definición resulta reveladora en varios aspectos. Primero que nada: Sin persona, no hay tecnología. En segundo lugar, permite entender que la Ingeniería se ocupa de los aspectos funcionales, los que se ajustan al problema… y el Diseño se ocupa de que lo que se proyecta, se adapte a la persona, habiendo entendido sus necesidades y capacidades. La tecnología no se limita a lo mecánico; no es algo que inventan los ingenieros y que los diseñadores coloreamos. Sin Diseño no hay tecnología: hay meras curiosidades técnicas.

Para incorporar Diseño al proceso, encuentro muy útiles las tres preguntas críticas: ¿Qué problema queremos resolverle…? ¿…a quién(es)? y ¿Cómo sabremos si lo logramos? Estas preguntas permiten integrar en una sola conversación a las tres áreas del problema: Ingeniería, Diseño y Gestión.

Cuando hablamos de Gestión, es bueno entender qué es una Metodología: un marco para organizar un proceso que involucra personas. Lo importante de esta definición es que nos revela lo que una Metodología no abarca.

Una metodología no reemplaza a las personas (involucradas en el proceso), las conversaciones (herramienta para compartir visión de futuro y coordinar acciones), ni a la toma de decisiones. Elegir una metodología es, de por sí, una decisión. 

Una metodología no puede prescribir decisiones, de la misma manera en que las reglas de tránsito (ej. “circular por la derecha”) no pueden dictarnos a dónde ir: sólo nos pueden ofrecer la organización necesaria para llegar a destino reduciendo el riesgo de accidentes.

La toma de decisiones es una parte fundamental del Diseño, y el mayor valor que aporta al proceso. Es frecuente que quienes nos contratan, consideren al Diseño sólo en cuanto a la ejecución de Diseño, esto es, hacer “bonitas” las decisiones de diseño tomadas previamente por Ingeniería y Negocio (sin siquiera ser conscientes de qué es una decisión de diseño).

Nos corresponde a los diseñadores marcar las distinciones correctas, proponiendo y cumpliendo la promesa de ayudar a Ingeniería y Negocio a tomar mejores decisiones.

Nos corresponde a los diseñadores marcar las distinciones correctas, proponiendo y cumpliendo la promesa de ayudar a Ingeniería y Negocio a tomar mejores decisiones, al punto que las decisiones de Diseño pueden alimentar a las decisiones de Negocio en las cuales deben basarse.

Cuando se considera al diseño como la mera ejecución, pareciera ser que un proyecto puede considerarse más o menos complejo por la “cantidad de pantallas” a producir – o cualquier otro entregable que pueda ser cuantificado.

Lo que encontramos en Kambrica trabajando sobre este problema, es que la complejidad del Diseño se puede entender de manera más apropiada como producto de la complejidad de la ejecución por la complejidad de las decisiones. Este modelo nos permite mostrar más claramente el rol necesario de UX en facilitar los procesos de toma de decisiones de los stakeholders, y brindar información para que resulten basados en evidencia.

Otra distinción importante hace al uso vulgar del término Ágil. Particularmente de parte del Negocio, se expresa interés en adoptar metodologías ágiles por la idea de lograr rapidez.

La realidad es que la rapidez no forma parte de los postulados del manifiesto ágil: lo que proponen es respuesta ante el cambio en lugar de aferrarse a un plan. En otras palabras, ágil es el esquiador que esquiva los obstáculos y llega a la meta; apurado, es el que llega al hospital.

El esquiador apurado se arroja a la meta en un acto de fe, impelido por la ansiedad. El esquiador ágil considera las evidencias del terreno en su constante proceso de toma de decisiones: un ciclo de observación, orientación, decisión y acción.

En un proyecto, la investigación UX es lo que permite información para toma de decisiones basada en evidencia. Sin embargo, suele ser desestimada con el pretexto de que “es lenta”, que es otra forma de decir “no hay tiempo”. Ahora bien: el tiempo no es algo que se almacena en cajón.

El tiempo es algo que se dispone. ¿Qué significa realmente “no hay tiempo”?
Supongamos que alguien va a un centro de esquí, pide unos esquíes y cuando el dependiente le pregunta cuánto calza, el cliente dice “no tengo tiempo de ponerme las botas, sólo quiero los esquíes”. Lo que quiere decir, es que no entiende las botas como condición necesaria para usar los esquíes.

Los profesionales de UX tenemos que aprender a escuchar “no tengo tiempo” no como una negativa inflexible, sino como una invitación a señalar la condición necesaria entre nuestra propuesta y lo que nuestro cliente necesita.

En el proceso de decisión de nuestro cliente, hay una balanza con dos bandejas: una, lo que no quiere, problemas presentes o futuros, sus miedos; y otra, lo que quiere, el futuro del cual quiere ser parte, su deseo.

Atender a las preocupaciones es crítico para lograr atención: todo lo que propongamos antes de haber satisfecho ese punto, será ignorado o malinterpretado, al punto que en lugar de ser entendido como parte de la solución, puede ser considerado como problemas adicionales recargando la bandeja del miedo.

Este enfoque permite resolver el  habitual pedido de técnicas cuantitativas, aún cuando encontremos que aporten poco y nada al entendimiento y resolución del problema. La razón de este pedido es que los clientes que lo enuncian, necesitan algo para presentar a sus superiores: se los mide. La mayor preocupación de estos interlocutores no está alineada a la calidad del diseño: está enfocada en su supervivencia en la organización.

En estos casos, la investigación cuantitativa debe ser presentada como condición necesaria para lograr una cuantificación que a nuestros clientes les resulte positiva. Esto es, reconocer las métricas que puedan mostrar con medidas crecientes a lo largo del proyecto.Distingo en la investigación cuantitativa tres niveles:

• Validación (comprobar lo que “sabemos que sabemos”) es el proceso cualitativo más simple, menos riesgoso, y sobre el cual es más factible establecer métricas cuantitativas.
• Investigación (ir a buscar lo que “sabemos que no sabemos”) representa mayor incertidumbre y sólo es viable una vez que nuestro cliente ha podido entender el valor de UX en reducir riesgos, típicamente luego de la validación de supuestos que se presentaban originalmente como verdades.
• Exploración (ir a buscar lo que no sabemos que no sabemos) es el proceso cualitativo más alejado de la preocupación del cliente por su supervivencia en la organización; sólo es viable cuando nuestro cliente dispone de recursos, capital político, experiencia y compromiso.

Recién con herramientas sólidas para las conversaciones y la toma de decisiones, podemos abocarnos a diseñar una metodología.

Lo más importante que toda metodología busca lograr, es lograr en la escala del proyecto una relación sana cliente-proveedor. Sin metodología alguna, a medida que se suma gente de ambos lados, se producen conversaciones cruzadas, confusiones y problemas que llevan a la formación de dos bandos: “esos cretinos” y “esa manga de inútiles”.

Por eso, toda metodología plantea un solo interlocutor de cada lado, contando con autoridad, competencia técnica, entendimiento de Negocio y competencias de gestión.

Una base muy importante para las metodologías ágiles es la distinción de Valor vs. Desperdicio propia de la filosofía “Lean”. Valor es lo que el Cliente valora; desperdicio, es todo lo demás… aún cosas que consideramos condiciones necesarias para lograr Valor.

Identificar el desperdicio obliga a cuestionarse todas las actividades que se realizan. En el caso de la construcción de una vivienda, las paredes –que permiten proteger a los habitantes de la intemperie y preservar su privacidad– son claramente un Valor. Ahora bien, los andamios, por más que se consideren necesarios para la construcción de esas paredes, son en realidad desperdicio constructivo: los habitantes no convivirán con los andamios una vez inaugurado el edificio. Si los andamios fueran de oro, el presupuesto crecería en varios millones de dólares, sin que los clientes finales encuentren Valor en ello. Por eso, los andamios son modulares, reutilizables, y en muchos casos, se alquilan.

Otros tipos de desperdicio pueden ser más claros de identificar. Si en lugar de descargar los materiales en el punto donde se los necesita, se los descarga a 10 cuadras de distancia, será necesario tiempo y esfuerzo adicionales para desplazarlos a donde deberían haber sido descargados en primer lugar.

Identificar el desperdicio en software resulta mucho más difícil. Lean Software Development es una herramienta muy valiosa para identificar, reducir y eliminar en nuestros proyectos:
Desperdicios en el producto:
Son los más claros… y también los más tardíos en poder ser identificados. Resultan evidentes una vez que el proyecto ha salido a producción… y por ello, cuando ya no hay recursos para resolverlos. El proceso de investigación UX busca, en un entorno controlado, identificar estos desperdicios de manera económica, cuando todavía hay tiempo y recursos para mitigarlos:

• Defectos: bugs, cosas que no funcionan de acuerdo a la expectativa del usuario final, problemas de usabilidad.
• Funcionalidad no usada: típicamente, producto de falta de entendimiento de las necesidades y capacidades reales de los usuarios.

Desperdicios en el proceso:
Pueden ser identificados y resueltos durante el proceso mismo. Atenderlos reduce la posibilidad de manifestación de desperdicios en el producto. Requieren de competencias de gestión, responsabilidad del equipo, y manejo de expectativas del Cliente.

• Pase de manos: cuando una tarea pasa de una persona a otra, hay o bien una conversación necesaria entre esas personas, o información que se pierde en el proceso.
• Multitarea: el ser humano puede realizar una sola tarea de forma consciente; la “multitarea” resulta en realidad, intercalar fragmentos de dos o más tareas. Pasar de la tarea A a la tarea B, requiere de un esfuerzo mayor a cero para entender el contexto de la segunda tarea; esa penalización de aplica nuevamente al retomar la tarea A.
• Reaprendizaje: retomar una tarea o práctica al cabo de mucho tiempo, requiere de un esfuerzo para recuperar el contexto y capacidad operativa, que se puede evitar manteniendo continuidad.
• Esperas: ocurren cuando una persona no puede avanzar con sus tareas asignadas por no contar con decisiones o insumos de los que depende. Una forma de evitar estas situaciones es manejando un cronograma de “sprints” que impone cadencia al proyecto, y que debe involucrar al Cliente.
• Trabajo incompleto: todas las decisiones y ejecuciones no finalizadas, aumentan la deuda técnica al punto en que el día de mañana, el costo para saldarla puede resultar inviable. Suele ser producto de apuro y presión sobre el proyecto, falta de planificación y visión.
• Talento no utilizado: uno de los casos usuales es cuando el Cliente considera al Diseño como mera ejecución, desatendiendo la capacidad del equipo de ayudar al Negocio a tomar mejores decisiones. Requiere de gestión, autoridad, manejo de expectativas y compromisos. Impacta al proyecto de maneras no cuantificables (nadie puede medir contra lo que “podría haber sido”), y al equipo en quiebres de motivación.

Desde Kambrica desarrollamos, iteramos y proponemos un modelo que en primer lugar, reconoce el valor de los procesos de Facilitación e Investigación para reducir la complejidad de la toma de decisiones. Y revela que la ejecución de diseño, lejos de “resolver” (como suele ser la percepción del cliente), en realidad siempre abren nuevas preguntas que requieren de procesos adecuados para su resolución.

Nuestro modelo mínimo de sprint considera ciclos semanales, con un track de Gestión adelantado una semana al track de ejecución. En el momento de Planificación, se empalman los dos tracks, considerando además una instancia de seguimiento con Negocio a mediados de la semana de ejecución para reducir riesgos y desvíos.

Aplicando este modelo logramos coordinar todos los proyectos, sin importar su complejidad.

En resumen, integrar Experiencia de Usuario y metodologías ágiles requiere trabajar sobre varias dimensiones, de general a particular: desde el entendimiento de Diseño, Ingeniería y Gestión, hasta el diseño y aplicación de una metodología particular para encaminar los proyectos identificando y reduciendo los desperdicios, estableciendo y cumpliendo compromisos de manera responsable.
 

La Medida del Diseño 2018: Métodos lentos en tiempos ágiles – IxDA Viña del Mar

El evento contó con Mauricio Azócar (Coach Ágil en Tinet), Estefanía Cotrini (Jefa de proyectos en Ilógica) y Santiago Bustelo (Fundador y Director de UX en Kambrica).

La industria del diseño de servicios digitales se basa cada día más en el uso de metodologías ágiles, las que han traído consigo nuevas formas de trabajo, con otros ritmos y metas que han demostrado aportar en eficiencia y transparencia en los procesos de diseño y desarrollo. Sin embargo, muchas de las metodologías ágiles como Scrum, Agile o Lean han sido creadas desde el desarrollo y, por lo tanto, no consideran en sus definiciones iniciales la relevancia del rol del diseño para la experiencia, sus equipos ni sus métodos.

En este contexto, IxDA Viña del Mar levantó las preguntas ¿Cuál es el rol de los “métodos lentos” propios de DCU e investigación en los tiempos ágiles en que nos encontramos?, ¿Cómo se hace cargo cada tipo de metodología de la experiencia de usuario?, ¿Qué factores externos, humanos o de otro tipo, favorecen o dificultan el desarrollo de procesos bajo cada metodología?

¡Muchísimas gracias a Nicolás Espinoza, Katherine Exss y a todo el equipo y voluntarios de IxDA Viña del Mar por la invitación, la excelente recepción y el esfuerzo por hacer todo posible!

Créditos de la Presentación

• Framing hammer – Luigi Zanasi (CC BY-SA 2.0 ca)
• Iceberg in the Arctic with its underside exposed – AWeith (CC BY-SA 4.0)

Todas las demás imágenes y videos bajo Licencia CC0 (Libres para todo uso sin atribución requerida), de dominio público o producción propia.

¿Querés proyectar tu UX Seniority?

¡Nuevo curso!

Seniority UX: Llevá tu carrera a otro nivel

Un curso para entender qué necesitás para proyectarte como UX Senior, y cómo lograrlo.

Conocé el temario y sumate!

La entrada Las metodologías ágiles como problema de Diseño se publicó primero en Kambrica.

Suele ocurrir que el Negocio contrate a diseñadores para “diseñar”, y las dos partes crean que están hablando de lo mismo… pero en realidad, el Negocio no esté esperando que los diseñadores tomen decisiones de diseño. Sino, que ejecuten las decisiones de diseño que el negocio ya tomó antes de llamar a los diseñadores.

En otras palabras, “que lo haga lindo”.

Este tipo de malentendidos resultan no sólo en frustraciones para todos los involucrados, sino en diversas formas de desperdicio (entendido bajo la filosofía Lean): idas y vueltas, sobreprocesamiento, defectos y talento desperdiciado.

Cuando en Kambrica empezamos a aplicar la distinción entre ejecución y decisiones de diseño, encontramos el espacio para poder trabajar esas decisiones junto con el Negocio. También fuimos descubriendo y trabajando en nuestros proyectos dos niveles más, que hoy forman parte de nuestra filosofía de consultoría UX: las decisiones de Negocio, y los valores de la Organización.

Cuando las decisiones de diseño no están soportadas en decisiones de Negocio, quedan sujetas a la arbitrariedad, al cambio de parecer y a la revisión constante por parte de todos los involucrados. Síntomas comunes son que el diseño “no cierra”, a algún stakeholder “no le parece”. Siempre en esos casos queda la duda de si no se podría haber hecho otra cosa. No necesariamente mejor… sino distinta. Una situación que resulta inevitable si la expectativa del Negocio, es que el diseño lo sorprenda. Porque la sorpresa del diseño que se presenta, dura tan sólo unos instantes. Luego del primer golpe de vista, empiezan a brotar preguntas y pedidos, que derrumban las bases de las decisiones que se habían tomado hasta ese momento.

Esta pérdida de foco se reduce enormemente cuando las decisiones de diseño, responden a decisiones de Negocio. Éstas decisiones tienen forma de objetivos: qué queremos lograr con el proyecto. O dicho en términos de diseño: ¿qué problema queremos resolverle, a quién, y cómo sabremos si lo logramos?

A veces, el diseño lleva a cuestionar decisiones de Negocio: eso no sólo es válido, sino que resulta para nosotros una expresión de “design thinking” mucho más profunda y madura que tan sólo una pared tapizada de post-its.

Pero encontramos que con eso no es suficiente. Diseñar la Experiencia de Usuario, requiere tomar decisiones sobre qué experiencia queremos brindarles a esos usuarios y en última instancia, cómo queremos tratarlos. Esas decisiones también resultan arbitrarias, y deben estar expresadas en los valores de la organización. Sin valores de la organización alineados a UX, el Negocio puede perder la dirección y considerar decisiones que podrían perjudicar la relación con sus usuarios y clientes.

Pocas organizaciones tienen declaraciones de Visión y Misión que describan cómo la organización se propone tratar a sus clientes. Pero esas declaraciones, aún incompletas, son siempre son el mejor punto de partida para lograr esas definiciones.

Nuestra Jerarquía de decisiones UX tiene forma de pirámide, representando que cada nivel debe estar soportado en los anteriores. “UX” en la punta, representa el hecho de que si bien la ejecución del diseño será el punto de contacto de los usuarios con la marca, en realidad la Experiencia de los Usuarios es la consecuencia de las decisiones de todos los involucrados en el proceso.

Cuando las decisiones de diseño no están soportadas en decisiones de Negocio, quedan sujetas a la arbitrariedad, al cambio de parecer y a la revisión constante por parte de todos los involucrados.

La entrada Jerarquía de decisiones UX se publicó primero en Kambrica.

Resumen: ¿Qué podemos aprender los profesionales UX de los errores del Marketing?

Entre los años 50 y 90, el Marketing trabajó duro para posicionarse como el eslabón perdido entre las empresas y los clientes.
Hoy en día, lejos de esa posición, tiende a ser una de las disciplinas menos respetadas en el negocio, tanto por las empresas como por los clientes.

• ¿Cómo sucedió eso?
• ¿Cuáles son las promesas de marketing que UX está repitiendo ahora, poniendo en riesgo nuestra credibilidad?
• ¿Estamos cometiendo los mismos errores? (pista: sí)
• ¿Cómo podemos evitar caer en las mismas trampas?

La promesa: Los días dorados del Marketing

Un breve resumen de los primeros grandes éxitos de Marketing, promesas, cómo cambió la forma de entender los negocios y se ganó un asiento en la mesa. Caso de estudio: Louis Cheskin y la aplicación del método científico.

La decepción: La caída en desgracia del Marketing

Los pecados que hicieron que el Marketing no cumpliera su cometido como disciplina: Engreimiento, Complacencia y Superstición (Cargo Culting).

Reflexionando sobre UX

Un paralelismo entre los altibajos del Marketing y nuestra situación actual. Cómo al ignorar la historia del Marketing, estamos condenados a repetirla – y cómo ya estamos cayendo en las mismas trampas.

Tomando el volante

No es demasiado tarde. Todavía podemos imaginar el camino a seguir y los riesgos de descarrilamiento, tomar decisiones y tomar medidas como profesionales y como comunidad.

• Identificar los errores que ya han comenzado (que deben ser detenidos) y anticipar nuevos errores (que deben ser prevenidos),
• Reconocer las buenas acciones ya en marcha (que deben ser apoyadas), y proyectar las buenas acciones aún no iniciadas (que tenemos que iniciar).
• Involucrarnos como profesionales y como comunidad con el futuro de nuestra práctica.

Acerca del autor

Santiago Bustelo es Director de Experiencia de Usuario en Kambrica, una consultora de UX con sede en Buenos Aires. Preside el capítulo local de la Interaction Design Association (IxDA BA) y fue el primer Coordinador Regional de IxDA para América Latina.

Santiago comenzó su carrera como diseñador de interacción en 1996, diseñando simuladores de negocios para capacitación gerencial. En ese entonces, estaba en auge Calidad Total. No cumplió sus promesas. Hoy en día, estamos repitiendo el mismo ciclo con Lean y Agile.

¿Querés proyectar tu UX Seniority?

¡Nuevo curso!

Seniority UX: Llevá tu carrera a otro nivel

Un curso para entender qué necesitás para proyectarte como UX Senior, y cómo lograrlo.

Conocé el temario y sumate!

La entrada Práctica profesional UX: ¿Qué podemos aprender de los errores del Marketing? se publicó primero en Kambrica.

El buen diseño es producto de buenas decisiones y excelente ejecución. Design Research comprende a las técnicas que informan a las decisiones de Diseño.

Lo que creemos saber … ¿es realmente válido? ¿O es sólo una colección de estereotipos y prejuicios? ¿Qué es lo que realmente necesitamos saber? ¿De quién podemos obtener esa información? ¿Cómo podemos obtenerlo sin contaminar la muestra?

Esta charla presenta las técnicas esenciales para responder a estas preguntas a lo largo del proceso de diseño. Desarrolla un caso real de aplicación de estas técnicas en un proyecto de rediseño de imagen institucional.

Temario

• Objetivos vs. Requerimientos.
• Los Objetivos encuadran decisiones de diseño. Design Research informa esas decisiones.
• Qué lugar tienen los requerimientos y por qué son problemáticos cuando no son resultado de un proceso de diseño previo.
• Proceso de diseño iterativo: las decisiones de diseño siempre abren nuevas preguntas.
• Dimensiones de métodos de Design Research: Cualitativo vs. Cuantitativo; Conductual vs. Actitudinal; Contexto de uso.
• Qué necesitamos saber? Validar lo que creemos saber que sabemos; Investigar lo que sabemos que no sabemos; explorar lo que no sabemos que no sabemos.
• Sujetos de investigación: ¿De quién podemos obtener qué información?
• Decisiones informadas en cada iteración vs. “estómago”. Involucrar al cliente en las decisiones y en el proceso de diseño.
• Caso: Jorge Frascara, Seguridad vial en Alberta (Canadá). Impacto de esa investigación 25 años después.
• Técnica #1: Procesar información disponible. Fuentes de información. Construcción de sentido: de Datos a Información, Conocimiento e Inteligencia.
• Técnica #2: Entrevista. Cómo evitar contaminar la muestra. 7 pasos desde la planificación hasta la obtención de insights. Cómo empezar a practicar. Entrevistas cualitativas, entrevistas contextuales, desarrollo de Arquetipos (Personas).
• Técnica #3: Mapeo. Características y posibilidades. Mapeo de requerimientos, Card sorting, mapeo improvisado.
• Caso real: rediseño de imagen institucional. Definición de objetivos. Primeras entrevistas. Ajuste de objetivos, definición de estrategia. Investigación de lenguaje de diseño: elementos característicos y lenguaje establecido en el mercado. Primeros prototipos: presentación y conclusiones. Exploración morfológica. Investigación de diseño: paletas de color. Exploración combinatoria. Iteración final y satisfacción de objetivos del proyecto.

Core Design

Core Design es una iniciativa de IxDA BA para el desarrollo de talleres y módulos teórico-prácticos, destinados a su incorporación en la formación universitaria de las carreras tradicionales de Diseño (Gráfico, Industrial, Multimedia, Indumentaria, Interiores, Arquitectura, etc).

“Design Research…” es el primer módulo creado dentro de esta iniciativa. Presentado en 2017 en Lamar University (Beaumont, TX USA), Universidad de Palermo (Buenos Aires) y Artmedia 2017 (Universidad Maimónides / Centro Cultural San Martín), brinda una introducción a fundamentos y técnicas de Design Research para estudiantes de Diseño Gráfico.

¿Querés proyectar tu UX Seniority?

¡Nuevo curso!

Seniority UX: Llevá tu carrera a otro nivel

Un curso para entender qué necesitás para proyectarte como UX Senior, y cómo lograrlo.

Conocé el temario y sumate!

La entrada Design Research: Cómo realizar las preguntas correctas para el proceso de diseño se publicó primero en Kambrica.

Mercado Libre había desarrollado y documentado una plataforma tan valiosa como compleja.

La documentación técnica producida era necesaria, pero no suficiente, para lograr adopción de parte de quienes desarrollaban, diseñaban e implementaban soluciones de e-commerce, parte vital de su ecosistema.

Era necesaria otra mirada.

Aplicamos técnicas de investigación cualitativa y cuantitativa para comprender los perfiles actitudinales involucrados, sus intereses y procesos de toma de decisiones, y estrategias apropiadas de comunicación.

Rediseñamos y validamos con usuarios reales la oferta de valor, landing pages, comunicación y navegación. Tomamos el diseño final y desarrollo front-end, siguiendo las definiciones de marca para asegurar que el producto final formara parte consistente de la plataforma.

Antes y Después

Áreas de trabajo

• Consultoría de UX, marketing y comunicación
• Entrevistas cualitativas
• Perfiles actitudinales (Personas)
• Diseño de propuesta de valor
• Arquitectura de información
• Redacción publicitaria
• Diseño de prototipos (Wireframes)
• Pruebas con usuarios
• Diseño visual
• Diseño Responsive
• Desarrollo front-end
• Metodología Lean UX

Resultados

• Mejoras de conversión.
• Reducción de los procesos explicativos sobre las herramientas disponibles.
• Mercado Libre obtuvo más leads que los proyectados.

La entrada Mercado Shops se publicó primero en Kambrica.

Charlas:

• El futuro del diseño y UX: los 15 años que se vienen.
  Martes 1 de agosto | 14:00 hs. | Lugar: Jean Jaurès 932.
  Presentada previamente en 2016.
• Design Research: cómo realizar las preguntas correctas para el proceso de diseño.
  Martes 1 de agosto | 17:00 hs. | Lugar: Jean Jaurès 932.
  Primera presentación en Argentina. Presentada previamente en febrero 2017 en Houston, Texas.
• UX y metodologías ágiles: diseñando sin desperdicio.
  Miércoles 2 de agosto | 14:00 hs. | Lugar: Jean Jaurès 932
  Presentada desde 2012.
• Experiencia de Usuario: diseñar más allá de las pantallas
  Miércoles 2 de agosto | 18:30 hs. | Lugar: Jean Jaurès 932
  Presentada en 2016 en Google LaunchPadBA, consolidando temas presentados desde 2008.

La entrada Santiago Bustelo en el XII Encuentro de Diseño UP 2017 se publicó primero en Kambrica.

Áreas de trabajo

• Capacitación
• Mentoría
• Metodologías ágiles

Resultados

Como resultado de nuestro programa de capacitación, Technisys formó su equipo de UX propio, se mejoró la integración de los equipos y procesos, y se logró la adopción de herramientas de diseño centrado en el usuario por parte de la compañía y clientes.


Con la incorporación de UX logramos aportar valor a nuestros clientes. UX es hoy un factor diferencial de nuestras soluciones.

Miguel Santos, CEO Technisys

La entrada Technisys se publicó primero en Kambrica.

Increase es una de las startups que, en el marco de la aceleradora Wayra, participó de nuestro programa de consultoría y mentoría en técnicas de UX para el desarrollo de su producto.

La plataforma de Increase permite a los comercios entender, manejar y administrar todas las operaciones que realizan con tarjeta de crédito y débito.

• Antes de nuestro trabajo con Increase, la mayoría de sus clientes interactuaban con la aplicación a través de Excel
• Después de las mejoras en la usabilidad de la interfaz, los usuarios empezaron a interactuar en mayor medida con la aplicación que con Excel

Áreas de trabajo:

• Como punto de partida, realizamos una ronda de pruebas de usabilidad sobre la plataforma tal como se encontraba en octubre de 2014. En esa instancia evaluamos la propuesta de valor y la usabilidad del sistema.
• Utilizamos esos insights para organizar una segunda sesión de research. Esta vez, realizamos entrevistas contextuales con los usuarios de la herramienta para relevar los problemas que encontraban a partir del uso recurrente de la misma.
• El equipo de Increase tomó toda la información obtenida en ambas instancias, y rediseñó la home del sitio, mejorando la comunicación de la propuesta de valor, el registro en la plataforma y el uso de la misma, realizando una priorización y jerarquización de la información que se muestra y permitiendo un mejor manejo de la misma. Todo el proceso de rediseño fue encarado por el equipo emprendedor con seguimiento semanal de parte de Kambrica.
• Se realizó la transferencia de conocimiento sobre el proceso de trabajo Lean para que el equipo pueda continuar replicando la metodología una vez finalizado el programa. De esa manera, la startup cuenta con las herramientas para continuar refinando y mejorando su producto.
• Mediante el programa Lean UX ayudamos a Increase a identificamos las principales áreas de mejora del producto, incluyendo funcionalidades y aspectos de usabilidad y diseño de interacción.
• Los ayudamos a mejorar la propuesta de valor a través de entrevistas con usuarios.
• Formamos al equipo en prácticas de UX.

Nos enseñaron a pensar y entender como crear un producto basado en lo que el cliente necesita y no en lo que los founders quieren. Como diseñar un producto escuchando, analizando y por sobre todo observando a nuestros usuarios. Kambrica nos ayudó a crear un producto sólido que hasta hoy sigue teniendo la misma estructura.

Matías Doublier, COO Increase

La entrada Increase Card se publicó primero en Kambrica.

“Mantenimiento” es cuando hay que reparar baches producto del paso de los autos. O reparar manchas de humedad, producto de la lucha entre el agua y los materiales. O reponer piezas sometidas a desgaste mecánico. 

Nada de eso pasa con el software.

Lo que se llama “mantenimiento” en software, en arquitectura se llama “ampliaciones y refacciones”.

Cuando hay que atender a nuevos requerimientos, es lo mismo que…

• proyectar un nuevo piso en una casa, para que tengan sus habitaciones privadas los niños que ahora son adolescentes.
• tapiar una ventana, porque se mudaron vecinos enfrente.
• instalar barandas en la bañadera, porque la pareja que encomendó la vivienda cuando era joven, ahora tiene problemas de cadera. 
• construir una pirámide de cristal en medio del Louvre.

¿Por qué entonces en el caso de software, a esto se lo llama “mantenimiento”?

Quizás porque hace unos 30 o 40 años, los comerciales encontraron que esa metáfora se aceptaba sin tener que explicar a sus clientes qué es realmente el software, algo que no iban a entender. En esa época, el software que se contrataba, no necesitaba atender a factores humanos ni responder a una realidad cambiante. Tenía sentido entonces invertir meses en negociaciones contractuales y definiciones de requerimientos, para luego aferrarse a un plan. Algo que desde hace 15 años, sabemos que no logra resolver los problemas que nuestros clientes tienen hoy.

Quizás hoy un comercial pueda lograr una venta empleando las metáforas de hace 30 o 40 años. Pero difícilmente logre los compromisos que un equipo necesita para construir la solución. 

Nuestros clientes hoy viven rodeados de tecnología que mejora día a día. No quieren funcionalidades: quieren desarrollar un negocio. Y para ello, tienen que entender qué es el software y cómo se construye. Porque los problemas para los cuales nos contratan hoy, requieren que sean parte comprometida de una solución que requerirá de agilidad y compromiso en las decisiones de negocio.

Dejemos de hablar de “mantenimiento”.

Hablemos de decisiones informadas de diseño, tecnología y negocios, construyendo hoy con previsión razonable de necesidades futuras. Hablemos de estar allí para reaccionar, demoler y construir cuando esas necesidades tomen forma y el negocio decida responder a ellas. Hablemos de colaboración necesaria para lograr objetivos bien definidos. Hablemos de qué problemas hay que resolver y no de cuál es el gusto particular de stakeholders que no serán usuarios.

Tengamos conversaciones propias de nuestro siglo.

Santiago Bustelo

La entrada Dejemos de hablar de “mantenimiento” de software se publicó primero en Kambrica.

Presentado en:

• Artmedia 2016: Universidad Maimónides / CCGSM, Jueves 10 de noviembre 2016
• Interaction South America 2016: IxDA / Universidad Católica de Chile, Jueves 3 de noviembre, 2016
• XI Encuentro Latinoamericano de Diseño: Universidad de Palermo, Martes 26 de julio, 2016

El software se está comiendo al mundo: no sólo hoy resulta omnipresente, sino que sus prácticas y metodologías están cambiando la forma misma de planear y hacer las demás cosas. El Diseño de Experiencias (UX), surgido en el contexto del software, está empezando a abarcar e impactar a las demás disciplinas de diseño, marcando su futuro.

En esta presentación haremos un breve repaso de los hitos de los últimos 15 años en el Diseño de Experiencias, y proyectando la dirección que tendrán en los próximos 15 todas las disciplinas de diseño.

La entrada El futuro del Diseño y UX: los 15 años que se vienen se publicó primero en Kambrica.

En 2010 el banco Santander Río necesitaba migrar la solicitud de sus productos del canal físico al online. Hasta ese momento el pedido de tarjetas de crédito era un trámite que muy pocos clientes estaban dispuestos a realizar de forma online.

Los motivos: escasa confianza en el canal online y formularios que requerían datos que los usuarios no comprendían o no estaban dispuestos a completar.

Áreas de trabajo

Rediseñamos todos los formularios de contratación siguiendo buenas prácticas de usabilidad y accesibilidad.

• UX Research para evaluar los procesos existentes, motivaciones e intereses de los usuarios, oportunidades y áreas de mejora.
• Rediseño del proceso de contratación de tarjetas y paquetes bancarios siguiendo mejores prácticas de persuasión, usabilidad, accesibilidad y diseño responsive.
• Rediseño de sistemas internos de Gestión del Conocimiento
• Realizamos entrevistas con el Call Center para conocer mejores prácticas de venta, aplicadas a procesos de upselling.

La entrada Santander Río se publicó primero en Kambrica.

Caso de ejemplo: La mejor teleconferencia del mundo, con la mejor tecnología, la mejor conectividad, el monitor más grande… nunca podrá ser mejor que la “maravillosa” experiencia de visitar a alguien a la cárcel y hablar reja o vidrio blindado de por medio.

Ése sería el techo para una App de videoconferencia. La tecnología puede servir para replicarla a la distancia, pero nunca le va a poder agregar más calidad. Viendo las cosas de esa manera, se pueden plantear expectativas más realistas para un producto… Y decidir si no sería mejor enfocar otros aspectos que puedan lograr una experiencia que realmente valga la pena.

La entrada Entender la experiencia primero, la tecnología después se publicó primero en Kambrica.

Creemos que a diferencia de lo que puede darse para aspectos concretos y finales de cara al usuario (tales como lenguaje visual), en una disciplina más abstracta que trata las relaciones entre personas, tecnología y organizaciones, las tendencias se desarrollan necesariamente de manera más profunda y en plazos más largos. 

Al mapear los hitos de nuestra disciplina –tanto históricos como proyectados– contra una línea de tiempo y órdenes de complejidad, encontramos cómo los logros de los últimos 15 años, marcan la dirección en la que se darán los próximos:

• En caso de la tecnología, hemos pasado de resolver adecuadamente una pantalla (interfaz), a resolver cuestiones propias de varias pantallas (flujos de operación), y luego los problemas de diseño a través de varios dispositivos. Hoy estamos empezando a abordar problemas que involucran varios canales y modos de atención; en un futuro, estaremos resolviendo problemas de ecosistemas de productos y servicios.
• En caso de los negocios, hemos pasado del establecimiento de competencias técnicas de un individuo, al trabajo en equipo y luego la coordinación de múltiples equipos. Hoy estamos empezando a ver la incorporación de técnicas de diseño aplicadas a pensar las organizaciones mismas. En un futuro, estaremos resolviendo problemas en el ámbito de ecosistemas de organizaciones.

En los últimos 15 años, muchas cosas se han establecido como la base ya asentada y compartida en nuestra industria. Qué es Accesibilidad, por qué es importante y cómo llevarla a cabo; qué y cómo disponer en una pantalla; o cómo integrar usabilidad, diseño y desarrollo en metodologías ágiles, ya no son temas de exposición en conferencias de UX. Han pasado de ser áreas de discusión y exploración, a campos en el que hay suficientes referencias y estándares reconocidos. Esto no significa que estos temas hayan dejado de importarnos, pero sí que representan cada vez menos un desafío o diferencial, y cada vez más expectativas básicas respecto a la formación que debe tener un profesional de UX.

Para los próximos 15 años, creemos que la tecnología y los negocios tenderán a cada vez mayores órdenes de complejidad y abstracción, abriendo campos y nuevos desafíos a resolver por el diseño. A continuación, presentamos los cinco puntos más sobresalientes en nuestra visión del futuro de UX.

1. De Responsive, a Experiencias Omnichannel

Las experiencias se tornan cada vez más complejas, más fragmentadas y más fluidas. Como resultado, estaremos pasando de la arquitectura de información “clásica” a estrategias de contenido más dinámicas, de “funnels” lineales a espacios de interacción, y a centrar el diseño desde los momentos del usuario y sus puntos de contacto, tanto virtuales como presenciales.

El Customer Journey, así como nuevas formas que encontremos para mapear y entender estas situaciones, serán documentos cada más indispensables en el proceso de diseño.

2. De lograr Conversiones, a diseñar Relaciones

A medida que la experiencia se vuelve más compleja, fluida y menos lineal, resolver una transacción no es suficiente para ser relevantes. Surge la necesidad de generar relaciones, esto es, construir y cultivar un vínculo con los usuarios. Esto, a su vez, impulsará la aparición de nuevas técnicas y herramientas de relevamiento y validación, y de evaluación del valor de los negocios.

3. De Ejecución, a Estrategia y Gestión

UX está dejando de ser un función de diseño o técnica, para pasar a ser una función del negocio y gerencial. A medida que más organizaciones entienden que la experiencia de usuario es el resultado de las decisiones de todos los actores involucrados, UX pasa de proponer y desarrollar soluciones, a encuadrar cómo dirigir y gestionar a los equipos y a la organización.

4. De UX en gestión pública, a gestión pública centrada en el ciudadano

En los últimos años, han surgido iniciativas como gov.uk y 18F que finalmente, logran una expresión de la gestión pública centrada en el usuario.

El camino allanado no sólo será seguido por iniciativas en el resto del mundo, sino que a partir del 2020 aparecerán signos de transformación en las relaciones entre gobiernos y ciudadanos, y hasta en la definición misma de lo que es gestión pública.

5. De dispositivos a ecosistemas

Internet of Things, Wearables, Inteligencia Artificial y Big Data se muestran hoy, particularmente para el consumidor final, como soluciones buscando un problema.

Si se plantean como experimentos para “estar a la avanzada” sin una visión integradora de a qué futuro quieren llevarnos, es porque ese futuro no estará en la oferta de un dispositivo o marca en particular, sino en ecosistemas de dispositivos, para lo cual aún falta mucho por recorrer en lo técnico (estándares y solidez tecnológica) y en el paradigma económico (colaboración entre actores).

Cada artefacto que sumamos a nuestras vidas multiplica su complejidad con todos los que ya tenemos; hoy estamos llegando a un punto de saturación. La respuesta que nuestra industria tendrá que lograr para sobrevivir, es la integración de todos estos artefactos en experiencias consistentes.

#include <felicidades>

Por último, desde estas líneas les deseamos no sólo felices fiestas y próspero año nuevo… sino un excelente quindenio :)

La entrada Tendencias UX 2016 a… 2030! se publicó primero en Kambrica.

Jared Spool, uno de los referentes del campo de UX identificó 5 tipos de decisiones de diseño.

Estos tipos de decisión no sólo se aplican al diseño de interfaces, sino que también impactan -y mucho- en el diseño de un producto. Y si hablamos de emprendimientos, el tipo de decisiones que se tomen pueden marcar la diferencia entre el éxito o el fracaso.

Los estilos están ordenados de menor a mayor costo y nivel de esfuerzo.

• Accidental
• Autorreferencial
• Diseño Informado
• Enfocado en tareas
• Enfocado en los usuarios

Diseño Accidental

Este tipo de diseño ocurre cuando no se toma ninguna decisión de diseño. El diseño simplemente ocurre como resultado de ir agregando elementos (funcionalidades) a medida que van surgiendo, sin pensar en el todo como conjunto.

En el diseño accidental predominan:

• Las funcionalidades sobre la experiencia de uso
• El modelo tecnológico sobre el modelo mental del usuario
• Las partes sobre el todo

A corto plazo es el tipo de diseño más barato, porque cuando se diseña de esta forma no se hacen pruebas de usabilidad u otro tipo de investigación. Pero en el mediano y largo plazo es el tipo de diseño más caro, porque la deuda de UX se va acumulando con cada nuevo usuario y con cada nueva funcionalidad que se agregue.

Diseño autorreferencial

Este tipo de diseño ocurre cuando uno diseña lo que a uno le gustaría usar, o diseña para resolver un problema que uno tiene. Si bien hay altas chances de que más de uno tenga las mismas necesidades que nosotros, para que un producto sea exitoso, o un diseño sea efectivo, es necesario validarlo con los usuarios potenciales de nuestro producto.

Junto con el diseño accidental, es uno de los estilos de diseño más usados. No necesariamente por un tema de costo, sino por el supuesto implícito de muchos emprendedores (diseñadores) de que uno es representativo de su mercado.

Construir o diseñar un producto sin validarlo con el mercado termina siendo costoso en el mediano y largo plazo, ya que se invierten recursos en un producto que en la mayoría de los casos necesita ser rediseñado para ajustarse a las necesidades del mercado.

Diseño Informado

Este tipo de diseño está basado en función de los conocimientos y la experiencia del diseñador o emprendedor. A veces también se toman en cuenta datos que surgen de estudios de mercado u otros informes, pero al ser genéricos esta información aporta más una guía que información específica del producto.

Si bien este tipo de diseño tiene una calidad mayor que los diseños anteriores, sigue sin haber sido validado con quienes realmente lo van a usar.

Basado en Tareas

Este es un tipo de diseño mucho más avanzado y suele involucrar cierto nivel de testeo con usuarios. El problema que tiene este diseño es que se enfoca en las partes y no en el todo.

Si bien las diferentes tareas se pueden concretar con facilidad, cuando éstas se concatenan suelen existir fallas de “sistema”. Por tener una visión fragmentada del todo, este tipo de diseño suele considerar un caso de uso por tarea, y el problema surge cuando en la realidad hay más de un caso de uso por usuario.

Basado en los Usuarios  

Obviamente este es el mejor diseño porque contempla la experiencia total del usuario con el producto y no casos aislados. Si bien es más costoso en un primer momento y puede agregar algunas semanas al tiempo de desarrollo, a la larga resulta ser el más barato, el que menor retrabajo necesita, y el que mayor éxito tiene.

En este video, Jared Spool habla con mucho más detalles acerca de los cinco tipos de decisiones de diseño.

Jared Spool – Anatomy of a Design Decision from User Interface Engineering on Vimeo.

La entrada 5 tipos de decisiones de diseño se publicó primero en Kambrica.

Identifica tres perfiles o áreas de interés que los diseñadores pueden elegir:

• Ser un especialista: es decir, saber más de un área en particular que de otras. Por ejemplo, especializarse en arquitectura de la información, pero también saber de diseño de interacción, UX research, y otras técnicas.
• Ser un generalista: es decir, tener igual cantidad de conocimiento en varias áreas. 
• Tener conocimiento compartamentalizado: saber mucho de una sola area en particular, por ejemplo, arquitectura de la información.

Tener un conocimiento compartamentalizado es una decisión que limita las posibilidades de carrera, mientras que los diseñadores que tienen un perfil de generalista son los que más posibilidades de crecimiento tienen.

En un estudio que hizo con managers de recursos de diseño, en respuesta a la pregunta “¿qué distingue a los mejores diseñadores?” se encontró con que, sorpresivamente, los empleadores buscan recursos con igual cantidad de conocimiento de diseño que de negocio, como muestra el slide de abajo.

En violeta se destacan los conocimientos técnicos imprescindibles, y en azul los conocimientos de áreas complementarias que enriquecen y potencian el desempeño de los diseñadores:

En este link se puede acceder al deck completo de la presentación; el slide de arriba es el #61.

Este estudio, tiene muchos puntos de coincidencia con otro que publicamos en un post anterior, sobre las dos características más buscadas por los empleadores en los recursos de diseño, donde también se menciona la importancia de que los diseñadores conozcan aspectos del negocio.

La entrada Se viene el generalista de UX se publicó primero en Kambrica.