Small UX details that real products teach you

The overlooked parts of UX: words, states, handoff, QA, accessibility, and real product constraints. These are the small details that do not look big in Figma, but decide whether the product feels clear in real use.

By Devendra SinghNotes between me and myself
  1. I used to think UX was the main flow.

    Onboarding, checkout, player, profile, all the important screens.

  2. The main flow matters.

    But real products are tested in the small moments around it.

    The button label. The empty state. The loading screen. The error message. The long title that breaks the card.

  3. That sounds like polish.

    Important, but still polish.

  4. It becomes product quality very fast.

    A button that says "Start your journey" may look nice, but the user still has to guess what happens next.

    A button that says "Listen to your first episode for free" does more work.

    Same layout. Better decision for the user.

  5. So words are design?

  6. Yes. Users do not use rectangles. They read what the rectangle says.

    Before making the screen pretty, ask what the user needs to know first, what action they should take, and what words may create doubt.

  7. What else should I check early?

  8. Use real content as soon as possible.

    Fake content makes weak layouts look safe.

    A show title looks clean when it is one line. Then the real title becomes three lines and the whole card starts fighting for space.

  9. And the weird states?

    Loading, empty, failed, no internet, that kind of thing?

  10. Design them like product screens, not leftovers.

    If there is no data, explain why. If payment fails, show the next step. If upload stops, keep the file name and let the user retry.

    The happy path is only one version of the product.

  11. Where does accessibility fit in this?

  12. It is basic hygiene.

    Can people read the text? Can they tap the control? Does the state work without color alone? Does the screen survive sunlight, a small phone, and one hand?

    A low-contrast screen may look premium in Figma and fail in real life.

  13. When should engineering come in?

  14. Before the design starts pretending everything is easy.

    Ask if the data loads fast enough, if the component already exists, what happens when the API fails, and what is expensive.

    Users do not use the Figma file. They use what gets built.

  15. So the small stuff is not small.

  16. Exactly.

    Write real content early. Test long text. Design loading, empty, error, and success states. Bring engineering in early. QA the built product.

    The main flow is the center. The full product is everything around it.