Produce Original Visuals for How-To Pages

How-to pages are judged on whether the pictures match what the reader is looking at, and stock imagery or vendor marketing shots fail that test on sight. Teams do capture their own screenshots, then record nothing about how or where they were taken, so when the interface moves the page cannot be repaired without redoing the entire walkthrough. Capture is the cheap part; the method exists to make the second capture cheap as well.

The skill file

---
name: original-visuals-for-procedural-content
description: Use when a procedural page depends on screenshots or diagrams that must be accurate now and repairable when the interface changes.
---

# Produce Original Visuals for How-To Pages

How-to pages are judged on whether the pictures match what the reader is looking at, and stock imagery or vendor marketing shots fail that test on sight. Teams do capture their own screenshots, then record nothing about how or where they were taken, so when the interface moves the page cannot be repaired without redoing the entire walkthrough. Capture is the cheap part; the method exists to make the second capture cheap as well.

## What you need first

- access to the actual product or process at the version the page describes
- a fixed capture setup: one viewport width, one zoom level, one theme, one demo account
- the agreed step list the visuals have to match, settled before capture starts
- somewhere to store editable source files, not only the exported images

## Method

1. Fix the capture environment before taking anything: one width, one zoom, one theme, one account. Shots taken at mixed widths cannot be recaptured consistently and look assembled from different products.
2. Populate the demo account with plausible data. Empty states and obvious dummy text make readers doubt the walkthrough, and real customer data cannot be published at all.
3. Capture every step, including the ones that look too obvious to need one. The missing screenshot is always the step where readers get stuck, and returning for one shot costs more than taking it now.
4. Annotate on a separate layer and keep the source file. Arrows burned into a flattened export force a full recapture when a label moves ten pixels.
5. Crop to the region that matters rather than the whole window. Full-window shots shrink to unreadable on a phone, which is where most how-to traffic reads them.
6. Write alt text describing what the reader should see rather than naming the file. "Billing tab with the annual plan selected" is useful; "screenshot of settings" is not.
7. Record the capture date, the product version and the account used alongside the page. Without that record the refresh becomes a new project instead of an edit.

## What this produces

A versioned set of annotated visuals with editable source files, written alt text, and a capture record naming product version and date.

## Where this goes wrong

- Capturing at a wide desktop viewport only, so the images are illegible on the phones most readers use
- Publishing shots containing real account data or internal names, a privacy problem that outlives the page
- Flattening annotations into the export and discarding the source, so every interface tweak means recapturing the whole sequence

---

From the QuQi skill library - https://www.quqi.io/skills/original-visuals-for-procedural-content

What you need first

• access to the actual product or process at the version the page describes
• a fixed capture setup: one viewport width, one zoom level, one theme, one demo account
• the agreed step list the visuals have to match, settled before capture starts
• somewhere to store editable source files, not only the exported images

Method

1. 01 Fix the capture environment before taking anything: one width, one zoom, one theme, one account. Shots taken at mixed widths cannot be recaptured consistently and look assembled from different products.
2. 02 Populate the demo account with plausible data. Empty states and obvious dummy text make readers doubt the walkthrough, and real customer data cannot be published at all.
3. 03 Capture every step, including the ones that look too obvious to need one. The missing screenshot is always the step where readers get stuck, and returning for one shot costs more than taking it now.
4. 04 Annotate on a separate layer and keep the source file. Arrows burned into a flattened export force a full recapture when a label moves ten pixels.
5. 05 Crop to the region that matters rather than the whole window. Full-window shots shrink to unreadable on a phone, which is where most how-to traffic reads them.
6. 06 Write alt text describing what the reader should see rather than naming the file. "Billing tab with the annual plan selected" is useful; "screenshot of settings" is not.
7. 07 Record the capture date, the product version and the account used alongside the page. Without that record the refresh becomes a new project instead of an edit.

What this produces

A versioned set of annotated visuals with editable source files, written alt text, and a capture record naming product version and date.

Where this goes wrong

• Capturing at a wide desktop viewport only, so the images are illegible on the phones most readers use
• Publishing shots containing real account data or internal names, a privacy problem that outlives the page
• Flattening annotations into the export and discarding the source, so every interface tweak means recapturing the whole sequence

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Questions about this skill

More in Content production