The single most common thumbnail I see from software tutorial channels is a full screenshot of the software, the whole window, every toolbar, every menu, a spreadsheet with forty visible cells, and then a line of text on top saying what the video teaches. On the creator's monitor it looks perfectly clear, right, because a monitor is huge and you are sitting a foot away from it, and then that same image goes into the feed on a phone, shrinks to a small rectangle and turns into a grey and blue blur with some words on it, and the viewer cannot tell whether it is a tutorial on spreadsheets, email or accounting software.
That problem is really the whole story of packaging for software channels, and it is the reason I wanted to write this one for creators in Redmond, Washington, where Microsoft is headquartered and Nintendo of America has its head office as well, so software and screens are anything but an abstract subject around there. If you are searching for a thumbnail designer Redmond tutorial channels can actually rely on, this is how ClickTheory approaches it, and I will be upfront that we do all of it remotely from Dubai.
Why are software screens unreadable at feed size?
Because a screen recording carries hundreds of small elements designed to be read at arm's length, and when the whole frame is scaled down to a phone thumbnail every one of those elements shrinks below the size the eye can resolve.
YouTube recommends uploading custom thumbnails at 3840 by 2160 pixels for regular videos, with a minimum width of 640, and those specs sit in YouTube's help page on custom thumbnails. But the upload size and the display size are different things, right, the image is shown much smaller in the feed and in search, and the menu text that was crisp in your recording now occupies a few pixels. Trust me on any level, if the viewer has to squint, they will not squint, they will scroll. The full story of why small text fails on mobile is already in why your thumbnail text is unreadable on mobile, so I want to focus on the specific case of interfaces, which are worse than ordinary text because they are dense on purpose.
What should a software tutorial thumbnail show instead of the whole screen?
One element of the interface, enlarged until it is readable, paired with the result the viewer wants, so the thumbnail shows a single button, cell or chart instead of the full window.
Here is how we usually approach a Redmond tutorial video. The strategist watches the video and asks what the viewer is actually trying to get to, which is almost never "learn this menu", it is "make my report take five minutes instead of an hour" or "stop losing files". Then the designer finds the one piece of the interface that proves that promise, a single formula, a single setting, a before and after of a messy inbox, and blows it up so it fills a big part of the frame. Often we rebuild that element as a clean, simplified mockup rather than using the raw screenshot, because the real screenshot carries anti-aliasing and clutter that turn to mush at small sizes, while a rebuilt version keeps the same look with half the noise.
The person can matter too, right, since a tutorial creator pointing at one enlarged setting, with a face that says "this is the one", tells the viewer exactly where to look, and the eye goes face first, then to wherever the face is looking. That is a cheap trick that works because it is honest, it really is the important setting. Shorts covers are their own case, since a vertical frame gives you even less width for an interface, so for a tutorial Short we usually show only the end state, the finished chart or the clean inbox, and leave the how to the video itself. I would rather the cover make one promise clearly than squeeze in a cropped screen that nobody can read while thumbing through a vertical feed.
How do you make spreadsheets, code and menus readable?
By showing far less of them, a single cell, a single line or a single menu item, enlarged and simplified, with surrounding detail cut away or blurred so it cannot compete.
Spreadsheets are the classic trap, right, because the whole point of a spreadsheet is that it is a grid of many numbers, and a grid of many numbers is the least readable thing you can put in a thumbnail. So we show one cell with the result, or one chart that tells the story, and let the title explain the method. Code is similar, and I have covered it properly in the post on thumbnail design for coding channels, so I will only say that one line of code, big, is worth more than a screen of it. Menus work best when the menu item is enlarged and the rest of the interface sits soft behind it, so the viewer gets the context without needing to read it.
Contrast does a lot of this work as well. Interfaces are often light grey on white, which is almost invisible at feed size, so we push the colour of the one element we are featuring and let everything else fade, and if you want the technical side of that, our guide to thumbnail contrast and readability goes through it in detail.
Selling the outcome, not the software
Productivity and tutorial viewers click for a better day, not for a better understanding of the tool, so the packaging should lead with the outcome and let the software be the means.
Nobody wakes up wanting to learn a menu, they wake up wanting their afternoon back, so put the afternoon on the thumbnail.
I think this is where a lot of productivity channels underperform, honestly, right, because the creator loves the tool and so they package the tool, and the viewer does not love the tool yet, they love the idea of being done by five. Hang on to this one point if nothing else, since it is where so many tool channels go backwards. A title like "Every Shortcut in This App" is about the software, while "I Cut My Email Time in Half" is about the viewer, and the thumbnail follows that, a calm person, an empty inbox, one clear word. The broader take on this is on our productivity channel thumbnail page, and packaging for tutorial videos covers why the result beats the steps, which I will not repeat here.
Do I need a thumbnail designer in Redmond, or will a remote studio do?
A remote studio works fine for tutorial channels, because almost everything we need is already on your screen recording, and a designer in Redmond would be working from the same files we would.
Tutorial content is about the friendliest category there is for remote packaging, since the raw material is digital already, so there is nothing to shoot on location and nothing a local designer would see that we cannot. The general version of this argument, including when local actually makes sense, is in our hub post on whether your thumbnail designer has to be local. If you prefer to compare with studios closer to home, there is an honest look at the YouTube packaging options Seattle tech channels have. And since Redmond calls itself the Bicycle Capital of the Northwest, I am pretty sure a few of you run a cycling channel on the side, which is a very different packaging job that we also do, and which I wrote about in thumbnail design for road cycling channels. The same goes for gaming, which has its own page on gaming channel thumbnails for anyone in a town where Nintendo of America keeps its head office.
How do the files and the Pacific time difference work?
You share the screen recording or a few key frames in a folder at the end of your day, and since Dubai is 12 hours ahead of Pacific Time in winter and 11 hours ahead during daylight saving, your 8 pm upload is waiting for us at 8 am or 7 am Dubai time.
For tutorial channels the brief can be tiny, the video link or the recording, the working title, and the one outcome the viewer gets. We do not need you to describe the interface, right, we can see it. From there the strategist drafts title options and sketches before you wake up, and you review on your own schedule in the Slack channel we set up for your account, with email as a backup. If you ever want to sanity check the gap before sending something time sensitive, the Dubai world clock shows it in a second.
What does it cost to package a tutorial channel?
A standard pack of eight custom thumbnails is 250 dollars, revisions included until you are happy, with title consultation on every video, and the pack usually comes back inside three days, weekends excluded.
For tutorial channels, the part I would actually look at hardest is the back catalogue, right, because tutorials are evergreen, people search for "how to do X" for years, and a library of old tutorials with unreadable screenshot thumbnails is often the best place to start. We use YouTube's test feature on older videos as well as new ones, and an alternate version for that test is a small add-on. You can see the add-ons and the turnaround on the services page, the reasoning for refreshing old uploads in repackaging tutorials and evergreen guides, and if you are still weighing whether to bring in help at all, the honest version of that decision is on our page about hiring a thumbnail designer. And if you only publish a tutorial now and then, I would genuinely tell you to keep making your own, just crop tighter.
Which tutorial should you repackage first?
Your most searched tutorial whose thumbnail is still a full screenshot, because that video already has demand and the packaging is the only thing standing between it and more clicks.
If you open your analytics and sort by views from search, I would bet the top few tutorials have thumbnails nobody can read on a phone, and that is good news, really really good news, because it means the fix is in the packaging and not in the content. You already made the useful video. The job now is just to make sure a person on their phone, looking for the answer you recorded, can see in one glance that your video has it, and if the thumbnail does that, the screen you worked so hard on finally gets the attention it deserves. So yeah. That's my way of saying it.