HTML y ARIA son aliados para hacer que los productos digitales sean accesibles, especialmente cuando se trata de tecnologías de asistencia. Ambos permiten la conversión del contenido a formatos alternativos por medio de las tecnologías de asistencia, como lectores de pantalla, dispositivos braille u otros.

¿Qué es ARIA?

ARIA, que significa “Accessible Rich Internet Applications”, es un conjunto de atributos que se pueden agregar a elementos HTML para proporcionar información semántica a las tecnologías de asistencia, como lectores de pantalla y navegadores por voz. Estos atributos permiten que las tecnologías de asistencia comprendan mejor el propósito, el estado y las interacciones de los elementos en una página web.

¿Cómo funciona ARIA?

ARIA se comunica con las tecnologías de asistencia a través de las APIs de accesibilidad integradas en los navegadores web. Estas APIs crean un árbol de accesibilidad, que es una representación de la estructura de la interfaz de usuario a nivel accesible. Las tecnologías de asistencia utilizan el árbol de accesibilidad para navegar por la página y proporcionar información a los usuarios.

El árbol de accesibilidad

Representa la estructura de la interfaz de usuario (UI) a nivel accesible. El navegador crea el árbol de accesibilidad y se basa en el árbol estándar del modelo de objetos del documento (DOM). Al igual que el árbol DOM, el árbol de accesibilidad contiene objetos que representan todos los elementos de marcado, atributos y nodos de texto. Las APIs de accesibilidad específicas de la plataforma también usan el árbol de accesibilidad para proporcionar una representación que las tecnologías de asistencia puedan comprender.

ARIA por sí sola no cambia la funcionalidad ni el aspecto visual de un elemento. Eso significa que solo los usuarios con tecnologías de asistencia notarán las diferencias entre un producto digital con ARIA y uno sin ella.

Beneficios de usar ARIA

El uso de ARIA ofrece varios beneficios, como:

• Mejora la accesibilidad: ARIA hace que los sitios web sean más accesibles para personas con discapacidades visuales, auditivas, motoras y cognitivas.
• Mejora la experiencia del usuario: ARIA puede ayudar a mejorar la experiencia del usuario al proporcionar información clara y concisa sobre los elementos de la página.
• Mejora la compatibilidad: ARIA es compatible con la mayoría de los navegadores y tecnologías de asistencia.

Características principales de ARIA

Las tres características principales de ARIA son los roles, las propiedades y los estados o valores.

Los roles definen qué es o hace un elemento en la página o la app. Por ejemplo, un <div> con comportamiento de botón:

<div role=“button">Self-destruct</div>

Las propiedades expresan características o relaciones con un objeto:

<div role="button" aria-describedby="more-info">Self-destruct</div>
<div id="more-info">This page will self-destruct in 10 seconds.</div>

Los estados y valores definen las condiciones o los valores de datos actuales asociados con el elemento:

<div role="button" aria-describedby="more-info" aria-pressed="false">Self-destruct</div>
<div id="more-info">This page will self-destruct in 10 seconds.</div>

Si bien estos tres elementos de ARIA se pueden usar en una línea de código, no es obligatorio. En su lugar, aplica roles, propiedades y estados o valores de ARIA en capas hasta que logres tu objetivo de accesibilidad final. Incorporar correctamente ARIA en tu base de código garantiza que los usuarios de tecnologías de asistencia tengan toda la información que necesitan para usar el sitio web, aplicación o cualquier otro producto digital de forma exitosa y equitativa.

No utilizar ARIA es mejor que utilizar una mala ARIA

Las reglas de uso de WAI-ARIA se centran en la accesibilidad web, especialmente para usuarios con discapacidades. La principal regla es usar HTML nativo cuando sea posible, y solo usar ARIA cuando el HTML no proporciona la semántica o comportamiento necesario. Recuerda, ARIA permite definir roles, estados y propiedades para elementos HTML, mejorando su accesibilidad para tecnologías de asistencia como lectores de pantalla.

Reglas clave para usar ARIA:

Prioriza el HTML nativo:

• Por qué es importante: Los elementos HTML nativos (como <button>, <input>, <nav>, <article>, etc.) ya vienen con semántica integrada que los navegadores y las tecnologías de asistencia entienden automáticamente. Esto incluye información sobre su rol, estado y cómo interactúan. Usar HTML nativo siempre que sea posible aprovecha esta semántica preexistente, lo que generalmente resulta en una mejor accesibilidad con menos esfuerzo. Además, los elementos nativos suelen tener funcionalidades de accesibilidad incorporadas, como la capacidad de ser enfocados con el teclado.
• Consecuencias de no seguirla: Reemplazar elementos nativos con elementos genéricos (como <div> o <span>) y luego intentar replicar su semántica y comportamiento con ARIA puede ser más complejo, propenso a errores y menos compatible con todas las tecnologías de asistencia. A menudo, se olvida alguna pieza crucial, lo que lleva a una experiencia inaccesible. Por ejemplo, un <div> con role=”button” no tendrá automáticamente la capacidad de ser activado con la tecla “Enter” a menos que se implemente JavaScript adicional.

Usa ARIA solo cuando sea necesario:

• Por qué es importante: Añadir ARIA innecesariamente puede confundir a las tecnologías de asistencia. Si un elemento HTML ya tiene la semántica adecuada, agregar atributos ARIA redundantes puede crear información contradictoria o ruido innecesario para el usuario de la tecnología de asistencia.
• Consecuencias de no seguirla: Un uso excesivo de ARIA puede hacer que la información presentada a los usuarios de tecnologías de asistencia sea más larga, confusa y difícil de entender. También puede llevar a inconsistencias si los atributos ARIA no se mantienen sincronizados con el comportamiento real del elemento.

Asegúrate de que la navegación con teclado sea posible:

• Por qué es importante: Muchos usuarios no pueden o no utilizan un ratón, incluyendo personas con discapacidades motoras, usuarios de lectores de pantalla (que a menudo navegan secuencialmente con el teclado) y personas con temblores. Una navegación con teclado lógica y predecible es esencial para que estos usuarios puedan interactuar con todo el contenido y la funcionalidad de un sitio web o aplicación.
• Consecuencias de no seguirla: Si los usuarios no pueden acceder a los elementos interactivos (enlaces, botones, formularios, etc.) con el teclado, quedarán completamente excluidos de usar esa parte del sitio o aplicación.

No ocultes elementos enfocables:

• Por qué es importante: Los elementos enfocables son aquellos con los que los usuarios pueden interactuar mediante el teclado. Ocultar visualmente un elemento que aún es enfocable puede generar confusión y frustración, ya que el foco del teclado se moverá a un elemento que el usuario no puede ver. Además, las tecnologías de asistencia pueden seguir anunciando estos elementos ocultos, lo que dificulta la comprensión de la interfaz.
• Consecuencias de no seguirla: Los usuarios de teclado pueden quedar atrapados en elementos invisibles o confundidos por el movimiento del foco a elementos inesperados. Los usuarios de lectores de pantalla pueden recibir información sobre elementos que no son visualmente evidentes, lo que dificulta la comprensión del contexto.

Usa nombres accesibles para los elementos interactivos:

• Por qué es importante: Un nombre accesible es el texto que las tecnologías de asistencia utilizan para referirse a un elemento interactivo (por ejemplo, el texto de un botón o la etiqueta de un campo de formulario). Un nombre accesible claro y descriptivo permite a los usuarios de tecnologías de asistencia entender el propósito y la función de cada elemento interactivo.
• Consecuencias de no seguirla: Si los elementos interactivos no tienen nombres accesibles adecuados (o tienen nombres genéricos como “clic aquí”), los usuarios de tecnologías de asistencia no sabrán qué acción se realizará al interactuar con ellos, lo que dificulta o imposibilita el uso del sitio o aplicación. ARIA proporciona mecanismos como aria-label, aria-labelledby y aria-describedby para definir nombres accesibles cuando el HTML nativo no es suficiente.

No cambies la semántica nativa a menos que sea necesario:

• Por qué es importante: Los elementos HTML nativos tienen roles y comportamientos implícitos que las tecnologías de asistencia esperan. Cambiar estos roles con ARIA de forma inapropiada puede confundir a las tecnologías de asistencia y llevar a una interpretación incorrecta de la interfaz.
• Consecuencias de no seguirla: Si se asigna un rol ARIA incorrecto a un elemento (por ejemplo, usar role=”button” en un <div> que visualmente parece un enlace pero no actúa como tal), las tecnologías de asistencia pueden anunciar el elemento de manera engañosa, lo que lleva a una mala experiencia de usuario. Cambiar la semántica nativa solo debe hacerse cuando es absolutamente necesario para describir un patrón de interfaz de usuario que no tiene un equivalente en HTML nativo.

Sigue la estructura ARIA:

• Por qué es importante: Algunos roles ARIA tienen roles “padre” o “hijo” esperados para que las tecnologías de asistencia puedan interpretar correctamente la estructura y las relaciones entre los elementos de la interfaz de usuario. Por ejemplo, un elemento con role=”listbox” debe contener elementos con role=”option”. Respetar estas estructuras jerárquicas permite a las tecnologías de asistencia navegar y comprender la interfaz de manera lógica.
• Consecuencias de no seguirla: Si la estructura ARIA no es correcta (por ejemplo, elementos option directamente dentro de un <div> en lugar de un <ul> con role=”listbox”), las tecnologías de asistencia pueden tener dificultades para interpretar la relación entre los elementos, lo que dificulta la navegación y la comprensión para el usuario.

Asegúrate de que la interfaz visual y la accesible estén sincronizadas:

• Por qué es importante: La información que se presenta visualmente a los usuarios debe corresponder con la información semántica que se proporciona a las tecnologías de asistencia a través de ARIA. Las inconsistencias entre lo que se ve y lo que se “lee” pueden generar confusión y frustración.
• Consecuencias de no seguirla: Si un elemento visualmente parece un botón pero no tiene el role=”button” adecuado y un nombre accesible, los usuarios de lectores de pantalla no sabrán que es interactivo. De manera similar, si un estado visual (por ejemplo, un elemento desactivado) no se comunica a través del atributo ARIA correspondiente (aria-disabled=”true”), los usuarios de tecnologías de asistencia pueden intentar interactuar con un elemento que no está activo.

Usa los atributos ARIA adecuados:

• Por qué es importante: Cada atributo ARIA tiene un propósito específico (describir el rol, el estado o la propiedad de un elemento). Usar el atributo incorrecto no proporcionará la información semántica necesaria a las tecnologías de asistencia.
• Consecuencias de no seguirla: Usar atributos ARIA incorrectos o irrelevantes puede hacer que la información proporcionada a las tecnologías de asistencia sea incompleta, incorrecta o confusa, lo que dificulta la comprensión y la interacción para el usuario.

ARIA en HTML

ARIA debe ser usado en ciertas ocasiones, priorizando siempre el uso del HTML nativo cuando sea posible y siguiendo las reglas ARIA para garantizar la accesibilidad web. Puedes vincular ARIA con HTML en patrones que necesiten un nivel más alto de compatibilidad con las Tecnologías de Asistencia, por ejemplo debido a restricciones ambientales o como método de resguardo para elementos HTML que no son compatibles por completo con todos los navegadores.

— — — — — — — — — — — — — — — — — — — —

Fuentes consultadas:

• https://www.w3.org/TR/wai-aria-1.2/
• https://web.dev/learn/accessibility/aria-html
• https://accesibilidadenlaweb.blogspot.com/2020/08/las-cinco-reglas-de-aria.html
• https://web.ua.es/es/accesibilidad/accesibilidad-web/wai-aria.html
• https://www.paradigmadigital.com/dev/introduccion-aria/
• https://olgacarreras.blogspot.com/2007/09/wai-aria-introduccion-referencias.html
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

La accesibilidad digital es más que una tendencia; es un derecho.
¿Sabías que el testeo manual juega un papel fundamental en la creación de experiencias digitales inclusivas? En este artículo trataré conceptos básicos del testeo manual que darán pistas de cómo asegurar que los productos sean accesibles para personas con diversas necesidades.

Testeo Manual

El testeo manual es un proceso fundamental en el desarrollo de software y productos digitales, especialmente en el contexto de la accesibilidad digital. El tester se encarga de identificar y reportar errores en un producto digital para que el equipo de desarrollo pueda corregirlos. A través de ciclos iterativos de pruebas, se garantiza una mejora continua en la calidad del producto.

¿Cómo probamos?

La actividad de realizar pruebas se divide en dos etapas fundamentales:

• Pruebas Dinámicas: Implican la interacción directa con el producto para verificar su funcionamiento.
• Pruebas Estáticas: Se basan en la revisión de la documentación asociada al producto, como historias de usuario, planes de prueba, reportes de errores y criterios de aceptación.

Documentación

La documentación previa al test y la que se genere después de una evaluación sirven como un registro detallado de las actividades realizadas, los resultados obtenidos y las decisiones tomadas durante el proceso de testing. La documentación es nuestro respaldo como profesionales para indicar que pudimos corroborar y probar en base a unos estándares

Más adelante, pienso ahondar sobre la documentación en otro artículo, pero mientras me gustaría recalcar 3 aspectos claves y quedarnos con ellas:

• Documentación: Es esencial para respaldar el trabajo del tester y garantizar la trazabilidad de las pruebas realizadas. Los casos de prueba son una herramienta fundamental para documentar los pasos a seguir y los resultados esperados.
• Métricas: Se utilizan para medir el trabajo realizado y tomar decisiones informadas. Ejemplos de métricas incluyen la cantidad de errores encontrados, casos de prueba ejecutados y tiempo invertido.
• Adaptabilidad: El tester debe ser capaz de adaptarse a diferentes circunstancias, como cambios de última hora o falta de documentación.

Tipos de Testing

Son un grupo de actividades de prueba destinadas a probar las características de un producto digital. Algunos tipos de pruebas son:

• Pruebas Funcionales: Evalúan si el sistema cumple con los requisitos funcionales especificados. Se pueden medir a través de la cobertura funcional. Pueden estar descritos en productos de trabajo tales como requisitos de negocio, historias de usuario, casos de uso o especificaciones funcionales.
• Pruebas No Funcionales: Evalúan características como rendimiento, seguridad, usabilidad, conectividad, accesibilidad, estabilidad o seguridad. Se pueden medir a través de la cobertura no funcional. Las pruebas no funcionales se realizan en cada nivel de prueba, ya que pueden prever problemas no encontrados en pruebas funcionales.
• Pruebas de Caja Blanca: Se basan en el conocimiento de la infraestructura interna del sistema (código, base de datos, arquitectura) y requiere conocimientos técnicos avanzados como lenguaje de código y la lógica interna del sistema. Al conocer la estructura interna del código, las pruebas de caja blanca son efectivas para identificar errores lógicos, bucles infinitos, divisiones por cero y otros problemas específicos del código.
• Pruebas Asociadas al Cambio: Su objetivo es probar cuando el software ha sufrido algún cambio, ya sea después de detectar y corregir un defecto o asociados a nueva funcionalidad. Y en ella podemos encontrar las Pruebas de Confirmación y Pruebas de Regresión. Donde las Pruebas de Confirmación verifican que los defectos corregidos hayan sido solucionados. Y las Pruebas de Regresión aseguran que las correcciones y los cambios no hayan introducido nuevos errores secundarios o en otras áreas del sistema.

Existen más tipos de pruebas, las aplicaciones de ellas dependerán en todo momento de lo qué se necesite evaluar y otros factores. A continuación os dejo una tabla comparativa con diferentes tipos de pruebas:

Consideraciones Adicionales:

• Pruebas Exploratorias: Pruebas sin planificación detallada, guiadas por la intuición del tester.
• Pruebas Automatizadas: Ejecución de casos de prueba utilizando herramientas automatizadas.
• Pruebas Manuales: Ejecución de casos de prueba por un tester humano.

Objetivos de los Diferentes Tipos de Pruebas:

• Evaluar: Completitud, corrección, pertinencia funcional, viabilidad, eficiencia, desempeño, seguridad, compatibilidad y usabilidad.
• Verificar: Si la estructura del sistema es correcta y completa.
• Evaluar los efectos de los cambios: Confirmar correcciones y buscar cambios no deseados.

El testeo manual es una actividad crucial en el desarrollo de software, especialmente cuando se trata de garantizar la accesibilidad de un producto digital. El tester manual desempeña un papel fundamental en la identificación y reporte de errores, así como en la verificación de que el producto cumple con los requisitos funcionales y no funcionales establecidos. La documentación, las métricas y la adaptabilidad son habilidades esenciales para un tester exitoso. Además, el conocimiento de los diferentes tipos de pruebas y sus objetivos permite realizar una evaluación exhaustiva de calidad.

¿Alguna vez te has detenido un momento, en una acción cotidiana en el mundo web, a pensar si todos lo hacen cómo tú? O sencillamente ¿Crees que porque lo percibes y operas cotidianamente con normalidad, todo el mundo es capaz de hacer una sencilla acción?

Te propongo algo muy sencillo, “ponerse en el lugar de otra persona” y gestionar la autorización de las cookies de una página web.

Metodología

Supongamos que somos un usuario con una discapacidad temporal, permanente o situacional. No podemos usar el mouse del ordenador y tenemos visión baja, vamos a buscar casa en una plataforma inmobiliaria con un dispositivo de escritorio y tendremos que valernos únicamente del teclado.

Entraremos en tres plataformas, las cuales llamaremos como: “Opción A”, “Opción B” y “Opción C” y ver cómo navegar la ventana de cookies con el teclado.

Entramos en cada site y se presenta una ventana modal con la configuración de cookies que debemos aceptar para seguir navegando en cada una de ellas.

Primer vistazo al entrar en las páginas: Páginas de inicio oscurecida con un velo creado por CSS, llevando el foco o mi atención al modal de configuración de cookies para realizar alguna acción y permitir navegar por la página. Hasta aquí vamos bien.

Todo elemento debe ser navegable por teclado

Las personas con discapacidad visual, algunas con discapacidad motriz y muchas otras no utilizan el mouse/ratón, utilizan teclados o tecnologías asistivas que las emulan. Si la página es navegable y operable por teclado tenemos garantizada parte de la accesibilidad. Para navegar con teclado las teclas más usadas:

· Flecha abajo y arriba para avanzar de arriba abajo por los textos
· Tab para avanzar entre elementos interactivos
· Shift tab para retroceder entre elementos interactivos
· Enter o barra espaciadora para accionar los formularios, desplegables y controles en general

También tengamos en cuenta:

· La secuencia de navegación debe ser la misma que la visual
· El foco debe ser visible, nuestros elementos o componentes interactivos al ser enfocados toman protagonismo.
· No debe haber trampas para el foco
· No olvidemos tener contraste suficiente

Continuemos…

Iniciamos la navegación por teclado, usando principalmente las teclas TAB y BARRA ESPACIADORA… nos encontraremos con lo siguiente:

Opción A / Discovery:

Al hacer TAB no cambia nada en la interfaz, repito la acción y sigue sin ocurrir nada. “Ops! no sé dónde estoy, tampoco sé si estaré marcando algo”, ya que no se aprecia ningún estado de FOCO en links o botones. Si continúas clickando TAB vemos que la página en cuestión se mueve, pero sigue oscurecida y sin permitir que podamos usar el servicio que ofrece la plataforma, ni aceptar o rechazar las cookies.

• Dato: cuando haces TAB en una página web puedes observar en la barra de estado del navegador algo similar a cuando usas el ratón y pasas por un enlace: te muestra un destino.

En resumen:

• El estado de foco no es visible en enlaces o botones.
• La página oscurecida se mueve al navegar con TAB, cuando solo deberíamos interactuar con el modal.
• No es fácil aceptar, rechazar o configurar las cookies.

Opción B / Discovery:

Iniciamos como en el caso anterior y al hacer TAB observaremos el FOCO en un enlace, un recuadro azul, que indica donde estamos y podríamos accionar este enlace con la barra espaciadora o la tecla ENTER…

Debemos ir hasta “Aceptar y cerrar” con TAB y con la barra espaciadora aceptar las cookies… pero ¡sorpresa! al llegar al botón azul el FOCO se quiebra o no funciona ya que el tono del borde del FOCUS es similar al fondo del botón, y tienen una pobre relación de contraste entre ellos. También hay que considerar que el color de fondo del botón en FOCUS es el mismo en su estado normal y esto hace que pase desapercibido cuando tienes alguna deficiencia visual.

Si continuamos haciendo TAB podemos comprobar que hasta no realizar una acción en este modal no podemos ir a la navegación de la página (no salir del modal), y esto está bien, porque es necesaria una acción por parte del usuario, la navegación fantasma (del caso anterior) no ocurre en esta página, pero seguimos sin poder aceptar las cookies 😞.

En resumen:

• El borde del foco y el color de fondo de los botones tienen bajo contraste.
• El color de fondo del botón en foco es el mismo al del estado normal.
• Es necesario realizar 143 TABs para llegar al botón de aceptación de cookies.

Opción C / Discovery:

Al hacer TAB no ocurre nada en el modal, pero si te fijas se puede percibir que el foco se mueve por la página oscurecida (donde no debería estar), impidiendo navegar por el modal, que tiene nuestra atención, y ejecutar alguna acción con claridad en el mismo, esto es un error o una mala práctica. Un total de 143 TABs hay que realizar para llegar al botón en el que se deben aceptar las cookies, o 141 TABs para cerrar el modal, pero lamentablemente los botones del modal no reciben foco y no sabemos si están marcados.

En resumen:

• El foco no se mueve claramente por el modal al presionar TAB cuando iniciamos la navegación.
• Es imposible navegar por el modal y realizar acciones.
• Se requieren 143 TABs para llegar al botón de aceptación de cookies.
• Los botones del modal no reciben foco.

Las Web Content Accessibility Guidelines (WCAG), también conocidas como Directrices de Accesibilidad para el Contenido Web, son un conjunto de pautas desarrolladas por el World Wide Web Consortium (W3C) con el objetivo de mejorar la accesibilidad de los sitios web y las aplicaciones para todas las personas, incluyendo aquellas con discapacidades.

En un principio quería destacar sobre el no cumplimiento de un criterio específico de la WCAG, pero al explorar los servicios te das cuenta que no se cumplen otros y ves como entre ellos se relacionan y te dan pistas de cómo mejorar.

Resultados:

En resumen te contaré que criterios de la WCAG no se han cumplido en los modales de estas tres plataformas seleccionadas:

1.3.1 Información y relaciones: El usuario se pierde, no sabe dónde está exactamente ni qué acción realizar. Falta una lógica para una buena navegación.

1.3.2 Secuencia significativa: Si debo aceptar las cookies desde un principio, ¿por qué no lo ponen fácil? La página oscurecida no debería navegarse hasta realizar una acción en el modal ¿Por qué tantos TAB para algo que debo resolver en principio? La navegación no es lógica ni intuitiva.

2.4.3 Orden del foco: Ya vimos como en la Opción C requerimos 143 TABs para llegar al botón y en la Opción B de pronto navegaba por la página sin una buena referencia ya que no se puede interactuar con el modal.

2.4.7 Foco visible: Hemos visto como no se cumplió correctamente en los 3 casos, no nos permitía tener una relación correcta con el servicio porque los focos de botón o enlace no están construidos para ser accesibles. No puedo operar correctamente por los componentes.

Hemos visto como en estos tres ejemplos analizados se presentan problemas de accesibilidad al momento de encontrarnos con la ventana de cookies, que un usuario sin discapacidad probablemente no percibiría y podría realizar acciones sin dificultad.

Recomendaciones

• Implementar las directrices WCAG 2.2 para garantizar la accesibilidad de los elementos web.
• Mejorar el contraste de colores y los estados de foco visibles.
• Asegurar un orden de navegación lógico y consistente.
• Probar los sitios web con usuarios con diferentes discapacidades.

¿Crees que se me escapa algún criterio a tener en cuenta? O ¿Quizás otro criterio en lugar de alguno de los mencionados? No hay trampa ;) hagamos visible a la accesibilidad digital y si se puede iniciar algún debate que nos ayude a crear mejores productos digitales, bienvenidos son… Esto va de nutrirse, iterar y mejorar. Recuerda que la accesibilidad digital es un derecho fundamental que debe garantizarse para todos los usuarios. Es necesario un compromiso por parte de desarrolladores, diseñadores y empresas para crear productos digitales accesibles e inclusivos.

#Accesibilidad #AuditandoCosasAlAzar #WCAG #BrechaDigital #Inclusión #CalidadDigital #UX #UI #TecnologiasAsistivas #Discapacidad #tab #focus #NavegacionPorTeclado

Process

UNDERSTAND

What is VYPER?

Vyper is a viral marketing tool that leverages gamification and incentive to acquire leads, engagement, and traffic. Easily create contests and giveaways. It can collect emails and you can also use this tool to build followers, get people to share posts and leave comments.

Value proposition

A suite of tools that helps business/website owners get more traffic and leads.
Empower users with autonomy to design and create their own contests and giveaways.

Who use VYPER?

E-commerce and content marketing specialists.

ANALYZE

IDEATE

Proposal

An overlay layer on any of the section pages of the web, showing the option to register or log in.

In the case of carrying out either of the two options, the intention is that the user be taken to a Welcome Page that presents information about the system and the next steps to be carried out to complete their profile, if required, and start using or try the product.

DESIGN — VALIDATE — ITERATE

Prototype created to validate the solution:

Thanks.

Figma Workshop: Construir un Design System

Para este proyecto me basé en la marca de ropa: UBICA / STREETWEAR. Trabajé desde Figma, donde creé una Biblioteca con Estilos, Componentes y Variants, documenté la Tipografía, Colores, Elevaciones, Breakpoints, Layouts, Grids y Espacios que permitan la construcción de un producto digital de forma ordenada y óptima.

Posteriormente publiqué el resultado de este repositorio en Zeroheight: https://zeroheight.com/149e724c2

Todo esto apoyándome en las herramientas que Figma aporta para realizar este tipo de tareas: Autolayout, Componentes Interactivos, Variants, Hand-Off y algunos plugins.

Brand logo

Colors

Typography, Elevations & Icons

Buttons

Layouts, Grids & Breakpoints

Cards

Ubica Responsive & Variants test in Figma

Tokens

Repositorio

Puedes visitar el repositorio, en Zeroheight, haciendo click en:
Visitar Repositorio UBICA / Streetwear

Gracias.

CO2to: Configurador de compra responsable

Para los supermercados, que tienen que adaptarse a normativas medioambientales y a un consumidor muy consciente con el futuro del planeta, nuestra propuesta es un indicador de la huella de CO2 que tiene cada producto. Esto ofrece a los supermercados posicionarse como una empresa comprometida con el cuidado del medioambiente.

Las compras online en supermercados han tenido un elevado crecimiento en los últimos tiempos.

Entre compañeros hablábamos de las experiencias positivas y negativas de estas compras: “no hay el que me gusta”, “Ese no lo conozco”, “A saber como me llegan los plátanos”, “Para mi solo no vale la pena”, “A saber a qué hora me la traen”.

Pero ¿qué pasa en nuestras casas cuando llega la compra deseada? ¿Nos aturde el exceso de embalaje? ¿Reciclamos o no? ¿Es más o menos ecológico? y en las familias y hogares donde se hacen buenas compras online a supermercado ¿Cómo viven estas experiencias?

Y por otro lado, ¿Están los supermercados comprometidos a no crear exceso de desperdicios? ¿Algún plan para contaminar menos? ¿Concienciar sobre el buen uso y reciclaje de cartones, plásticos? ¿Planes de re-utilización?

Validación del problema

Problemática encontrada

“Al hacer la compra online y recibir o recoger productos, me encuentro con exceso de embalaje”.

Entrevistas + Insights

Realizamos entrevistas a usuarios frecuentes que realizan este tipo de compras y a la Responsable de Calidad de una cadena de supermercados asturiana (Alimerka). Además investigamos en internet sobre qué procesos y acciones se están aplicando en la actualidad.

Detectamos los siguientes insights:
· Alimerka está en fase de mejorar sus protocolos de entrega a algo más sostenible
· Los Supermercados tienen políticas y protocolos para preparar los envíos, distribuirlos y entregarlos con garantía.
· Los usuarios le dan poca importancia al gasto ecológico en el embalaje.

Users

Creados los user personas nos centramos en dos tipos de usuarios que son los siguientes:

Nuestra propuesta

Tras la investigación realizada con los usuarios y los supermercados de venta online nos dimos cuenta de que la gente no cree que el exceso de embaleje sea un gran problema (nuestra primera asunción), sino en que desconocen el grado de contaminación que tienen sus decisiones de compra.

Por lo tanto, teniendo en cuenta las nuevas normativas a las que el comercio online se tiene que ir a adaptando y, sobre todo, la creciente conciencia de los compradores por el cuidado del medio ambiente decidimos lanzarnos a desarrollar una funcionalidad que se pueda insertar en supermercados (y posteriormene en otro tipo de comercios online) para informar de la cantidad de CO2 que tiene cada producto y cada tipo de envío.

Un supermercado online que se muestra más transparente con el consumidor, informándole del grado de huella de carbono que tienen los productos que venden y permitiendo al comprador ser libre de ser “más o menos contaminante”.

Hacer al consumidor consciente y participe en el cuidado del medioambiente según sus elecciones de compra.

CO2to

Configurador de compra responsable

Para los supermercados, que tienen que adaptarse a normativas medioambientales y a un consumidor muy consciente con el futuro del planeta, nuestra propuesta es un indicador de la huella de CO2 que tiene cada producto. Esto ofrece a los supermercados posicionarse como una empresa comprometida con el cuidado del medioambiente.

Transparencia de cara al consumidor:

Más información sobre los productos al mostrarle los indicadores de huella de carbono.

Empoderar al consumidor:

Al ser él quien elige la huella de carbono que quiere ir dejando en el planeta según los productos que compra.

Conscientes con el medioambiente:

Adelantarnos a las normativas de cara a SALVAR EL PLANETA Y LA VIDA.

Funcionalidades

Compatibilidad

Software compatible con los distintos lenguajes en los que puedan estar los sistemas de los supermercados (Webs, CRMs, ERPs…)

Personalizable

Configurar en función del tipo de cliente que eres (más o menos responsable con el medioambiente) y que se puede cruzar con el precio.

Libertad

Poder elegir el tipo de envío: packaging, urgencia en el envío.

Usabilidad

Geolocalizador para calcular la huella CO2 del envío.

Prototipo

El prototipo se basó en validar la funcionalidad en un proceso de compra dentro de un supermercado online, que en este caso podía ser cualquier tienda. Para el posterior testeo, indicábamos una ruta a seguir a nuestro usuario.

La funcionalidad se integrará a la interfaz del comercio online, se podrá visualizar la información siempre que se desee. Al deslizar o presionar, en la app del comercio, se visualizará la sábana inferior donde se podrá interactuar con nuestra funcionalidad.

Pantallas de Bienvenida y explicación

Proceso de visualización y decisión por parte del usuario, al comparar opciones menos contaminantes dentro del mismo comercio online.

Proceso de compra y elección de tipo de envío

User Testing

Comprobar si para el usuario es útil la funcionalidad de poder seleccionar sus productos en función del CO2 que produce desde la producción hasta que llega al supermercado y posteriormente su envío.

Tipo de test: Usabilidad cuantitativo, en remoto
Usuarios: 5
Recorridos: 3
Herramientas: Maze y Zoom.

Objetivo principal: vamos a dar al usuario un escenario y una serie de tareas para conducirle por todas las funciones de la aplicación y comprobar si les resulta útil la información que proporciona. Se pretende comprobar la viabilidad de la funcionalidad.

Objetivos secundarios: comprobar si al usuario le resulta fácil encontrar los pasos a seguir para completar las tareas propuestas. Se pretende comprobar la usabilidad de la aplicación.

Descripción del escenario

Has estado haciendo la compra en tu supermercado online y tienes tres productos dentro de tu carro, pero te ha llamado un amigo por teléfono y has dejado la compra a medias. Cuando terminas la llamada, vuelves a la aplicación a terminar la compra. Se te han antojado unas manzanas. Las Golden francesas que compraste la última vez estaban muy buenas. ¡Qué ganas de comerlas otra vez!

Tareas

1. Dentro de la categoría “Frutas” ordena los productos por su CO2.
2. Añade a tu carrito la Golden (Francia).
3. Consulta el CO2 acumulado que llevas en la compra de hoy.
4. Eres libre de aceptar las recomendaciones que te hacen.
5. Procede a finalizar tu compra y completa el proceso.

Conclusiones User Testing

Elección de producto

El 88,8% compraría un producto diferente al que suele comprar si supiera que produce menos CO2.

Visualización de C02

Al 100% le gustaría ver información sobre la cantidad de CO2 que tienen los productos mientras realizan sus compras.

Gasto personal de C02

Al 100% le gustaría conocer el CO2 que lleva acumulado mensualmente con sus compras.

Elección de supermercado

El 100% valoraría cambiar de supermercado al que le ofreciesen el visualizador de CO2.

Si quieres ver cómo quedó nuestro prototipo, te invito a clickar el siguiente enlace: CO2to

Gracias

Brief

Maruma Maestra de movimiento

Desde hace años, Maruma se dedica al estudio del cuerpo vivo, sus capacidades de expresión, regeneración y autorregulación. Es profesional certificada de Educación Somática, Bailarina y Licenciada en Artes.
Maruma ha impartido, de un tiempo atrás hasta hace poco, clases en gimnasios y estudios, diversos talleres, cursos, asistencias terapéuticas y emprendido proyectos, que de alguna manera le ayudaban a vivir el día a día. Diversas causas no permitían que Maruma centrase sus inquietudes y necesidades a llevar a cabo la construcción de su “servicio”.
Con el paso del tiempo, las experiencias vividas y varias inseguridades, la dirección de Maruma empezó a centrarse en su proyecto de vida y focalizar su necesidad de transmitir lo aprendido, a través del cuerpo y el alma. Muchas dudas se iban aclarando, hoy en día ella está más preparada.
En el 2020 con la llegada del COVID-19, Maruma logró reinventarse a través de clases y terapias online, un medio que veía alejado por la falta de una presencia física. Logró realizar diversas clases, formaciones, asistencias personales, encontró alumnos fijos que asistían a sus clases disciplinariamente y se disponían a trabajar el cuerpo a través de la pantalla.
Maruma está creciendo y todas estas circunstancias la están llevando a centrarse y a emprender profesionalmente la enseñanza y guía de sus aprendizajes y descubrimientos.

Contexto

La necesidad de concretar sus proyectos e investigaciones, promover sus clases y talleres, están encontrando un eje y camino para continuar. Se ha visto la necesidad de tener una mejor presencia online y crear su página web para informar, promover y exponer su Trabajo.
Ante este nuevo reto, Maruma quiere crear y fortalecer su identidad como educadora e investigadora somática, encontrar su “tono y voz”, ofrecer funcionalidades y opciones a través de internet y una página web donde ofrecer y exponer su trabajo.

Primeros pasos

En un primer encuentro, partimos de la necesidad de encontrar el tono y la manera de cómo Maruma debe comunicarse y divulgar su trabajo en Educación Somática.
Dispusimos de unas horas para empezar a indagar entre nosotros y ponernos en acción: 5W & 1H de Kaizen.
Al terminar, el canvas mostraba otras necesidades no planteadas en nuestra conversación. Nos indicaba llegar a más áreas, además del tono y voz. Pedía tener una claridad sobre la Identidad de Maruma, cómo comunicar, cómo acercarse y brindar diversas opciones de información y propuestas a sus alumnos, clientes y pacientes.

5W&1H de Kaizen

Fue interesante el planteamiento porque puso en “Modo Atención” a mi clienta, quien no tenía una visión tan tangible de su producto y seguidores. Se reformuló hasta su posición en el mundo, por decirlo de alguna manera.
Cuestiones necesarias a resolver: visualizar su alcance, tener bases sólidas y concretas para una propuesta de prácticas y trabajos corporales. Un escaparate conceptual, orgánico y cercano que debía dar luz y mostrar un trabajo corporal que lleva a su practicante a un estado de bienestar y evolución.
Hay mucho que definir y concretar. Se asomaron ideas y dudas a resolver. Se exige a Maruma crear su identidad, su marca. Conocer su negocio. Claridad en los servicios a ofrecer y funcionalidades que permitan cercanía e independencia a sus participantes.
Clasificamos, reordenamos y filtramos… Planteamos un resumen de preguntas que luego fuimos respondiendo. Algunas preguntas y respuestas nos daban pistas a una exigencia a formular y definir nuevos aspectos no contemplados, como la creación de planes y programas, concretar funcionalidades próximas y unas para realizar en una segunda vuelta para ofrecer nuevos servicios.
Clasificamos en 3 grupos:
· Las principales: trabajaremos en una primera fase
· La secundarias, para ser tratadas en una segunda fase
· Y las que tendrá que trabajar Maruma de forma personal para orientar su camino y dar forma a su actual meta en la vida.

Primeros puntos clave

Identificamos los primeros puntos clave y de valor para impulsar el concepto de nuestro negocio:

Planes-Programas

Como el momento y el proceso lo amerita, se pidió a Maruma que sintetizara y establezca los Planes-Programas que pasarían a formar parte de los servicios a ofrecer. Debíamos empezar a intentar a formalizar los servicios, aunque luego cambien durante el proceso, pero son necesarios para ir fijando metas y pruebas a validar.
Estos programas podrán impartirse en formato online o presencial y los hemos establecido partiendo de las investigaciones que ha realizado Maruma en el último año, el target de sus clientes y las formaciones que quiere ofrecer.
Una primera clasificación de la siguiente forma:
Programas para grupos.
Programas individuales.
Programas de formación para profesionales de lo corporal.
Programas de actualización, para antiguos alumnos y clientes.

En esta fase de la investigación decidí realizar un cuestionario. Posteriormente, elegiremos a 2 de ellos para hacerles una entrevista a cada uno.
A través del cuestionario, pudimos encontrar insights y pain points de los usuarios. Por mi parte, quería empatizar y encontrar respuestas, conocer las sensaciones y de cómo ven el trabajo de Maruma.
Se lo enviamos a 22 clientes, de los cuales nos respondieron 17 de ellos… Respuestas bárbaras, muy implicados, dando detalles y entre esas respuestas se disfrutaba del bienestar, buen feeling y cariño que tienen estas personas con el trabajo de Maruma

Respuestas

Entre todas las respuestas recibidas, logramos identificar sensaciones, valores, descubrimientos, sentimientos, posturas sobre este trabajo, y de cómo han aplicado lo aprendido en su día a día… Se ve claramente el cariño y el gusto que le tienen a este trabajo. Demostraron interés en responder, los clientes quieren más, necesitan continuidad, saber más, explorar…

Se seleccionaron pain points y puntos importantes, entre todas las respuestas… Hilamos estas respuestas, con los puntos claves obtenidos en la primera parte de investigación. Descubrimos necesidades a cubrir, propuestas que plantear, vimos que es necesario un Seguimiento y brindar fuentes de información sobre las investigaciones y propuestas de Maruma.

Los primeros puntos clave llevaban concordancia ante las respuestas. Esto nos abrió la mente a ir visualizando algunos apartados que deberíamos trabajar para el website.

El foco del trabajo de Maruma.
Se diferencia de los demás

Bienestar.
Por lo que provoca en el momento de práctica con ella. Por el desafío o necesidad de un autoconocimiento continuo por parte del cliente, ya sea un trabajo de investigación, artístico o paciente con dolencia. Una buena señal, el AUTOSEGUIMIENTO que aplican sus clientes.

Independencia.
La propuesta del trabajo de Maruma permite al cliente, de forma autónoma, a seguir experimentando por su cuenta. Deja sembrada una semilla gracias al bienestar vivido, que de alguna forma nos transmite conciencia corporal, reconocer momentos para conectar con uno mismo, posturas, la manera de caminar, respirar, el equilibrio…

La unión con el arte.
Para una conciencia creativa y corporal. Investigación corporal para bailarines, actores, educadores somáticos, expresión corporal.

La unión con el aprendizaje y desarrollo.
Desarrollo evolutivo y personal acorde a las propias posibilidades: en la vida de padres y bebés, pacientes con dolencias, fisioterapeutas y educadores físicos.

Complemento de otras áreas.
Danza, terapeutas, educadores, naturaleza, Psicoterapia.

Users

Después de ver y revisar repetidas veces las respuestas de los cuestionarios, seleccioné a 2 clientes de Maruma y a un tercero, que ha tenido una visión y experiencia más terapéutica: Paco.
Maruma se mudó literalmente a casa de Paco para asistir y llevar a cabo un trabajo 24/7 durante casi 2 meses.
Entrevisté a:
Janzet: Médico, bailarina y actriz, de 48 años
Nury: Terapeuta natural y botánica, de 46 años
Paco: Jubilado, de 69 años

Tres conversaciones amenas y enriquecedoras para el proyecto

Ideas

Imposible no detenerse a generar ideas, después de indagar con Maruma en los órganos de su trabajo, recibir un buen número de respuestas en el cuestionario y de las 3 entrevistas.
La página web debe llevar contenido esencial y de apoyo para quien la visite y para sus clientes. Demostraron mucho cariño e interés por estas prácticas. Se sienten motivados, les gusta, les interesa investigar y llevar estos aprendizajes a la práctica diaria. Les gusta el BIENESTAR que les hace sentir… Y ¿por qué no el bienestar como desafío? Un espacio que nos rete a algo que nos gusta, sentirnos bien.
Maruma debe exponer con claridad su propuesta, los resultados obtenidos y brindar apoyo gráfico. A ser posible material en video, para mostrarse y mostrar este trabajo. VIDEOS QUE HACEN BIEN, así veremos como se hace y es una forma de siempre contar con Maruma… quien a su vez, y motivada por los resultados de este research, tiene muchas ganas de ir contactando con sus clientes y ofrecerles SEGUIMIENTO… Siente que se ha creado un fuerte nexo y debe cuidarlo.

Se reafirma la personalización: un gancho de la propuesta de Maruma es que se trabaja acorde a las posibilidades de tu cuerpo que irá evolucionando en su progreso constante a través del movimiento… te quedas enbobado cuando te cuenta sus experiencias con adultos y bebés. En definitiva, tiene TOQUE PERSONAL.
Ese toque personal, estará presente en todos sus PROGRAMAS DE 21 DÍAS y TRATAMIENTOS… y, ante el alcance que ha obtenido gracias a sus movimientos varios por el mundo e internet, será necesario tener un sistema de RESERVA online y la posibilidad de que el usuario pueda comprar CLASES/PROPUESTAS para practicar por su cuenta.
Los CASOS DE ESTUDIO y los TESTIMONIOS de sus clientes son algo necesario, ellos mismos son conclusiones de los distintos procesos.
Algo más que late, y porque apareció en el research y en las entrevistas, es la posibilidad de COLABORACIONES y hasta TRUEQUES.
Nos gustaría poder llegar más allá, que el granito de arena de Maruma te llegue sin complicaciones y sin tener que abrir un Instagram. La posibilidad de SUSCRIBIRSE AL CALENDARIO DE MARUMA, de esa manera pueden llegar imágenes, propuestas y/o mensajes de Maruma como notificaciones en el calendario de desktop o móvil… o incluso avisar de algo importante. Quizás podamos valernos, también, de Alexa, Siri y Ok Google y lanzar estas alertas.

Trabaje con los 3 perfiles entrevistados y ajusté los beneficios que queremos ofrecer a las necesidades de los clientes. Posteriormente, con los datos obtenidos, cree el canvas de Propuesta de Valor.

Insights

Ideas seleccionadas

¿Qué va a sentir después de usar nuestro producto?

¿Cómo aporta ese valor funcional?

¿Qué podrá hacer el usuario que antes no podía?

¿Cómo aporta ese valor emocional o social?

Propuesta de valor

Hemos recopilado mucha información, se han generado ideas, dado con insights interesantes y tenemos muchas ganas de trabajar porque lo conseguido ha sido realmente interesante y emocionante. Tenemos un proyecto ambicioso entre manos ¿Qué necesitamos hacer para llevarlo a cabo? Debemos resumir e ir poniendo pies en la tierra para conocer bien el terreno y abonarlo de buena manera.

Creamos el Business Model Canvas para que nos ayude en esta labor.

Vimos con más claridad lo que hemos conseguido y ponemos sobre la mesa los que se necesita para llevarlo a cabo. No será un proyecto que llevemos a cabo totalmente a corto plazo. Tendremos que ir desgranando y priorizando con los recursos disponibles para ir creando la fuente y el corazón de este sistema online y participativo de Maruma.

Gracias a este research Maruma logra descubrir la dirección en la que encausar su proyecto, teniendo en cuenta las necesidades propias y las de sus clientes para llevarlo a cabo.

Tocará una etapa de priorización de objetivos a realizar en el tiempo, conseguir recursos e ir promoviendo los primeros pasos para poder ir avanzando.

El objetivo que queremos encontrar a largo plazo y al que se quiere llegar es el siguiente:

Para alumnos, pacientes y futuros clientes de Maruma, quienes tienen la necesidad de encontrar Bienestar en su Desarrollo físico y personal a través del Movimiento y el Arte, nuestra propuesta, es brindar a través de una página web, blog y redes sociales, la oportunidad de conocer y evolucionar con la Propuesta de Maruma, poder reservar y adquirir programas, clases o talleres, tanto presenciales como en formato online, obtener seguimientos e involucrarse en un estilo de vida que conlleva al bienestar físico-corporal y mental con uno mismo.

A diferencia de otros educadores somáticos, nuestro producto brindará la posibilidad al cliente de poder realizar sus propias prácticas, investigar y encontrar respuestas de forma independiente, siempre con la guía de Maruma. También poder indagar más y conocer de cerca las particulares investigaciones sobre el Movimiento por parte de Maruma y otros profesionales. Compartir sus experiencias y crear un sentido de pertenencia con el propio Bien-Estar.

Si quieres ver más en detalle la presentación de este research, haz click aquí

Continuará…

Contexto: El reto

Puntos clave de CoMAD

Es un proyecto de convivencia colaborativa de autogestión participativa y cooperativa de espacios y servicios comunes.

Se fomenta la interacción social, el diseño sostenible y los recursos compartidos.

35 hogares rodeados de espacios compartidos donde las personas pueden reunirse y compartir recursos.

Hay que diseñar una aplicación que favorezcan la vida comunitaria, acerque a los vecinos a diferentes actividades y fomente la cooperación.

Esta aplicación tendrá, entre otras, las siguientes funcionalidades:

• Registro de usuarios.
• Planificación de todas las actividades, talleres, tareas y servicios del espacio.
• Información general (descripción de las zonas, normas, comunidad de habitantes, etc).
• Reserva de talleres, actividades.
• Espacio de debate comunitario.

Tiempo máximo disponible: 2 días

Framework

Tres fases típicas: Empatizar, Investigar e Idear

Planteamos tres fases iniciales para poder llegar a unos wireframes de la aplicación que nos permitieran esforzar las necesidades principales y la funcionalidades que dieran solución a esas necesidades.

Empatizar

Preguntas clave

Como técnica para ponernos en situación de cara a afrontar el proyectos optamos por las 5W&1H de Kaizen.

De estas preguntas elegimos las que creíamos nos darían las claves del funcionamiento de la comunidad y sus necesidades, además destacamos los objetivos clave de esta comunidad basándonos en el briefing para mantenerlos siempre en el foco.

Una vez hechas las preguntas, había que darles respuesta y estas respuestas nos dieron una visión de los puntos clave en la aplicación a diseñar.

Llegamos a la conclusión de que la toma de decisiones y la parte “económica” de la comunidad eran aspectos importantes del funcionamiento de la misma, ya que nos planteaban las preguntas que consideramos más necesarias.

La parte logística del funcionamiento de las actividades fue también un punto destacado, con lo que llegamos a la conclusión de que estos aspectos deberían ser principales en la aplicación para solucionar los aspectos principales de la colaboración vecinal.

Pasamos a intentar responder esas preguntas para esbozar las necesidades reales que teníamos que intentar cubrir.

Momento pasional, Post-its, resumiendo… ideas fluyendo

Después de estudiar qué aspectos eran importantes en la comunidad que se nos describía en el briefing llegamos a las siguientes conclusiones:

No se podía perder de vista los valores de colaboración, sostenibilidad (económica y social) y la autogestión. Ya que eran partes esenciales de la personalidad del proyecto y de sus usuarios

Hacía falta tener unas reglas y formas de uso de los espacios comunes claras, pero estas debían de estar abiertas al cambio y ese cambio debía de ser democrático y relativamente sencillo.

La información es vital y una de las funciones principales de la aplicación.

Investigación (Research)

Debido al tiempo con el que contábamos, planteamos la fase de investigación de una manera simple, con dos métodos principales:

User persona (short-version) a una persona que vive en comunidad con zonas comunes en las que se realizan actividades. Podemos obtener información breve y real sobre una comunidad que presta servicios a sus covecinos.

Benchmarking, centrados en otras aplicaciones de comunidades de vecinos, pero también en aplicaciones de intercambio de servicios y productos, de cara a solucionar la parte de colaboración y servicios.

User persona (short-version)

Tuvimos la oportunidad de conversar con Natalia en Madrid, cuya comunidad se promueve la participación vecinal con algunas actividades y cuentan con salas para realizar eventos comunes o privados del mismo vecino. En contexto nos dio los siguientes detalles:

• Disponen de sala de gym donde pueden usar 2 cintas de correr y 2 bicicletas estáticas, con previa reserva en portería.
• Otra sala donde ofrecen clases de yoga, pilates o TRX eventualmente. Lunes y miércoles los hombres, martes y jueves las mujeres. Por un aforo mínimo contratan un profesional para dirigir estas clases.
• 3ª sala para eventos de los mismos vecinos, como una fiesta de cumpleaños. El vecino se encarga de reservar, coordinar y al finalizar, el evento, encargarse de la limpieza de la sala.
• Otra comunidad vecina alquila por horas la cancha de tenis para vecinos externos.

Benchmarking

Centrados en otras aplicaciones de comunidades de vecinos, pero también en aplicaciones de intercambio de servicios y productos, de cara a solucionar la parte de colaboración y servicios.

Conclusiones del research

Nos ponemos manos a la obra con la ideación teniendo los siguientes puntos en cuenta:

Debemos fomentar la interacción de los vecinos pero con flexibilidad, facilitando un foro para la información y la toma de decisiones.

La aplicación debe servir para la gestión de las reservas de las actividades y de los espacios comunes.

Debemos encontrar un sistema para que la economía circular y la autogestión resulten estables y justas.

Las categorías obtenidas en cuenta en la tabla de resumen del benchmarking serán nuestras funcionalidades principales:

Interacción vecinal, sistema de reservas, sistemas de puntos para el trueque y siempre, y sobre todo, fomentar la participación, la colaboración y la economía circular.

Arquitectura de la información

A la hora de crear la arquitectura de la información tuvimos de referencia los flujos que se nos pedían en el briefing y las ideas que surgieron en el research.

Hemos planteado el servicio de nuestra app como una herramienta de soporte que ayude a informar y gestionar las actividades, favorezca la relación y colaboración entre vecinos y fomente una economía interna a través de puntos o coins.

Idear

Aparte de los flujos de la aplicación en si, durante el proceso de ideación salieron dos ideas importantes de cara a la forma de funcionar la comunidad:

Los COCOCOINS, unos puntos que se recibirán al entrar en la comunidad y por los servicios colaborativos prestados, serán la moneda para pagar otros servicios que se reciban por parte de los vecinos. De esta manera el trueque no tiene que ser inmediato y conseguimos una economía interna más flexible. Se puede plantear vender por dinero real estos puntos, de manera que se puedan hacer frente así a los gastos del mantenimiento y gestión.

La opción de pedir un cambio en las normas de funcionamiento, mediantes un botón activado o desactivado en la aplicación. Si ese botón llega a estar activado en un tanto por ciento de usuarios de la comunidad, se planteará una reunión de cambio amplio de la regulación interna.

El resto de funcionalidades de la aplicación las explicaremos mediante los wireframes en 3 casos de uso.

Ver la planificación semanal de actividades y talleres comunitarios

Acceder a mi aplicación y ver una descripción de cohousing CoMAD (zonas comunes, normas, habitantes…)

Plantear el trueque/cambio de una tarea a un compañero.

Otras pantallas de la aplicación

Gracias por llegar hasta aquí…

Este rápido challenge ha sido muy muy satisfactorio, nos ha emocionado llevar a la práctica algunos conocimientos adquiridos de una forma independiente sin guía y superando el trabajo presencial, otro punto a favor para las nuevas tecnologías. Hemos visto cómo las ideas y respuestas del research cogían forma hacia lo que puede ser una buena experiencia usuario en una comunidad vecinal.

Desafío | Briefing

¿Cómo podríamos ayudar a padres, educadores y estudiantes a adaptarse a la educación en línea, mientras aprovechamos este momento para reimaginar radicalmente cómo debería de ser el sistema educativo?

Y un día se presentó una pandemia en nuestra rutina diaria, obligándonos a cambiar nuestra “normalidad”. El orden de nuestras vidas se subió al tren de los cambios… Giros con vértigo ocurrían en cada instante, el mundo ha tenido que unirse para enfrentar esta “nueva normalidad”.

Y acercando el ojo a uno de esos tantos giros, se pudo comprobar que para el 91% de los estudiantes, padres y educadores de todo el mundo, un desafío fundamental ha sido como adaptarse al aprendizaje desde casa. En algunos casos, las habitaciones de casa se convirtieron en “aulas de clase”, los padres han asumido una nueva responsabilidad de supervisar a sus hijos, a la par de mantener sus actuales trabajos o incluso iniciar una búsqueda urgente, en caso de estar desempleados.

Hubo una clara necesidad de cambio urgente: los modelos educacionales y los fundamentos de aprender y enseñar deben cambiar, adaptarse y evolucionar.

Algo así, debió pasar por la cabeza de Andrea Sagone, al plantearnos este desafío con un Design Sprint.

Llegado el momento, formamos un equipo de 6 personas, creamos los roles pertinentes y nos fue presentado el desafío:

En este mundo post-pandemia, ¿Cómo podríamos ayudar a padres, educadores y estudiantes a adaptarse a la educación en línea, mientras aprovechamos este momento para reimaginar radicalmente cómo debería de ser nuestro sistema educativo?

Contexto

Ya preparados para entrar en el Design Sprint, la facilitadora nos acompañaba y medía los tiempos. Estableció reglas finalizando con la frase “Confíar en el proceso” … eso es lo que hicimos, confiar y llevarlo a cabo.

Los participantes del sprint estábamos en diferentes localizaciones y por algunas razones de tiempo, los pasos de esta metodología fueron modificados y nos valimos de herramientas como Zoom, Miro y Google Drive.

Empezamos con la entrevista a la experta, en este caso una de las integrantes, ya que es madre y ha vivido esta experiencia en primera persona. Mientras narraba y preguntábamos, realizamos diferentes HMQ questions: “¿Cómo podríamos hacer…?” Las ordenamos y agrupamos en un board de MIRO.

Posteriormente, las leímos todas y las agrupamos en las siguientes categorías:
· Medios/Recursos
· Metodologías
· Padres
· Interacción social

Realizamos un Dot Voting y las agrupamos en otro board…

Por nuestras cabezas querían pasar ideas ya resolutivas, pero no era la idea… Confía en el proceso, era la pauta y de alguna manera “nuestros deseos no podían ser deseos”… Deja que el Sprint te lleve de la mano.

Seguido a esto, nos fue planteado escribir individualmente, durante 5 minutos, cuál sería el resultado óptimo en dos años, dejando fuera de este momento las emociones o sentimientos de los usuarios. El momento de ser optimistas ;)

Procedimos a leer todas las ideas de los integrantes… nos sorprendió que todas se acercaban, iban señalando un camino en común. El optimismo nos desvelaba y daba guiños de visión para descubrir el objetivo o meta de nuestro Sprint. La inspiración para nuestro proyecto iba creciendo. Votamos entre todas las ideas y surgió el objetivo inspirador para resolver nuestro caso.

El propósito del Design Sprint es conseguir respuestas. Las Sprint Questions nos proporcionan el focus del Sprint.
“Si construimos esto, ¿funcionará?“
Pensemos en todas las cosas que pueden salir mal, ¡ser pesimistas!

Si te pones a pensar, viendo los obstáculos podemos preguntarnos cómo solventarlos.

Y nos preguntamos … ¿Podríamos…?

Partiendo en esta nueva ruta, encontraremos las Sprint Questions. Cada uno elaboró las suyas y de nuevo a votar… Las obtuvimos:

Turno para el Mapa

Nuevas indicaciones:

Pasar el Post-it del objetivo a largo plazo/meta

Poner todos los actores que consideren que interactúan en esta problemática.

Rellenar cada uno de los pasos de Descubrir, Aprender, Usar (puede tener más de un paso cada una de las fases).

Recuperar las HMW Questions y ubicarlas debajo de la sección/paso que creemos que corresponde.

Identificar cual será nuestro foco viendo dónde tenemos más de las HMW.

y adelante

Y así es como nació nuestro proyecto en el primer día… Prototipar una app educativa, reglada y accesible para TODOS.

Empezamos una labor de investigación, antes de embarcarnos en el proyecto, encontrar inspiración y recursos que sean de ayuda para nuestra plataforma educativa. Recapitulamos qué es lo que queremos resolver y los problemas con los que nos encontraremos.

¿En qué punto estamos?

Lápices, rotuladores, bolígrafos y hojas en blanco, para dibujar, bocetar, crear storyboard… dando vida y agilizando las ideas para nuestro proyecto. De nuevo votamos con mucha más libertad, llenábamos de puntos lo que más nos llamaba la atención y gustaba… diferentes ideas llevadas a trazos. Se vale repetir voto… Esto nos ayudará a visualizar un mapa de calor de lo que más nos atrae al equipo para incluir en nuestro proyecto. Surgieron distintas ideas, todas relacionadas a un nuevo estilo de educación y maneras de aprender desde el juego y completando desafíos, acompañados de un asistente virtual, con un añadido comunicacional entre Representantes-Alumno-Profesorado.

Ahora debíamos pensar en el flujo para acceder al uso de nuestro prototipo. Tenemos una idea ambiciosa, pero prototipar todo en pocos días no es posible. Mejor validar nuestra idea con un prototipo simple. Pensaremos en puntos claves, en pasos o acciones para ver cómo es descubierto el prototipo por un usuario real. De nuevo votamos por el flujo que mejor consideremos para nuestro prototipo y así poder responder las Sprint Questions. El decisor tiene dos votos, uno para el flujo y otro para algo que le interesaría traer de otro flujo.

Trasladaremos el anterior flow y los pasos necesarios para ir bocetar nuestro prototipo. Nuestra propuesta-solución es extensa, debemos sintetizar para poder prototipar y tener unos primeros resultados que nos den respuestas para validar la idea.

En esta parte, a los miembros del equipo teníamos la necesidad de ir dando un nombre y personalización a nuestra solución, coger forma. Decidimos realizar una rápida votación con dots para elegir el nombre, colores y la imagen del asistente.

En esta fase del proyecto tuvimos una decisión sobre la presentación del prototipo y la app: realizarla para dispositivos móviles, por el fácil acceso que tenemos la mayoría a su uso y disponibilidad.

Decidimos usar esta aplicación por la facilidad de poder compartir el proyecto y trabajar online entre todos y avanzar en esta fase. Fueron momentos muy dinámicos y estábamos sincronizados en las distintas acciones a realizar: Textos, creación de logotipo, selección de fuentes tipográficas, scripts de interacción, maquetación y diseño, creación de símbolos…

Llegó el momento y buscamos a 6 niños entre 7 y 12 años para probar nuestro prototipo. Tuvimos la complicación de que se presentó un puente vacacional, además de tiempos de COVID-19. Intentar quedar en persona o incluso por videollamada se complicaba, así que decidimos realizar la prueba en la plataforma MAZE. Nos permite probar el prototipo con usuarios reales y obtener resultados cuantificables. La reacción y aceptación por parte de los niños fue buena.

Entre los resultados a destacar, cabe añadir que la idea del asistente o guía para el estudiante resultó positiva, las lecciones a aprender como un desafío y al cumplirlo, poder personalizar el avatar del asistente les motivaba.

Gracias.

Mind-blowing Meal / Design thinking en la cocina 😜

Preparaba quinoa, al terminar quedó muy pastosa… La cocí con más cantidad de agua de la que debía y no pensaba comerla así.
De pronto pensé en prensarla en una bandeja de silicona con un poco de harina de avena y ver qué pasaba.
30 minutos después tenía una base para algo.

¡Me sirve para una pizza!

¿Qué tengo en la alacena y nevera?

Después de ver que tenía, opté por añadir lo siguiente:
Tomate triturado, cebolla, tiras de pavo, queso cheddar, salsa pesto y algunas nueces.

Target

Una amiga y yo

Presentación

La pizza sobre una tabla de madera, también cuadrada.
Vino blanco y una ensalada sencilla con rúcula, queso feta y cherrys.
Platos, cubiertos y servilletas… muy sencillo todo

Resultados y experiencia

No es la típica pizza, porque la textura de la masa no es igual, pero la mezcla de sabores si nos hacían saborearla como una pizza, en plan crujiente.
Fue divertido, estaba muy rica… una experiencia nueva