In UX, it should all start with the user. Everything from visual design to information architecture flows from the needs of the user. If I don't have the resources to be conducting field research or testing with an audience other than close friends and family, how should I approach UX? Is there a methodology that is more effective than using my best judgement (and taking advice from UX Stack Exchange) to guess what will work best?
You should always start by asking yourself who are your users, what is their operational context and what is their task. There is always an initial assumption in every design, which is then refined and corrected through exposure to users.
If you don't have resources to talk to people, you should still be able to find a wealth of information about the goals, priorities and abilities of your target user population. You can reuse user research done in similar contexts and infer scenarios and personas from all that to help you to stay focused during your design iterations. An idea persona is grounded in real data about your real target population but I do believe a made-up scenario based on a decent understanding of the existing literature is much better than nothing!
Once you arrive at the stage where you know what interactions you want, you should not be shy to confront them to other people around you, even fellow developers, so long as they have a rough understanding of the users, context and tasks as well. This is mostly about spotting common mistakes in your mockups. If you have very limited resources, remember that the fidelity of the interaction (i.e. having controls and feedback loops in whatever ways you'd actually want them) is more important than visual fidelity.
Then comes the stage where you have a user interface prototype for each of your tasks (note that this equally applies to Web pages, software and everyday life tools; you always have an interface). Put it in the hands of various people who just happen to be available and observe them use it. You could look for issues outlined in Nielsen's Heuristics Evaluation, for unexpected uses of your tool (tasks you hadn't identified), for interaction breakdowns (when people have to actively rationalise your tool to use it rather than use it intuitively).
In parallel, ergonomics practitioners tend to take some time to brainstorm on misuse cases: for instance how a child might lock himself up inside a washing machine. Likewise, how can your UI prototypes be accidentally misused and how can you avoid this? In physical UIs you'll be particularly wary of button placements, whilst in software UIs you need to pay attention to irreversible actions that can be triggered with one click.
Another creative exercise that only costs you your own time is to question your own design decisions: systematically ask yourself "Why" you put a button here rather than there, or why a specific sub-task can be accessed only on certain UIs, etc. Do several iterations at different stages of your design to see if your justifications still hold!
Hope it helps.
Don't let the word "research" scare you. Field studies and formal usability testing are great, but they're just tools. They're the band saw and the welding torch, perhaps, but still just tools. Hammers and screwdrivers are also tools and, due to their simplicity, probably even more useful.
User research means seeking new knowledge about how people use your product or service. That means looking (a) at the people, and (b) at the product when people are using it. If you don't have an existing product, the same reason applies to any prototype of one.
Looking at the people
How do people solve the problem your product solves without your product? What homegrown solutions have people developed? How do they feel about your competitors' products? A lot of this is just a Google search away.
Do your customers exist in a community? Do they talk to each other? Do they do it in an online context, like Facebook or Twitter or a forum? Why not read up on what your users are saying; you can even ask questions to follow up on areas of particular interest.
Do you provide customer service? Do you have records of that? Look through those records and try to identify patterns of behavior or perception that suggest an incorrect mental model of your product.
Looking at the product
Capture video of people using your product; apps like http://silverbackapp.com/ let you do this quite cheaply. I also highly recommend Remote Research (free) and the accompanying book (cheap) as resources on finding tools that will let you see what users do.
Provide ways for users to give feedback as they're using the product. I like UserVoice for this; it's free for a single user (with limited functionality) and wicked easy to set up. Fair warning: when you start to scale, it does get pricey; hopefully at that point your UX is good enough you have some money to play with.
Test aspects of the design with the fidelity of user that matters. If you're designing software for doctors, it can be prohibitively expensive to get them in to test your product. But 95% of the product is interaction and navigation and visuals; a med student or even just a functioning adult could be a test subject and provide 95% useful feedback. We're all human and our brains are all wired disturbingly similarly.
All of this hinges on two things.
User research with limited resources
There are some very good UX research techniques which can be used at nearly zero cost and which provide some very useful information.
1. Card sorting
Card sorting is a great way to evaluate information architecture. Participants organize topics into categories that make sense to them. Provide a number of cards to test users with your websites topics on them. Ask your users to organise the cards in logical groups. Read more here.
2. Paper prototyping
Wether or not based on a previous card sorting test, you can also create and test user interfaces very low-tech using paper. It's way easier to make adjustments to this paper prototype than the final design. It happens A LOT that a client asks for adjustments concerning design during development. Make a desktop - tablet - mobile version. Read more here.
These techniques are so low-tech they require very little resources. You can get test users literally everywhere, but try to test with users of your target group.
I have the same problem. Through others I deal with the managers and can't get through to the users. Luckily my boss has a heart for quality and usability.
Even though I can't ask if I can observe users while they use the software, I do have the developers around me in the office who made and use the software. We came up with a plan to encode metrics in the search options and filters. If I can't watch the users from the outside, I might as well try watching them from the inside. It is certainly not the best solution. But if the access to users is blocked it might be the only option to find out how they go through the system.