Cross-Functional Design Collaboration

Why collaboration breaks down

Design depends on everyone else. Product decides priorities, engineering decides what's feasible, marketing shapes the promise, sales hears what buyers ask, support hears what users struggle with, and compliance or security define what's allowed. When design works in isolation from any of them, the result is predictable: designs that can't be built as drawn, features that don't match what marketing promised, and constraints discovered after the work is finished.

Collaboration isn't a personality trait. It's a set of practical habits: who is involved when, which artefacts are shared, and how decisions get made. Get those right and teams move faster with fewer surprises.

Is this you?

Signs collaboration needs attention

01

"That's not what we designed"

The built product drifts from the design.

02

"We can't build that"

Engineering sees designs too late to shape them.

03

Marketing and product disagree

The website promises what the product doesn't do - or undersells what it does.

04

Compliance surprises

Legal or security requirements arrive at the end.

05

Support insights go nowhere

Frontline teams know the problems but aren't asked.

06

Handoffs everywhere

Work passes between teams like a relay rather than being built together.

Where design meets each team

Team	What they need from design	What design needs from them	Useful shared rhythm
Product	Options and evidence for decisions	Priorities, goals, constraints	Weekly product-design sync
Engineering	Buildable, specified designs; early sight of ideas	Feasibility, performance, technical constraints	Joint kick-offs, design-engineering reviews
Marketing	A product story that matches reality; brand consistency	Positioning, campaign timing, audience insight	Launch planning together
Sales	Material that answers buyer questions	What buyers ask, where deals stall	Monthly insight sessions
Support	Fewer "how do I" contacts	Top issues and user language	Shared review of support themes
Compliance, legal, security	Designs that meet requirements	Rules and constraints, early	Checkpoints at defined stages

Habits that make the difference

Involve engineering from the first sketch. A 30-minute conversation early saves weeks later. In my current role at Robosoft Technologies, I work with developers every day to make sure designs are implemented faithfully and to resolve UI challenges as they come up - the earlier those conversations start, the fewer surprises there are.

Share artefacts, not just outcomes. Flows, prototypes and decision logs in shared tools let everyone see the reasoning, not only the final screens.

Bring constraints forward. Compliance, accessibility and security requirements are gathered at the start and checked at defined points - especially in healthcare and finance, where a "small" change to a regulated step can carry real risk.

Use one system. A shared design system and vocabulary give design and engineering a common language and remove a whole category of misunderstandings. See design system governance.

Close the loop. After release, share what happened - metrics, support themes, user feedback - with everyone who contributed.

Fitting into agile delivery

Most teams I work with run agile processes and use tools such as Jira, Azure DevOps or Aha to manage delivery. Design fits best when it works slightly ahead of engineering without disappearing into a separate phase:

Discovery alongside delivery - research and design for upcoming work while the current sprint builds the last tested design.
Definition of ready - designs, flows, states, content and accessibility notes complete before a ticket enters a sprint.
Definition of done - design QA and accessibility checks included before a story closes.
Shared ceremonies - designers join planning and reviews; engineers join design critiques.

The process

How I improve collaboration

01
Map the teams
Who contributes to design outcomes, and where work is handed over.
02
Find friction
Interviews and a look at recent projects to see where things broke.
03
Agree rhythms
A small set of recurring touchpoints between design and each team.
04
Set shared artefacts
Brief, flows, prototypes, decision log and specs in shared tools.
05
Adjust definitions
Ready and done criteria that include design and accessibility.
06
Review and refine
Check after a few cycles what's working and adjust.

What you get

01

Collaboration map

Teams, touchpoints and handoffs, with friction points.

02

Working rhythms

Recurring syncs and reviews that fit your delivery cadence.

03

Shared artefacts

Templates for briefs, decision logs and specs.

04

Definitions of ready and done

Including design QA and accessibility.

05

Facilitation

Running the first kick-offs and reviews with your teams.

06

Retrospective

What improved and what to change next.

Frequently asked questions

Can you work inside our existing process?

Yes. The goal is to strengthen the process you have - adding the right touchpoints and artefacts - not to impose a new methodology.

Which tools do you use for collaboration?

Figma and FigJam for design and workshops, and whatever your teams use for delivery - commonly Jira, Azure DevOps or Aha.

How do you involve compliance without slowing everything down?

Gather requirements at the start and review at defined checkpoints, rather than asking for sign-off on every change.

Is this useful for small teams?

Yes. Small teams often collaborate informally, which works until it doesn't. A few light habits - early engineering input, a decision log - scale well.

Do you work with distributed teams?

Yes. Most of my collaboration happens across locations, with remote workshops, shared tools and clear written decisions.

Related focus areas