To the 3 separate comments on not using IDE below: I am aware of the flaws and I would never use it in a continuous deployment environment, but it's a good gateway tool to get into the mindset of automation testing before moving on to other methods, such as using webdriver from a unit test framework or building a full blown framework (I'd put PageObjects somewhere in the middle).
There was a point for each of us where we had no used an automation library. I think the IDE is a much more accessible way to get in, play around, learn what can be done, and do some very basic tests than it would be to hand them a library and expect them to be able to code up a similar set of tests.
Selenium IDE is a bad road to go down if you're in any type of continuous deployment environment. Your test suite is unmaintainable after a dozen or so cases. What has worked for me is to use WebDriver directly, and to separate the testing and implementation logic. The testing side is driven by standard JUnit fixtures, and the implementation side follows the page object design pattern. Now even with huge changes or "pivots" to the UI, you only have to update a few xpaths and setter/getters in your page objects.
Selenium IDE is good, but it honestly isn't a huge step up to use Selenium proper (the WebDriver variant)- it's certainly something the HN crowd would be capable of doing. That way you can use more than just Firefox- we have tests running in IE, Chrome and Firefox regularly.
Selenium is really great. Easy to use, effective. One pitfall to remember: Any UI change (e.g. renaming a link) requires to update the test. On new sites these changes occur a lot, so try to focus on the main theme that changes less freq.
There was a point for each of us where we had no used an automation library. I think the IDE is a much more accessible way to get in, play around, learn what can be done, and do some very basic tests than it would be to hand them a library and expect them to be able to code up a similar set of tests.