PARA Is Great for Notes — Not Visual References

PARA — Tiago Forte’s Projects, Areas, Resources, Archives — is one of the best systems ever written for organizing notes and documents. It sorts everything by actionability: how soon and for what a thing will be used. That’s exactly right for a knowledge base you act on. It’s exactly wrong for a visual reference library, because references don’t have an actionability. Forcing PARA onto your inspiration is a common reason it feels like it’s fighting you.

What PARA optimizes for

PARA’s genius is that it files by when you’ll use something, not what it’s about. A document moves from Project (active) to Area (ongoing) to Resource (someday) to Archive (done). For tasks and notes this is perfect — a note’s whole value is tied to the work it feeds, and when the work ends, the note’s status changes with it.

Why that model breaks on images

A reference image has a different life. It isn’t bound to one project, and it doesn’t retire when a project ships. Three specific mismatches:

  • References are reused across projects, not consumed by one. That perfect warm-minimal layout serves this client, then next year’s, then a personal side project. PARA wants it filed under a project; it belongs to none and all of them.
  • They don’t “complete.” A note gets archived when its project ends. A reference just becomes relevant again later. The Archive step, PARA’s release valve, has nothing to do here.
  • You retrieve them by attribute, not by actionability. You never think “show me my Resources.” You think “show me warm minimal pricing pages.” PARA’s four buckets are invisible to that query — they organize on the one axis you never search visual work by.

So you end up with a Resources/Inspiration folder that’s really just a junk drawer with a methodology’s name on it. The structure isn’t helping; it’s a folder tree in disguise, with all the same problems.

What works instead: attributes, not actionability

Visual references want to be indexed by what they are and feel like, retrieved by what you need. That’s an attribute model — a small faceted tag set (pattern / mood / medium / source), a couple of tags per item, and search for the rest:

  • Tags describe the image, so it surfaces for any project that needs it.
  • Nothing gets archived — it just waits, findable, until it’s relevant again.
  • You search the way you actually think about visuals: by feel and function.

Build that set once and it carries thousands of images. The how-to is building a tag taxonomy; the middle-path philosophy behind it is the folder is dead, but so is ‘don’t organize’.

Use both, for what each is good at

This isn’t PARA-bashing. Keep PARA for the notes, docs, and project material it was built for — it’s excellent there. Just don’t route your visual references through it. Let text live in an actionability system and images live in an attribute system; each tool gets to be great at its own job.

Where Kelu fits

Kelu is the attribute half: a tag-first visual library where references are indexed by pattern, mood, and medium and found by search across iPhone, Mac, and the web — no project buckets, no archiving, no folder tree. Keep PARA in your notes app; keep the pictures here. First 2,500 items free.