 The New York State Department of Health developed the geographic aggregation tool, or GATT, as a way for anyone, irrespective of coding skills, to combine small geographic areas. I'll provide a brief overview of what GATT is and why we created it. Then I'll focus on strategies we use when developing GATT to reduce the need for users to know R. I'll speak from a public health perspective, but GATT can aggregate any geographic polygons by any numeric value, such as land area or species count. Why create GATT? Regional data can mask radiation, especially in regions with a mix of urban and rural populations. However, town-level data may be unstable due to very small populations. We aggregated census tracts for our project, both to combine smaller towns and to create smaller areas within larger cities. GATT's objective. We developed GATT to standardize our aggregation. GATT combines areas with small counts until those counts meet the user's minimum desired value. Since many public health workers are not computer programmers, we developed GATT to be accessible to non-programmers. I'll cover a few of the strategies that we used. User Dialogs. We developed a series of dialogues to walk the user through GATT's basic options using the packages TCLTK and TCLTK2. In the confirmation dialogue shown, the user verifies all selections. The drop-down list at the bottom allows the user to return to a previous step, correct their selection, and jump seamlessly back to this dialogue. Since this dialogue shows all basic settings that the user selected, someone can replicate results just from this image in the user's function call. Preparing for aggregation. GATT begins with the area with the highest count below the minimum desired value and selects the area to merge first based on the aggregation method chosen. For this illustration, we aggregate to the closest geographic centroid. How GATT aggregates. Here the minimum desired value is 5. The area with the highest value below 5 is E. GATT evaluates E's neighbors and determines the closest area is C, so GATT joins E to C. Aggregation continues until all areas contain values of at least 5. GATT's process. GATT generates several maps, including the one shown, which it writes to a PDF. GATT also writes a log of the entire process, a settings file, and unrequests a KML file. The PDF settings file and log are designed to help the user evaluate and report aggregation results. Last, GATT saves two shapefiles, a shapefile of aggregated areas and a crosswalk shapefile that adds aggregated area IDs as a new variable to the original shapefile. Reproducibility. The log. The log contains information about GATT's run, the input shapefile, merge settings, and the aggregation variables. The log helps users to first remember what settings they use six months later, second identify areas that may not have aggregated correctly, and third, read the output shapefile into another GIS program. Advanced options. The function to run GATT is aptly named Run GATT program. These options were placed here instead of the dialogues for two reasons. First, defaults for these options are what we most commonly use. Second, these options are complicated to explain. We felt that we could cover them more clearly in the technical notes and other documentation than in the brief dialogue instructions. Accessibility. Function help. This example shows the simplest dialogue in GATT. All dialogues and maps are drawn using functions that standardize their appearance. Because GATT relies heavily on dialogues, we included images of those dialogues in both the help functions and the vignettes. Help buttons in most dialogues can send users to relevant help files in case they do not know how to access help via the console. Accessibility, vignettes. We have developed eight vignettes in three general categories. Package information, technical notes, and using GATT. The vignettes and using GATT are designed for users with little to no prior knowledge of R. These include, first, how to structure the shapefile to be right into GATT based on what the user plans to do. Second, a step-by-step tutorial of using GATT with an embedded shapefile. Third, how to identify areas that may not have merged correctly so that the user can evaluate them separately. The tutorial includes links to other vignettes and help documentation for the relevant functions so that an advanced user who wants to customize GATT will know where to start. Takeaways. At all stages of development, we asked how to tailor an R tool for people who do not regularly use R. We wrote dialogue boxes to nearly eliminate the need to write code, documentation that catered to people with a wide range of R knowledge, and examples that detailed the necessary function inputs and could be run using only the resources bundled in GATT and the packages it requires. I acknowledge GATT co-author Gwen LaCelva, the CDC, and the many people who have tested and provided feedback during GATT's development. If you are interested in using GATT, please visit the GitHub link provided or email me.