Working with Designers

Designers bring a distinct and immediately visible strength to software teams: they can take a functional but ordinary interface and make it substantially better in ways engineers may not anticipate. Their different professional culture is an asset because they generally trust engineers to make technical judgments rather than trying to second-guess them. But the author argues that having multiple designers work on the same product can create costly conflict. In one project, two replacement designers repeatedly reversed each other’s decisions, forcing frontend rewrites and delaying a settled design until managers intervened shortly before launch. The author suggests this happens because design disputes depend more on taste than measurable standards, and because users experience a product as one unified design.

Design systems can help large organizations maintain consistency, but they also create friction. Their owners favor elegant, reusable components, while product teams need components that meet particular customer demands; teams may end up bending components with fragile CSS or rebuilding them. Different framework versions and legacy code add another burden: engineers must approximate the designer’s vision with tools that may look or work differently. Despite these drawbacks, the author sees design systems as the best available way to coordinate interfaces at scale. Designers are also not necessary on every team: APIs, billing systems, and document processing need technical judgment rather than visual design, and some businesses succeed despite awkward interfaces. The author wants designers on product teams where visual quality matters, but argues against treating design as universally essential.