Tag Info

Hot answers tagged

15

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 ...


11

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 ...


11

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 ...


9

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 ...


6

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 ...


3

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 ...


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

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 ...


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