For freelance work, organize windows around a specific client delivery rather than a broad “client work” bucket. A browser, document, chat, and asset folder can belong together even though each application also contains unrelated personal or client material.
Create one group per active delivery
Name the group after the client and result: “Northwind proposal revision” is clearer than “Northwind” or “Design.” Add only the windows needed for the next visible action. If the action is “apply the approved copy changes,” the group may need the feedback thread, current draft, preview, and asset folder—not every window ever used for that client.
Keep a short task beside the group that states the completion condition. That makes the window collection actionable instead of turning it into another archive.
Do not confuse organization with access control
A project label does not separate browser cookies, cloud accounts, permissions, or files. Use browser profiles, separate logins, client-approved storage, and operating-system permissions for those boundaries. A window can be in the correct group and still show the wrong account.
Before switching clients, check the visible identity clues: account avatar, environment label, document owner, repository path, or client code in the window title. Do not infer identity from color alone.
Close the delivery deliberately
After handoff, divide the windows into three sets:
| Keep open | Save durably | Close |
|---|---|---|
| Items needed for the next agreed action | final files, approved links, decision notes | old previews, duplicate exports, resolved feedback |
Removing a window from a project view does not delete its file, and closing a window may not quit its application. Confirm unsaved work in the source app. The goal is a clean boundary between current client work and retained records, without treating an active window group as the permanent client archive.