Last time: transparency doesn't guarantee quality. Here's what that looked like in practice. Over a year and a half on AVT, we made three significant mistakes — and one of them reached the client.
Mistake one: text didn't show up until later
Originally, nobody planned for on-screen text in the tutorials — we and the client's team both assumed camera movement and highlighted action would be enough. The need for text only surfaced once we were already in production, and we built it in on the fly.
On the earliest tutorials, that showed. Text and action highlights appeared fast, and viewers didn't always have time to read them. For an ordinary video, that's a minor detail. For an instruction a first-timer has to work from, it's a defect: a line nobody had time to read might as well not exist.
Once the pipeline settled, we extended the tutorials' pacing. But the first versions were built differently, and at the time, nobody had thought it through.
Mistake two: executors made it look good, not make sense
The first artists on the project fixated on visuals. They didn't account for the fact that this was instructional content with a specific job to do. The result looked good, but it had no pauses at the moments that mattered: one action happens, then immediately the next, with nothing holding the viewer's attention anywhere. People watched, but didn't have time to register what they were actually supposed to repeat with their hands.
We caught this one internally, in review and art direction — it never reached the client. But it kept coming back with every new person who joined. Reminders only held for so long.
We fixed it structurally: we added the requirement into briefs and storyboard templates, and built pauses directly into the working template files at the right points. A new person opens the file, sees the pause, and has to understand why it's there.
Mistake three: a composition problem nobody caught in time
In the earliest tutorials, text markers weren't placed where they needed to be. The composition didn't lead the eye to what mattered. The artists missed it, and art direction didn't catch it either.
The client approved it. And that flawed composition choice became the template for every tutorial that followed.
We caught it late. This isn't a story about catching and fixing everything in time. It's a quality-control failure: we had no criteria that could say "this doesn't work" before the decision shipped.
Those criteria only came later, as art guides for every level and camera angle. They started working in full roughly around the point we reached buses. By then, vans, pickups, sedans, crossovers, and trucks were already done — so a portion of the earlier tutorials were never brought up to the new guides.
We haven't forgotten about this. The project has other priorities right now, so the early tutorials haven't been rebuilt yet. When there's a reason to — an app interface update, say — we'll rebuild them to the current guides. The mistake is known, logged, and waiting for its place in the plan.
What all three have in common
None of these three were technical mistakes. All three came down to one thing: at the start, we had no system that could tell "looks good" apart from "works as an instruction." The first tutorials were made without a process — no template files, no criteria. Once the system existed, pace went up, and these mistakes stopped repeating.
There's one more uncomfortable conclusion here. Client approval is not a substitute for quality control. A client signs off on what they were shown. If the people doing the work didn't check what they were actually showing, the client's signature only locks the mistake in. Responsibility for what the client couldn't have caught stays with the vendor.
In a repeatable process, a mistake never stays a single mistake. Every wrong call, made once and approved once, gets reproduced in everything built after it. Which is why the check has to happen before approval, not after.
By the time I'm writing this, the system works, the first kind of mistake doesn't repeat, and new people reach the required standard faster. The project is ongoing — new vehicle types and new tasks ahead.
Next time: the wrap-up — what this actually delivered, what the client and his partners say about the work, and what's worth taking from it into your own process.