Creating a specifications document or "mock-up" for a programmer (especially one overseas) requires 4 steps:
Designing the output/report
Finding the data
Designing for exceptions within the data
Designing any default values, and ensuring the output is accessible to end-users
This is as far as most customers get. They know the information they need in the final version of the report but don't have a good way of conveying this to the programmer. Solution: Put together an Excel file with the column headers you want to see when the report is done. Populate the report with some data.
Next you need to specify where the programmer should pull the data from. This can be table and column names or screenshots, but the programmer needs a starting point for finding the data.
At the end of the day, this report is being generated by a dumb computer. Therefore it is up to the client to make sure that the dumb computer doesn't OMIT certain data in error. For example if a report needs to include "all of the people in the system", does that mean all full-time employees, part-time employees, contractors, and vendors in the system? Or if the report needs to include "all widget batches created on this date" does that include batches that were abandoned or only partially finished? Does the report have status-based data, and if so, have instructions been provided for each of the statuses that should be included?
In addition to creating the report, it is important that certain users can run the report and view the resulting data. Sometimes this requires the creation of permissions tokens, or adding the report to a menu. Knowing what to call the report, and where in the menu to place the report, is critical to testing and using the finalized report.
In addition, there are usually some decisions that can be made during report design that make the report easier to run--setting default values is one way of doing this. There are other considerations that can also be taken into account. For example, are the users going to primarily view the data on screen or will they likely dump to Excel? Will those users use Pivot Tables to organize the resulting data? Will this report need to be emailed to a specific group of users on a regular basis? Reports can be designed to accommodate these needs, but only if requested.
Having a process for going through each of these steps and putting this information into a single file is incredibly helpful to both clients and their programmers. It dramatically cuts down on confusion and provides clarity regarding exactly what is being requested.