01Align
Kickoff
Align on the problem, goals, roles, and open questions.
Purpose·Shared goals and expectations
Designing for
Cross-Functional Alignment
Exploring how shared systems, documentation, and collaboration practices could help Product, Design, and Engineering align earlier and make better decisions together.
Designing for Cross-Functional Alignment
Client
Immuta
Brown University Capstone
Role
Lead Product Designer
Category
- Product Strategy
- Design Operations
Year
2025
Problem
Cross-Functional Challenge
Teams were collaborating without a shared process
Product, Design, and Engineering worked closely together, but didn’t have a shared process for moving work from planning into development. Different expectations around requirements, ownership, and readiness created extra back-and-forth and meant some issues weren’t caught until implementation had already begun.
Where collaboration broke down
- 01Before Development
Unclear requirements
Missing requirements and edge cases left Engineering to fill in gaps.
- 02During Development
Repeated clarification
Teams relied on Slack, meetings, and one-off conversations to resolve questions.
- 03After Implementation
Issues surfaced too late
Design and interaction issues were sometimes caught only after implementation.
- 01Before Development
Unclear requirements
Missing requirements and edge cases left Engineering to fill in gaps.
- 02During Development
Repeated clarification
Teams relied on Slack, meetings, and one-off conversations to resolve questions.
- 03After Implementation
Issues surfaced too late
Design and interaction issues were sometimes caught only after implementation.
Discovery
Research & Mapping
Understanding How Work Moved Across Teams
I used interviews, workflow mapping, and competitive research to understand how Product, Design, and Engineering worked together throughout delivery. Looking across each discipline helped surface where expectations differed, where handoffs became unclear, and where collaboration needed more structure.
Current Workflow
The Cross-Functional Triangle
Product, Design, and Engineering were working toward the same goal, but each discipline needed something different from the delivery process. Mapping those needs side by side helped show where expectations aligned and where gaps in collaboration were creating friction.
Click a role to explore needs and friction
Or click a node on the triangle
Strategy
Design Principles
From research to operating principles
The findings shaped five principles for creating a more consistent way of working across Product, Design, and Engineering.
What we learned
Strategy
Questions were being resolved after development started.
01Align before development begins
Resolve important questions before implementation, not during it.
What we learned
Questions were being resolved after development started.
01Align before development begins
Resolve important questions before implementation, not during it.
More documentation wasn’t solving collaboration gaps.
02Create shared understanding
Give Product, Design, and Engineering the same expectations for readiness.
What we learned
More documentation wasn’t solving collaboration gaps.
02Create shared understanding
Give Product, Design, and Engineering the same expectations for readiness.
Process could easily become another source of overhead.
03Keep the process lightweight
Add structure only where it removes friction or improves alignment.
What we learned
Process could easily become another source of overhead.
03Keep the process lightweight
Add structure only where it removes friction or improves alignment.
Risks surfaced after teams had already committed to work.
04Surface risk earlier
Identify gaps and dependencies before teams commit to development.
What we learned
Risks surfaced after teams had already committed to work.
04Surface risk earlier
Identify gaps and dependencies before teams commit to development.
New processes are harder to adopt when they live outside existing workflows.
05Work within existing workflows
Build the process into the tools and rituals teams already use.
What we learned
New processes are harder to adopt when they live outside existing workflows.
05Work within existing workflows
Build the process into the tools and rituals teams already use.
Framework
Operating Model
A shared model for how work moves forward
The framework introduced clear points for Product, Design, and Engineering to align before and during development. Each part addressed a gap uncovered in research, while shared governance supported decisions and quality throughout the process.
- 02Ready
Definition of Ready
Confirm the work is understood well enough to move into development.
Purpose·Clear criteria before development
- 03Build
Design Delivery Checklist
Give teams the context and details needed for implementation.
Purpose·Consistent implementation context
- 04Review
Mid-Sprint Reviews
Check implementation while there is still time to respond.
Purpose·Earlier visibility into issues
Governance
Supports the full lifecycle
- Foundation
Design System Governance
Creates shared standards for consistent implementation.
Purpose·Consistent product standards
Implementation
Workflow Integration
Bringing the framework into existing workflows
Rather than introducing a separate process, the goal was to apply the framework within the tools, documents, and working sessions teams already used—so new expectations could become part of everyday delivery.
- In Jira
- In Figma + Jira
- In team rituals
- In prototyping
Measurement
Adoption & Impact
Tracking adoption and impact
Parts of the operating model are already in use, while broader adoption is still evolving. I documented what is working today and the measures I’d use to understand its impact over time.
In practice today
In use PXL component workflow
Shared components connect prototypes more closely to implementation.
In use Functional prototyping workflow
Designers can build higher-fidelity prototypes using reusable PXL components.
In progress Engineering integration
Storybook collaboration and broader engineering adoption are still evolving.
Measuring success
Metrics I hope to track as adoption grows
To track 01Engineering readiness
% of work meeting Definition of Ready
Expected impact
Clearer readiness before development.
To track 02Development clarifications
# of clarification loops after development begins
Expected impact
Earlier cross-functional alignment and fewer gaps during implementation.
To track 03Late-stage rework
# of issues requiring rework after development begins
Expected impact
Fewer issues carried late into development.
To track 04PXL adoption
% of work using shared PXL components
Expected impact
A closer connection between design, prototypes, and production code.
Designing the process is part of designing the product
This project pushed me to think beyond the interface and look more closely at the systems around how products get built. Creating the framework reinforced that better collaboration doesn’t come from adding more process. It comes from giving teams the right structure, shared context, and opportunities to make decisions together.
What I'm taking forward
- 01
Start with shared understanding
Getting teams aligned early can prevent much larger gaps later in development.
- 02
Design for how teams actually work
New processes are more useful when they fit into existing tools and workflows rather than adding another layer of work.
- 03
Connect design and implementation
The closer design artifacts, prototypes, components, and production code become, the easier it is for Design and Engineering to maintain a shared understanding of what gets built.
Next project: Bend HSA Portal Redesign
VIEW NEXT PROJECT