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.

Así que puedo declarar que esta heurística es mía. Es la Heurística de Bustelo.

Principio: Las interfaces deben liberar al usuario de tareas repetitivas, aprovechando la capacidad de las computadoras para automatizar procesos. No hacerlo es desperdiciar el potencial del medio digital y castigar la eficiencia del usuario.

Ejemplo: La interfaz que muestro a continuación, que mi banco nos inflige a todos sus clientes, nos obliga a hacer un click por cada comprobante que necesitamos descargar.

A la hora de hacer el cierre fiscal, son 72 clicks que hay que hacer con cuidado de no saltearse nada: 2 tarjetas x 12, 3 cuentas x 12, y un año de Inversiones. Y eso, suponiendo que no tenés Préstamos, y sin contar los clicks que hay que hacer para pasar de una pestaña a la otra.

Todo ello, teniendo cuidado en cada click y haciendo scroll lentamente para no perder la guía (porque no hay distinción entre íconos cliqueados vs. aún sin cliquear).

El proceso puede llevar hasta una hora. Que se podría evitar con un enlace o botón de “descargar todo”. Es decir, aplicando la heurística de la naturaleza digital: el principio de que las computadoras están diseñadas para manejar tareas repetitivas de manera eficiente. Esta heurística enfatiza la importancia de aprovechar la tecnología para automatizar y simplificar procesos, asegurando que los sistemas e interfaces estén optimizados para acciones repetitivas, mejorando así la eficiencia del usuario y reduciendo la probabilidad de errores.

Santiago Bustelo
Mayo 2024

La entrada Heurística de la naturaleza digital: “las computadoras se inventaron para realizar tareas repetitivas”. 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.

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.

Á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.

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.

Realizamos un trabajo de rediseño y consultoría estratégica que tuvo como objetivos mejorar la interacción y el engagement de los usuarios y generar nuevos modelos de negocios.

Gracias a los insights logrados, se pudieron explotar nuevas fuentes de monetización: anuncios, descuentos, categorías y formas de pago sponsoreadas.

El proyecto es hoy caso de ejemplo en la incorporación de metodologías ágiles al proceso de diseño.

Problemática inicial

• El sitio había crecido de forma desorganizada a lo largo del tiempo: inconsistencia, problemas de mantenibilidad.
• Como producto de diseño autoreferencial, no se conocía el impacto real de muchas decisiones sobre la interfaz.
• Muchas ideas de mejora sin priorizar, de difícil aplicación dada la falta de consistencia y solidez del sitio.
• Nuevas amenazas en el mercado.

Antes y después

Plan general

Diseño y desarrollo en sprints

Se inició el proyecto con un sprint inicial (Sprint 0) de relevamiento del sitio, modelo mental de los usuarios, entendimiento del modelo de negocio, áreas de mejora y oportunidades.

Áreas de trabajo Sprint 0

• Análisis FODA y de analíticas.
• Revisión experta de usabilidad.
• Entrevistas cualitativas con usuarios.
• Proyección a futuro: brainstorming y exploración de hipótesis.

Las conclusiones del Sprint 0 alimentaron un plan de 3 sprints para trabajar –respectivamente– sobre lo urgente, lo importante y lo deseable.

Áreas de trabajo Sprints 1, 2 y 3

• Diseño de prototipos.
• Diseño visual.
• Pruebas de usabilidad.
• Ajustes luego de las pruebas.
• Desarrollo front-end.
• Cada sprint genera entregables.

El trabajo que hicieron es excelente. Estoy feliz!

Esteban Brenman, Fundador Guía Óleo

La entrada Guía Óleo se publicó primero en Kambrica.

Pero el concepto de “autoservicio” no quiere decir “yo proveo las herramientas y que el cliente se las arregle” sino “automatizar procesos existentes para la atención al cliente”. En otras palabras, autoservicio no es “encajarle el sistema al cliente” sino en darle buenos modales al sistema para que lo atienda, manteniendo los mismos estandares y procedimientos que en cualquier otro canal.

Pero la realidad es que mientras en las sucursales y en el call center atienden representantes de atención al cliente, en Internet “atiende” el departamento de IT. Que, dicho sea de paso, es una de las áreas que menos contacto real tiene con el cliente.

Pensemos en homebanking. No importa de qué banco hablemos, casi todos operan desde la perspectiva “yo proveo las herramientas y que el cliente se las arregle” y no desde la idea de “ayudar al cliente a efectuar una transacción”. Es decir, en homebanking queda sólo la capa de IT atendiendo a los clientes, sin que el área de atención al cliente haya agregado buenos modales a la interacción.

Veamos un ejemplo con una de las transacciones más utilizadas en homebanking: transferencias bancarias.

Más allá de cuestiones de legibilidad y consistencia en el diseño (espacios verticales entre los campos, ubicación de los rótulos, consistencia en los botones, etc.), que hacen que el cliente se sienta “bienvenido”, la forma en que operan algunos de estos campos da cuenta de la “perspectiva del sistema” vs. “perspectiva del usuario” con que está encarada la operación de transferencias en este canal.

Importe a debitar

No solamente está separado en dos campos, sino que el campo de los enteros es más corto que el campo de los decimales. Salvo que alguien quiera transferir el número PI (3,14159265), tiene más sentido que haya más espacio para los números enteros que para los decimales.

¿Por qué están divididos los campos? Algunas hipótesis, suponiendo que el cliente quisiera transferir $1.789,32 :

• separar los enteros de los decimales evita que se debite un monto equivocado si se omiten puntos y comas (ingresando 178932 se transferirían $178.932)
• para que la gente no confunda puntos por comas (1.789,32 vs 1,789.32)

Esta es la respuesta de IT frente al riesgo de que el usuario ingrese un monto equivocado y de asegurarse consistencia de los datos. Además le evita al programador agregar unas líneas de código para separar los enteros de los decimales. Pero esta solución representa un problema para el usuario, ya que exige mayor esfuerzo en la interacción, interrumpiendo el flujo de escritura innecesariamente para pasar de un campo al otro.

¿Se podía solucionar de otra forma? Sí. Muchos sitios, financieros y de e-commerce (e incluso los cajeros automáticos) insertan automáticamente una coma y un punto a medida que el usuario va ingresando los dígitos. Así, el banco se asegura de que el monto es correcto y que tiene la puntuación correcta sin tener que molestar al usuario. Este es un ejemplo de agregarle buenos modales al sistema.

Cuenta de Destino (CBU)

Al contrario de lo que ocurre con el monto de la transacción, que el usuario puede conocer y tipear directamente, el CBU tiene 22 dígitos, y es improbable que alguien lo recuerde de memoria.

Para ingresarlo sin errores, lo más común es copiar el CBU de algún lado y pegarlo en el formulario. Pero al separar el campo en dos, la operación copiar/pegar es imposible. Esto obliga al usuario a: copiar el CBU del documento original y pegarlo en otro documento, contar los primeros 8 dígitos y separarlos del resto, copiar esos dígitos y pegarlos en el formulario, volver al documento, copiar los 14 dígitos restantes y volver al formulario a pegarlos.

Pero hay otra opción: que el usuario los ingrese manualmente, con el alto riesgo de error que esto significa, sin mencionar la incomodidad para el usuario.

Era necesario hacerlo así? No. La forma de agregarle buenos modales a este campo es simplemente juntar los campos. Pero si por algún motivo el sistema requiere que se ingresen los dígitos en campos separados, la interfaz debería hacer la separación automáticamente y, de alguna manera, comunicarle al usuario que puede pegar los 22 números en el campo y que el sistema se encargará del resto.

Microsoft hace esto cuando pide el código para sus productos: si bien aparecen 4 campos separados, se puede pegar todo el número en el primero (20 dígitos) y el sistema lo separa automáticamente en grupos de 5 dígitos.

Con el campo Documento del Beneficiario pasa lo mismo que con los dos ejemplos anteriores, así que no lo desarrollamos.

Si bien hay empresas que pueden darse el lujo de priorizar sus sistemas por sobre sus clientes porque son cautivos, hay pocas opciones o porque el costo de cambiar de empresa es mayor que el de tolerar la mala atención, la mayor parte de las empresas operan en un contexto competitivo. Y esas empresas no pueden  darse este lujo de pensar en sus sistemas sin pensar en sus usuarios.

La entrada ¿Pensar en el sistema o pensar en el cliente? se publicó primero en Kambrica.

UX (Diseño de Experiencia de Usuario) y Diseño de Interacción, son nuevas disciplinas de diseño relacionadas con Diseño Industrial, Diseño Gráfico, Usabilidad e Ingeniería de Software.

En la charla se presentó diferencias y puntos en común del Diseño de Interacción con el Diseño Gráfico y Diseño Industrial. Además, de las nuevas habilidades que requieren los profesionales del diseño para desempeñarse dentro de estas disciplinas, y sobre técnicas y metodologías de trabajo específicas.

Se mostró cómo un programador, un diseñador visual y un diseñador de interacción resolverían el mismo caso de ejemplo, exponiendo las diferencias de criterio y proceso, y aplicando un modelo cuantificado para comparar los resultados.

Temario

UX y Diseño: definir cómo es, cómo funciona y cómo luce un producto digital

Disciplinas de diseño, entre lo abstracto y lo concreto: Diseño de Experiencias (UX), Diseño de Interacción (IxD): Define el modelo de operación de productos interactivos para lograr mejores experiencias para más usuarios.

Diseño de Interfaces: define los elementos concretos empleados en la interacción.

Diseño visual: Define lenguaje, carácter e identidad visual del producto.

Funciones del diseño: presentación, información, uso

Usabilidad: forma y función. La usabilidad de una interfaz es una medida de la efectividad, eficiencia y satisfacción con la cual determinados usuarios pueden alcanzar determinados objetivos en un entorno particular con dicha interfaz. (ISO 9241, Requerimientos ergonómicos para trabajo de oficina con terminales visuales, Parte 11 – 1997).

Un ejemplo de proceso de diseño aplicado a un caso

Producto: Software de administración de un videoclub. Nuestros personajes: Programador, diseñador, emprendedor.

• Enfoque del Programador
  Tres entidades: Películas: Datos; Clientes: Datos; Alquileres: Relaciones. Operaciones: Alta, baja, modificación y consulta para cada entidad.

• Enfoque del Diseñador
  Metáforas. Películas: DVDs; Clientes: Fichas; Alquileres: Ficha + DVD.
  Representación, Experiencia inmersiva, Fotorealismo.

• Enfoque del Emprendedor

Relevamiento competitivo, Definición del mercado, Especificación, Recursos y plan de trabajo

Problemas comunes a estos enfoques: diseño sin intención / autoreferencial. El usuario final no participa del proceso. Proceso lineal. Falta de metodología. Falta de política de calidad.

Diseño y Usabilidad: siempre ocurren. A un producto no le “falta” diseño o usabilidad; en todo caso, su diseño o usabilidad son malos. Son atributos cualitativos intrínsecos al producto: Como la performance, no se pueden “agregar”. Son definidos por el elemento más débil y afectados por todos los que construyen el producto. Proceso lineal vs. Proceso convergente.

Incorporando UX a nuestro ejemplo

Filosofía de Diseño Centrado en el Usuario: Creación de productos que resuelvan necesidades concretas de sus usuarios finales, consiguiendo la mayor satisfacción y mejor experiencia de uso posible con el mínimo esfuerzo de su parte.

Proceso de Diseño Centrado en el Usuario: Conocer a fondo a los usuarios finales reales. Diseñar un producto que resuelva sus necesidades y se ajuste a sus capacidades, expectativas y motivaciones. Poner a prueba lo diseñado.

Caso Centrado en el Usuario: Proceso de diseño y desarrollo convergente e iterativo. Evaluación competitiva, identificación de oportunidades. Definición preliminar del modelo. Validación y ajuste del modelo con usuarios. Priorización y estrategia de versiones. Prototipado de la interfaz. Pruebas con usuarios y ajuste de prototipos. Metodología ágil. Pruebas de usabilidad y QA antes de cada lanzamiento.

Calidad y cuantificación. Modelo KLM-GOMS. Comparación de los ejemplos previos. Desarrollo de la solución desde principios racionales de diseño y criterio de aceptación. Proceso de exploración y puesta a prueba.

Conclusiones: No hay Experiencia de Usuario sin usuarios.

Proceso iterativo de análisis y diseño centrado en la operación del usuario.

Bases racionales, cuantificación, calidad.

Obtener producto como resultado de un proceso, y satisfaciendo metas.

Charla presentada en:

• Microsoft Regional Architect Forum 2008
• Microsoft MIX 2008
• Día de la Usabilidad – Bogotá, Colombia, 2011
• UTN Tucumán, 2012
• Universidad de la Cuenca del Plata, 2013

Video (Día de la Usabilidad – Bogotá, Colombia 2011)

La entrada Charla “UX y Diseño de Interacción: Usabilidad aplicada” se publicó primero en Kambrica.

Transcipción de la entrevista publicada por TN

SB: Cuando ponemos afip.gov.ar nos encontramos con… una página de error [“El URL solicitado no se puede conseguir”]. Y esa página de error sucede porque el sitio no está preparado para recibir la dirección sin “www” adelante. Antes de recibirte, el sitio ya te está declarando que está hecho de alguna manera y es tu problema resolverlo, no por una intencionalidad sino porque no se ha observado que eso podía suceder y se podía prever.

SB: A través de la web vemos “clave fiscal: ingrese aquí”. OK. Bien. Y si no sé lo que es “clave fiscal”? Solicite clave. OK… “clave fiscal”, además, es un nombre como… Oh… Parece que no anda.

SD: Sí, y acá se ve que fue a blanco.

SB: Todo blanco.

SD: Bueno esto es lo que le pasa todos los días a todo el mundo.

SB: Yo creo que cuando suceden estas situaciones es porque justamente no se conocen alternativas, porque no se conocen posibilidades. Recién conociendo posibilidades uno puede reconocer un problema.

SD: Hay una ley que dice que la accesibilidad web es la posibilidad efectiva de que el mayor número de personas accedan de manera satisfactoria una web y hagan uso de sus contenidos. Algo que evidentemente no pasa con la AFIP. Entonces, ¿por qué no se hace? ¿Por desidia, por dejar un sitio diseñado como si fuera en el 1990?

SB: Yo creo que es por falta de conocimiento. Yo creo que es por falta de ver alternativas. Tienen problemas tales que hacen que la gente termine acudiendo a terceros: contadores, hijos que lo ayuden a usar el sitio, nietos, lo que sea. O, terminan haciendo cola, volviendo al canal tradicional y a veces se encuentran, para peor, que el canal tradicional le dicen: “Tiene que entrar al sitio”. Entonces, entramos en un círculo donde el servicio no está ofrecido como servicio y no hay solución. Creo que todo organismo público tiene una responsabilidad hacia los ciudadanos. El estado somos todos, y si el organismo a cada persona que entra a hacer un trámite la obliga a pasar por una serie de situaciones que no son necesarias, que son confusas, que puede dar lugar a problemas y lo esté haciendo con todos los ciudadanos está efectivamente haciendo que el país invierta su tiempo en algo que no es productivo.

Clarín: expertos afirman que la web de AFIP es “poco amigable”

El diario Clarín hizo eco de la entrevista realizada por TN, su canal de noticias. En el artículo disponible en clarin.com sobre los problemas de usabilidad del sitio de la Administración Federal de Ingresos Públicos, recoge algunas partes de la entrevista que no llegaron al aire.

“Santiago Bustelo, consultor en experiencia de usuarios, afirma a Clarín que “la cultura del organismo recaudador se refleja en su sitio, porque está enfocado en brindar un sistema para operar y en menor medida en dar ayuda”.

“Y plantea algunos ejemplos: “El sitio tiene una forma de llamar a las cosas que al normal de la gente no le resulta razonable. Por ejemplo, ‘siradig’ es el nombre del trámite para desgravar ganancias; en vez de factura electrónica se llama ‘comprobante en línea’; el sitio entrega comprobantes de cuil o cuit con guiones pero después pide que se ingresen sin guiones”.

“Planteado como está ahora –dice Bustelo– resulta necesario recurrir a un experto. Porque la gente no logra cumplir con lo que se exige, en un tiempo razonable y sin errores. Y en vez de sentirse orgulloso de haber cumplido un deber ciudadano, cuando logra concluirlo, el usuario siente que por fin se terminó un calvario”.

La entrada ¿Por qué se cae la web de la AFIP? se publicó primero en Kambrica.

Wayra es la aceleradora de proyectos tecnológicos del grupo Telefónica, con presencia en 12 países de América Latina y Europa. Todos los años, selecciona un grupo reducido de startups a las que brinda financiamiento, espacio de trabajo y acceso a una red global de mentores, expertos e inversores.  

Dentro de su programa de aceleración, brindamos consultoría, mentoría y capacitación a las startups sobre metodología Lean UX, diseño UX, diseño centrado en el usuario, pruebas de usabilidad, entrevistas cualitativas, tests A/B, priorización de tareas, identificación de oportunidades de negocio y evaluación de la escalabilidad de las soluciones, entre otras.

Áreas de trabajo

• Brindamos consultoría a más de 35 startups que participaron de nuestro programa de formación en técnicas de UX y metodologías ágiles para el desarrollo de productos digitales.
• Trabajamos con startups de diferentes sectores, incluyendo fin-tech, med-tech, agro-tech, entretenimiento, marketplaces, apps, e-commerce, IoT y smart-cities entre otras.
• Mediante el programa “Lean UX” ayudamos a startups de diferentes industrias a identificar/refinar su propuesta de valor, entender a sus usuarios para ajustar el producto acorde a sus necesidades, mejorar la usabilidad de sus productos para captar más clientes, crecer de forma más consistente y reducir costos.
• Desarrollamos un proceso de trabajo iterativo mediante el cual cada startup pudo ir refinando su producto en cada iteración, agregando más valor para el negocio, sus usuarios finales y sus inversores

Su programa Lean UX ayudó a los emprendedores a testear en ambientes reales sus productos, generando servicios de calidad con menor tiempo de salida al mercado.

Lorena Suárez, Business Development Manager Wayra

La entrada Wayra se publicó primero en Kambrica.

Áreas de trabajo

• Análisis del Negocio
• Diseño de reporte
• Desarrollo de lenguaje visual
• Diseño de Información
• Diseño de Interacción
• Diseño de interfaz
• Evaluación de Usabilidad

En una primera instancia ayudamos a Keepcon en el rediseño de la plataforma de moderación. Trabajamos en el relevamiento de modelos mentales, análisis y mejora de procesos y operaciones.

En una segunda instancia, Keepcon desarrolló una plataforma de reportes estadísticos para sitios. El valor diferencial a comunicar, pocos datos requeridos para obtener información de los sitios y rapidez en el procesamiento de los datos.

El mayor desafío en este caso fue ayudarlos a definir y comunicar una oferta de valor sólida. Lograr la atención, reflejar confianza, credibilidad y efectividad de la herramienta. Generamos una solución para la landing de venta incorporando técnicas de Cold Reading. 

La entrada Keepcon se publicó primero en Kambrica.

La Oficina de Asuntos Judiciales de esta Universidad nos eligió por nuestra capacidad de proveer diseño y desarrollo que cumpliera con los estándares de la Sección 508: que fuera accesible a todas las personas, independientemente de sus capacidades técnicas, cognitivas o físicas. Esto le valió el reconocimiento del panel de expertos en el prestigioso Festival South by Southwest (SXSW) en el año 2004.

La arquitectura de información y recomendaciones para el enfoque de contenidos fueron realizadas considerando los casos de uso en que docentes y estudiantes deben consultar el site: temas delicados relacionados con infracciones al código de honor de la universidad, tales como plagio, abuso de sustancias o acoso sexual.

El desarrollo HTML/CSS no sólo permitió resolver con el mismo código situaciones de accesibilidad, sino que también fueron contemplados estilos especiales para diferentes resoluciones y para impresión, de selección automática al imprimir la página o generar PDFs.

Gracias a este enfoque responsive, la página se convirtió en el repositorio único de información oficial para todos los formatos, eliminando los problemas de mantenimiento de la información en múltiples formatos y requiriendo el personal responsable documentación y capacitación sobre una única plataforma.

Áreas de trabajo

• Consultoría
• Accesibilidad
• Arquitectura de Información
• Diseño de interfaces
• Desarrollo front-end
• Validación con usuarios con discapacidad

Declaración oficial de la Universidad de Stanford

Accessibility Design Recognition, SXSW Interactive 2004, Austin, Texas

At the SXSW Interactive 2004 Accessibility Shoot-Out, Judicial Affairs was selected for its commitment to ensure that people of all abilities using any Internet device can access this site.

Accessibility experts attending the panel included:

• John Slatin, Director – Accessibility Institute at the University of Texas
• Jim Allan, Webmaster – Texas School for the Blind and Visually Impaired
• Sharron Rush, Executive Director – Knowbility.org
• Giorgio Brajnik, Asst. Professor – University of Udine, Italy, Usablenet
• Rashmi Bhat, Business Manager – SBC

Each Stanford University website is required to meet the definition of a generally accessible Internet site, and ensure that web pages transform gracefully and remain accessible despite any physical, sensory, or environmental constraints or technological barriers.

To meet these accessibility objectives, the Judicial Affairs site was designed, monitored and tested for compliance with Web Content Accessibility Guidelines (WCAG 1.0), as published by the Web Accessibility Initiative of the W3C. The Judicial Affairs site also complied with the accessibility requirements of Section 508 of the federal Rehabilitation Act Amendments of 1998 (29 U.S.C. § 794d). See 36 C.F.R. Part 1194.

As with most assistive technology, changes made to accommodate those with a disability end up benefiting everyone. A web page that is designed with accessibility in mind will be better structured and more user-friendly.

La entrada Universidad de Stanford se publicó primero en Kambrica.