LinkedIn Post Ideas for UI Designers

Set a timer. 60 minutes. Redesigned Instagram's profile screen from scratch. Not because it's bad — it's actually well-considered. But constraints make for a good exercise, and unsolicited redesigns teach you more about your own defaults than any tutorial. What I changed: — Bio section: collapsed the link-in-bio pattern into a single scrollable card row instead of one static link. Small thing, but it matches how creators actually use that space now. — Grid: swapped the 3-column photo grid for a 2-column masonry option, toggle at the top. Vertical content gets crushed in a 3-column square grid; masonry respects aspect ratio. — Stats row: moved follower count from a tap-to-see-list pattern to inline preview avatars, so you get social proof without a tap. What I didn't change: the core navigation, the story ring, the overall visual language. Redesigning everything is easy and useless. Redesigning three specific decisions and explaining why is the actual skill. The exercise isn't about Instagram needing my help. It's a forcing function — an hour is enough time to notice one real flaw and not enough time to overthink it into mush. Try it on an app you use daily. Sixty minutes, three changes, explain the why.

Our design system had 340 components. I audited actual usage across every product surface. 61 components were used in more than five places. 279 were used once, twice, or not at all — built for a specific feature, never generalized, never reused, just sitting in the library collecting maintenance debt. Every one of those 279 still had to be documented, still showed up in autocomplete, still confused new designers deciding which button variant to use. The system wasn't helping consistency. It was actively working against it, because "which of these twelve button styles is the real one" is a worse question than having three honest options. We deleted 210 components in one sprint. Kept 130, including a few used-once components that mapped to genuinely distinct, recurring patterns we expected to need again. The team's velocity on new features didn't slow down. It sped up, because picking a component stopped being an archaeology exercise. Bloat doesn't feel like a problem while you're building it — every component felt justified in the moment it was created. It only shows up as a problem eighteen months later, in the audit nobody wants to run. Run the audit. Delete more than feels comfortable.

Every spacing value in our product is a multiple of 8. Here's the one screenshot I use to explain why to every new hire. [Annotated card component: padding 16px, gap between elements 8px, icon-to-text gap 8px, section margin 24px, card-to-card gap 32px] The rule: 4, 8, 16, 24, 32, 40, 48, 64. Nothing in between, ever, in production. Why 8 and not some other number: it divides cleanly across common screen densities (1x, 2x, 3x), which means less sub-pixel rendering weirdness across devices. It's also small enough to feel intentional at the micro level (icon gaps) and scales cleanly to macro spacing (section margins) without needing a second system. What breaks when you skip it: a designer eyeballs "looks about right" at 13px here, 19px there. Multiply that across 50 screens and three designers, and your product develops a spacing dialect nobody can articulate but everyone can feel — vaguely inconsistent, slightly off, hard to pin down. The grid isn't a creative constraint. It's a shared vocabulary that lets three designers and twelve engineers all produce the same 8px gap without a single conversation. Screenshot this, pin it in your team's design channel.

Dark mode estimate: three days. Actual time: three weeks. Here's exactly where it went sideways: Week 1, day 1-2: swapped our color hex values for a dark palette. Looked done. Shipped to staging. Week 1, day 3: contrast checker flagged 40+ text/background pairs failing WCAG AA. Our light-mode grays, inverted naively, produced text at 2.8:1 contrast in several states. Had to rebuild the neutral scale from scratch for dark, not just invert it. Week 2: semantic tokens. We'd been hardcoding hex values in components instead of using tokens like "surface-primary" and "text-secondary." Every hardcoded value was a place dark mode silently broke. Rebuilding the token layer took four days alone. Week 2-3: edge cases nobody scoped. Chart colors that worked on white washed out on near-black. Elevation, which relies on light contrast, needed a completely different treatment — dark mode uses lighter surface layers to show elevation, not shadows. Week 3: images and icons with baked-in white backgrounds. 60+ assets needed transparent or dark-aware versions. The three-day estimate assumed "swap the palette." The real work was "build a token system we should have had already." Dark mode didn't create the debt. It exposed it.

The oldest joke in design: client asks for a bigger logo. Mine actually asked. I said yes without an argument, and here's why. Their homepage hero had a logo at 120px wide, floating in a sea of whitespace above a headline that took three seconds to read. The client's instinct — "it feels small, make it bigger" — wasn't about ego. It was about hierarchy. The logo was competing with nothing, but it also wasn't anchoring anything. It read as an afterthought, not a brand. I bumped it to 180px, added a thin baseline rule beneath it, and tightened the vertical rhythm of the header so the logo felt load-bearing instead of decorative. Client's reaction: "yes, exactly that." Not because bigger equals better. Because "bigger" was their imprecise word for "give this more presence," and my job was translating the request, not overriding it. The instinct to reflexively resist client feedback is its own kind of ego. Sometimes the client is pattern-matching on a real problem with the wrong vocabulary. Ask what "bigger" is actually trying to fix before you decide whether to push back. This one took ten minutes and earned more trust than any pixel-perfect deliverable that quarter.

Five interfaces I'd call beautiful. All five fail basic accessibility. Here's what's hiding in plain sight. 1. Low-contrast gray text. That elegant #999 on white looks refined. It's 2.85:1 contrast — fails WCAG AA's 4.5:1 minimum for body text. Beautiful and unreadable aren't mutually exclusive; they're often the same design decision. 2. Icon-only buttons with no label. A trash can icon deleting your account with zero text confirmation. Screen reader users hear "button" with no context. Sighted users guess from convention, which fails the moment the icon isn't universal. 3. Hover-only interactions. Tooltips, secondary actions, entire menus that only appear on mouse hover. No touch equivalent, no keyboard equivalent. On mobile, that feature doesn't exist. 4. Focus states removed for aesthetics. `outline: none` with nothing to replace it. Looks cleaner in a screenshot. Makes the interface unusable via keyboard, which isn't an edge case — it's a legal requirement in most jurisdictions for public-facing products. 5. Color as the only signal. Red text for errors, green for success, no icon, no pattern difference. Roughly 1 in 12 men have some form of color vision deficiency. That's not a niche audience. None of these require redesigning anything. They require checking before you ship. Run a contrast checker and a keyboard-only pass on your next release.

Prompted Figma's AI to generate a pricing page. Here's the before and what I fixed. What it got right, fast: layout skeleton, three-tier card structure, reasonable default spacing, a CTA hierarchy that wasn't embarrassing. Ten seconds versus the twenty minutes I'd have spent blocking out the same skeleton by hand. What I had to fix: — Typography scale was generic — not our type system's actual scale, just plausible-looking sizes. Swapped every text layer to our real tokens. — The "most popular" tier had no visual distinction beyond a badge, when our actual users need scannable price-to-feature comparison at a glance. Added a highlighted border and reordered the feature list to lead with differentiators. — Feature list icons were decorative, not semantic — same checkmark regardless of whether the feature was included or excluded from a tier. Had to rebuild that logic entirely. — Copy was structurally fine, tonally generic. Every line needed our actual voice. Net time saved: maybe 15 minutes on a task that would've taken 30. Not nothing. Also not the "10x design" the demos imply. The tool is a fast first draft generator. It doesn't know your design system, your users, or your voice. That part's still entirely on you — and probably always will be.

Every icon in our product goes through the same six steps before it ships. Here's the actual pipeline, not the idealized version. 1. Rough sketch on paper or an iPad, five to ten thumbnails per concept. Digital-first icon design skips too quickly to "close enough." 2. Build on a 24x24 pixel grid in Figma, keyline shapes only — square, circle, rectangle bounds — so every icon in the set shares consistent optical weight. 3. Stroke width locked at 1.5px across the entire set. Mixed stroke widths is the single most common reason an icon set looks amateur, even when individual icons are well-drawn. 4. Optical alignment pass. Mathematically centered icons often look off-center to the eye — a play triangle needs to shift right of true-center to read as balanced. This step is manual, no shortcut. 5. Export as SVG, run through SVGO to strip metadata and redundant groups. Unoptimized exports from Figma routinely carry 3-5x more code than needed. 6. Component in Figma with a size prop (16/20/24) and a stroke-width-scaling rule, so the icon doesn't just scale — it stays visually consistent at every size it'll actually ship at. Skipping step 4 is the most common shortcut I see, and it's the one that's most visible in the final product.

Before any file goes to engineering, I run this six-point typography check. Takes ten minutes, catches most of what would've come back as a revision. 1. Line height. Body text needs 1.4-1.6x font size. Headlines can go tighter, 1.1-1.2x, but check for descenders (g, y, p) getting clipped at tight leading. 2. Optical alignment. A quote mark or bullet at the start of a line needs to hang slightly outside the text block margin, or it reads as misaligned even though it's mathematically flush. 3. Rag. Ragged-right text shouldn't create a shape — no single short line stranded alone, no line dramatically longer than its neighbors. Manual line breaks fix this in headlines; body copy needs width adjustments. 4. Minimum sizes. 12px absolute floor for any UI text, 14px preferred for anything read for more than a glance. Below that, you're excluding real users, not just being minimalist. 5. Contrast per size. Smaller text needs higher contrast to stay WCAG-compliant — the ratio requirement is stricter below 18px than above it. Easy to miss if you're checking contrast once at the design-system level, not per instance. 6. Widow and orphan check. A single word alone on the last line of a paragraph. Ugly, fixable with a non-breaking space or a slight rewrite. Checklist items get bookmarked because nobody remembers all six under deadline pressure. I don't either — that's why it's written down.

Debate time: which app has the best empty state, and why? Mine: Notion's empty page. Not flashy — just a cursor, a faint placeholder prompt, and a slash-command hint. It does the one job an empty state actually has: tell the user what to do next without making them feel like they've done something wrong. Compare that to the empty states that just say "No items yet" with a sad illustration. Cute, but it answers a question nobody asked (what happened) and skips the one that matters (what do I do now). The best empty states I've studied share three things: a clear next action, not just a status message; tone that doesn't apologize for the emptiness like it's a failure state; and they teach a feature the user hasn't discovered yet, using the empty moment as onboarding rather than wasting it. Duolingo's empty streak state does this well too — it reframes "zero" as "start today" rather than "you failed yesterday." Drop your pick below, screenshot if you've got one. I want to see the ones that turned nothing into onboarding instead of an apology.