As a programmer, how close do you work with a UX team?

I've been on teams with minimal interaction between dev and UX, where the UX team would throw a design over the wall. These were not great experiences and led to frustration on both sides.

I've also been on teams where we work very closely with UX and they are a part of all our agile ceremonies, etc. They were a core team member of the team.

The latter experience was on a mobile team. We would review the proposed designs as a team, make comments on potential navigation issues, or non-standard UI elements for our platform. There was some give or take here on both sides. Once we were in general agreement the dev teams would start their implementation work.

Then we had a bi-weekly meeting for both platforms where a rotating engineer would meet with the team's UX team member (UX-Palooza) for 30 minutes. They would come prepared with a list of small UI issues they saw that they wanted adjusted. Minor alignment issues, font issues, etc. Things that were too small to bother writing up tickets for. The developers would try to fix everything live while sitting with the UX team member and if anything seemed like it would take more than a couple minutes we would create a story.

I feel like this model worked really well. The one "drawback" is that the UX team member identified more with the product development team than their UX peers who didn't operate like this. I feel like it may have caused some friction between the UX team member and their broader UX organization.

Here at PhotoStructure, Inc., there's a remarkable amount of access and harmony between the engineering staff, the UX and product team, customer support, and executive teams. It's like we're all thinking with one mind.

In companies that are larger than 1, however, crossing team boundaries can be rough.

UX and design teams can be either "embedded," where a design/UX person sits with a product/engineering team, or they can be kept all together.

The first approach can be great at facilitating communication and iterating on something that results in something not obviously "designed by an engineer."

The second approach, where all the designers sit together as a team, helps homogenize the overall UX esthetic across products, but their comments and input provided to engineering teams can come off as "drive-by critiques" that aren't always warmly taken.

A great approach, if you can swing it, is to have the UX person "loaned" to your team for a couple days a week. Then that person has a chance to be "adopted" but the team, and not have as much default latent friction/discord due to being an "outsider."

Very closely because our business problems require a lot of understanding to solve accurately (more heads thinking about the problem). There’s very little siloing because the end result could be a useless product that solves nothing if you blindly build it to spec.

I’ve worked at places where design does throw something over the wall and the devs just build it, which worked fine when the problem space was straight forward (e.g build a photo album). Only so much to figure out there.

It depends on the work at hand.

For a brand-new feature, I work very closely with the UX team (well, UX person). For minor changes, not at all.

Generally, the UX person and the frontend person will work very closely together when working on web app features. When I'm on the backend, I have zero interaction with UX.

We work super closely with product designers on almost everything we do. I work with product designers on an almost daily basis (depending on the stage of a project).

I work on consumer internet products.

Quite far away but that’s because we’re in lock down.