When Designers and Developers Collaborate, Your User Wins

If you’ve navigated a digital experience easily, there’s a good chance that the designer and developer who built it had a strong working relationship. On the flip side, if it’s a bumpy user experience – long load times, hidden log-ins, irretrievable data – then it’s possible their collaboration wasn’t as seamless. Maybe they spent most of their time patching up the backend and slapping duct tape on design problems. 

This impacts both the UX and the business. Inevitably, issues require taxing rework and resources. A healthy partnership between these roles is a necessary investment that can turn the ship for the business, and minimize design debt and technical debt. 

“These are legitimate concerns that happen across enterprises everywhere,” said Chris Mattison, Salesforce Technical Architect and certified Platform Developer. He and Asterisk Loftis – Salesforce MVP and certified UX Designer – are locked in about this issue.

They’ve been discussing and presenting on designer-developer collaboration regularly since they met at the onset of the first Dreamin’ in Color. In 2022, the conference launched to empower Black professionals to thrive and succeed in the Salesforce economy. Loftis continues to be on the organizing team and Mattison co-leads the Salesforce Black in Tech (BIT) community. Together, they’ve identified a few ways to help designers and developers avoid common obstacles. 

Discover how to set collaborators up for success with inclusive workflows, user research advocacy, and cross-skilling. 

Inclusive workflows break down designer-developer silos 

Designers and developers are regularly separated into functional silos. This can create miscommunications. “I remember I thought I was a good designer,” said Loftis. “I was on the scene, working on a highly polished design team, designing campaigns, really feeling myself and projecting disdain toward our dev team when they couldn’t make it.” One day, a developer encouraged Loftis to try CSS himself. It was harder than he thought. 

Today, he doesn’t wait until the handoff to show developers his designs. He includes his counterparts from the beginning. Both he and Mattison agree that the lead developer attends the first round of client meetings. Getting feedback about the user experience directly helps them understand why resources are being prioritized. Plus, the practice of inclusion dismantles elitism in both roles.

Of course, the bridge goes both ways. Developers can adapt “rubber ducking” – a debugging method where one explains a problem line by line – when breaking down technical work for a designer. Stand-ups can be an opportunity to identify what needs further explanation.

While designer practices don’t always align with Agile, Loftis and Mattison strongly recommend everyone attends stand-ups, sprint reviews, and sprint demos. “That will influence the next iteration of design,” said Mattison. “The whole point of doing Agile is to have a short feedback loop, right? You never get too far.” Working as one creates a different culture than working in kingdoms that can foster elitism.

Actions:

• Invite the lead developer to the first round client meeting.
• Invite the designer to all Agile ceremonies.

This housekeeping can eliminate barriers. Another way to support this relationship is to bring a third voice into the equation: the user’s.

User research advocacy reduces designer-developer rework 

Maybe an online portal has lots of apps under one UI and a ton of custom work. Weeks and months of design and development hours go into it. No one wants to waste their time. That’s why it’s necessary to validate requirements with users. 

Mattison recommends that designers and developers co-create high-fidelity mockups. He never wants to be in the position where someone points out that the team made some assumptions, which made that work less solid or valid.

It’s not surprising that one of Mattison’s favorite design collaborations included a team that tested an element every 10 weeks. It kept everyone on track to meet the spirit of what the user desired. Today, he’s committed to the design practice of user research. He frequently asks his teams how they can make sure what they’re building fits the needs of the user – before they get too deep in the process. 

At project kickoffs, Mattison is known to ask questions about the user interface (UI) to get to the why? He sees a red flag when a response is “because this person said so.” And for good reason. In the past, he’s built difficult projects that went wrong following orders from the business without user validation. “Could it have been better?” he reflects. “Maybe. We didn’t involve the end user.”

It’s obvious why he appreciates designers like Loftis. This #DreamDesigner builds user validation into his internal process without anyone asking him to do it.

Actions:

• At the kickoff, align on the why for each requirement.
• Ensure the product development plan includes user research.

In the same way that Mattison learned more about design with user research, Loftis is a lifelong learner when it comes to development. 

Cross-skilling builds a common designer-developer language 

Good collaborators never want to back a teammate into a corner. To avoid this, Loftis looks for the limitations and constraints early on.

“That helps us build a better story and really solve a problem,” he said. The Salesforce platform provides guardrails. So he asks every designer if they’ve created a Trailhead account, a dev or demo org, and bookmarked Salesforce Lightning Design System (SLDS) pages.

He wants them to know about API limits and data maximums. After all, it’s free and easily accessible. “If not, I worry.” This comes from lived experience. Early in his career, he threw designs over the fence to development without any technical knowledge. 

Today, Loftis is capable with CSS and HTML – and wants you to be, too. “I’m gonna leave you alone in JavaScript. But I think that you should even know that.” 

Here’s why: Small design decisions can constrain many Scrum teams. A custom design may take three dev teams six months to build with custom APEX and Lightning Web Components (LWC). Alternatively, a page layout with declarative configuration may take one developer three weeks.

Actions:

• Create a Trailhead account, dev org or demo org.
• Bookmark SLDS pages.
• Learn CSS and HTML. Learning Javascript is a bonus.

Mattison remembers spinning dev wheels for weeks on a custom floating dot in the UI. It turned out that any separation element would’ve worked for the design. Moments like that make him passionate about modeling and normalizing frequent communication lines between the roles. 

The result of cross-skilling 

Loftis and Mattison exemplify what’s possible. They are so aligned that they finish each other’s sentences. If not, they nod in agreement while the other speaks. It’s clear that they love what they do. 

The duo talk offhand about how to use a component with a related record without getting a new developer widget. They laugh about red flags like custom grids or a bold class instead of a utility class. This ability to be on the same page comes from building their skills in the other’s discipline. Loftis studied UI development and Mattison knows enough about SLDS to be dangerous.

“If you want to be a really good chef, then you need to know how the plants are grown,” said Loftis. “To create a better user experience, I need to understand these things that are around the space but not (necessarily) in my core skill set.” Learning about other work streams doesn’t just benefit personal growth and team culture. It has outsized effects on the product development process. 

When designers and developers collaborate, it helps create user-centric, visually appealing, and technically feasible solutions while maintaining efficiency and quality. 

Both Trailblazers exhale deeply when sharing what it’s like to enter a kickoff and notice a great collaborator in the other role. “This product is safe,” said Loftis about this moment. “It’s gonna be okay.”