Preface
Interface design is part of software design decisions, not a specification, and it is far more than a single image. Treating mockups as specifications often fails to reflect real needs
Continuous Delivery in the video The Biggest Problem With UI pointed out my long-standing question about product UI development processes: why are the UI design and development processes always so disjointed and uncoordinated?
UI, as part of product specifications, is typically designed by the design team and handed off to developers to implement, but the process has too many points of friction. From my own experience:
- People who don’t understand UI easily treat interface designs as static images rather than dynamic experiences, and no matter how high-fidelity the mockups are, they cannot fully reflect the real user experience (and they take a lot of time to produce).
- If developers disagree with design decisions, back-and-forth communication means blocking each other’s progress, which not only lowers efficiency but also harms the work experience.
- Having any single role make all interface design decisions is impossible and dangerous; meeting user needs requires cross-disciplinary collaboration—product, development, user research, etc. How can we coordinate different domains while remaining efficient?
The core question of this article is: “Is there a way for teams to consistently and efficiently produce products that truly satisfy user needs?”
The UI Problem from a Developer’s Perspective
I’m a frontend engineer. In work we split responsibilities clearly: product writes specs based on requirements, UI designs from the specs, and developers implement from the designs. It looks like a clear division of labor, but it’s not as coordinated as one would expect.
This process discourages me from raising opinions about the specs. If I disagree with a design decision, I can only silently accept it (sometimes without even knowing why it was made), or find time to escalate it layer by layer. Such communication often takes a lot of time just to go back and change an already decided design. If every question requires opening a request to the UI team or starting a meeting… most people will give up!
When forced to limit implementation methods to the design choices provided by higher-ups, we often overlook real user needs and development difficulties. For example, it’s hard for me to quickly convey my considerations to designers, and management often doesn’t have enough time to understand those technical details.
In a work model with clear responsibilities, everyone only cares about their own tasks, and there is no real collaboration.
So How Should UI Be Done?
The video The Biggest Problem With UI suggests that although engineers are not UI specialists, they are, to some extent, deep users and generally have some level of UI understanding compared to others.
According to Team Topologies concepts, the UI team can act as an Enabling Team to compensate for shortcomings of Stream-aligned teams, giving development teams time to acquire and develop capabilities without taking time away from their primary objectives.
Enabling Teams focus on strengthening teams’ capabilities by concentrating on problems rather than solutions, thereby increasing the autonomy of Stream-aligned teams. Stream-aligned teams should be able to solve about 80% of common problems independently and can reduce cross-team dependencies through efforts such as:
- Knowledge sharing and training
- Defining good UI documentation and conventions
- Defining reusable assets and components
Conclusion
We tend to think it’s excellent when engineering implements every requirement and appearance one-to-one, but that’s only the baseline. True excellence is being able to discern real needs and improve the team’s operational efficiency. Thinking from the big picture to promote the team’s success is, I believe, the real solution.