Ask HN: As a programmer, how close do you work with a UX team?
At our company we have no easy access to a UX team, thing that I am starting to strongly request.
Can you share your experiences, how involved is UX into development?
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.
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."
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.
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.
I work on consumer internet products.