I've been a part of several large-scope, big-budget projects over the past few years, and although I've always referenced my contributions, successes, challenges faced, etc. I've never provided screenshots, code, or anything else to prospective employers. And I do not think I will ever start doing so:
First of all, my former employers, most of whom I'm still on good
terms with, might not appreciate it.
Second, as you've noticed, there's typically a lot of context that
may need to be provided, and it gets very tedious.
Third, most early interview rounds are with people who essentially
play buzz-word bingo with your resume, and have no actual idea of
what they're looking at when confronted with anything more
complicated than Microsoft Office or their email client.
Furthermore, more complications can arise when some third party looks at code or interfaces you've designed:
Interfaces, like art, are often subjective. One set of users /
managers think it's great, others will think the colors are tacky,
Great code is often complex, relies on libraries, etc. and takes a
long time to understand. Maybe the person reviewing it doesn't like
some of the techniques you've used, or feels intimidated by the
complexity, and thus ranks you lower.
By far the best approach (IMO), is to do describe the projects you've been a part of, and your role in them. Describe the problems you've solved, and how you handled new challenges, etc.
Example: I was the senior technical specialist assigned to designed a new order system for so-and-so. Over the 12 months that I was a part of the project, I participated in numerous requirements gathering meetings, with managers and employees from 3 different departments. My role was to translate user requirements into technical ones, and to write comprehensive documentation. Later, when we had a solid idea of what was required, I was the one who created mock-ups of how the system would look, and how the process flow would work. This was an iterative process, with our users providing input, and our vision changing over the months. At the end of those 12 months, the project went into the implementation stage, and my role switched to ...
Being able to communicate your successes will do a lot more for you than simply relying on your audience to understand how great you are based on some code samples, or screenshots.
Similarly, your resume should read as a compressed version of that (too many times I see short bullet points that do not help candidates stand out at all), and you should be ready to explain your accomplishments/role at length in interviews.
Practice your explanations such that you can keep it short and sweet. Play a little buzzword bingo of your own, such that HR or recruiters can tick their check-boxes.
Most importantly, learn to tailor your explanations to your audience. Your contributions to the exact same project can be tailored to emphasize your team-working abilities, your communication skills, or your technical prowess. You have to understand which one you need to highlight based on who you're talking to.
For example, you may look at the technical interviewer when discussing code and technical challenges, then change focus and give the HR rep your attention when discussing how you handled user's fears that the system would replace them, etc. If the HR person is not in the room, but the manager is, instead mention the techniques you used to meet your deadlines, and how you communicated and accounted for any complications, etc.