Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

What's the common practice for warranty chapters in technical manuals?

+1
−0

I'm working on a technical manual project for industrial machines and the original documents have some warranty warnings and statements at the beginning. We decided to keep them on the new documents but there were some objections from the team members. They've suggested to separate the warranty chapters from the main manual and handle them as individual documents. Their argument was that the warranty topic is something different from the user's manual and that it should be presented to the customer in a different format. The final decision was to keep them in the main manuals because most of their competitors do include these chapters in their manuals, too.

My question is if there are some general rules or common practices on warranty statements in product documentation? How do technical writers handle this subject?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

This post was sourced from https://writers.stackexchange.com/q/16840. It is licensed under CC BY-SA 3.0.

0 comment threads

2 answers

You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.

+0
−0

I would put them at the end as appendices. That way they're part of the documentation but not in the way when someone goes to look up a feature. But I actually like the idea of having them as part of the documentation, because individual documents mean more moving parts, and a smaller physical document (like a warranty) can be easier to misplace than a thick instruction manual.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

0 comment threads

+0
−0

This is a decision you need to make in consultation with your company's legal advisors. The ability to defend against claims is affected by both what the warranty says and how prominent it is. A separate document or appendix that people are less likely to read might cause problems in this area. (Never mind that users are trained to skip past all that stuff at the front of manuals in consumer products...)

In my position I don't have to deal with warranties but I do have to deal with licensing terms, a similar case. We have restrictions on what you can do with our product based on what license you bought; that text is owned by product management and we technical writers don't alter even one word without discussion. The placement of that documentation in the doc set (ours is part of the bundle too) was worked out with product management. I would personally prefer that this be in a separate document (that product management can then maintain), but it's not my decision to make.

I suggest that you consult with your product manager if you have one or your team lead otherwise, to make sure you know all the requirements before you act.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »