IT: +39 338 62 46 214
The Invisible Work of a UX Lead: 4 Ways to Add Value Beyond the Screen
There is a specific kind of exhaustion that design leads don’t talk about enough. It’s not the exhaustion of doing too much design work. It’s the exhaustion of feeling like you’ve stopped doing design work at all.
You spend your days in status meetings, writing Confluence pages nobody reads, reviewing Jira tickets, and navigating stakeholder dynamics. The work feels important — it is important — but somewhere in the middle of it, you wonder: am I actually making the design better, or just making the organisation feel like design exists?
This is the invisible work paradox of a UX lead. The most valuable contributions you can make are often the ones hardest to see, and the most visible things you do are often the least valuable.
I’ve been thinking about this for the past few years, particularly during my time leading UX at Roche. Not because I figured it out, but because I kept getting it wrong in interesting ways. What follows are four ideas I’ve tested, failed at, and eventually made work — about what it actually means to lead design without always being hands-on.
The operational work trap
Every design lead I know falls into the same trap within six to twelve months of the role. The calendar fills up. The Slack messages accumulate. The deliverables multiply. And before long, the job starts to feel less like design leadership and more like design administration.
This isn’t a failure of character. It’s a structural problem. Organisations are very good at generating operational work — meetings to align, documents to review, processes to maintain — and very bad at protecting the time needed for systemic work. The design lead ends up absorbing everything the organisation doesn’t know where to put.
John Kotter, writing about organisational change, observed that most leaders spend 95% of their time managing the present and 5% creating the future. In design leadership, I’d argue the ratio is even worse. The operational work is visible, urgent, and socially rewarded. The systemic work — building the conditions under which better design consistently happens — is invisible, slow, and rarely celebrated.
The four ideas below are attempts to shift that ratio. Not to eliminate operational work, but to make sure the systemic work actually gets done.
Idea 1. Make your feedback culture a design problem
Early in my time as a UX lead, I assumed that if I gathered people in a room and showed them work, feedback would happen naturally. It didn’t. What happened instead was a mix of silence, politeness, and the occasional opinion from whoever had the most seniority.
Feedback culture doesn’t emerge. It’s designed. And treating it as a design problem — rather than a communication problem — changes everything about how you approach it.
What I eventually built at Roche was a bi-weekly design critique session with a fixed structure: the designer presents context and a specific question, the group responds only to that question first, and critique is separated from approval. Simple in theory. Incredibly difficult to maintain in practice, because the organisation constantly pulls towards critique-as-approval-seeking rather than critique-as-thinking-tool.
“Design critique is not a meeting. It’s a practice. And like any practice, it requires structure, repetition, and the willingness to make it uncomfortable sometimes.”
Three things that helped: shared templates for presenting work (so the framing was consistent), a rotating facilitator role (so critique wasn’t always moderated by the most senior person), and a written feedback artifact after each session (so decisions were traceable). None of these are original ideas. But implementing them consistently over eighteen months changed the quality of the work more than any individual design decision I made.
Idea 2. Establish principles that actually get used
Most design systems have principles. Most of those principles live on a Confluence page that was last edited two years ago and is visited primarily by new joiners who are trying to understand what the team believes.
Design principles that work don’t live in documents. They live in conversations. The difference is less about the content of the principles and more about how they’re activated in the day-to-day flow of design work.
The test I use: can a designer on my team invoke a principle in a design review to close an argument? If yes, the principle is working. If the answer is “it depends on who’s in the room,” the principle is decorative.
At Roche, we went through three iterations of our design principles before we found language that was specific enough to be useful but general enough to apply across product contexts. The key shift was moving from aspirational statements (“we design for clarity”) to behavioural ones (“when in doubt, remove”). Behavioural principles create a decision rule. Aspirational principles create a mood board.
The other thing that helped: principles need owners. Not a team that “believes in” them, but a person who is responsible for making sure they’re being used. In most teams, no one owns the principles, so they become furniture.
Idea 3. Protect time for cross-product work
One of the structural problems of design leadership in a multi-product organisation is that the incentives all push towards product-specific work. Each product has a roadmap, a PM, a set of stakeholders, and a very clear definition of what success looks like. Cross-product work — design system maintenance, shared patterns, consistency reviews, tooling — has none of that. It’s nobody’s priority and everybody’s problem.
The only solution I’ve found is to make cross-product time explicit in the team’s capacity planning, rather than assuming it will happen in the margins. We called this ODSU (One Design System Update) — a standing allocation of roughly 20% of each designer’s sprint time for work that benefited the system rather than the product.
The resistance was predictable. PMs saw it as capacity withheld. Designers saw it as overhead. It took about two sprints of visible output — a shared component that saved three teams two weeks of work — before the narrative shifted from “why are we doing this” to “what are we doing next.”
The lesson isn’t that ODSU is the right model. It’s that cross-product work requires structural protection. If it’s not on the calendar with a name and an owner, it doesn’t happen.
Idea 4. Make collaboration explicit, not assumed
Conway’s Law states that organisations design systems that mirror their communication structures.[1] The corollary for design teams is that collaboration doesn’t happen because people are well-intentioned. It happens because the conditions for collaboration are deliberately created.
The most useful thing I’ve done in this area is what some people call a “Manual of Me” — a short document each team member writes about how they work best: when they’re most focused, how they prefer to receive feedback, what drains them, what energises them. It sounds soft. In practice, it dramatically reduces the friction that comes from mismatched working styles and unspoken expectations.
“Most collaboration problems are not personality problems. They’re information problems. People don’t know enough about how their colleagues work to collaborate effectively with them.”
The second thing that helped: modelling explicitly. As the design lead, how I collaborate sets the tone for how the team collaborates. If I give feedback asynchronously and in writing, that becomes a norm. If I show up to reviews with opinions already formed, that becomes a norm too. Explicit collaboration isn’t just a team practice. It’s a leadership practice.
Additional ideas worth pursuing
- Treat hiring as a design problem. The people you bring into the team shape the culture more than any principle or process. Define the design values you’re hiring for before you open the role, not during the interview.
- Make your work visible to the organisation. Design leadership is often invisible to senior stakeholders. A monthly one-page summary of what the team is learning, building, and deciding is more valuable than most presentations.
- Invest in mentoring outside your team. Some of the highest-leverage work I’ve done as a design lead has been with designers in other functions — product, engineering, research — who had no formal design background but were making design decisions anyway.
- Speak at all-hands as a designer, not as a manager. When you present at all-hands, present design thinking, not project status. Show the problem space, the options considered, the decision made. This is how design builds credibility at the organisational level.
Summary
The invisible work of a UX lead is not about doing less design. It’s about doing design at a different scale — designing the conditions under which better design consistently happens across the team and the organisation.
Four things I’ve found worth the effort:
- Treat feedback culture as a design problem, not a communication problem
- Write principles that are behavioural, with an owner who keeps them active
- Protect cross-product time structurally, not aspirationally
- Make collaboration explicit through artefacts and modelling
None of these are quick wins. All of them compound over time in ways that individual design decisions rarely do.
Notes
[1] Conway, M. E. (1968). “How Do Committees Invent?” Datamation, 14(4), 28–31. Conway’s Law has become a foundational idea in systems design: the architecture of a system tends to mirror the communication structure of the organisation that built it. Applied to design teams, this means that how the team is structured and how people communicate determines what kind of work gets done — not just the stated goals.
[2] Andy Budd has written extensively on design leadership and the shift from individual contributor to multiplier. His framing of the design lead as “someone who makes the team better” rather than “someone who makes the best designs” is one I return to often.
[3] The “Manual of Me” concept has been popularised by various practitioners in the agile and design communities. The core idea — making your working preferences explicit — is simple but consistently underused in design teams.
Awesome Works
Awesome Works
Related Posts
Use any form
Design impactful user experiences with ease—everything you need is at your fingertips.
Feel free to reach out for a project inquiry, a coffee chat, or a consultation. Let’s explore how I can help you achieve your design goals. Whether it’s crafting impactful experiences or discussing innovative ideas, I’m here to collaborate and bring value to your vision.