I've watched three enterprise projects ship this year without a design lead. All three delivered working software. All three met the functional requirements. All three have interfaces that feel like they were built by engineers who are good at engineering and indifferent to the experience of using what they built. Functional. Forgettable. And subtly expensive, because "forgettable" in enterprise software means "requires more training, generates more support tickets, and resists adoption."
What You Need to Know
- Enterprise projects without dedicated design leadership consistently underinvest in user experience
- A design lead's job isn't making things pretty. It's ensuring the product works well for the humans who use it daily
- The cost of missing design leadership shows up in adoption rates, training costs, and support load
- Design leads are most effective when embedded in the delivery team, not consulting from the outside
What a Design Lead Actually Does
The misconception is that a design lead creates mockups. That's part of it. A small part. The actual job is broader and more valuable.
Advocates for the User
In every enterprise project, there are competing interests. The business wants features. Engineering wants clean architecture. The project manager wants on-time delivery. Without a design lead, nobody's primary job is advocating for the person who will use the software eight hours a day.
That advocacy shows up in specific decisions. "This form has 30 fields. Can we split it across three screens?" "This error message says 'Error 422.' Can we tell the user what they need to fix?" "This workflow requires seven clicks. Can we reduce it to three?"
72%
of enterprise users say their workplace software is harder to use than the consumer apps they use at home
Source: Forrester, The Future of Work Report, 2021
Each of these is a small decision. Collectively, they determine whether the software is a tool that helps people or an obstacle they endure. Without someone whose job is to notice these decisions, they default to the path of least development effort, which is rarely the path of least user effort.
Creates Consistency
Enterprise applications are large. Fifty screens. A hundred interactions. Built by a team of five to fifteen developers over months. Without design leadership, each developer makes their own decisions about button placement, form layout, error handling, and interaction patterns.
The result isn't chaos. It's inconsistency. The save button is top-right on one screen and bottom-left on another. Dates display as "15 Nov" on one page and "2021-11-15" on another. Search works differently in each section. Users can't build intuitive patterns because the patterns keep shifting.
A design lead establishes and enforces patterns. Not as a dictator, but as a quality bar. "Our save button goes bottom-right. Our dates display as '15 Nov 2021.' Our search is always full-text with filters." These decisions, made once and applied consistently, create software that feels coherent.
Bridges Business and Engineering
Design leads translate between stakeholder language and engineering language. When a product owner says "I want the dashboard to feel responsive," the design lead translates that into specific performance targets, animation patterns, and loading states that engineering can implement. When engineering says "that interaction would require a WebSocket connection," the design lead evaluates whether the user benefit justifies the technical complexity.
The design lead's most important meeting isn't the design review. It's the sprint planning session where someone proposes a feature and the design lead asks "how will the user actually use this?" That question, asked consistently, changes the quality of everything the team builds.
Rainui Teihotua
Chief Creative Officer
The Cost of Not Having One
The costs are real but distributed, which makes them easy to ignore.
Higher training costs. Inconsistent interfaces require more training. Users can't transfer learning from one section to another because the patterns change. Training sessions get longer. User manuals get thicker.
More support tickets. Confusing interfaces generate questions. Every unnecessary support ticket is a cost. Across 400 users, even a small percentage of avoidable confusion creates significant support load.
Lower adoption. Users find workarounds for software they don't enjoy using. They export to Excel, they use email instead of the built-in messaging, they keep a parallel spreadsheet because the search doesn't work the way they expect. Every workaround is a failure of the interface.
Harder maintenance. Inconsistent interfaces are harder to maintain because there are no patterns to follow. A new developer joining the project has no shared conventions to learn. They add their own patterns, making the inconsistency worse.
Where Design Leads Fit
The design lead should be embedded in the delivery team. Not an external consultant who reviews designs weekly. Not a designer in a separate department who hands off mockups. A team member who participates in sprint planning, attends standups, reviews code for UX impact, and is available when a developer has a question about an interaction pattern.
This embedding is what makes the role effective. Design decisions happen constantly during development - in every conditional layout, every error state, every edge case. If the design lead isn't present for these decisions, they happen without design input. And they happen in the way that requires the least development effort.
Enterprise projects can't always justify a full-time design lead. That's fine. A part-time embedded design lead - two or three days per week - is dramatically better than no design leadership at all. The alternative isn't "design happens without a lead." The alternative is "design doesn't happen."