1. 5

  2. 2

    I think every horizontal team is dangerous. If you have a “database team” then you’ve told a bunch of people their job is to do databases, and so they’ll do databases - whether those databases are adding business value or not. Likewise a “backend team”, a “server team”, a “network team” or so on. You need to split teams by the functionality they offer, and make sure those teams can get access to the skills they need (whether that’s internally, by hiring, or something else). I’ve had a great experience working with the “design guy” in a small company, but we all knew we were providing functionality and it was more a case of him being on our team for a couple of months (and then on a different team that had more need of his skills) than of him being a team of his own.

    1. 1

      Your problem was hiring a UI team and assuming they were a UX team. There’s nothing wrong with someone who knows what good UI’s look like, but there’s no replacement for good user testing and a member who is disinvested from making things look good, and instead focused on making the whole process smooth. This is what bothers me when people say Designers are UXers, because it’s almost always untrue, they are someone who has a good intuition for what people need typically, but they are not out with boots on the ground doing quality research. Research that might totally eliminate the need for a screen to be designed in the first place.