Web Design for Shared Devices: When AI Must Forget the Last Visitor

A useful AI assistant can become a privacy problem the moment somebody leaves the screen. That is a Web Design problem as much as an AI Development problem. Whether your work sits in Web Development, Website Design, or Web AI, you need to account for the person who uses the device next.

Picture a tablet at a property showroom. A visitor asks whether their income would qualify them for a particular rental, then leaves to speak with an agent. The next visitor taps the chat bubble and finds the whole conversation waiting.

Nothing spectacular went wrong. There was no clever attack and no stolen password. The website simply behaved as though a browser belonged to one person, which is an assumption we make far too casually.

Web Design needs a shared-screen assumption

We tend to imagine website visitors sitting at their own laptops, with their own accounts and their own browser history. Plenty of real visits happen on family computers, reception tablets, borrowed phones, school laptops, and machines in public libraries. Even a personal laptop can become a shared device when someone turns it around during a meeting.

AI makes the consequences more interesting because people type things into a helpful conversation that they would never put into an ordinary contact form. They explain a financial worry, paste an internal email, or upload a document because the interface seems ready to help. A friendly text box can collect a surprisingly personal story in three minutes.

My starting position is simple: unless the product has a good reason to know otherwise, it should not assume that the next interaction belongs to the same person. That does not mean deleting everything after every click. It means treating continuity as a deliberate product decision rather than a convenient default.

Decide which environment you are actually designing for

A public information kiosk needs different behavior from an account-based research tool. On a kiosk, a fresh start should be the normal state. In a private workspace, retaining a draft may be exactly what the user expects.

I would write that distinction into the brief before discussing the chat window’s shape or color. If a business plans to put the feature on a reception tablet, that is a separate usage mode, not a small responsive adjustment. The session rules, saved history, and timeout behavior all need their own decisions.

Separate conversation, identity, and storage

One mistake I watch for in AI Development is treating the conversation as a single object with a single lifetime. In practice, several things are happening at once. There is what appears on screen, what remains in the browser, what the server retains, and what an external AI service receives.

Clearing the visible messages does not necessarily clear any of the other three. A page can look empty while its browser storage still contains the previous upload name or its backend still accepts requests for the old conversation. The interface needs a real session boundary behind it.

A blank chat is not proof of a fresh session

Suppose a visitor uploads a lease called “Morgan rental agreement.pdf” and asks for an explanation. After they press “Finish,” the messages disappear, but the attachment picker still shows the filename. That small leftover detail is enough to expose something the next visitor should not see.

The practical Web Development task is to map every place where session material can live. That includes input drafts, upload previews, generated download links, browser storage, and conversation identifiers. It also includes server authorization: knowing an old conversation ID must not be enough to reopen it.

I like a concrete acceptance test here: finish one session, start another, then try every ordinary route back to the first. Use the back button, reopen the widget, refresh the page, and follow an old link. The product should behave according to a documented rule, not whatever each component happens to remember.

Give people an unmistakable way to finish

A small close icon is not an adequate ending for a sensitive conversation. Most people reasonably interpret it as “hide this panel,” not “end my session and remove access to my information.” Good Web Design should not ask them to guess which interpretation the developer intended.

For a shared-device mode, I prefer a clearly labeled “Finish and clear this session” control. Its supporting text can explain the immediate effect in plain language: messages and uploaded files will no longer be available from this screen. Any separate retention policy belongs in a short, accessible explanation nearby.

Keep the promise narrower than the implementation

Do not label that control “Delete everything forever” unless you can actually honor that promise across backups, operational logs, vendors, and retained records. Usually, you cannot make that guarantee instantly. Ending access and completing data deletion are related operations, but they are not the same operation.

A useful confirmation might say, “Your session has ended. This device can no longer open your conversation.” If some records remain for a defined period, explain that honestly rather than borrowing the comforting language of permanent erasure.

The finish action also needs to handle work that is still running. An answer arriving two seconds later must not repopulate the screen after the session has closed. The server should stop accepting further work under that session, while the client ignores any late responses associated with it.

Make inactivity rules visible before they matter

Automatic timeouts sound straightforward until someone pauses to read a long answer. A person comparing insurance options may spend several minutes looking at paperwork without touching the screen. A timer that treats that silence as abandonment can erase useful work while they are still present.

This is where Website Design needs a little restraint. Choose an inactivity period that fits the setting, then explain it before the person invests effort. On a public tablet, a short message near the conversation could say, “For your privacy, this session clears after a period of inactivity.”

The exact timing should come from the actual environment, not a number copied from another product. A busy reception area and a supervised consultation room have different risks. Test the timing with realistic reading and document-handling tasks.

Warn without making the warning another obstacle

Before clearing a session, show a noticeable warning with a simple way to continue. Give people enough time to respond, and make that response work without precise tapping or a mouse. Accessibility requirements still apply when a security feature is inconvenient to implement.

There is a useful balance here: the warning should not expose the conversation more widely. Avoid reading sensitive answer text aloud as part of a timeout announcement, for example. A neutral message about the session ending is enough.

Reduce what a bystander can learn

Not every shared-screen problem happens after somebody leaves. Sometimes the wrong person is standing three feet away while the answer appears. Web AI interfaces often make this worse by turning a short question into a large block of highly specific personal information.

Imagine someone asking an assistant to explain a utility bill at a service counter. The system may need the account address to find the right record, but it probably does not need to repeat that full address in a large heading. Showing less can be a better design decision than adding another privacy notice.

I would review generated answers for unnecessary repetition of names, addresses, account numbers, and uploaded document titles. This is not a promise that a model will always redact perfectly. It is a combination of limiting the data sent to the model, controlling structured output where possible, and checking what the interface chooses to display.

Use neutral labels outside the conversation

Browser tab titles and navigation labels deserve attention too. “Your assistant session” reveals less than a title generated from someone’s question about debt or a medical appointment. The same principle applies to recent-session menus and notifications.

This is one of those quiet Web Design choices that rarely appears in a portfolio screenshot. It matters anyway. A discreet label can prevent disclosure without asking the user to understand a single setting.

Test the next visitor, not just the current one

Most feature testing follows one person from opening the page to getting an answer. For shared devices, the more revealing test begins when that person stops. Hand the device to someone else and ask what they can discover without doing anything unusual.

For a Web Development test session, I would create a fictional visitor with a recognizable name, a fake document, and a distinctive question. Then I would finish the conversation and let a second tester explore the page. The recognizable details make leftovers easier to spot than a screen full of placeholder text.

Try interrupted endings as well as tidy ones. Disconnect the network while the finish request is running, close the tab before confirmation arrives, or let an answer complete during the timeout warning. These are ordinary browser conditions, not exotic edge cases.

Check the paths outside the main window

A downloaded file may remain in the device’s downloads folder even when the website session is gone. A printed answer may sit in a printer tray, and browser-managed autofill may retain information outside the application’s control. The website cannot honestly promise to clean up every trace on a device it does not manage.

For a public installation, that means the surrounding setup matters. Managed browser profiles, restricted downloads, and device administration may be necessary alongside the application. The feature team should be clear about which protections belong to the site and which require control of the hardware.

Make remembering a choice, not a surprise

There are perfectly good reasons to preserve an AI conversation. Someone may want to return to a complex explanation tomorrow or keep working through a document next week. Privacy does not require making every useful feature forgetful.

The distinction is whether the person understands where that continuity lives. “Save to my account” is a more meaningful choice than quietly storing history in whichever browser happens to be open. On a public device, saving should not leave the account signed in for the next visitor.

For teams building Web AI products, this is also a coordination problem. The designer cannot solve it with a reassuring sentence if the backend keeps accepting old session credentials. Equally, careful server controls will not help someone who mistakes a hide button for a secure ending.

The AI Development brief and the Website Design brief should therefore share the same session rules. Define what starts a session, what ends it, what can be recovered, and what remains stored. Then make the interface tell the same story the software actually implements.

A good ending is part of the product

I think we spend too much time polishing how an AI assistant introduces itself and not enough time deciding how it leaves. The greeting gets the friendly copy and the animation. The ending gets an icon tucked into a corner.

Thoughtful Web Design gives both moments proper attention. A visitor should be able to ask for help, use the answer, and walk away without wondering whether the next person can read over their shoulder after they have gone.

Before shipping a shared-device experience, I would put one question on the final review agenda: what exactly does the next visitor inherit? If the answer is anything more than a clean, clearly explained starting point, there is still design work to do.