There's no difference in terms of the kinds of elements that you'd use (classes vs objects, kinds of arrows, etc.). It's the same kind of diagram. The difference is extraneous to UML and depends on the details of the development process people use; the difference is entirely in intent, and the level of detail needed.
UML is a communication tool & a thinking tool; diagrams can be used in formal documents (such as a specification), but you can also use them in informal settings, e.g., you and your teammates gathered around a whiteboard, trying to figure out how to approach the problem, what the "moving parts" are, what extra info you'll need to collect from your clients, etc. You don't have a specification, you're trying to come up with one. So, in this initial phase, people might be scribbling diagrams on the whiteboard to capture what's known, or to work through ideas etc. You might even have one of the business stakeholders in the room, and ask them to clarify things as you draw. (I'm not talking yet specifically about sequence diagrams, but diagrams in general.)
You are working with incomplete information at this stage, so your diagrams are not intended to be exactly what you are going to make in the end. They are high-level, conceptual diagrams, intended to give you a rough idea of what you're dealing with. E.g., the business people (your clients) might have mentioned that they need to have products placed into a small number of major categories, and then each is classified into a product type. So you draw a "Product" box, connect it with a "Category" box, and with a "ProductType" box.
The connections do not neccesarily mean that there's going to be a member field in a Product class that references an instance of the Category class. Maybe it will, but maybe the Category will be just a string, or an enum. Or maybe they'll be related by the database ID. You're just identifying general conceptual relationships between elements at this stage. Is Product represented by a single class, or is it a composite object made up of 3 classes? You don't know - you'll find out later, but at this stage, it's just a single box. What's the multiplicity on the Category end: 1, 1..*? Can a Product belong to more than one Category? You assumed not, but now that you think about it, the business people weren't clear about that. What should the system do if no category is specified? You'll need to find out all that too. But wait, to which box should the ProductType connect? Is ProductType really a subcategory, so that you can divide ProductTypes into these categories (so it should connect to Category), or is ProductType an entirely separate (orthogonal) property (so it should connect to Product)? If you had a business stakeholder in there, you could ask them which picture makes more sense.
So you see, these diagrams aren't detailed, they are rough sketches and are not set in stone. You might draw a bunch and then erase them, throwing them away. You might come up with something that you feel captures the big picture well enough, take a photo of that, and place it in an internal wiki or something. You're not going to expend a lot of effort writing formal documents containing these conceptual diagrams, because your conceptions will change as you learn more, and the exact details of the implementation might depend on the quirks of the libraries, languages and other tools you use to actually build the system.
You use sequence diagrams to work through, for your own understanding, (or depict, for others) a sequence of events in an interaction. But this is only really useful if there are some subtleties in the interaction that you want to emphasize. Something that may be confusing, or non-obvious (e.g., maybe there's a lot of nontrivial back and forth, or maybe the call goes off to some non-obvious object to make a decision, or maybe there's asynchrony involved). If the interaction is simple (like a straightforward sequence of calls), then just don't draw the diagram. You don't have to have every kind of diagram for everything.
My search so far shows the boxes on top of the sequence diagrams used
for design consist of objects, while the boxes used on top of sequence
diagrams for requirement specification contain classes
The boxes on top are always instances (objects) - classes are just static "blueprints" for how to create objects, and they don't really interact; it's object that talk to each other at runtime. (At least in the idealized OO world; you can tweak this to suit your needs; e.g. you might have static classes and/or free functions that you want to include.)
The boxes contain labels of the form
objectName:ClassName, but often you don't care about the object name, so you use an anonymous object, and write
:ClassName. So it's still an object, it just isn't named. Sometimes, people will not bother with these formalities, and will just write