You all know that feeling - something's got to give...Time, budget or features? Oh wait a minute...interface! That can give...our code is more important, that's what makes the product work, right? Well no. (And yes, but mainly no.)

The user (generally) only sees the interface, and has no concept of the code behind it.

I keep hitting this at the moment. Life isn't a green field project and it's inevitable you have to compromise, the issue for me is that UI / UX is often an easy target for 'not MVP' slashing. I see that's often acceptable, but sometimes it's a cut to far. This is for me where you have to choose your battles.

Where is the line?

For me, when I start a new project, I always aim for perfection. In the back of my mind, I am assessing where I'll pare that back to meet the inevitable constrains. I am also assessing a baseline of acceptable functionality, usability and user familiarity beneath which we cannot compromise.

The line is different for every project. I base this off the constraints and embrace change as it happens. This is really hard when it's a major change mid project, but things happen and sometimes you have to roll with them. (In my case, with accompanying grumbling!)

So how do you find this line?

Acceptable loss

I try to ask myself what is my motivation for arguing for this? If we lose this element, are we below the 'baseline' standard? Are we near enough the baseline standard that the next (inevitable) compromise will push us below it? Can we find a different solution that pushes us back up the scale of acceptable?

Sometimes, it's simply that I really like that element/feature/behaviour/colour. That's when I walk away...

Sometimes it's that I know a bar has already been set in the ether, that we will sink below if we cut something. This is harder, sometimes there is a compromise to be found, that still delivers enough that the UX won't be compromised, sometimes there isn't and you have to decide if you are better killing the whole feature than under-delivering.

Sometimes it's IE6. Check your logs, see how many IE6 users you have and if your client can live with loosing X% of non-upgraders. If they have corporate clients, often this simply isn't possible. In this instance, I've started to favour an IE6 specifically compromised approach. Make it minimally functional and that's it. (Or accept you need to double your project cost!)

Is massive improvement enough?

Often the starting point of a project is so bad, that you can't really help but improve it. The issue for me then becomes one of setting expectation for ongoing improvement. UX / UI (certainly in the agile context) is an iterative process and when you release, it's NOT done. On the other hand, I have to accept that a great improvement, is probably a totally acceptable compromise for release one.

Make friends not enemies.

I am not an island. I've found that if I can get people to mind-shift and understand the value of UX, I have an incrementally easier time when the next compromise has to be discussed.

My stance is to champion quality. I am not interested in glossy UI. (Nice though it is) I am interested in delivering a product for the client that turns users into advocates. I believe this is done by removing friction from their experience, making things easily usable and not forcing them to learn new interface models when the existing ones aren't broken.

Live with it.

I have to compromise. You will (unless you are omnipotent) have to compromise at some point. I try to compromise where it's OK, stand my ground, where I know I really should, and choose my battles everywhere in-between. If you battle over every last thing, you'll make enemies, not friends. This will make your life harder, I know, I've tried it in the past!

Something I've seen a few times recently is the current shift to mobile devices. Mobile devices offer additional functionality such as location. Here the compromise is dangerous. You can easily deliver a 'broken' experience by not embracing the technological expectation of the users. 'What, I can't search near me? Lame.' I also feel that just because you can, doesn't mean you should. The 'we need a mobile app' mentality only holds up, only if you really do. I try to persuade the client to think about their user, what is the mobile app actually allowing them to do?

Reality is that it's the new hotness and so you'll probably not win this one ;-)

Don't beat yourself up.

At the end of the day, I find, I live with relinquishing things and compromising by knowing that I've fought for the important stuff, and I hope that this communicates back to the team/client that I have the project's best interests at heart.