Un robot de compañía para personas mayores necesita ser aceptado por quien va a convivir con él. Esa es la cuestión central del proyecto que Pablo Mariñosa presenta en el capítulo 33 de Toque de Ingenio. Onorato AI adopta la forma de un loro y plantea combinar conversación, recordatorios y comunicación con familiares. La entrevista muestra un desarrollo en curso donde diseño emocional, interacción y tecnología debían integrarse todavía en el producto final.
Invitado: Pablo Mariñosa, presentado en el episodio como CEO de Onorato AI.
Conversación publicada: 13 de enero de 2025. Episodio: 33. Duración: 1 h 8 min.
En este capítulo:
- Cómo la experiencia de acompañar a un familiar orientó la forma y la intención del producto.
- Por qué un dispositivo técnicamente capaz puede ser rechazado por la persona que debe utilizarlo.
- Qué distingue validar la apariencia de completar la integración electrónica y funcional.
Pablo sitúa el origen del proyecto en el cuidado de su padre y en el vínculo que este establecía con un loro durante sus salidas. La grabación se refiere a diciembre de 2024 y se publicó en enero de 2025. Las funciones y vías de comercialización descritas son propuestas del proyecto en aquella etapa, no una verificación de prestaciones clínicas ni de disponibilidad actual.
El rechazo a la tecnología también es un requisito de diseño
Pablo cuenta que había probado distintos dispositivos para acompañar a su padre. Su intención era facilitar rutinas y conocer si necesitaba ayuda, pero el resultado no dependía únicamente de las funciones. La percepción del propio usuario podía impedir que la herramienta cumpliera su propósito.
Al recordar aquella experiencia, explica que su padre:
«todo lo consideraba una intrusión».
Pablo Mariñosa, 4:20.
Ese aprendizaje cambia la pregunta de desarrollo. El equipo no solo debe pensar qué puede detectar o comunicar el producto, sino cómo será interpretado por la persona. Un dispositivo que genera rechazo difícilmente puede integrarse de manera estable en su vida cotidiana.
El caso conecta con el diseño de producto centrado en el uso. Comprender rutinas, preferencias y preocupaciones permite definir una interacción que tenga sentido. La aceptación no es un detalle de acabado: puede determinar si el objeto llega a utilizarse.
Por qué el proyecto adopta la forma de un loro
La forma de Onorato procede de una experiencia concreta. Pablo relata que su padre esperaba escuchar a un loro en un establecimiento y que esa relación le producía alegría. La idea del producto intenta trasladar parte de esa familiaridad a un objeto que pudiera acompañarlo.
El diseño busca presentarse como una presencia simpática y cercana. En la entrevista, Pablo concede mucha importancia al aspecto, al tacto y a la reacción que provoca. La forma exterior debe comunicar una intención de compañía antes de explicar todas las capacidades técnicas previstas.
Ese punto de partida ayuda a entender el tiempo dedicado a explorar la carcasa. El promotor tenía una imagen mental muy específica y necesitaba trasladarla a diseñadores y prototipos. La conversación muestra la dificultad de convertir una sensación deseada en una propuesta física compartida.
Para otros equipos, la enseñanza está en describir qué respuesta se espera del usuario y cómo se observará. Una referencia emocional puede orientar el proyecto, pero necesita convertirse en decisiones y pruebas. La apariencia debe evaluarse con personas y en condiciones cercanas a las de uso.
La interacción propuesta incluye iniciativa y personalización
Pablo plantea que el producto pueda iniciar conversaciones y recordatorios, además de responder a peticiones. En su relato, esa iniciativa intenta resolver una limitación de herramientas que requieren que la persona recuerde dar una orden. La propuesta se vincula a rutinas y momentos cotidianos.
También describe personalización a partir de información facilitada por familiares. Nombres, aficiones y preferencias ayudarían a adaptar la conversación. El objetivo es que el producto tenga un contexto que permita relacionarse de forma más familiar con la persona.
La entrevista incluye ideas de comunicación con familiares y alertas apoyadas en sensores. Son funciones que el equipo quería integrar y que deben distinguirse de resultados demostrados. La conversación no aporta una validación independiente de detección de caídas, interpretación emocional o respuesta a emergencias.
Desde el diseño de experiencia de usuario, el reto es definir qué hace el sistema, qué puede esperar la persona y cuándo debe intervenir alguien. Cuanto más cercana sea la interacción, más importante resulta mantener una relación comprensible entre apariencia, respuesta y capacidad real.
Llegar a casa con una puesta en marcha comprensible
Pablo describe una experiencia de instalación que quería hacer sencilla. Su propia dificultad al preparar otros dispositivos para su padre influyó en ese requisito. El producto debía llegar con una configuración previa y con un recorrido de activación fácil de entender.
La propuesta incluía el loro principal y elementos para distintas estancias. Esa arquitectura distribuye funciones, pero también añade pasos de colocación y conexión. La experiencia completa necesita explicar qué va en cada lugar y cómo se sabe que el conjunto está listo.
En la entrevista aparecen dos perfiles con responsabilidades distintas: quien compra o prepara el producto y quien convive con él. El desarrollo debe atender a ambos. Un familiar puede completar una configuración inicial, mientras la persona usuaria necesita una interacción cotidiana adecuada a sus capacidades y preferencias.
Esa diferencia es habitual en productos de apoyo. La compra no describe por sí sola el uso. Observar la entrega, la instalación y el acompañamiento permite detectar necesidades que no aparecen al evaluar únicamente el dispositivo sobre una mesa.
La carcasa y la función requieren pruebas distintas
Pablo divide el desarrollo en varias fases. Primero, ordenar la idea en una propuesta; después, trabajar el aspecto físico; y, finalmente, integrar la tecnología necesaria. En el momento de la entrevista, identifica como trabajo pendiente:
«la implementación de la electrónica».
Pablo Mariñosa, 34:08.
También cuenta que ya realizaban experimentos con un ordenador conectado y con capacidades de conversación. Esa actividad permite explorar partes del comportamiento, pero no equivale a tener todo el sistema integrado en su formato final. Cada prueba aporta una evidencia diferente.
La aceptación de la forma y el funcionamiento técnico deben encontrarse después. Un objeto que gusta necesita alojar componentes y mantener una interacción coherente. Un sistema que responde en una prueba informática tiene que funcionar también dentro del producto y de su entorno de uso.
Un programa de prototipado ayuda a ordenar esas preguntas. Puede validar primero apariencia y manipulación, después una función concreta y más adelante el recorrido completo. Es importante conservar qué demuestra cada versión para no confundir una reacción positiva con una validación de todas las prestaciones.
Comercialización y feedback para continuar el desarrollo
La conversación explora vías de llegada al mercado a través de compradores particulares y de organizaciones. Pablo imagina diferentes canales y colaboraciones para facilitar el acceso al producto. Son planes que todavía necesitaban concretarse y comprobar su funcionamiento comercial.
También explica su interés por una preventa vinculada a una comunidad de primeros usuarios. Además de recursos, buscaba personas que pudieran aportar feedback sobre el uso. El aprendizaje posterior debía ayudar a revisar funciones y a orientar nuevas versiones.
El episodio muestra la relación entre ambición, tiempos de desarrollo y preparación del lanzamiento. Cada avance técnico necesita coordinarse con lo que se comunica al mercado. Mantener claro qué está probado y qué se está construyendo ayuda a sostener expectativas realistas.
Qué puede aprender otro equipo de desarrollo
- Investigar cómo interpreta el usuario la tecnología, además de qué funciones necesita.
- Diferenciar a quien compra, a quien configura y a quien utiliza el producto cada día.
- Validar por separado apariencia, interacción e integración antes de evaluar el sistema completo.
- Comunicar con precisión las capacidades demostradas y los objetivos pendientes del desarrollo.
Onorato AI aporta una reflexión sobre el vínculo entre forma, compañía y tecnología. Para empresas que desarrollan dispositivos donde la aceptación del usuario es decisiva, i-mas puede ayudar a convertir requisitos de interacción en propuestas físicas y pruebas útiles. Puedes contarnos qué producto quieres desarrollar.
Para seguir leyendo: El desarrollo de una aplicación de comunicación mediante pictogramas con TalX.
Fuente del artículo: entrevista de Edgar Guerrero con Pablo Mariñosa en Toque de Ingenio, publicada el 13 de enero de 2025. Las citas enlazan con sus pasajes en el vídeo; los aprendizajes son una síntesis editorial y las funciones futuras se presentan como propuestas del proyecto.
