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.

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.

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.

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

El proceso de diseño se trata de abrir alternativas válidas, generar nuevas preguntas, podar el árbol de posibilidades y volver a iterar… hasta llegar a una respuesta capaz de satisfacer la expectativa con la que se inició el proceso de diseño.

Al igual que dominar un idioma, o aprender a tocar el piano, la formación en diseño se trata de incorporar una práctica, no de la acumulación de información. Esta distinción resulta fundamental para evaluar adecuadamente cualquier tipo de formación en UX. 
A continuación, algunos aspectos que ayudarán a aclarar qué se puede esperar y qué no de un curso de UX.

¿Qué es aprender a diseñar?

En ningún curso de UX, sea cual fuere su extensión, se pueden aprender todas las respuestas concretas para tener a la mano ante cada situación que se pueda presentar. Ello no se debe a falencias particulares del curso, sino a que no es ésa la naturaleza de UX – o del diseño en general. 
Diseñar no es la capacidad de aplicar soluciones conocidas en respuesta a un requerimiento. Diseñar es la capacidad de idear y ejecutar buenas soluciones en respuesta a problemas particulares, de carácter complejo, y por ello formulados inicialmente de manera incompleta o simplemente errónea.
Por ello, diseñar es:

• una práctica: la visión y capacidad para idear y ejecutar buenas decisiones surgen de la experiencia validada, no de la mera adquisición de información;
• un proceso: llegar a una buena solución requiere desarrollar no una, sino varias alternativas, que a su vez llevarán a preguntas que no se habían considerado previamente.

El proceso de diseño se trata de abrir alternativas válidas, generar nuevas preguntas, podar el árbol de posibilidades y volver a iterar… hasta llegar a una respuesta capaz de satisfacer la expectativa con la que se inició el proceso de diseño. Lo que se puede aprender en un curso de UX no son las “respuestas correctas”, sino el universo en el cual se pueden formular preguntas de diseño, cómo desarrollar respuestas y someterlas a validación.

Por ello, el valor de un curso de UX no está en las “certezas” que promete, sino en las preguntas que sus alumnos puedan realizar y ser capaces de responder después de haberlo concluido. 

Aprender a diseñar: algo que un curso de UX puede iniciar, pero nunca completar

En disciplinas creativas, la información ayuda a ganar estructura, tiempo y claridad. Pero atiborrarse de información no es buena idea: en UX, como en cualquier disciplina creativa, es necesario un balance entre el saber y la práctica. Cuando el saber supera ampliamente a la práctica, resultan diseñadores frustrados por no poder ejecutar sus ideas. O críticos implacables, capaces de demoler cualquier propuesta y la moral de todo un equipo. 

Por eso, un buen curso de UX debe ayudar a aclarar, a abrir puertas, a ver posibilidades a la medida de los alumnos… que deberán ser exploradas y desarrolladas en la práctica profesional.

Siempre comento a mis alumnos que me siento satisfecho con dejarles puertas para abrir cuyo sentido irán encontrando con el tiempo, a medida vayan diseñando su propia carrera y construyendo su propia visión.

Creo que es intelectualmente deshonesto ofrecer y prometer otra cosa a la hora de ofrecer capacitación en cualquier disciplina de diseño.

Porque es la práctica (algunos dicen que 10.000 horas) la que lleva a la maestría. Porque la formación en disciplinas creativas implica un desarrollo y transformación de la persona que no puede ocurrir en unos pocos meses o años.

Porque la idea de una escuela o universidad como “fábrica” que toma como insumo estudiantes y produce profesionales formados al final de una línea de montaje, sólo puede ser fruto del anacronismo, estándares bajos, y/o publicidad engañosa.

Conclusión

¿Cuánto se puede aprender en un curso de UX? Si la medida es, “respuestas para tener en el bolsillo”, pues más bien poco o nada. Si la medida es, “la capacidad de ver más allá, de identificar problemas que no sabía que tenía, de poder darles respuestas mejores a las que tenemos hoy”… hay un mundo por delante.

Todo problema complejo tiene soluciones simples rápidas y erróneas. Si entendés tu carrera como un problema complejo que merece un buen proceso de diseño, nuestra propuesta de formación profesional es para vos.

Santiago Bustelo

La entrada ¿Cuánto se puede aprender en un curso de UX? se publicó primero en Kambrica.

En parte, esto ocurre porque diseñadores y desarrolladores tienen diferentes procesos y metodologías de trabajo y les falta un lenguaje compartido. Pero dado que necesitan trabajar en conjunto para lograr objetivos comunes, es importante encontrar una forma para que esta integración sea posible.

Pero dado que necesitan trabajar en conjunto para lograr objetivos comunes, es importante encontrar una forma para que esta integración sea posible.

Como parte de su tesis doctoral, Andrés Rodríguez propuso un modelo donde compara y equipara los roles de IT con los roles de UX en el marco de metodologías de desarrollo RUP, para generar una visión compartida entre ambas disciplinas.

A continuación, un resumen del modelo, basado en la Metodología RUP de IBM (Rational Unified Process):

Brevemente, la metodología RUP a pesar de ser un proceso dogmático, no es lineal sino que establece iteraciones, vueltas y pivoteo. Combina elementos de metodologías estructuradas y metodologías ágiles, y asegura que hay pasos pero no todos son secuenciales.  

Lo primero que Andrés Rodríguez resaltó como una problemática fue ver qué roles existen dentro de esta metodología y a qué nivel son comparables con los de UX. Así, desarrolló las siguientes comparaciones:

Stakeholders: están, en cierta forma, fuera del proceso. Es el cliente, el dueño del proyecto y puede ser:

• Patrocinador o sponsor: es la persona que le da apoyo político o económico al proyecto. Suele ser una sola persona que en caso de caerse u oponerse al proceso el proyecto se interrumpe. Por eso es importante definir claramente quién es el patrocinador del sponsor.
• Líder técnico del dominio: es la persona o comité que tiene conocimiento no tecnológico sino técnico del área de dominio.
• Representante del usuario: es el responsable pero no es quién ejecuta. Si solamente nos quedáramos con su postura, probablemente estaríamos presentando un “cuello de botella” al que el usuario se enfrentaría al hacer las cosas.
• Usuario final: el responsable de la ejecución. Es quién lleva a la práctica el hacer. Muchas veces, al llevar a la práctica el proyecto, se saltea muchos pasos que le resultan molestos por cuestiones productivas. Estos pasos son los que el Representante del usuario probablemente no haya tenido en cuenta.

Analista vs Especialista UX:  

IT: Analista (arquitecto de software)

Toma las decisiones que minimizan riesgos y aseguran la calidad del proyecto. Necesita experiencia que le den la capacidad de tener una visión a largo plazo. A su vez, es capaz de establecer una serie de prácticas en el equipo que permiten que la documentación no solamente funcione sino que, además, sea útil. 

Diseño: Especialista de UX (líder de UX, experto de UX)

Toma decisiones experiencia del usuario (UX), que, por definición, tienen impacto a largo plazo sobre la aplicación. Estas decisiones deben ser compartidas obligatoriamente con el Arquitecto ya que si no están sostenidas estructuralmente afectan el tipo de producto que se va a construir.

La responsabilidad de ambos en el proyecto es muy grande ya que toman decisiones estructurales que luego son muy difíciles y costosas de cambiar.

Desarrollador vs Diseñador de UX: 

IT: Desarrollador (programador)

Es quien tiene a cargo la ejecución. Toma decisiones de menor escala que el Analista. Tiene una visión de futuro más cercana.

Diseño: Diseñador de UX

Implementa experiencia del usuario diseñando los componentes de la interacción, los storyboards, prototipos, navegación, arquitectura de la información.

Ambos perfiles son responsables de darle forma concreta a la visión establecida en la etapa anterior.

Tester vs Tester de UX:

IT: Tester

Verifica que no haya errores, riesgos y vulnerabilidades que puedan presentarse y le hace una constante devolución al programador. La relación entre el tester y el programador es cíclica y se basa en el feedback.

Diseño: Tester de UX

Toma los diseños creados y lleva a cabo las pruebas de usabilidad verificando que los componentes desarrollados sean efectiblemente útiles y usables para el usuario final.

Es imprescindible que ambos trabajen en paralelo ya que el testeo se realiza sobre el producto en desarrollo.

La entrada UX & IT: un modelo para trabajar mejor se publicó primero en Kambrica.

Proyectos que se vuelven interminables, clientes insatisfechos y productos finales con los que el equipo no se siente orgulloso, son problemas comunes a muchos proyectos de diseño. No sólo son problemas evitables, sino que en los últimos años han surgido, desde la ingeniería industrial e ingeniería de software, definiciones y herramientas que resultan aplicables a todas las disciplinas de diseño.

En esta presentación se verán conceptos fundamentales como la triple restricción, definiciones objetivas de Calidad y Desperdicio, la diferencia entre problemas bien definidos y problemas complejos, bases de la metodología Scrum, y un caso real de aplicación de estos principios en un proyecto de diseño. 

Si bien diseño y desarrollo parecen dos mundos muy diferentes, diseñadores e ingenieros no sólo podemos encontrar puntos en común para entendernos, sino que también podemos aprender mutuamente.

Una muestra de que estos aprendizajes son aplicables a todas las disciplinas de diseño es que las metodologías ágiles, cada vez más aplicadas en proyectos de desarrollo, nacieron originalmente como respuesta a problemas de diseño e ingeniería industrial.

Los problemas que trata la ingeniería suelen involucrar mucha más gente y recursos que los que tratamos los diseñadores. El costo de un fracaso, por ello, resulta mucho mayor, resultando en la necesidad de definiciones y metodologías capaces de evitarlos.

Gestión vs. Azar

La primera definición importante es que un proyecto necesita de Gestión. Esto es, un esfuerzo constante sobre el “cómo” se trabaja, para poder despejar el camino a la hora de resolver el “qué” del problema. Este rol es desconocido por muchos diseñadores o programadores que trabajan por su cuenta, quienes consideran que sólo están trabajando mientras diseñan o programan. No considerar como “trabajo” el tiempo de interacción con el cliente, organización del trabajo, reporte del avance y otras tareas que no se identifican como productivas, lleva a que estas tareas -que se conocen indispensables para el éxito de un proyecto- se realicen mal o, simplemente, no se realicen.

La triple restricción

Para la gestión tradicional de ingeniería, se considera al proyecto enmarcado en tres variables: tiempo, costo y alcance, entendiendo por alcance lo que el equipo se compromete a hacer. Estas variables son mutuamente dependientes, de manera que no es posible tocar una de ellas sin impactar a las otras. Este modelo ya advierte de la necesidad de una definición y estimación correcta de las variables para poder gestionar tempranamente cualquier cambio. Pero al mismo tiempo, el hecho de que el modelo no defina claramente Calidad, lleva a que frecuentemente la calidad del producto sea sacrificada para satisfacer restricciones que surgen durante su ejecución. Este problema viene siendo atacado por lo que conocemos como Metodologías Agiles.

Metodologías ágiles y Calidad

Las metodologías ágiles proponen enfocar los esfuerzos en entregar mayor calidad en menor tiempo. Para ello, requerien en primer lugar definir de manera objetiva qué es Calidad. Ello hace posible asegurarla como resultado de un proyecto, en lugar de quedar librada a la suerte.

Tanto la ingeniería industrial como la ingeniería de software han plantado diversas definiciones y modelos de Calidad, de los cuales en la presentación se verá el de la filosofía Lean, surgida de adaptar a proyectos de software el modelo de Toyota. Ese modelo logró, en tan sólo 20 años, convertir a un país arrasado por dos bombas nucleares, en una potencia industrial.

La filosofía Lean establece que Calidad es lo que el usuario o cliente final valoran, y considera a todo lo demás como Desperdicio. Una conclusión importante es que la gestión y el equipo tienen la misión de identificar y eliminar el Desperdicio. La otra es que no podemos lograr calidad si no podemos entender y medir qué valora el cliente o usuario final.

Para las disciplinas de diseño, ergonomía, marketing y usabilidad son disciplinas que nos permiten, precisamente, entender y principalmente, medir qué valoran los usuarios finales. Aplicar correctamente las herramientas que proveen permite no sólo un producto de calidad, sino además un proceso de diseño en el cual cliente y equipo trabajan juntos con análisis, en lugar de enfrentarse en opiniones.

Scrum: domando problemas complejos

La ingeniería tradicional enfoca sus esfuerzos y metodologías de trabajo a lo que hoy se conoce como “problemas bien definidos”. Se trata de problemas conocidos, que pueden tener una formulación y resolución precisa.

En contraste, las metodologías ágiles enfocan sus esfuerzos a resolver problemas dinámicos, en los cuales los requerimientos cambian frecuentemente, no es posible entender el problema por completo antes de empezar a resolverlo, y no es posible encontrar una solución “correcta”, sino una mejor o peor que otra. En esta categoría de problemas, precisamente, se pueden enmarcar los esfuerzos de todas las disciplinas de diseño.

Scrum es una metodología ágil definida por Hirotaka Takeuchi y Ikujiro Nonaka en 1986 para incrementar velocidad y flexibilidad en el desarrollo de productos. Basada en casos de industria automotriz, fotocopiadoras e impresoras, y utilizado en Xerox, Canon, Honda, NEC, Epson, 3M y HP, hoy es un estándar aceptado en proyectos de desarrollo de software.

Scrum aplica a proyectos en los que los requerimientos cambian o son definidos sobre la marcha, ejecutados por un equipo bien capacitado, con buena comunicación interna y con el cliente.

Scrum propone:

• Separar el proyecto en sprints: iteraciones, mini-proyectos de tiempo fijo.
• Repriorizar tareas al principio de cada sprint.
• Las tareas son tomadas por el primer miembro del equipo que está libre.
• Cada sprint genera entregables.
• Intervención necesaria y estructurada del cliente en el proceso.

Roles e interlocutores en Scrum:

• Equipo (Scrum Master, diseñadores, desarrolladores)
• Equipo extendido (Equipo + Product Owner)
• Stakeholders (Equipo extendido + Clientes, Usuarios, Patrocinadores, Gerencia).

En la presentación se desarrolla este modelo y se presentan casos reales de aplicación de principios de Scrum en proyectos de diseño de diferente complejidad y escala. 

Esta charla también fue presentada en:

• Curso Experto Universitario en Accesibilidad y Usabilidad, UTN Facultad Regional Buenos Aires, 2015
• Curso Experto Universitario en Accesibilidad y Usabilidad, UTN Facultad Regional Buenos Aires, 2014
• Universidad de la Cuenca del Plata, 2013
• UX2012, Centro Cultural San Martín, 2012
• Encuentro Latinoamericano de Diseño, Universidad de Palermo, 2012

¿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 Charla “Metodologías ágiles: diseñando sin desperdicio” 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.

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.