Hot answers tagged

16

After some years of fighting I got used to it. There are various ways to struggle with it, you can play as an authority often saying "no", or actually "NO!", but you will lose your followers, because there are always decisive people who will maintain that they know better. You can try to establish processes, but there are going to be people who will not ...


13

The easiest way to fix it is make them the same people. Hire people with both UX and development skills. Knowing code makes your UX better, because you know what is possible and what the impact of your UX decisions are. Knowing UX makes your code better, because you can prevent development decisions from compromising the experience. They're ultimately two ...


12

Your story sounds similar to my case( I am not the first UX hire but I am the first guy whom they have hired who has had formal education in UX as such). Anyway here is what I would focus on: Find out who are the key stakeholders in the company who are interested in user experience: This is really important as you would need the support of atleast someone ...


10

It's a good but difficult question, without any universally good solution. However I will try to give you some things that you can do to help with this. Firstly, recognise that the role of a UX designer is to say no a lot of the time. That doesn't mean that you say "no" whenever someone suggests something that you don't particularly like. Secondly, you ...


8

Reframe this: it's a great opportunity! The obvious way to interpret your situation is... The team has a hard time keeping in touch because individuals are off in project-land, each assigned to different project. As a result fragmentation and isolation happens and I'd like a way to avoid that and promote sharing and team spirit. This view of the ...


7

From what I have experienced, it is rather a problem of team management than a problem specific to UX VS. Developers. Each company will have the risk of two teams being in a competition, whether it is the cooks VS. the dishwashers in a restaurant, the drivers VS. the mechanics in a bus company, etc. Based on that, try to reduce group separation. Having ...


4

Involve developers in the design process. This helps developers understand what how and why the design is the way it is, and it helps the designers understand any technical limitations there may be and look to create a design which enables it. It also helps create empathy amongst teams to understand what each other are working towards. There should be a ...


3

Another idea I would add to everything said above is do user testing when you can. When there is a proof that something works/doesn't work people are more likely to agree. Some important people are also more agreeable when you talk to them in person and they don't need to show their power to a bigger group. So you can try convincing them individually and ...


3

In our company we have a monthly stand ups for sharing project updates among teamleaders. This works quite good as there is always enough news to tell. And it does not take too much time too often - around one hour. May be you try two tracks, one weekly 5 minutes update each member and a monthly 10-15 minutes update with slides or images in form of a little ...


3

Interesting, I am about to join such a group (starting tomorrow, actually), so I was hoping for a huge discussion here :-) From my frontend experience, I would try the following: Splitting the group in two halves, say, Blues and Reds. Let them present separately one day per week. This will also bump up the team spirit. Gamify presenting with visuals: one ...


2

Ideal solution is that UX and Front End Dev aren't separate departments run by different managers and housed in different org charts. How practical that solution is entirely dependent on your corporate structure. I find the bigger the corporate structure, the more segregation there is between each individual component of the process. What happens where ...


2

Online tools such as Slack and Asana can really help with team communication and collaboration. In your situation, it would enable any member of the team to see at what stage other parts of the project(s) are. As it can also be used as a replacement for internal email, it is more likely to be kept up-to-date than a physical board that may be less obviously ...


1

I work at a company that has UX pods in a lot of different teams. In the pod I work in, the UX designers often work on different projects. We have a weekly pod meeting and everyone has the opportunity to discuss/share what they are working on. We also have an overall UX staff meeting once a month. The individual contributors have the option to present their ...


1

See if you can organize your team around 2-3 common missions or objectives? Split your team into 2-3 mission-based sub-teams and identify a point-person for each mission (for example "team process simplification", "team delight", etc.). Make the point-persons responsible for certain mission-specific KPIs. Rotate team leads every couple of weeks or months to ...


1

I saw this blog post a little while ago. The main article focuses on American placeholder names, but there are some fascinating international examples in the comments section. EDIT: Just found that she did a post about the international ones too.


1

It is definitely useful to get input from a variety of different people, but the key here is to define the people that are asked for input, and the people that make decisions based on the input. This way, people know which part of the process they are involved in, and how the decisions are being made. Also, for the 'design committee', it is important to have ...


1

Focus on goals, not visuals. In other words, when presenting part of the UI, explain what that part of the UI does to accomplish the particular goals it was put there to handle. By doing that, you end up explaining WHY things are designed they way they are. The won't stop all random 'stripes vs. polka dot' type questions, but should at least reduce them.


1

It'd make sense to drive by facts. If you can setup measurable conversion goals, and verify them either by user testing or metrics from your production - you won it. If its not easily measurable, I'd suggest collecting qualitative user feedbacks about alternatives.


1

Though I like J. Jeffryes answer,my primary challenge with that is that not only are people who can code and design expensive,they dont really have time to focus on multiple tasks in parallel i.e. code and design at the same time.Also throw in the mix of having to attend UI reviews, usability testing sessions,code reviews and product management stuff and you ...



Only top voted, non community-wiki answers of a minimum length are eligible