De un proyecto en tarjeta a un artículo y un video

Una tarjeta de desarrollo en el escritorio, un sensor conectado y una terminal imprimiendo números son la materia prima de dos de los formatos que más valoran los ingenieros: un artículo técnico y un video de demostración. Pasar de un proyecto en tarjeta de desarrollo a un artículo y un video suena a trabajo de filmación. En realidad es sobre todo trabajo de ingeniería con una cámara al final. Esta nota del estudio describe, paso por paso, el método que usamos en AlphaCrew Studio y las reglas que seguimos para que lo que ve el lector sea lo que de verdad pasó en el banco.

Puntos clave

• Empezamos por una pregunta del lector, no por la tarjeta. La pregunta decide qué construir, qué medir y qué tienen que mostrar el artículo y el video.
• La medición va antes que el guion. El artículo se escribe alrededor de un resultado real, con sus condiciones y sus límites, no alrededor de lo que se supone que hace el producto.
• El video muestra lo que pasó en el banco; la animación muestra lo que no se puede filmar, como las señales dentro de un convertidor o una onda dentro de un material. La investigación sobre animación instruccional respalda usarla para cosas que se mueven o cambian.
• Los datos ilustrativos, las demostraciones del estudio y las señales simuladas llevan etiqueta. Nada se presenta como resultado de un cliente a menos que lo sea y el cliente lo haya aprobado.
• Los expertos que designa el cliente revisan las afirmaciones técnicas antes de la entrega, empezando por el índice, porque quienes mejor conocen un producto muchas veces juzgan mal lo que a alguien nuevo le cuesta entender.

Por qué un proyecto en tarjeta de desarrollo es un buen punto de partida

Los ingenieros que evalúan un componente o una plataforma quieren saber si funciona en condiciones parecidas a las suyas y cuánto esfuerzo cuesta llegar ahí. La encuesta 2025 de TREW Marketing a ingenieros encontró que los artículos técnicos (61%) y los videos de demostración del producto (35%) estaban entre los contenidos que más se mencionaron como valiosos para una compra importante, después de la hoja de datos (datasheet) (79%). Un proyecto en tarjeta de desarrollo puede alimentar los dos: produce un montaje real, datos reales y problemas reales resueltos en el camino.

El riesgo es que el proyecto se vuelva una vitrina: un demo limpio que funciona una vez, filmado desde el mejor ángulo, con un artículo que explica el producto en lugar del problema. Los ingenieros lo notan rápido. El método de abajo está hecho para evitarlo.

Cómo lo hacemos

1. Primero escribimos la pregunta del lector

Antes de tocar el hardware, escribimos una o dos frases que describen al lector y su pregunta: “Un ingeniero de firmware quiere saber cuánto tiempo de CPU y cuánta RAM consume un clasificador de vibración en un Cortex-M4, y cómo medirlo.” Esa frase se acuerda con el cliente durante el Descubrimiento, porque decide todo lo demás.

También les preguntamos a los ingenieros de aplicaciones o de soporte del cliente qué preguntas escuchan más seguido. El estudio de Pamela Hinds de 1999 sobre la “maldición de la experiencia” encontró que las personas con más experiencia en un dispositivo predecían peor las dificultades de los novatos que las personas con experiencia intermedia, así que quien diseñó el producto no siempre es quien mejor sabe qué hay que explicar.

2. Definimos el montaje más pequeño que la responde

Durante el Alcance decidimos el mínimo de hardware, firmware e instrumentación necesario para responder la pregunta con honestidad: qué tarjeta, qué sensor, cómo se va a medir el resultado (un toggle de GPIO y un analizador lógico, una sonda de corriente, un instrumento de referencia) y bajo qué condiciones va a valer el resultado. Si la pregunta no se puede responder con una medición real en el tiempo disponible, lo decimos y acotamos la pregunta.

3. Construimos el prototipo y medimos

Las etapas de Prototipo y Construcción son ingeniería normal: cablear, escribir el firmware, sacar una lectura, averiguar por qué está mal, corregirla y anotar las condiciones. Guardamos notas de los problemas que encontramos, porque muchas veces son lo más útil del artículo: el lazo de tierra, la frecuencia de muestreo equivocada, el valor por defecto de la librería que no coincidía con la hoja de datos.

La medición se registra de forma que se pueda repetir: versión de firmware, configuración, instrumento, y temperatura o alimentación cuando importan.

4. Escribimos el artículo alrededor de la medición

El artículo sigue la pregunta del lector, no el orden en que hicimos las cosas. Explica el principio, muestra el montaje, da el resultado medido con sus condiciones y dice los límites: qué no se probó y dónde cambiarían los resultados. Los números calculados, no medidos, se marcan como calculados, y los ejemplos ilustrativos se etiquetan como ilustrativos.

5. Filmamos lo que pasó y animamos lo que no se puede filmar

El video demo muestra el montaje real haciendo lo que dice el artículo, con las lecturas del instrumento a la vista. No volvemos a montar un resultado que no ocurrió, ni cortamos una falla de la que habla el artículo.

Hay cosas que no se pueden filmar: la carga en un capacitor de muestreo, el aliasing de una señal rápida, un pulso de ultrasonido reflejándose dentro del tejido. Esas se animan, y la animación se presenta como explicación, no como grabación. El metaanálisis de Höffler y Leutner (2007), con 76 comparaciones, encontró una ventaja general mediana de las animaciones instruccionales sobre las imágenes estáticas, mayor cuando la animación era representacional (mostraba el proceso mismo) y no decorativa. La revisión de Mayer y Moreno (2003) da las reglas prácticas que seguimos: poner las etiquetas junto a lo que describen, quitar lo que no sirve a la explicación y dividir un proceso complejo en segmentos que se puedan seguir.

6. Revisamos con los expertos del cliente

La revisión no es una pasada final. Los expertos que designa el cliente ven el índice, luego el borrador y el primer corte, y revisan cada afirmación técnica antes de la entrega. La confidencialidad se acuerda al inicio: qué se puede mostrar, qué revisiones de tarjeta, qué datos y si puede aparecer algún contexto de clientes. En el trabajo de educación médica, como las animaciones de física radiológica que producimos para Sybil Digital Learning, los educadores aportan la experiencia en la materia y la revisión; nosotros lo convertimos en la explicación visual.

7. Lanzamos y lo mantenemos al día

Después del lanzamiento, el artículo y el video quedan ligados a una versión de firmware y a una revisión de tarjeta. Cuando cualquiera de las dos cambia, se revisa el contenido. El estudio de Novick y Ward (2006) sobre por qué la gente no lee el manual encontró que los usuarios acuden a la documentación cuando están atorados y la abandonan cuando no coincide con su tarea; el contenido desactualizado es el camino más corto para llegar ahí.

Qué mostramos y cómo lo etiquetamos

Material	Qué es	Cómo se etiqueta
Grabación en banco	El montaje real haciendo lo que describe el artículo	Se muestra tal cual, con las condiciones
Resultados medidos	Datos registrados durante el proyecto	Con condiciones, instrumento y versión
Valores calculados	Resultado de una fórmula o un modelo	Marcados como calculados
Ejemplos ilustrativos	Números o escenarios elegidos para explicar algo	Marcados como ilustrativos
Animación explicativa	Un modelo visual de algo que no se puede filmar	Presentada como explicación, no como grabación
Demostraciones del estudio	Construcciones propias, como el tablero de la historia de la señal o el panel de C embebido de nuestro sitio	Etiquetadas como demostraciones del estudio, nunca como trabajo para clientes
Resultados de clientes	Resultados del producto o de los clientes de un cliente	Solo con aprobación del cliente

Cómo aplicarlo

Si tienes una hora

Escribe la pregunta del lector, en una frase, para un proyecto en tarjeta de desarrollo que ya tengas, y anota qué tendrías que medir para responderla.

Si tienes un sprint

Arma el montaje más pequeño que responda la pregunta, registra una medición con sus condiciones y haz el índice del artículo alrededor de ese resultado antes de planear cualquier video.

Si quieres que dure toda la vida del producto

Liga cada artículo y cada video a una versión de firmware y a una revisión de tarjeta, nombra al revisor que lo comprueba cuando alguna cambie y guarda los archivos de medición originales junto al contenido.

La pregunta que debes hacerte: “Si un ingeniero armara este montaje a partir del artículo, ¿obtendría el mismo resultado y sabría por qué si no?”

Preguntas frecuentes

¿Cuánto tarda convertir un proyecto en tarjeta en un artículo y un video?

Depende sobre todo de cuánto tarda en salir bien la medición, no de la redacción ni de la filmación. Cada proyecto se define después de una conversación inicial, así que no publicamos una duración estándar.

¿El video demo debe ser una grabación de pantalla o de la tarjeta?

Normalmente las dos cosas: la grabación del montaje real para que quien lo ve sepa que es real, y capturas de pantalla o del instrumento para que pueda leer los resultados. Lo que no se ve, como las señales dentro de un chip, conviene animarlo y presentarlo como explicación.

¿Se puede hacer que un demo se vea mejor que el resultado real?

Nosotros no lo hacemos. Los resultados se muestran como se midieron, con sus condiciones, y el material ilustrativo lleva etiqueta. Un demo que no se puede reproducir daña la confianza justo de los ingenieros a los que quería convencer.

¿Quién revisa el contenido técnico?

Los expertos que designa el cliente, acordados al inicio del proyecto. Revisan el índice, el borrador y el primer corte, y comprueban las afirmaciones técnicas antes de la entrega.

¿Qué pasa si la medición muestra una limitación?

La reportamos con sus condiciones. Un límite bien dicho le sirve al lector y suele ser más creíble que un resultado sin condiciones.

Lecturas relacionadas: cómo armar el brief para lanzar un producto embebido, cómo medir un demo de IA embebida y lanzamiento de un sensor: más allá de la hoja de datos.

Fuentes

1. TREW Marketing with GlobalSpec (2025). 2025 State of Marketing to Engineers Research Report. https://www.trewmarketing.com/hubfs/Technical%20Resources/Research/2025%20SMTE%20Research/PDF/2025%20State%20of%20Marketing%20to%20Engineers%20Research.pdf
2. Hinds, P. J. (1999). “The Curse of Expertise: The Effects of Expertise and Debiasing Methods on Prediction of Novice Performance.” Journal of Experimental Psychology: Applied, 5(2), 205–221. https://doi.org/10.1037/1076-898X.5.2.205
3. Höffler, T. N., & Leutner, D. (2007). “Instructional Animation Versus Static Pictures: A Meta-Analysis.” Learning and Instruction, 17(6), 722–738. https://doi.org/10.1016/j.learninstruc.2007.09.013
4. Mayer, R. E., & Moreno, R. (2003). “Nine Ways to Reduce Cognitive Load in Multimedia Learning.” Educational Psychologist, 38(1), 43–52. https://doi.org/10.1207/S15326985EP3801_6
5. Novick, D. G., & Ward, K. (2006). “Why Don’t People Read the Manual?” Proceedings of the 24th Annual ACM International Conference on Design of Communication (SIGDOC ’06), 11–18. https://doi.org/10.1145/1166324.1166329