I'm a relatively recent practitioner, and although my work's quality is pretty good, I still have one big back-draw (in my opinion): I always miss something or two when making or fixing a web site.
What I mean is when I deliver the work required, I find out later that I forgot to design an interaction, include a link, include an element, fix how an element looks or even skip an entire page buried deep within the web site.
So, how do you insure that you've covered everything in your work?
You can't.
The best you can do is have a solid process for analysis, design and documentation that involves everyone who needs to be involved from both business, development team and users, review it, review it again, get a peer/colleague to review your work then have processes in place for revising the design during the development, testing and maintenance phases for when omissions or errors are noticed.
Firstly I sympathise, and I agree with the other answers. I'd like to add that this is one of the situations where agile methodologies have a big advantage in my opinion. It's perhaps not completely relevant to your situation if you're working on your own, but in a traditional waterfall process, it's often easy to miss things because requirements tend to change over time and things get dropped and picked up as priorities change. It's especially true of a large site with lots of content, or complex functionality.
However with an agile process typically you're working on a section at a time or building up in layers. So when you move on to the next iteration, it's a good time for your client or someone else (maybe the UAT team in a larger development environment) to review and test the work already completed before the product as a whole is released. This way you can come back to anything that's been missed or needs more work later. You can split the development as a whole into manageable chunks.
This is a great resource related to that http://www.useit.com/papers/heuristic/heuristic_evaluation.html
In general, heuristic evaluation is difficult for a single individual to do because one person will never be able to find all the usability problems in an interface. Luckily, experience from many different projects has shown that different people find different usability problems.
I agree with Nathanael, you can't.
Anyway there are some tips that may help you. Ask some expert (colleague, friend) to look through your work. It is so wholesome that I recommend to do it everytime. Make a short usability test. Use checklist (you may create your own or an existing one) to control quality. You may also try to perform use cases just to make sure that the interface actually works. All this increases probability to find something you've missed.
I agree that peer review is the best. It's also beneficial if you explain your designs to others, have a discussion about it. Even saying these things out aloud is often helpful for me.
And I'd recommend checking the designs from different viewpoints (user's, developer's, visual designer's, etc.).
It might help you rest easier if you reconsidered what the goal of the design work we do is.
Remember that the visuals, wireframes, persona, etc. aren't the designers' goal. Having a really great product is the goal. The former are just communication aids to help make the latter a reality.
Having complete 100% accurate design documentation isn't what we should be aiming for. We should be trying to provide the right information so everybody involved can work together to build a really great product.
Having a good process with lots of feedback, testing, and with the whole team understanding the design goals will be much more effective than eight binders of design documentation that nobody will every read covering every possible interaction and error state in exhaustive detail :-)
Pretend a very interested audience is asking you really good questions and spend an hour or two answering those questions by demonstrating the system. I find more bugs this way than any other way.
Someone else will think differently than you do, click differently, and look at a system differently. The less you can tell this person - your second set of eyes - the better. You don't want to accidentally lead them down the trail through the system you always follow if you don't have to in order to explain the system to them.
Install the site on a different server. Use a different browser or different browser version. Use a different operating system. Delete your cookies, turn off JavaScript, block cookies and try again.
A brief, high-level outline helps ensure you visit all the functionality you need to. Too much detail and you will focus on the test at the expense of finding issues. Also maintaining a detailed test takes a lot of time. Too little detail and you will miss critical areas of the system.
I recently saw a great entrepreneur video where they said, "The difference between Good and Great is 10 minutes." Which they explained meant that when you write your all-done email, don't send it. Get a coffee, walk around the block, then re-read your all-done email and try your system one more time from the perspective of the person you are sending it to. In software, that difference might be 2 hours instead of 10 minutes, but you get the idea.
"So, how do you insure that you've covered everything in your work?"
You adopt a design development methodology that accounts for this inevitability.
This problem usually arises in a waterfall (what I call 'assembly line' process) where things are signed off before a line of code is even written.
It's impossible to design every interaction completely on paper. Much of the interaction design decisions have to be made with working code. And since you don't have working code yet, then it's inevitable that things will be missed.
Ideally you'd be working in more of an agile system where you're designing as code as being written and both you and development are able to tweak things as you go along.
The really tricky things to watch out for are error messages, as often they are only triggered by a particular set of inputs.
You often need to simulate 'non compliant' user behaviour to make them appear (or realise that they should have appeared, and haven't...)
Eg things which cope with the irregular format of UK postal codes...
