Most people who watch a Scandlearn course module never think about why it looks the way it does. That's by design. But behind every animated schematic, every 3D cutaway, every camera move through a cockpit or an engine, there's a deliberate argument about how people actually learn an aircraft — and a genuinely difficult production process to make that argument real.
We recorded a conversation about it. Emelie Lindqvist, Creative Director, on why the content looks and feels the way it does. Carl Bolton, Production Manager, on what it actually takes to build it. Lightly edited for length, not for honesty.
Why don't aviation training videos use flat 2D schematics?
Flat 2D schematics teach recognition, not understanding. A crew member can learn to identify a system in a diagram without ever understanding what that system actually does when it operates — or fails. Scandlearn builds every course module as a dimensional, behaving system instead of a static diagram, so crews learn how the aircraft works, not just where its parts are labelled.
Emelie: That's the creative brief I kept coming back to when we started shaping the look and feel of our course content. Flat content teaches recognition, not understanding. A crew member can learn to recognise a diagram without ever understanding what the system inside it is actually doing.
So the brief from day one was: show the aircraft as a real, dimensional thing. Not an illustration of a system — the system itself, moving, failing, recovering, exactly the way it does in the aircraft. If a crew member sees a hydraulic circuit lose pressure in our content, I want it to look and behave like it would in the sim, not like a diagram of the idea of pressure loss.
That's the look and feel decision. Carl's the one who had to figure out how you actually build that without every module taking six months.
Carl: That brief is lovely right up until somebody has to build it. Twenty-plus modules, several systems in each, and every one of them has to hold up next to the real aircraft. Nobody has ever come to me with a small version of this idea.
How do you combine a familiar cockpit view with a 3D system underneath it?
Scandlearn's production process separates two layers: a reference layer (the exact cockpit view or instrument a crew member already recognises, modelled precisely) and a depth layer (the actual system behind it — the wiring, the bus, the valve, the mechanism). The camera moves seamlessly from the reference layer into the depth layer and back, so crew members always connect what they see in the aircraft to what's actually happening behind it.
Carl: We split the job in two, which sounds like an admin decision but is actually the whole trick.
First is the reference layer: the view a crew member already recognises. The overhead panel, the ECAM page, the thing they would physically put a hand on. We build that first, and we build it properly, because if it is wrong then nothing after it survives. You lose credibility in the first three seconds, and you do not get it back.
Second is the depth layer. That is where the camera pushes past the panel into the system itself. The bus, the valve, the wiring, whatever is actually doing the work. Separate asset, separate build, and it has to meet the reference layer cleanly enough that nobody notices there were ever two of them.
The join is where the money goes. Getting that move to read as one continuous idea rather than two bits of content taped together was the hardest technical problem on the whole course, and it is the part no viewer will ever consciously notice. Which is the point, annoyingly.
Reference layer is what they already know. Depth layer is what is actually going on behind it. Making the camera travel between the two like it was always one thought, that is the expensive part.
What does 'simple for the crew, not simple underneath' mean at Scandlearn?
It's the principle that runs through both Scandlearn's software and its training content: the end user experiences something clean and effortless, while a serious amount of engineering and production work sits invisibly behind it. On the platform, a training manager sees a simple dashboard while a full competency-scoring architecture runs behind it. In course content, a crew member sees a system that behaves correctly, while extensive system modelling, failure-sequence logic, and FCOM cross-referencing happen before a single frame is animated.
Emelie: This is actually the same idea we've talked about on the platform side — the CBTA engine. What the crew sees is simple. What's running behind it isn't. I didn't set out to make the visual philosophy mirror the software philosophy, but once we'd built a few modules it was obviously the same principle. Simple surface, serious depth, and the depth is what makes the simplicity trustworthy rather than just easy.
Carl: Same principle, and the same production discipline. The training manager never sees the competency scoring; they see a dashboard that works. The crew member never sees the system modelling, the failure logic, the FCOM cross-referencing that happens before anyone animates a single frame. They see a system behaving correctly, and they carry on.
If either one felt like hard work to use, we would have got it wrong. It is a strange thing to aim at as a production team. Enormous effort spent making sure nobody ever notices the effort. There are no awards for that one.
Why is realistic 3D training content harder for competitors to copy?
A flat schematic can be screenshotted and reproduced by a competitor in an afternoon. A dimensional, behaving 3D system cannot — it requires accurately modelling the real system, animating correct failure sequences, and validating all of it against actual aircraft behaviour. That depth of engineering work can't be copied by looking at a finished render.
Emelie: There's a competitive angle here too, which I'll admit I think about more than I probably should. A flat schematic is something a competitor can screenshot and reproduce in an afternoon. What we're building can't be copy-pasted. That was never the reason we chose this approach — the reason is that it's the right way to teach a system — but it's a real consequence of building this way.
Carl: Agreed, and it is also why this is slower and more expensive than it looks from the outside. Depth is hard to fake. Either you modelled the system correctly, or you did not, and a type-rated instructor will find the gap in about ten seconds. They enjoy it, as well.
What's wrong with the old-school pixelated diagrams most training providers still use?
Flat, low-resolution diagrams with arrows, circles, and text labels create two different problems depending on the learner. For a first-time student, there's nothing to anchor the abstract symbols to — they have no prior mental model of the aircraft, so a circle and an arrow on a pixelated photo doesn't tell them how the system actually behaves, only where it's located. For a recurrent crew member who has seen the same diagram for years, the content is so familiar it invites disengagement — they recognise the image before they've actually re-engaged with the material, so attention drops and nothing new is reinforced.
Emelie: This is the thing that actually frustrates me most about a lot of training content still in circulation. It's old photographs, pixelated, with arrows and circles drawn over the top and a label next to it. And it fails two completely different audiences for two completely different reasons.
A first-time student has no existing mental model of the A320. When you show them a flat photo with a circle around a component and an arrow pointing at a label, you're asking them to build understanding out of symbols that don't connect to anything they already know. They can't tell how the system behaves from an arrow. It's not that the information is wrong — it's that there's nothing for a new learner to hold onto.
Then take a recurrent crew member — someone who's seen that exact same photo, maybe that exact same slide, every recurrent cycle for the last five years. The moment they recognise the image, they mentally check out. They're not actually re-engaging with the system, they're pattern-matching 'I've seen this before' and moving on. That's arguably worse, because it creates false confidence. They think they know it because they recognise it, not because they've actually reprocessed it.
Carl: From the production side, that is exactly why we do not treat new-learner content and recurrent content as the same asset with a different sticker on it. Even where the underlying system is identical, we ask what is genuinely new for someone coming back. A different failure scenario, a different way into the system, an angle on the same mechanism they have not seen before.
A photograph cannot do any of that. It is the same pixels forever. Once we have built a system dimensionally, we can re-enter it somewhere else, break it differently, start from an unfamiliar point. Someone on their fourth recurrent cycle is then actually looking at something rather than recognising something.
The new learner cannot join the dots because there is nothing to join them to. The recurrent crew member joins them too fast, decides he has already solved it, and stops looking.
Be the first to know
How does Scandlearn verify its training content is technically accurate?
Accuracy isn't a final checkpoint at Scandlearn — it's a daily working relationship between the design team and instructors throughout production. Instructors are involved continuously, not just at sign-off, which means small technical issues get caught and corrected early, before they compound into something larger. This ongoing collaboration has been the standard workflow for years.
Emelie: This is something people don't see from the outside, and it's probably the least glamorous part of the whole process. It's not a single dramatic review at the end where something either passes or gets sent back. It's a constant dialogue — design and instructors talking daily, all the way through production.
The value of that is catching the small stuff early. A detail that's slightly off in week one is a five-minute fix. The same detail found in week six, after twenty other things have been built on top of it, is a much bigger problem. So the workflow is built around never letting that gap open up in the first place.
Carl: Having a type-rated pilot reviewing while we build changes how the team works. We are not making something in a basement and then praying it survives a review at the end. Somebody who actually flies the aircraft is looking at it while it is still cheap to change.
That matters because of what a late correction costs. A note in the first round is five minutes. The same note after twenty other things have been built on top of it is a rebuild, and rebuilds are where schedules go to die.
It feels slower, because you are never fully left alone with it. It is faster in every way that counts, because we are not discovering a structural problem in something that is basically finished.
Emelie: That daily collaboration is probably the least visible part of the whole process and the most important.
The content has to survive contact with someone who actually knows the aircraft. Not impress someone who doesn't.
What should you look for when evaluating aviation training content quality?
Ask to see a system depicted in failure, not at rest — any provider can show a system working normally, but showing what happens when two systems fail simultaneously reveals how deep the content actually goes. Also ask who reviewed the content: production quality confirms the animation is good, but only review by a qualified instructor confirms it's technically correct.
Emelie: If you're comparing training providers, here's a concrete way to test the difference between content built this way and content that isn't: ask to see a system in failure, not at rest. Anyone can show a clean diagram of a hydraulic system working normally. Ask what happens when two circuits fail at once. If the answer is a static slide with a bullet point, that tells you how deep the content actually goes.
And ask who reviewed it — not just who built it. Production quality tells you the animation is good. Instructor review tells you it's correct.
Carl: Same principle runs through the A320 Flight Crew course itself. Systems taught the way they actually behave, assessment built in rather than bolted on at the end, and every module built to survive scrutiny. From an instructor, from an auditor, and eventually from a crew member sitting in a simulator who has no interest whatsoever in whether we found it difficult.
Systems taught the way they actually behave
About the authors
Emelie Lindqvist is Creative Director at Scandlearn, leading marketing strategy and creative direction across the company's training content and campaigns.
Carl Bolton is Production Manager at Scandlearn, overseeing 3D production and animation for the company's aviation courseware.
