Earning trust through transparency

Context

I joined an established product team in a newly opened Warsaw office as the first UX designer on site. The team consisted of a PM, an Engineering Manager, several engineering leads, and a group of engineers. Most of them had worked together for years and already had strong collaboration habits.

My challenge was to become a trusted decision partner — without disrupting a team that was already effective.

The problem behind the problem

“Design the feature” was never the real ask. The real question was: how do we work together so UX adds signal, not noise?

• New person, new discipline — unclear expectations on both sides
• Risk of UX being perceived as a late-stage “UI polishing” function
• High engineering throughput — easy to create rework if decisions aren’t shared early
• Distributed communication (meetings + async) that needed a clear rhythm

My goal

Establish a lightweight, repeatable collaboration system where:

• Everyone understands the “why” and constraints before we commit
• Progress and decisions are visible by default (not trapped in Figma)
• Feedback happens early and cheaply
• UX work scales across multiple initiatives without becoming a bottleneck

Approach: transparency as a system

I treated trust-building as a design problem. Instead of trying to “prove myself” through a single artifact, I focused on shaping the collaboration surface area: what the team sees, when they see it, and how they can respond.

The common denominator was simple: communicate early, communicate often, and make it safe to contribute.

What I did

1) Feature kickoffs for shared context

For every new initiative where I was involved, I ran a kickoff with the whole team. The format was intentionally practical:

• What we’re building, for whom, and what “success” looks like
• Known constraints: technical, timeline, dependencies, legacy behaviors
• Open questions and assumptions — clearly labeled
• How we’ll collaborate: checkpoints, owners, and decision points

Outcome: engineering leads and ICs could challenge assumptions early — before design or implementation locked in.

2) Async narrative in Teams (work in the open)

I used the team’s channels as the default place to share progress and decisions — not as an afterthought. I posted short updates with:

• What changed and why (1–3 bullets)
• Trade-offs and risks (explicit)
• Questions to the team (specific asks, not “thoughts?”)
• Links to artifacts (Figma, notes, short clips)

This made design legible to people who don’t live in design tools — and reduced the “surprise factor” later.

3) Milestone reviews for alignment (no new information)

For larger changes, I scheduled milestone reviews where I walked the team through what was already shared async — step by step. The goal wasn’t to present; it was to align:

• Confirm shared understanding
• Close open questions
• Make final calls explicit (and documented)

4) Invite contributions without creating chaos

I actively encouraged input, but kept it structured: “comment on these 2 flows” or “validate this assumption”. This helped the team participate without turning feedback into an unbounded discussion.

Staff-level behaviors this demonstrates

• Operating model design: shaping how teams make decisions, not just what they ship
• Decision clarity: making trade-offs explicit, trackable, and revisitable
• Systems thinking: treating communication channels and rituals as part of the product system
• Enablement: increasing the team’s ability to reason about UX independently over time
• Trust building: consistency, predictability, and “no surprises” collaboration

Impact

Over the following weeks, the team’s engagement steadily increased. We developed a shared understanding of roles and responsibilities, and UX became part of the team’s default planning and problem-solving.

• More frequent questions, comments, and alternative proposals from engineers
• Earlier involvement of UX in technical discussions and planning meetings
• Less rework caused by late discovery of constraints or mismatched assumptions
• Higher confidence in decisions — because the reasoning was visible, not implicit

What I’d improve next time

• Formalize a lightweight “decision log” to make rationale easier to find months later
• Introduce a rotating “UX buddy” from engineering to improve two-way context sharing
• Measure collaboration health with a few simple signals (cycle time for feedback, number of reopened decisions)

The lesson: in a high-performing team, UX impact often comes from reducing ambiguity and friction — not from louder opinions or bigger artifacts.