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.

O ficheiro da competência

---
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.

## O que precisa primeiro

- 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

## Método

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.

## O que isto produz

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

## Onde isto corre mal

- 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

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/original-visuals-for-procedural-content

O que precisa primeiro

• 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

Método

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.

O que isto produz

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

Onde isto corre mal

• 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 esta skill na sua própria IA

O ficheiro é markdown simples, com o nome e o gatilho no frontmatter. Quando um assistente consegue carregar skills sozinho, é esse frontmatter que lê para decidir que esta se aplica.

Mais em Produção de conteúdo