I've worked in all kinds of team configurations in my ten years (so far) in the game industry, so I thought I'd talk a little bit about what I've experienced as a game UI/UX designer from two different perspectives: that of the embedded designer, and that of the "client services" designer. Both styles of working have their pros and cons.
This is the way I worked for years in the game industry -- not by choice, but because nearly every game company is structured in such a way that, if they even had multiple UI designers, they chose to embed the designer in the project. Having frequently been the only UI designer at any company I worked, I was embedded within a particular project during a particular part of its lifespan and then moved to another project, sometimes with some overlapping.
Being embedded within the team means that you're always in the head space for that game, which is great for focus, concentration, and always feeling like you have your pulse on the current state of the game. If you're working on it every day, you're seeing progress and change in it every day, and that means never needing to spend time refreshing your knowledge about the current state of the game.
You'll also develop a tighter relationship with your fellow team members. Because UI and UX are so intertwined with a game's core design, an embedded UI/UX designer has the advantage of (hopefully) being more in tune with the project's lead designer. You'll be seen as a team member that works with the designers, rather than an external resource that may or may not be easy to reach.
One of the drawbacks of being an embedded designer is Robinson Crusoe syndrome: a game project usually only needs one UI/UX designer, and that UI/UX designer can begin to feel very lonely professionally.
If you're like me, you need -- nay, crave -- the feedback and interaction of other UI/UX designers. While you can certainly solicit feedback from other members of your team, if they're not actual UI designers, or even designers with some kind of graphic design background, you're not going to get the kind of feedback you need that only another UI/UX designer can give you -- does the important interaction in this screen have the right visual weight? Am I being consistent in my visual language? Am I properly affording the right interactions?
UI is a subject that many people tend to think they know about, because they use interfaces in many aspects of their daily life. But as well-intentioned as feedback is from your non-UI designer teammates (and even the lead designer falls into this category), it won't be the kind of feedback you actually need when designing UI. And again, if you're like me, being Robinson Crusoe on UI/UX Designer Island can leave you second-guessing your decisions, with no one to help see when you might be heading into problems until it's too late.
The external UI/UX team really only works if it's exactly that: an actual team. Otherwise, you're really just trying to spread one UI/UX designer very thinly across every project your company is working on, and your UI/UX designer will essentially function as a thinly-spread embedded designer for multiple teams, gaining none of the benefits of an actual embedded designer nor a centralized team, and all of their problems.
When you do have an actual team of more than one UI/UX designer, and they're working together -- literally working in the same physical location -- there are some great benefits.
First, the designers are able to feed off of each other for feedback and problem solving. Not only will a designer be able to get a second set of eyes (or third or fourth, depending on your team size) on their work, you hopefully won't suffer from anyone reinventing the UI wheel. When UI designers are embedded on a project, they may all be working on solving very similar problems, but their lack of interaction with each other might mean that they're missing out on sharing solutions that others may have already arrived at.
Secondly, from a management perspective, it means you may be able to be more agile about UI/UX development, using the natural ebb and flow of projects and tasks to keep UI and people running smoothly. When one project's UI needs are light, a UI/UX designer can be working on a project that requires more time and then switch back when the current task is finished.
An additional gain from this process is that an external team, by virtue of working on all of the projects at a company, has an opportunity to enforce a standardized user experience across all of the company's projects, if that's an applicable goal.
A centralized UI/UX team still suffers from its own unique problems. Unlike the embedded designer that sees the same project and work day in and day out, a "client services" designer may work on a project for only a brief period of time, and then switch to another, and then switck back again. They won't be in the head space of a project for too long, and so it may take some time and effort on the part of the designer to refamiliarize herself with the current state of the game.
The gains in feedback and problem solving that come about from being a centralized team can mean that you lose that camaraderie and link with the team for the project you're currently working on. You may not be seen as a team member that's working in the trenches, and your communication pipeline will almost assuredly suffer without some extra work on your part. You may need to put in extra effort to maintain good lines of communication with all stakeholders on your current project.
So Which Is Better?
There's no formula for knowing which solution is right for every company, and even within the game industry, project needs vary so widely that there's no one answer. What style does your company use? I'd love to know how it's working out for you, so drop me a line on Twitter or Google+.