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.

“El mayor impacto está en el área de diseño de chips, donde todas estas tareas a nivel de bloque corren en paralelo y hoy existe una incapacidad para gestionar bien el proceso.” – Evaluación interna del proyecto

* Este proyecto se presenta de forma anonimizada bajo acuerdos corporativos de confidencialidad. Aunque la plataforma general permanece bajo reserva, este componente operativo ilustra cómo el diseño de interacción estructural habilita la productividad.

“Nos estábamos ahogando en mails.”

Senior Tooling Engineer, fabricante global de semiconductores

En un fabricante global, 100 ingenieros distribuidos en dos continentes sufrieron un colapso operativo crítico: mientras el cronograma exigía el cierre de tiempos (timing closure), 60 ingenieros permanecían bloqueados en el ruteo físico.

Cuando las herramientas internas no lograron procesar la complejidad de la lógica de negocio, las operaciones de ingeniería colapsaron en correos electrónicos: los líderes recibían más de 200 emails por día intentando coordinar tareas interdependientes entre bloques.

El análisis operativo reveló el cuello de botella central: los formularios planos estándar provistos por la consola Django eran incapaces de expresar dependencias de hardware multidimensionales.

La solución: notación prefija y árboles recursivos

Para superar los límites de los formularios planos, estructuramos la interfaz usando notación prefija. Mapeamos los grupos visuales directamente a código XML anidado, sin parsers ni capas intermedias:

En esta arquitectura:

• El operador engloba al grupo: las condiciones están gobernadas por Match [ ALL ] o Match [ ANY ].
• Cero operadores huérfanos: los usuarios pueden agregar, eliminar o reordenar reglas sin generar estados de sintaxis inválidos.
• Anidamiento visual arbitrario: la sangría funciona como paréntesis estructurales, permitiendo a los líderes evaluar consultas como (A AND B) OR (C AND D) de forma geométrica, sin tener que escribir lógica booleana.

Paridad bidireccional: del árbol visual al código directo

Obligar a un ingeniero a armar veinte variaciones de una consulta compleja mediante menús desplegables es un antipatrón.

Para acompañar los flujos de trabajo técnicos, el componente ofreció paridad bidireccional de código: hacer clic en [ Edit XML ] exponía directamente el árbol de sintaxis subyacente.

<assertion id="">
  <group type="any">
    <eval>
      <question id="qOwner" />
      <comparator type="EQ" />
      <answer id="">Lead Designer</answer>
    </eval>
    <group type="all">
      <eval>
        <question id="qStage" />
        <comparator type="EQ" />
      <answer id="pr">Place and Route</answer>
      </eval>
      <eval>
        <question id="qStatus" />
        <comparator type="NEQ" />
        <answer id="blk">Blocked</answer>
      </eval>
    </group>
  </group>
</assertion>

Los ingenieros podían editar el XML directamente, alternar la vista y ver el árbol validado renderizarse al instante.

Preservar el stack existente: por qué un rediseño visual era un antipatrón

Las iniciativas de software corporativo suelen asignar el presupuesto a lavados de cara cosméticos. Peor cambiar estilos de botones, márgenes o tipografías, no habría destrabado a un solo ingeniero. El diseño existente de Django Admin era completamente funcional; el cuello de botella era que los componentes de formulario estándar no pueden modelar lógica multidimensional.

El diseño de interacción no es cosmética; es la lógica operativa que conecta la intención humana con la arquitectura del sistema. A partir de nuestro diagnóstico, dejamos intacta la capa visual y nos concentramos exclusivamente en el cuello de botella estructural: la arquitectura de interacción para la construcción de consultas.

Saber qué patrón aplicar

Al diseñar filtros complejos, los desarrolladores suelen proyectar el código del backend directamente sobre la interfaz, insertando selectores AND / OR. Esto genera la ambigüedad visible en herramientas de servidor masivas como cPanel: en una secuencia como A OR B AND C, la interfaz falla en comunicar la precedencia de operadores.

Apple demostró previamente el valor de la notación prefija en lenguaje natural en Apple Mail (“Si se cumplen [todas / alguna de] las siguientes condiciones”). Sin embargo, por razones de usabilidad para el público general, Apple limitó deliberadamente este patrón a una lista plana.

Las dependencias en microprocesadores exigían anidamiento. No reinventamos la rueda (lo cual es una pésima idea en diseño de interacción): evaluamos y adaptamos el modelo prefijo de Apple para soportar grupos recursivos, y lo conectamos a la herramienta existente en Django.

Aunque la plataforma integral permanece bajo acuerdos de confidencialidad, este componente fue el punto de apoyo decisivo: le dio a los líderes un mecanismo confiable para consultar tareas en paralelo sin salir de la consola.

Resultados: restaurar el throughput de ingeniería

Destrabar un cronograma de microprocesadores de millones de dólares no requirió reemplazar sistemas corporativos ni reconstruir bases de datos del backend.

Al integrar una arquitectura de interacción formal en su herramienta existente de Django, los líderes técnicos pudieron aislar bloques demorados y ejecutar acciones masivas en segundos a través de frentes paralelos de ingeniería.

Y 100 ingenieros de chips tuvieron la herramienta adecuada para coordinar sus esfuerzos y volver a enfocarse en lo que realmente importa: entregar silicio a tiempo.

La entrada Semiconductores e Ingeniería de Hardware se publicó primero en Kambrica.

Desde 2012 trabajamos junto a los equipos de Producto Digital del Grupo Telefónica diseñando y mejorando las experiencias de usuario web y móvil con las que interactúan millones de personas.

Ayudamos a mejorar la usabilidad de los procesos de compra de telefonía fija, móvil e internet para incrementar ventas, reducir llamados al call center y optimizar procesos. 

Trabajamos en el desarrollo de landings promocionales, mejoras en los procesos de atención al cliente y comunicación de productos y ofertas, mejorando la comprensión y captación de la propuesta de valor.

• Disminuimos los costos de soporte y redujimos la frustración de los usuarios.
• Ayudamos a mejorar la madurez en UX de los equipos de producto digital, con impacto en otras áreas de la compañía.

Cómo ayudamos

• Rediseñamos la home de telefonía fija y móvil.
• Mejoramos los flujos de navegación del sitio.
• Rediseñamos el flujo de compra de planes de telefonía móvil.
• Rediseñamos el flujo de compra de planes de Internet.
• Rediseñamos el flujo de compra de fibra y planes de TV.
• Diseñamos y mejoramos el impacto de landings promocionales: portabilidad, Hotsale, Multiplicate, día de la madre, del padre, etc.
• Mejoramos los procesos de descubrimiento, adquisición y upselling de líneas telefónicas, Internet y líneas móviles.
• Mejoramos los procesos de autogestión de grandes clientes.
• Mejoramos la calidad de la información de la sección Atención al Cliente.
• Análisis de usabilidad y necesidades de comunicación para el lanzamiento del rediseño de la app de Movistar.
• Análisis de usabilidad y propuestas de mejora accionables para procesos críticos de negocio.
• Análisis cualitativo y cuantitativo de la performance de páginas y flujos específicos.
• Creamos el primer manual de usabilidad para la compañía, permitiendo alinear a todas las áreas.
• Creamos herramientas para reducir costos y tiempos en procesos de toma de decisiones, diseño y desarrollo.
• Desarrollo de workshops con stakeholders para definir visión de producto, facilitar la toma de decisiones de producto y diseño.
• Capacitaciones sobre metodología Lean UX, diseño centrado en el usuario, Design Thinking.

La entrada Movistar 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.

Entre muchas otras cosas, este modelo me ha ayudado a entender cómo enfocar mi propia carrera. Cuando me encontraba en la facultad, parecía ser mejor diseñador quien dominara mayor cantidad de recursos estéticos impactantes… o al menos, ésa era la persona que recibía las mejores calificaciones. ¿Era ésa la única vara posible para medir el Diseño? ¿Era eso a lo que yo quería dedicarme? ¿O había otra búsqueda posible para mí?

En menor escala, este modelo me ha servido para identificar qué función debería primar en una pieza, y en dónde dedicar mayor esfuerzo. Por ejemplo, el problema… ¿es que la pieza es aburrida? ¿O tal vez el problema será otro?

Para poder entender cada función, veámoslas primero por separado:

• Cuando sólo está presente la función Información, tenemos datos en crudo.
• La función Presentación refiere a la expresión estética. En estado puro (sin transmisión de información ni permitir el uso), resulta en figuras, colores y movimiento que provocan una experiencia estética.
• La función Uso refiere a la posibilidad de interpretación y operación que la pieza permite a quien accede a ella. Un caso de la función uso en estado puro (sin transmisión de información ni expresión propia de la pieza), es un papel en blanco.

Como verán, ninguno de los ejemplos de cada función aislada, es un diseño. 

Eso es porque en este modelo, el Diseño resulta del encuentro de estas tres funciones, en mayor o menor proporción. Si sólo están presentes una o dos funciones, no es una pieza de diseño.

Veamos cómo agregando funciones, paso a paso, nos lleva a una pieza de Diseño, y a entender mejor el carácter que debe tener.

Agregando funciones, paso a paso: del dato al Diseño

Tomemos como punto de partida las siguientes series numéricas (el cuarteto de Anscombe):

( 10.0/8.04; 8.0/6.95; 13.0/7.58; 9.0/8.81; 11.0/8.33; 14.0/9.96; 6.0/7.24; 4.0/4.26; 12.0/10.84; 7.0/4.82; 5.0/5.68 ), ( 10.0/9.14; 8.0/8.14; 13.0/8.74; 9.0/8.77; 11.0/9.26; 14.0/8.10; 6.0/6.13; 4.0/3.10; 12.0/9.13; 7.0/7.26; 5.0/4.74 ), ( 10.0/7.46; 8.0/6.77; 13.0/12.74; 9.0/7.11; 11.0/7.81; 14.0/8.84; 6.0/6.08; 4.0/5.39; 12.0/8.15; 7.0/6.42; 5.0/5.73 ), ( 8.0/6.58; 8.0/5.76; 8.0/7.71; 8.0/8.84; 8.0/8.47; 8.0/7.04; 8.0/5.25; 19.0/12.50; 8.0/5.56; 8.0/7.91; 8.0/6.89 )

En este caso, acabamos de mostrar datos en crudo: sólo está presente la función información. Si presentamos estos datos en una tabla, permitimos cierta lectura de los datos, incrementando la función uso:

Y por último, la presentación visual de esta información, incrementa la función Presentación:

El empleo del formato correcto, nos permite ahora ofrecer conclusiones al usuario. No sólo es posible distinguir rápidamente que estas series son distintas: a primera vista, también se puede reconocer el carácter de cada una (dispersión, progresión lineal, etc).

Como contaba antes, es por el encuentro de las tres funciones que llegamos a una pieza de diseño. En este caso, por el balance de las funciones, se trata de una pieza de diseño de información.

El balance de funciones hace a una disciplina de Diseño

Cada disciplina de diseño se caracteriza por un balance y priorización particular de estas funciones. Por ejemplo, en el diseño publicitario prevalece la función de presentación, en el diseño editorial la información, y en el Diseño de Interacción y de Experiencia de Usuario (UX), el uso.

Es por esto que muchas veces, el diseño centrado en el usuario puede ser percibido como “aburrido” por quienes entienden al diseño como sinónimo de publicidad. Y es por esto que los esfuerzos de volver a UX más “visual”, más “disruptiva”, más… publicitaria, en definitiva, suelen partir de ignorar a la usabilidad como foco de UX, con los resultados esperables: la degradación final de la experiencia del usuario.

Este modelo nos permite entender que el espacio de diseño es limitado, y que no es posible “agregarle impacto” a una pieza de diseño: sólo es posible cambiar su carácter. La cuestión, entonces, es cuál es el carácter que el diseñador o el cliente buscan… y si ése es realmente el carácter que esa pieza debería tener para resolverle un problema real a sus usuarios reales.

Santiago Bustelo

La entrada Las tres funciones del diseño 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.

Ante los excelentes resultados obtenidos para la nueva versión 3.0, el Consorcio SIU emprendió una versión intermedia 2.5 con menores requerimientos técnicos para facilitar la adopción.

Áreas de trabajo

• Realizamos entrevistas cualitativas con estudiantes usuarios del sistema para relevar problemas con la herramienta existente, necesidades y expectativas.
• En función de lo relevado rediseñamos el sitio, incluyendo: 
  • Arquitectura de Información
  • Diseño de Interacción
  • Diseño de interfaz
  • Pruebas con Usuarios.

La entrada SIU Guaraní 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.