Read and quote books. When someone tells you it'll be great to have a navigation that is just icons and no text, quote Vincent Flanders's views on mystery meat.

To start, try these books:
Jakob Nielsen Designing Web Usability ^[1]
Steve Krug Don't Make Me Think ^[2]
Luke Wroblewski Web Application Form Design ^[3]
Joshua Porter Designing for the Social Web ^[4]
Robert Hoekman Jr. Designing The Moment ^[5]

Most experts have blogs, so read them too. In the case of Nielsen, there are years worth of knowledge to be gleaned.

You become an authority by doing, and by proving that you have the know-how and ability to become an authority.

Then, you'll start having your own ideas. If you wish, you can experiment with those ideas and write about them in journal papers. There are lots of journals and other publications dedicated to various aspects of user interface design that you should be able to submit the papers to. This will turn into presenting your papers at conferences.

Or, you could start a blog, and expound on your great insight there.

See also the Nielsen/Norman Group.

Also read "The Design of Everyday Things" by Donald A. Norman. It's dated, and the examples are not software, but they are oh, so important.

You could appoint yourself as one.

But otherwise, you could read:

Don't Make Me Think:

http://www.amazon.com/Think-Common-Sense-Approach-Usability/dp/0789723107 ^[1]

User Interface Deisgn for Programmers:

http://www.amazon.com/User-Interface-Design-Programmers-Spolsky/dp/1893115941 ^[2]

About Face 2.0

http://www.amazon.com/About-Face-2-0-Essentials-Interaction/dp/0764526413 ^[3]

I found the lecture notes for the MIT User Interface Design and Implementation useful:

http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-831Fall-2004/CourseHome/

I think the most important step you can take, if available to you is to take ownership of that part of the application stack. Many programmers, in my experience, tend to run from UI work. I'm not entirely sure why, but it happens. You can see it in action when you start playing with apps that have no-one owning the UI.

You know the type of apps, lots of functionality - no organization. Below the UI, often times, there is a very nice set of code - properly layered, unit tested and nicely refactored to use the latest 'best practices'.

It's a pity that to the end user, the UI is the application. It doesn't matter how fast the stored procedures run or how many transactions per second the app can hit. If the UI is a disaster, the app is a disaster.

Many of the suggestions listed are defiantly great places to start. I'm partial to 'Dont make me think'. Solid principles. Take ownership and be the UI guy.

Your customers will thank you.

I've found being able to show examples of what you're trying to achieve tends to go a long way to convincing people of its merits.

The following sites have been really helpful for showing different web designs in practice:

• UI Patterns ^[1]
• CSS Remix ^[2]
• Smashing Magazine ^[3]
• CSS Zen Garden ^[4]

Also, The List Apart ^[5] has a collection of fantastic articles on web design.

Not sure about the "authority" thing (that's something one earns, no way around that), but I think it's a very good start to read some famous books in the subject, like " Don't make me think ^[1]" and " Designing Interfaces ^[2]".

Other than that, is to develop an interest in the subject, for instance when you see a well-designed site, not only think "this is cool" and move along but try to understand which decisions were made, have a critical eye.

So, whenever people challenge you or say something stupid, you at least have the knowledge and the references to pull out.

I like the suggestions for learning, but as for earning "authority", try conducting A/B usability tests ^[1]. If your designs win, you'll gain respect, which should lead to authority.

Caveat: No UI tips here baby! Just tips on becoming an authority in general.

Check out I.M. Wright's 'Controlling your boss for fun and profit' ^[1]

Grow up, you weenies. Based on your pathetic excuses for inaction, nothing would ever get done. Don’t you think your bosses say the same thing regarding their bosses? If you don’t make desired change happen, it doesn’t happen. Period. The difference between you and someone powerful is not your level of control; it’s your willingness to act.

Related SO question: http://stackoverflow.com/questions/165985/resources-to-create-applications-with-a-great-user-experience

All great recommendations and references. I'll add just one idea: step out of computer UI design arena for a day or two and spend some time with print-oriented graphics design texts. (I wish I could name a couple of recent ones, but my experience in this area is pretty old. In any case, you'll find them in any big, art-oriented book store.)

Basic composition and layout techniques including variation in the sizes of visual features to indicate relative importance, use of clustering and alignment to indicate relationships or distinctions, recognition of the value of "empty" space, use of cues for easy scanning, use of color to create associations and distinctions. This is probably "art" training that, as a developer, you haven't seen since grade school and you may feel like a kid. That's OK. You may even be inspired to use colored paper cutouts arranged and rearranged on a white sheet to asses your layout.

This is a small but fundamental part of UI design and it's a part that most UI designers get wrong.

To quickly answer your question, yes there are books that you can read that can help you win these arguments, and there's also courses you can do to really understand where they are coming from.

Also, there's really two types of UI Designers: There's Visual and Interaction Designers. Visual Designers focus more on making it beautiful, Interaction Designers worry about Information and its layout. Which one do you want to get more advice on?

However, that being said, I think it's important to know what the problem here really is. To me, it seems that you don't respect, or really even understand, their contribution to the project and just want to get rid of them from the process.

If that's the case, maybe you should reflect on why your ideas on good interfaces are more important than other peoples.

By reputation only. You can read all you like but unless people recognize your work as quality then you will have a very hard time becoming an authority. If you believe that you are presenting quality work but not getting the recognition then you have a marketing problem.

Do you consider yourself to be creative? If yes, then start creating and get your work out there. Exhibit at trade shows and get into some mags. Write a white paper on an idea and submit it to a trade journal. This is not as hard as it seems. Find someone in your particular line of business and submit your work to them for peer review. Solicit feedback and take the good with the bad. Don't fall into the trap of actively promoting yourself as a UI designer. If your work is good and the right people get a look at it then you will earn that badge by reputation.

Above all, get into the head of the user and reflect your understanding of their world in your work. If you can consistently do this then you may become an authority.

If your ideas are good, but they are being ignored, then you have an influence problem, not an idea problem. The reasons people give for ignoring your ideas may not be their actual reasons. Are you significantly junior to them, or do they see it that way? Does your UI work step on the toes of people with a job title which suggests it is their territory?

Another thing. It sounds like you're pretty sure your ideas are better than the ideas of other people around you. If you honestly believe that's true, you aren't going to learn anything from these people. Consider moving to a place where you will learn.

All the book recommendations are great, but let me add in just one more title.

Stephen Few's Information Dashboard Design: The Effective Visual Communication of Data ^[1]

This book's mid chapters will put you through some visual exercises that prove to your very own eyes how the human brain breaks and segments the image of the real world it sees into groupings and objects. It is an "eye opener" indeed.

The knowledge and understanding of visual psychology cannot be underestimated.

I have a similar problem and am going to take a graduate course at my local university in GUI Design. It's included in the Software Engineering program. University courses are great for some people (not all) as it gives you a wide purview of the state of the field and you are able to tell if someone knows best practices or is BS'ing. I think Schools of Design also offer courses in this subject.

Other great reads with concrete, applicable UI/UX practices:

• Designing the Obvious ^[1]
• Sketching User Experiences ^[2]

Outside of the computer science departments, most systems engineering schools have courses about user interfaces. They often use the the term human machine interaction (HMI).

The way you get to Carnegie Hall: Practice. Study. Practice some more.

Oh, read The Inmates are in Charge of the Asylum Inmates are Running the Asylum ^[1] to find out why programmers as UI designers are often ineffective.

It's interesting that as a programmer you feel you wield little power over the interface. Interaction Designers are a relatively new profession and are constantly fighting to get authority. Here is the "call to arms" from 2003.

http://www.asktog.com/columns/057ItsTimeWeGotRespect.html

You can see that there is some insecurity. And it makes sense: If there is only a budget for one person to work on a project, and you need to choose between an interface designer and a programmer, who is more essential? (Not to say that interface designers don't contribute, but ultimately you will be building the interface.)

Also, as interfaces become more complex -- ajax, animations, etc. -- the simplistic boxes and arrows approach of many designers, managers and marketers simply isn't rich enough to outline the interaction. The design they provide will not describe all of the boundary conditions, and you can reveal the inadequacy simply by asking logical questions. What happens if this field is blank? Where does the error message appear? How does the user know the request was processed? etc. All of those decisions that the programmer needs to make are often invisible, and it's worth revealing how much you've already thought about the problem.

A final thought: Don't make butt-ugly designs. Ever. Even if it's just a throw away prototype. The interface is what everyone sees, and consciously or not, they will evaluate your code with it. Take a few minutes to select a red for the alert that isn't a garish (255,0,0). Don't have pixelated text. Spend time studying beautiful interfaces at look at the use of colours, gradients and shadows. You don't need to get obsessive about this, but there are many quick tricks that you can use to improve the look of a design. If people see more attractive output, there will be less of a chance of people stepping in and adding their own helpful opinions.

I don't see Jakob Nielsen's website www.useit.com being mentioned. It has some useful articles which are quite specific.

Some of the most interesting articles are on the topic of user testing, for example he finds that you don't need any more than 5 testers for most usability tests. This sort of advice can be invaluable, since based on intuition you'd think the more the better up till about 20 testers.

But be warned, when you look at his site, it's not exactly the most useful. He created before there were any hard and fast web design standards. In time his design has become something completely non-standard - not good from a usability perspective. But his argument is that consistency is what he is aiming for. Fair enough.

Once again www.useit.com

If the product your designing is ultimately going to end up in the hands of a client (which you hope it would), then unfortunately marketing people will always want to have their say as they feel they are responsible for branding and image. The same goes for any manager that has a stake in the product and wants to have their input. Unfortunaletly the designs' evaluation is subjective so you are always going to have difficulty in having final say (authority). You can reference successful websites like this one and use facts and figures to get people on board with your ideas.

As a developer you only become an authority by merits.

You'd want to have the designers as allies, not enemies. If both the designer and front end developer agree, the others will most likely trust you.

If you value their graphical expertise and have a friendly dialogue with them, they'll probably trust your usability expertise (assuming you actually have any;).

Try to implement their ideas even if you think they're crazy, if you find it impossible try making experimental branches and implement alternative solutions while keeping the "spirit" of their original idea. Designers love developers that don't defaults to "that's not possible" all the time (of course with web development some things is simply not possible, but try their ideas anyway, and demonstrate why something isn't optimal, and suggest alternatives).

Try arguing from the end users perspective when you disagree with the design, not that you personally dislike something.

Don't be too obsessed with writing pretty code, the users don't care how pretty the code is and nice user interfaces sometimes needs "ugly" code. My gui-code is mostly impossible to unit test (lots of classes within classes, classes where everything happens within the constructor and private methods, etc..), but the gui should be algorithmically trivial anyway...