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 either one. How can I convey both elements more clearly and consisely?
What I want to convey:
- The business functions related to the specific metric ==> who in the sense of who might have to deal with the issue
- Why they would care ==> The specific issue the the application is meant to resolve
Current:
The intended audience is anyone tasked to ensure the accuracy of [analytic metric] generated by the their implementation of the [Specific Analytic Software] Platform, whether for [business function A], [business function B], [business function C], or [business function D].
Proposed:
The intended audience includes personnel tasked with ensuring the accuracy of [analytic metric] sourced from the [Specific Analytic Software] Platform. This information could be included within any of the following: [business function A], [business function B], [business function C], or [business function D].
Update
Based on your proposed solutions, here is my current, much improved take:
This application is for anyone in [business function A], [business function B], [business function C], or [business function D] who compiles [analytic metric] using (ESP). It is designed to help you ensure the accuracy of the [analytic metric] by connecting to ESP to generate and collect, in just a few minutes, related analytic and underlying data that would otherwise take hours to compile. The compiled information is then organised and presented in a way that makes troubleshooting and documenting specific [analytic metric] values easier.
Comments?
This post was sourced from https://writers.stackexchange.com/q/7271. It is licensed under CC BY-SA 3.0.
1 answer
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 comment threads
0 comment threads