Skip to content
Showing posts with label Experimentation and innovation. Show all posts
Showing posts with label Experimentation and innovation. Show all posts

Monday, April 14, 2025

Who should see the AI's advice first? Why we put nutritionists in the loop

In 2024 we started building Nutr(IA) Coach, an AI product for nutrition. The first big product decision had little to do with models or prompts. It was about who receives the output. As a team we decided that the AI would work for nutritionists, and that a nutritionist would review its suggestions before they reached anyone.

The decision

The obvious version of the product gave nutrition advice straight to the public. It has the most potential users and the shortest path to growth. We chose the other version: the nutritionist uses the AI to prepare and speed up their work, and the person who receives the advice deals with a professional, with the AI behind them.

We made that call as a team, and the reason was ethical. Advice about what someone eats touches their health, and a person reading a confident answer on a screen has no easy way to tell a good suggestion from a harmful one. A nutritionist can, and can also see what the screen does not: the person's history, their circumstances and the questions that never made it into the prompt.

What the frameworks say

The principle has a long history in AI ethics, and reading the frameworks helped us put words to what we already felt.

The World Health Organization's guidance on ethics and governance of AI for health (2021) sets out six principles. The first is protecting human autonomy: humans should remain in control of health-care systems and medical decisions. Its 2024 guidance on large multi-modal models applies the same principles to generative AI.

The EU's Ethics Guidelines for Trustworthy AI (2019) list human agency and oversight first among seven requirements, and describe human-in-the-loop as one way to achieve it.

The AI Act turns human oversight into a legal duty for high-risk systems (Article 14), and since 2 February 2025 its first obligations apply, AI literacy among them. I am not saying the Act classes our product as high-risk. The point is that regulators and health bodies reached the same conclusion we did: when the stakes are personal, a person stays in charge.

The hard part: a reviewer can still rubber-stamp

A human in the loop is only a safeguard if the human actually reviews. Automation bias is well documented: people tend to accept a system's suggestion, more so when it is usually right and they are busy. A 2012 systematic review in JAMIA found it in clinical decision support. A nutritionist who approves every draft with one click gives the same protection as no nutritionist at all.

So the design question moves from "is there a human?" to "does the human have the time, the information and a reason to disagree?" These are the checks I would apply to any human-in-the-loop design:

  1. The professional can see why the AI made a suggestion and which data it used.
  2. Editing a draft is as quick as accepting it, so changing it costs nothing.
  3. The AI says what it cannot handle and passes those cases straight to the professional.
  4. Responsibility is written down: the professional signs the advice, and the record shows it.

What an analyst brings to it

Human in the loop also creates a measurement point that a direct-to-consumer product lacks. Every suggestion is accepted, edited or rejected by an expert. Those rates say more about the quality of the AI than a satisfaction score, and a rise in one-click approvals is an early warning of automation bias. Before a feature goes live, I want to know how we will measure it, and this design gives us something worth measuring.

Sunday, February 20, 2022

Product ideation: Diagrama de Ishikawa

Dentro de la metodología de innovación en design thinking se puede hacer uso del diagrama de Ishikawa. 

El Diagrama de Ishikawa, también conocido como Diagrama de Espina de Pescado, una herramienta visual poderosa que te ayudará a navegar por las complejidades del proceso creativo y a asegurar que tu producto final sea un éxito rotundo.

El Diagrama de Ishikawa es una herramienta versátil y valiosa para cualquier equipo de desarrollo de productos. Al utilizarlo de manera efectiva, podrás anticipar y superar obstáculos, optimizar tus procesos y, en última instancia, crear productos que deleiten a tus clientes y impulsen el éxito de tu negocio.

¿Qué es el Diagrama de Ishikawa?

Imagina el esqueleto de un pez: la cabeza representa el problema o efecto que quieres analizar (en este caso, un producto fallido o con margen de mejora), y las espinas son las posibles causas que contribuyen a ese resultado. Estas causas se clasifican en categorías principales, como:

  • Métodos: Procesos de diseño, desarrollo, producción.
  • Máquinas: Tecnología, herramientas, equipos utilizados.
  • Mano de Obra: Habilidades, capacitación, motivación del equipo.
  • Materiales: Calidad, disponibilidad, costo de los insumos.
  • Medio Ambiente: Condiciones de trabajo, factores externos.
  • Mediciones: Métricas, sistemas de control de calidad.

¿Cómo Aplicarlo en la Creación de Productos?

  1. Define el Problema: ¿Qué quieres lograr con tu producto? ¿Qué desafíos o problemas potenciales anticipas?
  2. Identifica las Categorías Principales: Adapta las categorías tradicionales (6M) a tu contexto específico. Por ejemplo, en desarrollo de software, podrías considerar "Código", "Diseño UX/UI", "Requisitos", etc.
  3. Lluvia de Ideas: Reúne a tu equipo y genera ideas sobre las posibles causas que podrían afectar el éxito del producto, asignándolas a las categorías correspondientes.
  4. Profundiza en las Causas Raíz: Analiza cada causa y busca subcausas más específicas. Utiliza preguntas como "¿Por qué sucede esto?" para llegar al fondo del asunto.
  5. Prioriza y Actúa: Identifica las causas más impactantes y desarrolla soluciones concretas para abordarlas.

Beneficios del Diagrama de Ishikawa:

  • Fomenta la Colaboración: Involucra a todo el equipo en la identificación y resolución de problemas.
  • Visualiza las Relaciones: Permite ver claramente cómo las diferentes causas interactúan y afectan el resultado final.
  • Promueve el Pensamiento Crítico: Estimula el análisis profundo y la búsqueda de soluciones efectivas.
  • Previene Problemas Futuros: Al identificar y abordar las causas raíz, se reducen las posibilidades de que los mismos problemas vuelvan a surgir.
Si quieres tener más información. Desde esta página puedes encontrar una template para trabajar este modelo:

Thursday, January 7, 2021

MLOps - Machine Learning + Operations, un framework agile para equipos de Data Science

 Conforme aumenta la madurez en datos en las empresas y el uso de Machine Learning se hace más común el uso de framework e intentar buscar standares para que la colaboración dentro de la empresa y el self'service de datos sea más rápido y ágil. Cualquier que haya trabajado en un equipo de Data o de Analytics, o incluso haya tenido que trbajar creando modelos con Data Scientifics (Científicos de datos) se habrá dado cuenta que Scrum u otros frameworks de desarrollo de software no funcionan tan bien como en un proyecto puramente de desarrollo. Muchas veces se crean cuellos de botella o se tienen que rehacer tareas continuamente y el equipo dependen continuamente de DevOps para las release de los modelos y bueno, un largo etcétera.

Las grandes tecnológicas parece que han estado trabajando en como unir Operations y Machine Learning y han creado un framework para unirlo. Ya el año pasado comentaba el caso de DataOps manifiesto. Sin embargo, aquí se va un paso más alla y se especifica que es para equipos de Machine Learning o Aprendizaje Automático, ya que estos requieren de releases para los modelos y da esa agilidad que encontramos en Devops a los equipos de Data.

La wikipedia tiene una definicion de MLOps esto que viene a decir que la unión de DevOps y Machine Learning.

Esto, es algo bastante novedoso así que todavía esta todo un poco en pañales pero parece que tiene un gran futuro. Así que es mejor que nos informemos de como podemos empezar a usar este framework gracias al cloud computing


Qué tiene en común DevOps y MLOps

Si pensamos en un equipo de Devops, debemos fijarme en las prácticas ágiles que siguen. 
Las dos tareas principales que ambos tienen en común son
- Integración continua (CI)
- Entrega continua (CE)

Sin embargo, según el equipo de GCP que han creado una introdución a MLOps y las fases de maduración de las empresas o equipos, MLOps además  tienen otras fases que los distintgue de DevOps
- Entrenamiento Contínuo (CT)

Para saber más sobre MLOps es muy recomendable este artículo del equipo de GCP sobre las fases de maduración de MLOps

Para una introducción y saber como llevan esto las grandes empresas de tecnología, aquí puedes ver un video introductorio de Google sobre Best Practices



Y otro video de Microsoft de introducción de Machine Learning- Operations

Monday, April 6, 2020

User story - historia de usuario - en Metodologias Agiles

Qué son las User stories o historia de usuarios
Las User Stories son artefactos usados en Scrum, el framework más usado en Agile o Metodologías Ágiles.

Para qué se usan la user story en Agile
En Agile, siempre se intentan descomponer las tareas en unidades más pequenas. Las historias de usuario suponen la parte más pequena en la que trabajar en un producto o feature.

Cómo se crean historia de usuarios
Normalmente este siguen el siguiente esquema

“Como [ tipo de usuario ] 
necesito/quiero [ el qué ] 
así puedo [ beneficio ]”

Por qué usar historias de usuarios para definir nuestras tareas
Con esta sentencia ponemos al usuario en el centro de nuestras tareas tratando de resolver un problema que el usuario tiene por encima de lo que nosotros creamos que es mejor o más fácil de hacer

He creado algunos ejemplos de historia de usuarios en github qué puedes visitar aquí

Monday, December 23, 2019

Trabajar en Agile o metodologías Ágiles

Cada uno tiene su historia y

De cómo Agile llegó a mi vida

Hace un par de años empecé a trabajar en el Gobierno Británico. Ya conocía GDS por diferentes cursos que había hecho sobre Experiencia de Usuario y porque siempre me ha interesado el tema de la colaboración como Socióloga que soy la psicología social siempre me ha fascinado.

También conocía de oídas Agile y las metodologías Ágiles. Como analista digital siempre me ha tocado mi parte de project management y negociación. Al estar en el centro del negocio nos toca lidiar con todo tipo de stakeholders e influenciar a los programadores o techies para que hagan los cambios que necesitamos. Sin ellos no samos nadie. Así que desde que empecé en digital esto soy una ferviente leedora de blog y libros de como ser más productivos y suelo guardar los mejores artículos aquí  https://www.scoop.it/topic/productividad-y-tic,

Pues bien, el papel de transformación digital en GDS no puede entenderse sin Agile. Tengo que decir que al principio me costó pillar que estábamos haciendo y por qué trabajábamos así. Sin embargo ahora me he dado cuenta que la visión de Agile en la creación de software es la correcta. Entiendo que a las empresas les pueda dar un poco de miedo este cambio, sin embargo, cada vez que hablo con otros compañeros del sector que siguen trabajando con otras metodologías me reitero que Agile es la forma adecuada de trabajar para crear productos digitales - desarrollo de software.

De que va todo esto de Agile...


  • De entrega rápida de software, en vez de mega proyectos que nunca se terminan (te suena...)
  • De Trust o confianza y mucha transparencia. Hay mucho de psicología social y sociología en todo esto para los miembros de la empresa. 
  • De tener en cuenta a los usuarios para darles lo que necesitan, adaptando el producto a sus necesidad en vez de que ellos se adapten al producto. Al fin y al cabo vivimos en un mundo cada más global donde la competición es cada vez más grande y los productos están en constante evolución.


Y si lo pensamos, asi es como deberia ser. Deberiamos confiar en nuestros jefes, en nuestros compañeros de equipo y en las personas que tenemos a nuestros mando. Una vez que todo esto se ha conseguido, todo va como la seda. Pero hasta que llegamos allí va a un largo camino y para ello alguien debe velar por que esto se pueda hacer y que esa confianza no se rompa.

Ya había comentado que Agile es una metodología, pero seguro que habrás oido hablar de Scrum, Lean ,de Kanban, de poner al usuario en el centro,... .Ahí un va un poco de luz a todo esto.

Agile es una metodología. Todo empezó con un manifiesto,aquí puede leer los principios del manifesto en inglés.Y  aquí puedes leerlo en castellano.
Sin embargo aunque esos principios no han ido cambiando con los años, si que se lo ha hecho como utilizarlos.

Dentro de Agile podemos encontrar dos frameworks ampliamente usados- Scrum (el más usado y más reglado) y Kanban. Sí, a mi también me sonaba a chino.


Tuesday, May 17, 2016

Principios básicos para realizar test a/b

Jelo People,hacía que no escribía una barbaridad (pero una barbaridad de verdad).

Unfortunatelly he terminado la temporada 3 de House of Cards  y la 4 aún no está en Netflix (la vida es así de dura, pero hay que convivir con ello) Pero bueno,he cogido mi lista de cosas por hacer y me he encontrado el curso de A/B testing  que dejé a medias hace unos meses. Os hago aquí un resumen por si os interesa.

Así que he estado mirando unos videos de la friki-pandi de CRO de Google y os resumo en estos vídeos de ejemplos y de un minuto aproximadamente. El tipo de preguntas que se puede hacer y que no se puede hacer en a/b testing. Cuando hacemos a/b testing nos interesa poder medir algo básico, mutuamente excluyente y que podamos saber que es aleatorio porque si no, nosotros estamos influenciando los resultados y claro, eso no vale  porque es una técnica cuantitativa y los números sólo dicen sí o no.

When can you use a/b testing
https://www.youtube.com/watch?v=EwV5Vs2m33w


Otro ejemplo
https://www.youtube.com/watch?v=tlSe7H9BDy8


Información sobre a/b testing en castellano

Y si pasáis del inglés. Este hombre con gorro lo explica bastante y en castellano (da el pego con el titulo en inglés pero está en castellano)
http://www.slideshare.net/joanby/how-to-properly-analyze-an-ab-test?ref=http://juangabrielgomila.com/como-analizar-correctamente-un-test-ab/

Seguiremos informando