From Dev-Board Project to Article and Demo Video

A development board on a desk, a sensor wired to it and a terminal printing numbers is the raw material for two of the formats engineers value most: a technical article and a demo video. Turning a dev board project into an article and demo video sounds like a filming job. It’s mostly an engineering job with a camera at the end. This Studio Note describes the method we use at AlphaCrew Studio, step by step, and the rules we keep so that what the reader sees is what really happened on the bench.

Key Takeaways

• We start from one reader question, not from the board. The question decides what to build, what to measure and what the article and video must show.
• The measurement comes before the script. The article is written around a real result, including its conditions and limits, not around what the product is supposed to do.
• Video shows what happened on the bench; animation shows what can’t be filmed, such as signals inside a converter or a wave inside a material. Research on instructional animation supports using it for things that move or change.
• Illustrative data, studio demonstrations and simulated signals are labelled as such. Nothing is presented as a customer result unless it is one and the client has approved it.
• The client’s designated experts review technical claims before delivery, starting with the outline, because the people who know a product best often misjudge what a newcomer finds hard.

Why a dev-board project is a good starting point

Engineers evaluating a component or a platform want to know whether it works in conditions like theirs and how much effort it takes to get there. TREW Marketing’s 2025 survey of engineers found that technical articles (61%) and product demo videos (35%) were among the content most often named as valuable for a significant purchase, after the datasheet (79%). A development-board project can feed both: it produces a real setup, real data and real problems solved along the way.

The risk is that the project turns into a showcase: a clean demo that works once, filmed from the best angle, with an article that explains the product rather than the problem. Engineers recognize that quickly. The method below is built to avoid it.

How we approach it

1. Write the reader’s question first

Before touching hardware, we write one or two sentences describing the reader and the question: “A firmware engineer wants to know how much CPU time and RAM a vibration classifier takes on a Cortex-M4, and how to measure it.” That sentence is agreed with the client during Discovery, because it decides everything else.

We also ask the client’s applications or support engineers which questions they hear most often. Pamela Hinds’ 1999 study on the “curse of expertise” found that people with the most expertise in a device predicted novices’ difficulties less accurately than people with intermediate experience, so the person who designed the product is not always the best judge of what to explain.

2. Scope the smallest setup that answers it

During Scope we decide the minimum hardware, firmware and instrumentation needed to answer the question honestly: which board, which sensor, how the result will be measured (a GPIO toggle and a logic analyzer, a current probe, a reference instrument), and what conditions the result will hold under. If the question can’t be answered with a real measurement in the time available, we say so and narrow the question.

3. Build the prototype and measure

The Prototype and Build stages are ordinary engineering: wire it, write the firmware, get a reading, find out why it’s wrong, fix it, and record the conditions. We keep notes of the problems we hit, because those problems are often the most useful part of the article: the ground loop, the wrong sample rate, the library default that didn’t match the datasheet.

The measurement is recorded so that it can be repeated: firmware version, settings, instrument, temperature or supply where it matters.

4. Write the article around the measurement

The article follows the reader’s question, not the order in which we did things. It explains the principle, shows the setup, gives the measured result with its conditions, and states the limits: what wasn’t tested, where results would differ. Numbers that are calculated rather than measured are marked as calculated, and examples that are illustrative are labelled as illustrative.

5. Film what happened; animate what can’t be filmed

The demo video shows the real setup doing the real thing, with the instrument readings visible. We don’t re-stage a result that didn’t happen, and we don’t edit out a failure that the article discusses.

Some things can’t be filmed: the charge on a sampling capacitor, the aliasing of a fast signal, an ultrasound pulse reflecting inside tissue. Those are animated, and the animation is labelled as an explanation, not footage. Höffler and Leutner’s 2007 meta-analysis of 76 comparisons found a medium overall advantage for instructional animations over static pictures, larger when the animation was representational (showing the process itself) rather than decorative. Mayer and Moreno’s 2003 review supplies the practical rules we follow: put labels next to what they describe, cut what doesn’t serve the explanation, and break a complex process into segments the viewer can follow.

6. Review with the client’s experts

Review isn’t a final pass. The client’s designated experts see the outline, then the draft and the rough cut, and check every technical claim before delivery. Confidentiality is agreed at the start: what can be shown, which board revisions, which data, and whether any customer context may appear. For medical-education work, such as the radiology-physics animations we produce for Sybil Digital Learning, the educators provide the subject-matter expertise and the review; we turn it into the visual explanation.

7. Launch and keep it current

After launch, the article and video are tied to a firmware version and a board revision. When either changes, the content is checked. Novick and Ward’s 2006 study of why people don’t read manuals found that users turn to documentation when they’re stuck and abandon it when it doesn’t match their task; out-of-date content is the fastest way to get there.

What we show, and how it’s labelled

Material	What it is	How it’s labelled
Bench footage	The real setup doing what the article describes	Shown as is, with conditions stated
Measured results	Data recorded during the project	Conditions, instrument and version given
Calculated values	Results of a formula or model	Marked as calculated
Illustrative examples	Numbers or scenarios chosen to explain a point	Marked as illustrative
Explanatory animation	A visual model of something that can’t be filmed	Presented as an explanation, not footage
Studio demonstrations	Our own builds, such as the signal-story board or the embedded C panel on our site	Labelled as studio demonstrations, never as client work
Client results	Outcomes from a client’s own product or customers	Used only with the client’s approval

How to put it to work

If you have an hour

Write the one-sentence reader question for a dev-board project you already have, and list what you would need to measure to answer it.

If you have a sprint

Build the smallest setup that answers the question, record one measurement with its conditions, and draft the article outline around that result before planning any video.

If you want it to last the product’s lifetime

Tie every article and video to a firmware version and board revision, name the reviewer who checks it when either changes, and keep the raw measurement files with the content.

The question to ask yourself: “If an engineer rebuilt this setup from the article, would they get the same result, and would they know why if they didn’t?”

Frequently asked questions

How long does it take to turn a dev-board project into an article and video?

It depends mostly on how long the measurement takes to get right, not on writing or filming. Each project is scoped after an initial conversation, so we don’t publish a standard duration.

Should the demo video be a screen recording or footage of the board?

Usually both: footage of the real setup so the viewer sees it’s real, and screen or instrument captures so they can read the results. Anything that can’t be seen, such as signals inside a chip, is better animated and labelled as an explanation.

Can you make a demo look better than the real result?

We don’t. Results are shown as measured, with their conditions, and illustrative material is labelled. A demo that can’t be reproduced damages trust with exactly the engineers it was meant to convince.

Who reviews the technical content?

The client’s designated experts, agreed at the start of the project. They review the outline, the draft and the rough cut, and check technical claims before delivery.

What if the measurement shows a limitation?

We report it with its conditions. A clearly stated limit is useful to the reader and usually more credible than a result with no conditions at all.

Related reading: briefing a content partner for an embedded launch, measuring an embedded AI demo and sensor product launch: beyond the datasheet.

Sources

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