Board Technology Oversight

A Screenshot Is Not a Workflow: Explain the Steps Between the Screens

A screenshot shows a moment, not the work around it. Explain the user task, transitions and visible result so a technology walkthrough makes sense.

Laptop with a blank screen, tablet and phone on a wooden desk

A slide shows three screenshots. Each looks polished. The presenter moves to the next slide, but a reader still cannot explain how the user got from the first screen to the last.

Screenshots can help explain a workflow, but the spaces between them carry much of the meaning. What did the user do? What changed? What result should the reader notice? Those are writing questions before they are design questions.

Key takeaways

  • Name the user task before showing the interface.

  • Give each image one clear purpose.

  • Describe the action between screenshots.

  • State what the final screen demonstrates, and what it does not.

Step 1: Name one task

Choose a task small enough to follow from beginning to end. "Explore the new portal" is broad. "Find the opening hours for a location" gives the reader something concrete to watch.

Use a fictional example or a demonstration environment. Keep personal information and real customer records out of an explanatory walkthrough.

Step 2: Write the captions before choosing images

Google's technical-writing guidance suggests writing a caption before making an illustration. That helps the author decide what the image is meant to show.

Apply the same idea to screenshots. If the caption is only "new page," it does not yet explain the image's job. "The location filter narrows the list to three nearby branches" gives the reader a specific change to notice.

Step 3: Show the transitions

A fictional example:

  1. Start: the visitor sees a list of library branches.
  2. Action: the visitor chooses a neighborhood.
  3. Change: the list shows branches in that neighborhood.
  4. Result: opening hours appear beside each branch.

The screenshots illustrate the starting point and result. The short action sentence explains the movement between them. No particular product or performance is implied.

Step 4: Separate the demo from the claim

An image can show that a particular screen exists in a demonstration. It does not, by itself, show how every user will experience the workflow. Label sample data, prototypes and unfinished screens plainly.

A short note such as "illustrative prototype, not a live product" is more informative than leaving the audience to infer the status. Keep the walkthrough focused on understanding the interaction, not certifying the system.

Sources

Google Technical Writing: Illustrating

Google documentation style guide: Procedures

Frequently asked questions

Do we need a screenshot for every step?

No. Use images where they explain something the words alone do not. A short transition can be clearer than another nearly identical screen.

What belongs in a caption?

The action or change the reader should notice, with any context needed to interpret the image. Avoid a caption that merely repeats the slide title.

A practical next step

Choose one existing walkthrough and cover the screenshots. If the captions still tell a coherent story, the images have a clear role. If they do not, start with the missing transitions.

Next step

Get Board-Ready on AI and Cyber Risk

A 30-minute call. No charge. You'll leave with a clear read on where your oversight stands and what to do about it.

Stop Guessing. Start Scoring
Tyson Martin

Written by Tyson Martin, NACD.DC

Chief Trust, Security & AI Officer. CISO of record at MIO Partners; former CISO & CTO at Lumber Liquidators and Orvis; advisor to 200+ Fortune 500 boards and C-suites at AWS.

See the track record
Keep reading

More on Board Technology Oversight

All CISO Insights
Board Technology Oversight

Concentration Risk in One Cloud Region

When most workloads sit in one cloud region, one failure reaches everything. A dependency heat map shows where the blast radius is bigger than intended.