LinkedIn Post Ideas for Heads of Design

We redesigned our core onboarding flow eighteen months ago. Every design metric we track moved in the right direction: task completion up 14%, time-on-task down 22%, satisfaction score up from 7.1 to 8.4. Conversion to paid: flat. Exactly flat, within noise, for the following two quarters. I had to walk this into a QBR with our CRO watching, and the instinct in the room was to defend the redesign on the metrics that moved. I didn't. I said plainly: we made the experience better and it didn't make the business better, and here's why I think that happened. What we found digging in: the friction we removed wasn't the friction blocking conversion. Users were completing onboarding faster and more happily, then hitting a pricing page that hadn't changed, with an ROI case that still wasn't clear for their specific use case. We'd polished the wrong stage of the funnel. The redesign wasn't wasted — a smoother, more satisfying product is worth something on its own, and it's helped retention modestly since. But I stopped presenting UX metrics as business metrics that quarter, and I built a rule for my team: every redesign proposal now has to name the business metric it's targeting before we touch a single screen, not after. Aesthetics and outcomes diverge more often than design leaders admit publicly. Naming that divergence honestly is what earns you the next redesign budget.

I told our CFO our design system would pay for itself in a year. It took closer to two, and I want to own that miscalibration because I still hear leads pitch the one-year number to their execs. Year one, real cost curve: building the initial component library took four designers roughly 30% of their time for two quarters. Adoption fights ate the rest of year one — three product lines had existing patterns they were reluctant to abandon, and every migration conversation was a negotiation, not a rollout. The maintenance tax nobody warns you about: a design system isn't done at launch, it's a permanent 15-20% allocation of design and engineering time to keep it current across every product line using it. I underbudgeted this by roughly half in my original pitch. When ROI actually arrived: month nineteen. That's when net-new feature design time across our three product lines dropped measurably — components engineers could pull directly, review cycles shortened because designers weren't relitigating spacing and color on every screen, and cross-line consistency stopped requiring a dedicated QA pass. What I tell other design leaders pitching this to their exec team now: budget two years, not one, and be explicit that year one is a cost center with no visible return. The system that finally pays off is the one where leadership didn't get surprised by the slow start, because you told them upfront. Oversold pitches cost design credibility at the exact table where it's hardest to rebuild.

Five minutes is the actual budget I get in front of our exec team for any design review. Here's the structure that survives that constraint. Minute one: the business problem, not the design problem. Not "our checkout flow feels dated" — "checkout abandonment on mobile is costing us an estimated $340K a quarter, concentrated at step three." Minutes two and three: exactly two options, never three or five. More options reads as "we haven't decided," and executives read indecision as risk. I show the option we recommend and the strongest alternative, with the tradeoff named in one sentence each. Minute four: the ask, stated as a decision, not a request for feedback. "We're asking you to approve option A, which requires two weeks of engineering time" — not "what do you all think?" Minute five: questions, and I answer in the same register the room is used to — dollars, timelines, risk — never in design vocabulary. I never explain our tools, our process, or our craft rationale unless someone asks directly. What I cut to get here: no walkthrough of alternatives we rejected, no process narrative, no "we explored twelve directions." That's real work and it matters to my team, but it doesn't belong in the five minutes that decide whether design gets funded next quarter. The skill that gets design a seat at the table isn't better taste. It's ruthless editing of everything except the business case.

Our support team was fielding roughly 800 tickets a month tied to one confusing settings flow — the single largest ticket category outside billing. I made a case to redesign it purely on support cost, not aesthetics, because that's the language that gets budget approved at our company. Estimated fully-loaded cost per ticket, including agent time: $14. That flow alone was costing roughly $11,200 a month before any escalations. We redesigned it with one target: reduce the specific support ticket tags tied to this flow. Not "improve the settings experience" — that number, that flow, that tag. Three months post-launch: ticket volume on that flow down 31%. Translated to the same cost basis, roughly $3,470 a month in avoided support cost, or about $41,000 annualized, against a redesign that took six weeks of one designer's time. I presented this exact framing — cost avoided versus design hours invested — to our COO, not a before-and-after screenshot comparison. It's the first design project that got proactively referenced in a board deck by someone outside my team. What made this repeatable: we now tag every redesign proposal with an estimated support-cost hypothesis before starting, so we can measure against a real prediction instead of describing improvement after the fact, in whatever terms make the outcome look good. Design earns budget by publishing numbers finance already trusts, not by publishing better screenshots.

I've sat on senior design hiring panels for six years, across two companies, representing design at the VP level. The single most common reason a strong-looking portfolio doesn't clear senior: it's a gallery of screens, not a record of decisions. What that looks like in practice: a candidate walks me through a beautiful final flow and, when I ask "why this direction over the alternative," they either don't have an alternative to describe, or the answer is a preference, not a rationale tied to a business or user constraint. What I actually probe for now, three questions every review: What did you reject, and why? What would you have done with half the time or double the budget? Who disagreed with you, and how did that get resolved? The candidates who clear senior on my panels aren't always the ones with the most polished final screens. They're the ones who can narrate a decision the way I'd need to narrate it to our exec team — problem, options considered, tradeoff, outcome, what I'd change knowing what I know now. This matters more at the senior level specifically because senior designers are the ones I need to eventually represent design work to non-design stakeholders without me in the room. If they can't articulate the decision to me in an interview, they won't be able to defend it to a skeptical VP six months into the job. Screens show craft. Decisions show whether someone's ready for the table.

Our critique format looks different depending on the room, and that's deliberate — the version I want to talk about here is the one we run with cross-functional stakeholders in it, not the internal team version. Rule one: problem statements first, always, before anyone sees a screen. Whoever's presenting states the business or user problem in one sentence. If a stakeholder can't repeat that problem back in their own words two minutes later, we pause and re-state it. Rule two: feedback comes as questions, not verdicts, especially from non-designers in the room. "What made you choose this layout over showing both options side by side" gets a real answer. "I don't like this" gets redirected to "what specifically feels off, and what would need to be true for it to feel right." Rule three: no pixel-pushing from anyone above the level actually executing the work. If an exec wants a font changed, that's fine, but it doesn't happen live in the room — it goes to the designer to weigh against the actual problem statement, not adopted on the spot because of who said it. What this format buys us: stakeholders who sit in these leave understanding the tradeoff, not just the outcome, which means they stop relitigating decisions three weeks later in a hallway conversation instead of in the room where the reasoning was live. Critique that includes the business side of the table needs different rules than critique among designers alone.

Across three product lines, six months of AI-assisted design tools, and the pattern I didn't expect: they made our volume work faster and our judgment work slower. Faster: first-pass exploration on well-scoped, low-ambiguity screens — settings panels, standard form flows, marketing landing page variants. What used to take a designer half a day of exploration now takes 90 minutes, and the output is genuinely usable as a starting point roughly 70% of the time. Slower, and this surprised me: our highest-stakes work — the core product experience that differentiates us across all three lines — actually took longer with AI tools in the loop. Designers were spending review time evaluating AI-generated options that looked plausible but didn't hold up against our actual design principles, then having to articulate why to justify discarding them. That justification overhead didn't exist when the option came from a teammate whose judgment the team already trusted. The net effect at the org level: I've reallocated AI tool usage explicitly by tier. Volume screens across our product lines: AI-first, human review. Strategic, brand-defining, or cross-line-consistency screens: human-first, AI only for reference exploration, never for a first draft that gets presented. The mistake I see other design leaders make is applying one AI policy across all work. The tools aren't uniformly good or bad — they're good at one kind of problem and a tax on the other kind.

No redesign gets approved across any of our product lines without answering these six questions in writing first. I built this list after approving too many redesigns driven by vibes I couldn't defend later to my own leadership. 1. What evidence says this is actually broken? Not "it feels dated" — a number: a support ticket category, a conversion metric, a survey theme. 2. What specific number should move, and by how much? If nobody can name a target, we're not ready to start. 3. Who maintains this after launch? A redesign with no owner past ship date decays within two quarters, and I've watched it happen. 4. What's the cost of doing nothing for two more quarters? Sometimes the honest answer is "nothing bad happens," and that reframes the priority immediately. 5. Does this touch more than one product line? If yes, it needs a cross-line consistency review before a single screen gets built, or we create three slightly different versions of the same pattern. 6. What would make us stop halfway through? Naming a kill criterion before starting is the question that gets skipped most and matters most. This list has killed roughly a third of the redesign requests that came to me last year — not because the ideas were bad, but because nobody could answer question two. Gating on evidence, not enthusiasm, is what makes design's roadmap defensible at the exec table.

Product and design disagreed on our pricing page layout for three weeks last quarter. Both sides had legitimate reasoning. Neither side had data that settled it. Here's the tie-break process I've built, because "whoever's more senior wins" isn't a process, and it quietly erodes whichever function loses by default. First: name what evidence would resolve it, before escalating. In this case, we agreed a two-week A/B test on the two layouts would settle it on conversion, the metric both sides actually cared about. Second: if there's no time to test, the decision defaults to whoever owns the metric most directly tied to the disagreement. Design owns comprehension and usability metrics. Product owns conversion and retention. Pricing page conversion is product's metric, so in an untested tie, product's call wins — and I say that as the design leader, because pretending otherwise erodes trust with product long-term. Third: design gets a standing right to document the dissent, briefly, in writing, without re-litigating it after the decision is made. This isn't about winning later — it's about the org having a record when a similar question comes up again. The A/B test resolved our pricing disagreement: the design-favored layout won by 6 points of conversion. Product conceded gracefully because we'd agreed to the test upfront, not because design out-argued them in the room. Ties resolved by hierarchy breed resentment. Ties resolved by pre-agreed evidence rules breed trust, even when your side loses.

An honest question for other design leaders: what did you say no to, specifically, to protect your team's time for the work that actually matters? Mine, from this year: I declined a full visual brand refresh that an incoming CMO wanted in her first 90 days. Not because it was a bad idea in the abstract — because saying yes would have consumed 60% of my org's capacity for a quarter, on a project with no committed business metric behind it, while our actual roadmap of cross-line consistency work sat unstaffed. I didn't just say no. I brought her three lower-cost alternatives that addressed her real underlying concern — she wanted the brand to feel more current, not necessarily a full refresh — and one of those shipped in three weeks instead of consuming a quarter. The harder one: I turned down a speculative concept project from our CEO twice before he stopped asking. Exploratory work with no committed scope has an unlimited appetite for design time if a leader doesn't set a boundary, and mine hadn't been set clearly enough the first time. What both decisions cost me personally: a slightly awkward relationship with two executives for a few weeks each. What they protected: roughly a quarter of committed capacity that went into work with a clear business case behind it instead. Saying no at this level is rarely about the request being wrong. It's about being the person in the room willing to name the tradeoff out loud. What did you turn down this year?