: How can I express this fragment more clearly and concisely? For the 'who is this application for' section of an application user guide, I have the following alternatives, I'm not happy with

Vote Up Vote Down

For everyone who wants to control the accuracy of [analytic metric] of their [Specific Analytic Software] Platform implementation. No matter if it is for [business function A], [business function B], [business function C], or [business function D].

Your examples are exactly in that formal tone that makes me fall asleep. Some guides are forced to be written in that tone, because of bosses who have no single clue about user guides (or especially users). I hope you do not have to suffer one of these.

I wouldn't use adjectives (or derived adverbs) like "quick" and "easy". Always I read stuff like this I think automatically "Oh, what a splendid idea. I always try to make my programs slow and hard to comprehend". (Add sarcasm tags at will.)

(0)

Vote Up Vote Down

[The application] is designed with [business function A], [business function B], [business function C], and [business function D] in mind, with the specific purpose of ensuring accuracy of [analytic metric] generated by your implementation of the [Specific Analytic Software].

As I understood, some unfortunate code monkey gets tasked with debugging a huge enterprise software product using your tool as aid in understanding what happens under the hood of that ESP. That would mean the actual intended audience is the overlords of that code monkey.

Putting it in more PC terms, the intended audience is the businesses which perform functions [A,B,C,D] and the actual use/purpose is ensuring the accuracy.

The fact this purpose is achieved by harnessing said monkey to your tool and letting them loose on the ESP, is out of focus of the the business-side, an insignificant detail left for the technical crew which won't be interested in that section of the document anyway.

(0)

Vote Up Vote Down

Try something like this:

This application is for users of (ESP) who need to understand its results quickly and easily. (Product) takes the metrics compiled by (ESP) and presents them in a way that makes troubleshooting and documentation easier. (Product) produces reports for (business function A), (business function B), ... .

Rationale:

First, explain how it fits in with the context they already know. Then tell them how your product fits into that world; they (presumably) know the pain of dealing with (ESP), but they've never heard of you. Focus on what your product does for them, rather than who they are; if you say, for example, that a product is for users of type X, then users of type Y who also need to do that thing may not realize you can help them. But everybody has some idea of the problem he's trying to solve. (Well, usually. We hope. :-) )

Depending on your house style, you might want to list the business functions your product addresses in a bulleted list instead of in running text like above. This helps people who are skimming. Think about the last set of product specs you read (online, on a physical package, or whatever); it was probably a list, wasn't it? It was designed to make you quickly realize "I need this"; so too is this section of your document.

(0)