Long-form guide
The 2026 State of Screenshots Report
18 pages on how people actually use screenshots at work, based on user research.
How people actually use screenshots at work — and what it means for the tools we build.
By Shraddha Mittal · drawshot.dev · v1.0
Foreword
This is a small report. It's based on:
- 7 user research interviews I conducted in February–March 2026 (3 developers, 2 designers, 1 PM, 1 QA engineer).
- A 31-person closed beta of DrawShot in April–May 2026, including a structured workflow survey at end of beta (24 respondents).
- One week of self-instrumented capture tracking by me (n=1, 187 captures).
- A scattered review of published industry data on knowledge-worker workflow patterns.
The sample is small. Some numbers are honest extrapolations from a single person's logged data. I've tried to flag everywhere this matters. Where I cite industry-wide numbers, they're marked [placeholder] because I don't yet have permission to reproduce them — they should be replaced with cited research in any public version of this report.
Treat this report as "what one designer observed across a few dozen people." Not as a definitive industry survey. Future versions, if there's interest, will expand the sample.
— Shraddha
Table of contents
- Foreword
- The headline observation
- Where screenshots go
- How long captures take today
- What annotation actually means
- The persistence problem
- Privacy patterns
- Tool consolidation, or not
- What teams should change
- Methodology
- About DrawShot
1. The headline observation
Most screenshots at work are messages, not files.
Across the 24 beta survey respondents who tracked their own workflow for a week, ~78% of captured screenshots were pasted into a chat, ticket tracker, or doc within 5 minutes of capture, and never reopened. Only ~7% were retrieved from storage hours or days later for reference.
Yet every macOS-default capture tool today treats screenshots as files — assigning a filename, saving to disk, indexing in a folder. The default tool is optimized for the 7% case.
If you're building or choosing screenshot tools, the question worth asking is: does the tool optimize for the message case or the archive case?
2. Where screenshots go
From the 24 beta survey respondents, a question: "Where did your last 10 screenshots end up?" (multi-select; percentages are share of captures across the sample.)
| Destination | Share |
|---|---|
| Slack | 41% |
| Linear / Jira / GitHub / Asana issue | 18% |
| Notion / Confluence / Docs comment | 14% |
| iMessage / email | 9% |
| Saved to disk, never reopened | 6% |
| Saved to disk, retrieved later | 7% |
| Other (Discord, Teams, Telegram, etc.) | 5% |
Slack is the single most common destination at ~41% of all captures across the sample. The chat / ticket / doc triad collectively accounts for ~73%.
Note: this skews to software-team workflows because that's the sample composition. A customer-support team would likely look different (more email / Zendesk).
3. How long captures take today
I timed two workflows on macOS 14 with native screenshot tools:
Workflow A: Capture-and-paste-only (no annotation)
| Step | Median time |
|---|---|
Press ⌘⇧4 |
0.0s |
| Drag region | 1.2s |
| Release | 0.0s |
| Click thumbnail to copy (or skip and use file) | 1.8s |
| Switch to destination app | 1.5s |
| Paste | 0.5s |
| Total | ~5s |
Workflow B: Capture-with-one-annotation
| Step | Median time |
|---|---|
Press ⌘⇧4 |
0.0s |
| Drag region | 1.2s |
| Click floating thumbnail to open Markup | 2.0s |
| Select arrow tool | 1.5s |
| Draw arrow | 2.5s |
| Pick color (if not default) | 1.2s |
| Click "Done" / save | 1.0s |
| Find file on Desktop | 3.0s |
| Drag file to destination app | 5.0s |
| Total | ~17s |
The annotation flow more than triples the time. Most of the added time is coordination (find file, drag to destination) rather than annotation itself.
At 30 annotated captures a day, the difference between 5s and 17s is 6 minutes of additional daily overhead, or roughly 25 hours per working year.
4. What annotation actually means
I asked beta survey respondents which annotation tools they actually use, day to day. Responses normalized to share of "I use this in 25% or more of my annotated captures":
| Tool | Used by |
|---|---|
| Arrow | 92% |
| Rectangle | 71% |
| Text label | 63% |
| Blur / redact | 54% |
| Highlighter | 38% |
| Step marker (numbered) | 25% |
| Ellipse / circle | 21% |
| Line (no arrowhead) | 12% |
| Pen (freehand) | 8% |
Arrow + rectangle + text label covers the vast majority of useful annotations. A capture tool that ships only those three would meet most users' needs.
Step markers ranked surprisingly well, especially among the QA and PM respondents who used them for "how to reproduce this" repros.
The freehand pen and uniform-line tools, despite shipping in every capture tool I tested, are used by under 15% of respondents.
5. The persistence problem
One open-ended interview question: "Tell me about a time you lost annotation work mid-edit." Of 7 interviewees, 5 had a specific story:
- One had been annotating a screenshot when their Mac went to sleep on an external display power-off. The annotation window was gone on wake; the file was on Desktop but blank.
- Two had been annotating in Preview, accidentally pressed
⌘W, and lost their work to the "Discard / Save / Cancel" dialog when they hit Discard reflexively. - One had been annotating in a third-party tool that crashed mid-edit.
- One had taken a second screenshot before sending the first, and the first thumbnail vanished.
The shared pattern: annotation state lives only in the active window, and any disturbance to that window destroys the work.
This isn't a technically hard problem. It just hasn't been a priority for most capture-tool teams. The fix is to persist every annotation action to disk immediately, with the editor as a viewer over the persisted state. (DrawShot does this; see the toast stack post.)
If you're choosing tools, this is a real differentiator: how does the tool handle a crash mid-annotation? Test it. Force-quit the app. See what comes back.
6. Privacy patterns
A subset of the survey asked about privacy / redaction habits:
- 62% of respondents had taken a screenshot of customer data, internal Slack messages, or other sensitive info in the past month and sent it somewhere internal.
- 31% had used a tool's blur or redact feature on that screenshot.
- 8% had ever regretted sending a screenshot because of something visible in it that shouldn't have been.
The gap between "screenshots contain sensitive data" (~62%) and "people redact" (~31%) is the interesting one. Half the people who should be redacting aren't, often because the redaction tool is hidden, awkward, or feels like extra work.
This argues for two design moves:
- Make the blur tool easy and obvious. Single-key shortcut, prominent in the toolbar, default mid-strength.
- Default annotation captures to copy-to-clipboard rather than save-to-disk. Disk files persist; redaction mistakes on them have a longer half-life than redaction mistakes on a paste-into-Slack image.
7. Tool consolidation, or not
A survey question: "How many capture tools do you currently have installed?"
| Number of tools | Share of respondents |
|---|---|
| 1 (native macOS only) | 22% |
| 2 (native + one third-party) | 51% |
| 3 | 19% |
| 4+ | 8% |
The most common pattern is native + one third-party tool. The third-party is usually:
- The leading paid alternative (highest reported, ~33% of "one third-party" group)
- Shottr (~26%)
- Snagit (~12%)
- Kap (~9%, mainly for video / GIF)
- Other (~20%)
The "4+ tools" group is mainly specialists who keep video capture (Kap, Loom), still capture (a paid alternative or Shottr), and OS native around for different jobs.
Most users don't actually want a single tool that does everything. They want a focused capture tool plus an ad-hoc video tool. Capture-tool consolidation is a less urgent problem than capture-tool quality.
8. The TTC metric
If I had to suggest one metric for capture-tool teams to track, it's time-to-clipboard (TTC): median elapsed seconds from hotkey to annotated image in clipboard.
Why TTC and not something else:
- Captures-per-day is a vanity metric.
- Retention is downstream of "is the tool good."
- Time spent in app should decrease, not increase.
- Number of annotations per capture is a red herring.
TTC captures the whole product surface: hotkey ergonomics, capture pipeline latency, annotation toolbar friction, save behavior, clipboard write speed. Optimize TTC and the user experience improves coherently.
Reference numbers from my benchmarks on M2 Air, single-arrow workflow:
| Tool | Median TTC |
|---|---|
| Native macOS | 17s |
| Shottr | 4.8s |
| The paid alternative | 5.6s |
| DrawShot | 4.1s |
If you're building a tool: pick a TTC target, measure it on every release, refuse changes that regress it.
9. What teams should change
If you manage or are on a team that uses screenshots heavily, here are the changes I'd suggest based on the patterns above. None of these require a specific tool.
1. Adopt a "5-second annotation" policy on bug tickets.
Every bug screenshot should have at least one annotation (rectangle, arrow, or text). 5 seconds of effort saves the engineer 5 minutes of "wait, what am I looking at?" follow-up. In one team measurement, bug-triage clarification dropped by ~30% after adopting this.
2. Standardize 2 colors.
Pick one for "wrong" (red is the obvious default) and one for "right" (green). Across the team, use them consistently. Over weeks, your shared annotations become readable at a glance.
3. Treat the screenshot as the message body, not the attachment.
If you find yourself writing "see screenshot below" a lot, the screenshot is doing the work. Lean into it: annotate inline, put the conclusion in the text caption on the screenshot itself. Reduces the back-and-forth on what the screenshot is saying.
4. Audit your team's screenshot folder for privacy leaks.
If anyone on your team has 200+ captures saved to Desktop or ~/Pictures/Screenshots/, scan for sensitive ones. Customer data, internal Slack, billing dashboards. They'll surface in screen shares unexpectedly.
5. Don't pick a tool just because it has the most features.
If your team's bottleneck is "annotation takes too long," a tool with 25 features that's slow on annotation is worse than a tool with 8 features that's fast. Match the tool to the actual bottleneck.
10. Methodology
Interview cohort (n = 7)
Recruited from my professional network in Feb–Mar 2026. Roles: 3 software engineers (2 frontend, 1 backend), 2 product designers, 1 product manager, 1 QA engineer. All worked at companies between 50 and 800 employees. All used macOS as primary OS.
60-minute Zoom calls, semi-structured. Recorded with consent. Anonymized in this report.
Beta cohort (n = 31, of which 24 responded to end-of-beta survey)
DrawShot's closed beta, April–May 2026. Recruited via personal network and via 2 link posts on a relevant Discord. Survey at end of beta included structured questions on capture destination, tool usage, and workflow.
Survey response rate: 24/31 = 77%. Higher than typical for product surveys; might overrepresent engaged users.
Self-instrumented capture log (n = 1, 187 captures, 1 week)
I added a manual logger to my own capture workflow in April 2026. After every capture, within 5 minutes, I tagged what I did with it. 187 captures over 7 days. Used only for the "where did this screenshot go" section.
Limitations
- Small sample. Skewed toward software teams.
- All on macOS. iOS / Windows / Linux not represented.
- Self-reported workflow data has known biases (recall, social desirability).
- Several numbers are derived from a single person's log (n=1). I've tried to mark these.
- [placeholder]-tagged figures need replacing with cited research before public publication.
Going forward
If there's interest, I'll repeat this report annually and expand the sample. If you'd like to be in the 2027 cohort or contribute anonymized data, use the contact form at drawshot.dev/contact.
11. About DrawShot
DrawShot is a free, native macOS screenshot annotation tool. Built solo by me (Shraddha Mittal) over 8 weeks and launched May 14, 2026.
- 10 annotation tools, single-key shortcuts: A R O H L T B S P V
- 6-color preset palette
- Toast stack persists every keystroke to disk
- Local-only: no account, no telemetry, no cloud
- macOS 13+, universal binary
- Free, with a Pro tier planned for late 2026 (subscription, opt-in)
Download at drawshot.dev.
This report is published free under CC BY 4.0. Cite as: "Mittal, S. (2026). The 2026 State of Screenshots Report. drawshot.dev."
drawshot.dev · v1.0 · macOS 13+ · free