Ask
23

Rounded corners versus the smoother continuous kind — is there a real difference or is it just fashion?

Designing a mobile interface and I have started using the smoother, more gradual corner shape everywhere instead of a plain rounded rectangle. It looks better to me. The transition into the straight edge is less abrupt and the whole thing feels calmer.

But I cannot articulate why beyond that, and "it looks nicer" is a weak position to defend in a review. It is also clearly a trend — platform design languages have moved this way, and I may simply be responding to what I have been looking at.

Is there anything functional underneath, or is this purely aesthetic and I should stop trying to justify it?

5 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @frontend_felix · 4d ago

    The practical consideration that usually decides it: cost.

    A plain rounded corner is one CSS property, it is what every component library ships, it is what your design tokens already express, and every engineer implements it identically without thinking.

    The smoother version needs either a platform that provides it natively, or a clipped path or SVG per component, plus a decision about what happens at every size and every nesting level. That is not enormous, but it is a permanent tax on every new component, and in my experience it gets applied inconsistently within about two months — some things smooth, some things not, which looks worse than either alone.

    If your platform gives it to you for free, take it. If it does not, be honest that you are buying a subtle improvement with an ongoing maintenance cost.

    20
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @wireframe_wren · 6d ago

    There is something real underneath, though it is smaller than its advocates claim and it is about perception rather than usability.

    A plain rounded rectangle joins a circular arc to a straight line. The curvature jumps from a constant value to zero at that join — the shape is continuous but the rate of turning is not. The eye is quite good at picking that up, and it reads as a slight tightness or pinch at the point where the corner ends.

    The smoother variant blends the curvature in gradually so there is no discontinuity. That is why it looks calmer to you, and why the effect is strongest at large radii: the bigger the corner, the more visible the join.

    So you can defend it in a review with something better than taste: it removes a curvature discontinuity, and the effect scales with radius. What you cannot claim is that anyone completes tasks faster.

    26
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @research_rosa · 3d ago

    The functional argument for rounding at all is well established and worth separating from the argument about which kind of rounding.

    Corners are visually noisy — a sharp corner is a high-contrast point that draws attention, and an interface full of them has attention scattered across every element boundary. Rounding reduces that, which is part of why rounded interfaces feel less busy. There is also a plausible claim that rounded shapes are read as friendlier and less threatening, which shows up consistently enough in preference studies to be worth knowing.

    Between the two rounding styles, though, I have never seen a difference in any measure I care about. Nobody misses a button because its corner has a curvature discontinuity.

    So: rounding is defensible functionally, the choice between roundings is defensible aesthetically, and being clear about which claim you are making is what will get you through the review.

    22
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @corner_radius_cato · 4d ago · 2 replies

    The consistency point is the one that will actually decide this for us. A design system where half the components have one corner treatment is worse than either option applied uniformly, and I can already see which way that would go.

    11
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @frontend_felix · 5d ago

      It always goes that way. The rule I use now is that any visual property which cannot be expressed as a single token is a property the system will eventually apply unevenly.

      7
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report