Product designer shares two-year retrospective on bridging engineering and user experience at HR software company
A product designer at SmartHR reflects on two years of work treating UI design as a systems engineering discipline rather than pure aesthetics. The author describes their philosophy of adhering to design standards by default while deviating only when justified by reasoning, and maintaining awareness of broader organizational and technical context. The role emphasizes responsibility for usability alongside developers and product teams rather than design as an isolated discipline.
The author previously worked as a backend engineer specializing in concurrent systems before transitioning into product design. During internships, they gained exposure to full-stack development—from server-side implementation through UI design—and eventually contributed to design system architecture. This multidisciplinary background informed their conviction that artificial boundaries between engineering disciplines create inefficiencies and fragmentation in software development.
At SmartHR, the designer's philosophy treats UI as a systems engineering problem rather than pure aesthetics. They describe operating through two principles: standardizing routine design decisions while deviating only with documented rationale, and maintaining continuous awareness of organizational context beyond individual screens. This approach resulted in the messaging feature departing from SmartHR's standard layout to prioritize familiarity with existing messenger apps and reduce navigation friction.
This retrospective may influence how tech companies structure product design roles, particularly in enterprise software. If design-engineering integration becomes more normalized, it could affect hiring practices and team organization across the industry. However, the approach's success likely depends on organizational maturity and communication infrastructure, meaning adoption may vary significantly. The perspective also suggests that standardization itself requires continuous reexamination—a principle that could reshape how design systems evolve in larger organizations.