Designing for the Second Visit

The first visit is a performance. The hero animation lands, the gradient behaves, the onboarding tour points at the right button. The second visit is a different product entirely. The user already knows what the app does. They came back because something was unfinished, and they want to finish it without being entertained.

Most interface work is optimised for the first visit. The second visit is where retention actually lives.

The first visit is a demo

A demo is a controlled sequence. The data is seeded, the network is fast, and the empty state has never been seen. The second visit has none of those advantages. It has a returning user, partial data, a different device, and a memory of what the app looked like yesterday.

That changes the questions:

• Does the app remember where I was?
• Is the thing I came back for still there?
• Did the interface change while I was gone?
• What happens if I start on my phone and finish on my laptop?
• Can I get back to the one screen I actually use?

These are not polish. They are the product’s ability to be a habit.

What the second visit needs

A return path. The fastest route back to unfinished work should be on the first screen after login. Not a notification that says “continue where you left off” with a modal in front of it. The work itself, with a direct link.

Saved state. If a user has typed half a paragraph, the app should know. If they filtered a table, the filter should survive a refresh. If they opened a detail panel, the back button should return to the list they came from. State is a form of respect.

Speed on the common path. The second visit is usually the common path. If the dashboard takes four seconds to load every morning, the first visit was a lie. Performance work should start from the route a returning user takes most often, not the landing page.

Memory without noise. A recently viewed list, a saved view, a small “last edited” label. These are quiet conveniences. They should not become a dashboard of their own.

Graceful failure. The second visit is more likely to hit an error because it is doing real work. A failed save should keep the draft. A failed load should keep the last good state. The interface should never punish a user for coming back.

The empty state is the first return

The empty state is usually designed as a welcome mat. It should also be designed as a return path. The best empty states do three things: explain what will appear here, give one action that creates it, and show what a populated version looks like.

A good empty state is a small contract: this is the shape of the thing you are about to make. A bad one is a mascot and a sentence about how “there’s nothing here yet.”

A small example: saved state

The technical version of “remember where I was” is usually less work than it looks. For a client-side view, a URL is the best state container: filters, sort, selected tab, and page number belong in query parameters. The user can bookmark, share, and use the back button.

For unsaved input, a draft store is enough:

const key = `draft:${documentId}`;
 
export function useDraft(documentId: string) {
  const [value, setValue] = useState(() => {
    return localStorage.getItem(`draft:${documentId}`) ?? "";
  });
 
  useEffect(() => {
    const id = window.setTimeout(() => {
      localStorage.setItem(key, value);
    }, 400);
 
    return () => window.clearTimeout(id);
  }, [key, value]);
 
  return [value, setValue] as const;
}

The details matter: debounce the write, clear the draft after a successful save, and never make the draft the source of truth on the server. The point is to protect the user’s unfinished thought, not to build a second database in the browser.

The second visit is a design constraint

Designing for the second visit changes what you remove. The onboarding tour is less important than the keyboard shortcut. The celebratory confetti is less important than the error message that keeps the form filled in. The illustration is less important than the fact that the page loads at 8:55 a.m. on a phone with two bars of signal.

A useful exercise: take the screen a returning user sees most often and remove everything that only makes sense on the first visit. Then check whether the screen still explains itself. If it does, the interface has a chance of becoming a habit.

The first visit gets the screenshot. The second visit gets the user. Design for the one that comes back.