I like sparse interfaces. My approach to design owes a lot to Danish functionalism, and I’m usually looking for something I can remove before I start adding another control. But a screen can look beautifully restrained whilst asking the person using it to do a surprising amount of work.

I’ve written about affordances before, and the argument gets a little abstract if we leave it at making controls easier to discover. I want to work through a small example instead: saving an article to read later.

The versions below are illustrative designs, not a usability study or a teardown of a particular product. They contain the same article and offer the same action. What changes is how much of that action they explain.

Saving an article

Imagine a reading list where each row shows a title, a source and a date. In the sparse version, a bookmark outline appears when you hover over a row. Press it and the outline becomes a filled icon.

That feels like a reasonable amount of interface if you already know what the icon does. You reveal it, press it, notice the change and move on. The article gets most of the space, which is what we wanted.

Now remove the assumptions. You haven’t used this product before, so you don’t know whether the bookmark means save, open saved items or add this article to a collection. Before you can decide, you need to find it. On a touchscreen, hovering isn’t available as a dependable way to reveal a control, so the design needs another route.

We could reveal it when the row receives keyboard focus too. That helps a keyboard user reach the action, but it doesn’t resolve the uncertainty about what the icon means. An accessible name helps someone using a screen reader; it doesn’t give a sighted reader the visible explanation we’ve removed.

For a more explicit version, put a small Save button beside the title. After activation it becomes Saved, and a nearby message offers Undo. The interface now gives the action a name, confirms its state and offers a way back.

The second version contains more visible information. I still think it asks less of someone encountering the task for the first time. They can read what will happen rather than reconstructing it from an icon and a change in fill.

That’s my judgement looking at these examples. I’d still want to watch people use them, because a label that seems helpful to me isn’t proof that the whole task has become easier.

Kevin Bonett made a useful point in response to this article (paraphrased here): explicit labels can take up more space whilst giving people less to work out. And if every article has a Save button, its accessible name needs to include the article title too, so someone using a screen reader or voice control can tell which article they’re saving.

What happens on the fiftieth visit?

The explicit version has costs too. A Save button on every row repeats the same word. Confirmation messages can interrupt reading, particularly if every press produces an announcement in a distant corner of the screen. A dense list may become harder to scan if every action competes with the article titles.

I’d keep Save visible and visually subordinate to the title. I’d show the saved state in the same place, so you can check it without moving your attention. Undo could appear beside that state for the immediate correction, with a persistent, discoverable Remove from saved action available afterwards. The short-lived message shouldn’t be the only route back.

If the product has a dedicated saved-articles view, it may need a different action label there. You’re already looking at saved items, so repeating Saved beside every one adds little. Remove would explain the available action more directly.

In that view, we already know the items are saved, so I can use the space to explain what somebody can do next. The context is doing some of the work the repeated label did before.

A control can be quick and familiar in one setting and baffling in another. We can’t settle that from an isolated component screenshot.

Remove the work as well

For this example, my revised version would retain the quiet layout, keep the action visible on every input method and use a short word to explain it. I’d remove the separate success toast if the local Saved state and Undo action communicate enough. I’d also avoid adding an explanatory tooltip that merely repeats Save.

I’d end up with a fairly quiet layout, a visible action and feedback close to where the person used it. There’s still some explanation on the screen, but fewer separate things asking to be read.

To check the result, I’d ask someone to save an article, find it again and remove it. I’d watch where they pause and what they expect the controls to do. Then I’d repeat the task with touch and keyboard input, and check that its state and actions make sense with a screen reader. Counting visible elements wouldn’t tell me any of that.

I’m still inclined to remove things. I just want to check what they were helping somebody understand before I take them away. It’s quite easy to forget how much I already know about an interface I’ve been designing.