Speaking the Same Language: Engineering and Design in Product Teams

Key Actionable Insights

1

Replace handover culture with entity-first collaborative sessions between design and engineering. Instead of waiting for hi-fidelity mockups, start with joint discussions about what entities are needed, how users interact with them, and what UI components will support those interactions. This prevents the costly rework that occurs when designs are divorced from system capabilities.

Apply this at the start of any new feature development. The author found that this approach naturally emerged from conversations with design colleagues at SafetyCulture.

2

Establish a shared vocabulary around domain entities and interactions before any implementation begins. This ubiquitous language, similar to Domain-Driven Design principles, enables both designers and engineers to discuss solutions using the same terms, reducing miscommunication and ensuring alignment on what's being built.

This is especially valuable in teams where design and engineering have historically operated in silos and use different terminology to describe the same concepts.

3

Apply shift-left principles to design collaboration by involving engineering at the earliest stages of feature exploration. Rather than engineering becoming involved only when hi-fidelity designs are ready, engage engineers during problem discovery to identify architectural constraints and opportunities early when they're cheap to address.

The author observed that waiting for completed designs can mean weeks or months before engineering becomes involved, leading to designs that don't align with system capabilities.

4

Create a safe environment for sharing early, incomplete work between design and engineering. Encourage designers to discuss rough concepts with engineers before creating high-fidelity mockups, and engineers to suggest technical alternatives during the design phase, building trust and shared ownership.

This cultural transformation helps team members become more comfortable with uncertainty and more confident in cross-functional discussions.

5

Structure collaborative discussions in three progressive layers: first identify entities (what data/objects solve the problem), then define interaction models (what business logic and APIs are needed), and finally consider UI components. This ensures both teams build understanding from the ground up rather than starting with surface-level UI concerns.

This layered approach ensures the underlying data model and architecture will support the final design, preventing the common problem of designs that require significant architectural changes.