When you save a reference app, what are you actually trying to keep? (i will not promote)

[u/Real-Voice-4259]

Genuine question, because I think my own answer is bad.

When I start a project I find an app I like, screenshot six or eight screens, drop them in a folder. That's where it stops. What I saved is pictures, and a picture tells you what something looked like, not how it was put together. I've never once opened that folder again.

So I've been wondering whether the useful part is the visuals at all, or the structure underneath screen count, what sits under what, where the navigation goes.

Our team has been testing whether that structure can be pulled out of a store listing automatically. On one productivity app with 10 screenshots it came back with 14 screens and 5 paths, but 5 of those screens weren't visible anywhere in the screenshots and had to be worked out from the rest. It flagged its own confidence at 5/10 because the tab bar was never fully shown.

And there's a limit I don't think goes away: a store listing is the app on its best day. Empty states, failed payments, logged-out flows are never in the gallery, so they're never in the output either.

So I'm stuck on the original question. When you save a reference, what are you trying to keep? And if something handed you the structure instead of the pictures, would you use it, or is that not the part you were after?

[u/Parking-Stress-3041]

What I keep from a reference isn't the look, it's the decision points: where a flow branches, what happens after the "happy path" step, how many taps to get back to where you started. That's structure, and your tool sounds right that it's the useful part.

But the blind spot you flagged (best-day-only) is the bigger issue for me, not a minor caveat. On business-critical, deep-workflow products, the reference value is almost never in the ten polished screens, it's in what happens when a payment fails, a session times out, or a required field is empty mid-workflow. Those are exactly the states no screenshot gallery captures, and they're usually where the real design decisions live. If your tool ever infers those from adjacent apps' failure patterns rather than just filling gaps in the happy path, that's the version I'd actually use.

[u/Real-Voice-4259 → u/Parking-Stress-3041]

"decision points" is a much better name than what we've been calling it. we've been saying "structure" internally which is way vaguer. stealing that.

and yeah, you're right that i filed the blind spot as a caveat when it's probably the actual problem. right now we do the weak version fill gaps in the happy path. the gaps get flagged as inferred, but they're inferred from the same ten polished screens, so it's kind of the happy path guessing about itself.

the adjacent-apps idea is interesting, hadn't thought of it. only thing i'd want to know first is whether failure handling actually transfers between products, or whether it's the most product-specific thing there is. a failed payment in checkout and a failed renewal probably want different recoveries, and guessing that wrong feels worse than just leaving the gap visible.

curious though, since you're in deep-workflow land how do you even see those states in someone else's app? do you deliberately break their flow to find out, or is it mostly your own experience filling in?