Building Trust and Best Practices on a New Team

As designers getting up to speed on a new client project, we often feel the tension of designing quickly to earn trust, and designing to provide lasting value to users and the business. We want to be partners, not just another resource to be called upon when desired. But how can we smoothly transition into this partnership?

Many clients we work with have products that evolved without consistent design support, and teams used to a “build first, fix later” approach. Both make it tricky to implement significant changes from the get-go—but not impossible. Let’s dive into some practical principles we’ve followed to build trust, integrate with engineering & product management, and move client relationships towards that ideal partnership.

For a video version of this article, check out this short talk by Annah Amici!


1. Make planning visible

Design can’t work in a silo! How well does the rest of the team know what designers are working on? Check out the design board—if there is one. Is it a simple kanban board, or is it aligned with engineers’ sprint cadence? How are design tickets written, groomed, and accepted? How are they broken down to engineering tickets?

On a recent project, one of the first things we did was add sprints to our design planning board. This significantly reduced the amount of backlog clutter on the board and improved the visibility of our work to the rest of the team.


2. Foster team collaboration

How can we increase team cohesion when design has traditionally been on its own, called upon when needed, and otherwise left out of the planning process? To start, sharing in-progress design work is a welcome change to engineers, PMs, and leadership. But sharing doesn’t only go one way—we invite ourselves to planning meetings, help draft acceptance criteria & size tickets, and offer design feedback when scope needs to be cut.


3. Plan consistent (but flexible) meetings

Another aspect of integrating into a new team is managing meeting load. Design, engineering, and product should sync on a regular basis, ideally daily. With a recent client, we set up flexible daily meetings that easily adapted to our shared workload. They could stretch from a quick round of updates to a full design review, keeping us in the context of the work while avoiding streams of future meetings. Having this consistent heartbeat while also adjusting to expected & unexpected changes isn’t an easy balance, so this approach won’t work for every client. Evaluate the team’s culture and adjust as necessary.


4. Engage stakeholders early and with context

While regular, flexible meetings help move everyday design work forward, decision-making doesn’t happen solely within the realm of product, design, and engineering. Fostering our PDE relationships, however, is incredibly helpful when other stakeholders need to be pulled in at the right time.

With a recent client, stakeholders across different parts of the org had very different understandings of the work being done. As a small feature neared completion, one stakeholder brought up that some data could be calculated in a way that might make more sense to users. It was trivial to adjust our designs to accommodate, but by the time we tested the two options, engineering had already finished their planned work—unfortunately, not the solution the users preferred. At that point, there were no development hours remaining, so the change had to be pushed to the backlog.

Moving forward, Lab Zero was able to help by calling out misalignment to decision-makers earlier in the process, but just calling it out isn’t always enough. We have to remember that stakeholders have their own work as well, and switching back into ‘design mode’ isn’t always easy. Setting context is vital to getting alignment, so make the most of limited time with stakeholders. Take a few minutes at the start of meetings to review project goals, scope, and status. Then, make sure to address the complexity of the problem not only for users, but also from a data or engineering side. Only now is it time to dive into the designs!


5. Ask the right questions in the right way

How to ask questions is almost as crucial as knowing what questions to ask. Asking questions in a neutral, genuinely curious way tends to put people at ease. Especially when challenging long-standing assumptions, asking simple questions from an outsider’s perspective can feel less threatening. Try to make information-gathering sessions flow more like a conversation than an interview!

If someone is lingering on a design or seems unsure of what to do, try asking, “So, what’s the first thing that catches your eye here?” Or, if they’re blazing through the prototype, comment that they seem quite comfortable with the interface and ask if they’ve used similar products before—and if there’s any features of those products they particularly like!


6. Keep specifications and designs aligned

Especially when working on multiple design initiatives, keeping product specs aligned with the current state of design is vital. That’s not to say every single design tweak or potential iteration needs to be documented, but if the project’s objectives change, everyone should be on the same page. Ideally, the PM updates written specs, the designer iterates on a design, and the engineer modifies development tickets—with everyone checking and integrating each other’s work.


7. Structure and document design work

When hired as design support, it’s rare to be the first designer to work with a client’s team. They’ll likely have experienced multiple designers with multiple ways of working over the years. Design files are probably fragmented, leading to any sort of system accumulating a good amount of design debt.

After an initial audit at a recent client, we discovered multiple issues with the way files had been set up. Engineers were having a hard time finding the proper designs for their tickets due to imprecise linking. When they did find what they were looking for, they were often still unsure which iteration was actually approved for development.

To alleviate these concerns and make engineers’ lives easier, we split out Figma files by initiative, creating pages for logical chunks of work. On each page, we clearly indicated which work was ready for development and linked to those sections from supporting documentation. Any previous iterations were hidden or moved to their own archive page to keep the focus clear.


8. Conduct the occasional UX spike

For designers, it’s sometimes frustrating to work within the constraints of an existing system. If only we could just redesign it from the ground up! Unfortunately, wholesale design system upgrades take time and serious leadership buy-in. To scratch that particular itch, try to identify a bite-sized slice of the product around which to design a little glimpse of the future, free from the pressures of delivery.

While starting to check good ideas against product constraints, make sure to ask the right questions about why things are the way they are and what’s possible to change (see principle #5). Keeping designs customer-centered will make it easier to push past some of those constraints and get team members onboard. If done right, some of the biggest improvements should make their way into the next chunk of prioritized engineering work!



As with most things design, none of the above are set in stone; they can and should adapt to the individual work environment. Integrating into a new team will always take time, but in our experience, these principles guide the way to genuine understanding and team alignment. And ultimately, that alignment delivers real value to users and the business. So let’s keep it real, advocate for design & the user, and collaborate with our PDE partners—we’re all in this together!

Continue the conversation.

Lab Zero is a San Francisco-based product team helping startups and Fortune 100 companies build flexible, modern, and secure solutions.