LinkedIn Skills, rebuilt in an evening

July 2026 3 min read Figma → vibecoded prototype → this page Personal exploration. Not affiliated with LinkedIn.

Cleaning up my own Skills section, I hit the same wall three times: broken lazy loading, reordering buried in menus, and a card that hides its own proof. So I redesigned the flow — and built it. Try every iteration below.

01 — The problem

Three frictions in one screen

Loading that fights you. The list loads in chunks as you scroll — and chunks regularly fail. The only fix is a full page reload, then the same janky scroll again. There's no reason 30–50 short strings can't arrive in one response.

Reordering is hidden. Skill order matters — the top three show on your profile. Moving one means an overflow menu, a separate edit screen, and losing your place.

The card hides its evidence. A skill backed by four companies and twelve endorsements shows one grey square and one line of text. The strongest social proof on the page is invisible.

Fig. 1 — Current behavior, recorded from the live product. You can also reproduce it in the “Today” tab of the prototype below.

02 — Why it's probably like this

Steel-manning the current design

Before fixing anything — why would a team of this caliber ship it this way?

One list to rule them all. The lazy-loading list is almost certainly the feed's infrastructure, inherited for cost and consistency — not because 40 strings need pagination.
Server-driven UI. Profile blocks render from the server. Cheap A/B testing for the team; every edit becomes a round-trip for the user.
Editing is rare. Low-frequency surfaces lose prioritization fights, so friction accumulates.

All three are reasonable trade-offs. None justify a broken loading state — and the rest can be fixed within those constraints.

03 — The fix, in iterations

Try it — this is code, not a mockup

Every tab is a working prototype, not a mockup. Drag things. “Today” simulates the current failure so you can feel the difference.

01 · Explicit reorder mode

The full list loads at once — it's kilobytes of text. Two actions buried in the ⋯ menu get promoted to the header: reorder (arrows) and endorsement settings (people + gear). Tapping reorder enters an edit mode: check several skills and they drag as one group. Discoverable and safe; the cost is header space and a mode to enter and exit.

02 · Direct manipulation, no mode

The evolution: no button at all. Hover highlights the row, the cursor becomes a grab hand, the pencil brightens. You just drag — Ctrl/Cmd-click or Shift-click to move several at once. The cost is discoverability on touch — so mode 01 stays as a fallback.

03 · Chips for density

For 40+ skills, rows waste vertical space. Chips show the whole set on one screen, keep drag-to-reorder, and carry the endorsement count inside. A view option, not a replacement.

04 · The evidence row

Everything on one line: company logos as rounded squares with a count, endorsers as circular avatars with a count. Squares read as organizations, circles as people — the shape carries the information before you read a word. Direct drag stays.

04 — How I'd validate it

What I'd measure before shipping

Load reliability

Rate of “list never finished rendering” sessions. Target: zero by definition — one response.

Reorder completion

Time and success rate for “move skill X into top 3”: current vs. 01 vs. 02. Moderated test, then A/B.

Discoverability of 02

% who reorder unprompted within 30 s. Fails on touch → 02 desktop-only, 01 everywhere.

Evidence row impact

A/B on profile viewers: dwell on Skills, endorsement taps, messages sent. Hypothesis: visible proof lifts recruiter engagement.

Guardrails

Accidental drags (undone in 10 s), edit-screen entries, reloads on the Skills route.

On my own products I run this loop with Clarity for behavior and A/B experiments for outcomes — same method, smaller traffic.