What you’ll make
One feedback spec for a control that leaves people guessing.
Did that save to your shortlist?
Two small fixes for a sound-effects library
Say you’re picking sounds for a video. You tap ‘Save to shortlist’ and the page sits there. When you open a track preview, the card grows while you reach for Play. Here’s how I’d handle those two moments.
Save button
Saving… → Saved
- Show ‘Saving…’ right away. When the track is saved, show ‘Saved’ and fade in a check mark over 160 ms.
- On failure, show ‘Couldn’t save. Try again.’ and keep the button usable.
- With reduced motion, the check mark appears immediately.
Preview button
Show preview → Hide preview
- Put Play above the panel so the control stays put. Open the panel at full height and fade in the waveform.
- With reduced motion, show the waveform and the same label immediately.
Before you start
- Open a working copy of your page and record two things people do. Pick actions with a clear before and after, like saving an item or opening a preview.
- Try the controls as they are. Tab to each one and watch what happens when you use it, wait for a response, or hit an error.
Find one confusing click
Pick one control you’ve used yourself. Write down what you expected after clicking and what appeared while you waited. Attach a screenshot or recording if it helps.
Write down the feedback it needs
Open a Claude chat, paste the prompt below, and send it with your notes or capture. Ask for wording and behavior you can check on the page.
Write a small feedback spec for one control
Use the details I provide in this chat or in my attachments. Write one spec I can implement for the control I describe. Give the trigger, exact visible text for each supported state, what should be announced, and where keyboard focus stays. If motion helps, choose one small effect and give the equivalent reduced-motion behavior. Keep the control in place and preserve how it works today. Finish with one before-and-after check. Ask if the action or supported states are unclear.
Save the spec beside the control
Read the proposed status text out loud and keep the small effect you can explain. Record which state changes the message and what stays in place.
I describe how Save to shortlist goes quiet after a tap.
The spec might show ‘Saving…’ immediately and ‘Saved’ with a small check when it finishes. With reduced motion, the check appears without a fade.
Follow the states yourself
Trace a slow response, a success, and a failure through the spec. If you already have a preview, try each state with the keyboard before you save your notes.
- Point to the message for each supported state.
- Check where focus stays after you use the control.
- Find the same feedback with reduced motion on, or confirm it in the spec.
Optional: Try the control with motion off
Turn on reduced motion and try the same action. Make sure the text or icon still tells you when it’s saving, when it worked, and what you can do if it fails.
Give these controls clearer feedback
Start with your baseline and two unclear moments to write the behavior you’ll build and test.
Here are my page or component files and a short recording: [inputs]. These are the two actions where I’m unsure what happened: [moments]. Here’s something I liked on a similar control: [observation]. If you can’t inspect the page, work from the recording or description and mark where I’ll need to confirm the current behavior. Write one short spec per control. Give me the trigger, visible text, accessible feedback, effect property and duration, and what appears with reduced motion. Include keyboard focus and the states this action actually has, such as waiting, success, or failure. Keep the native input and its target area usable, and show where you’d reserve space if a label changes length. For each spec, give me one quick before-and-after check. Tell me which file or component to start in if I supplied the code.
Check what happens when I use it
Once the changes are in, share the update and your test notes to find feedback that still falls through.
Here’s what changed and what I observed in the browser: [files, recording, or notes]. Compare it with [baseline and motion spec]. Check each action with mouse, touch, and keyboard, including reduced motion. Use [expected result] to judge a slow request, a failed request, and two quick taps if the action uses a request. Look for a lost focus ring, stale status text, a confusing accessible name, or a target that moves. Give me one row per problem with viewport and input, steps to reproduce, expected and observed result, and a small fix. Label anything you can’t verify as a test for me.
Optional worksheet: Website microinteraction worksheet
Fill this in as you go. Keep this page open while you work. Reloading it clears your answers.
Troubleshooting
Why does a card stay lifted after a tap?
Apply the hover effect only when the device supports hover. Then try the touch press and keyboard focus on their own. Test on the phone where you saw it stick if you have it handy.
The button shifts sideways between labels. How do I stabilize it?
Leave enough room for the longest label, or give the status its own spot next to the button. Try the loading, saved, and error messages at phone width with the real words.