Deep work / method

How to turn a vague goal into a browser boundary

A browser can hold a clear route more easily than it can hold an intention. Replace the broad promise with an observable result, then keep only the sites that can help.

Work on the project is not a bad goal. It is a bad starting instruction for a browser. It gives every page a plausible connection to the project. A message, a new tutorial, a forum thread, and a shopping tab can all look like preparation.

A useful browser boundary begins with a result. Draft the introduction, verify the two sources, and send the document has a finish line. Reproduce the bug, add a test, and open a pull request has one too. The result tells you what must remain reachable and what can wait.

Step one: name what changes

Use a verb that leaves evidence. Finish, draft, solve, submit, review, deploy, or decide are useful. Add the object and a modest limit. Read about databases becomes compare two indexing options and write the recommendation. Study the chapter becomes answer eight questions and mark two topics for spaced review.

Do not write a goal that depends on a feeling. Feel caught up has no visible end. Clear the three urgent messages and put the rest into tomorrow's list does. The browser cannot create a feeling, but it can protect the action that produces a record.

Step two: draw the smallest route

List the domains the result needs. A writing session may need a document editor, a source archive, and a citation manager. A course may need a lesson platform, a repository, and documentation. A deployment task may need a repository, a provider dashboard, and a log view.

Remove convenient sites that are not necessary. Search can be useful, but its home page is a large doorway. If you need a source, write the exact question first. Add the source when you know it belongs. If you need a new domain halfway through, decide whether it serves this result or a different one.

The route should be small enough that you can explain it in one breath. If it takes a paragraph to justify every site, the task may need a wider research period before a narrow session.

Step three: choose a finite duration

Time is a boundary, not a moral score. Choose a duration that matches the result and your current attention. A short first session tells you whether the route is complete. A longer session may make sense for a large draft, but it should still have a visible result.

Focusward gives each installation 30 cumulative minutes of active website blocking before Focusward Pro is required. Pro is planned at $6.99 per month or $59.99 for a lifetime license. Those are product choices, not research claims. The important part of the method is that the session ends when the chosen duration ends. There is no break cycle inside the extension.

Step four: write an if then rule

An implementation intention connects a situation to an action. If I start the deployment task, then only GitHub, the documentation, the package registry, and Vercel remain open. This is clearer than I will try not to browse.

Research on implementation intentions supports a careful claim. A 2005 paper by Sheeran, Webb, and Gollwitzer found that implementation intentions improved goal attainment when underlying goal intentions were strong, but not when those intentions were weak. A 2006 meta analysis synthesized 94 independent tests and reported a medium to large positive effect for forming implementation intentions. The evidence supports a planning tool. It does not guarantee completion.

Translate the if then rule into the browser boundary. State the goal. Choose the domains. Start the session. When a blocked page appears, read the goal before making a new choice. The rule removes one negotiation. It does not remove the work.

Step five: begin with one concrete action

Before the timer starts, name the first click that matters. Open the failing test. Write the first paragraph. Retrieve the lesson's three ideas. Compare the two sources. A first action prevents the session from becoming a ceremony about preparing to begin.

Keep the first action reversible and small. You are testing the route. If the task is wrong, the first action will reveal that sooner than a long list of productivity rituals.

Step six: review what changed

At the end, write what changed in the world outside your intention. A paragraph exists. A test passes. A pull request is open. A source is verified. A decision is recorded. If nothing changed, note why. The problem may be the goal, the route, the duration, or the task itself.

Write the next result while the context is warm. Continue project is not a next goal. Resolve the two review comments and update the preview is. A sequence of visible results creates a trail that is easier to trust.

What the method cannot promise

Goal setting is not a cure for distraction. A browser boundary cannot manufacture motivation, guarantee flow, or control every device. The evidence on goals often comes from laboratory tasks. A 2024 study of sustained attention found that specific, difficult goals reduced long response time lapses in a four choice reaction task. That result is useful context for writing a specific goal. It is not proof that Focusward recreates the laboratory effect.

Do not remove rest because a timer makes you feel behind. A finite session is useful because it has an end, not because a long session proves character. Stop when the task is done or when continuing would be unsafe or unreasonable.

The route can fail for ordinary reasons. The goal may be too large. The source may be missing. The required account may be signed out. The chosen duration may be too short for the first action. Treat those failures as information. Change one variable at a time, then run another small session.

Do not let a blocked page hide a real duty. Keep emergency information, accessibility tools, account recovery, and urgent work reachable. If the project changes into an incident, end the focus session. A boundary is a planning aid, not permission to ignore a person or system that needs you.

Privacy is part of the boundary too. Focusward's local model keeps goals, domain lists, session history, and browsing information used for enforcement in Chrome local storage. License verification sends only the key and installation information needed for paid access. Read the current privacy policy for the full list and do the same for any competing tool.

A useful review asks one final question: did the route reduce a choice that was wasting attention? If yes, keep it for the next similar task. If no, remove the extra rule. A good boundary is not the most severe boundary. It is the one that leaves the necessary action visible and makes the next decision plain.

The boundary is a small promise

Write what will change. Keep the sites that can cause that change. Choose a finite time. Start with one action. Review the evidence. That is enough. A browser boundary is only a small promise to make the next useful choice easier.