First, some criteria:


The product is an application and is heavy on user interaction.  Think web 2.0 or mobile application, not a marketing or commerce site, or some back-end tool with only command-line access.
I realize that it is not always clear who is a UX person and who is a developer (nor should it be), so I'd like to focus on overall team resource allocation.  For instance, "My team puts 25% of our resource-time into UX design/research vs. 75% of our resource-time in development."  
I am not distinguishing between front-end and back-end development as it is too platform-specific and difficult to tease out the dividing like.  It's all software development for this question.
EDIT: Development is occurring in an agile-esque, ongoing manner, rather than a one-time, big-bang delivery.


So:


How does this proportion commonly look in practice?
How should it look?  Or, better yet, what has been the proportion on successful teams?


(I realize this is a classic "it depends" question, but I suspect that there is some use in asking when constrained by a few parameters, and allowing that conditions will vary.  I am also open to suggestions to further constrain the question.)


Question: Cannot access non-static field
Answer: We have worked hard to give error messages that are accurate, so read them carefully. The error message is telling you exactly what is going wrong: you are accessing a non-static field in a context where it is only legal to access statics.

So why is a base constructor call argument list a context where it is only legal to access statics?

When you call a base constructor, the arguments you pass must not reference "this". Why? Because neither the derived constructor nor the base constructor for your "this" has run yet, and therefore "this" is almost certainly in an inconsistent, partially-initialized state. That is a recipe for crazy bugs. We therefore restrict you from accessing "this" until we know that at the very least, the base constructor has run.  

This feature encourages sensible, well-ordered, understandable, maintainable and bug-free construction logic; I recommend working with, not against, those safeguards.