As you are conceptualizing and planning a collaborative science project, your team will likely generate a short list of anticipated research products. Specific expected outputs can help focus and motivate project activities. However, teams should recognize that the form of those products will likely need to evolve as the team learns more about the management context, as research findings emerge, as accessibility needs become clearer, and as users offer new insights.

Your intended users' needs and preferences should guide the product type and format. Ask yourself critical questions like what how do we hope intended users will use this product? Is it practical? Are we including too much or too little information? Ask them whether it matches their intended uses.

The table below links to examples of the products we have seen emerge from collaborative research and science transfer projects supported through the NERRS Science Collaborative. These products are designed for a range of users, including restoration practitioners, planners, homeowners, K-12 teachers, outreach and training professionals, and technical staff involved in long-term monitoring.

For even more inspiration, you can browse the Science Collaborative Resource Library, which is a growing database of all the products generated by the projects supported by the program. The library also includes the more traditional research outputs (articles, reports, theses, presentations, datasets, etc.) that are not included in this table.

A key reason for engaging intended users is to gather input that will make project products more relevant and usable. However, intended users sometimes do not know exactly what they want until they see it. It is easier to provide feedback on a draft product than to sketch out an idea on a blank canvas. As a result, some of the best feedback is likely to come once a team has a draft product to share.

Projects that will be developing tools for users to use in their work should allow adequate time for those users to test the tools and provide feedback on them, and for the product developers to revise them in response to that feedback.

Testing could occur through a group workshop or through an independent exercise, but it should be focused and purposeful. Such requests as "Take a look and let me know what you think" will generate a range of responses that may be outside your intended scope for revisions or may not even be possible. Ideally, the testers you choose should span a range of technological, cultural, social, and accessibility perspectives.

It can be helpful to give users a specific scenario in which they might use the new resource and encourage them to go through an exercise that illustrates how it could be applied. Specific prompts will focus their feedback on questions most useful to the product developers.

Projects are often pieces of larger efforts that started before and continue beyond funding periods. Products may serve their purpose and meet a need in a brief time period, or be needed and useful for a longer duration – their longevity depends on context and intended use. When thinking about the appropriate lifespan of products, consider their long term utility and accessibility.

• Products don’t need to live forever. Be explicit about the intended lifespan of your products and/or whether you can commit to updating them.
• When products need to be sustained beyond the project end period, leverage support from partners who may be able to commit to upkeep.
• Everyone involved in product development should help envision and design the product during the scoping phase. Involvement from the beginning of the process will make it easier to commit to long-term maintenance and support.
• As your project wraps up, ask your users what they see as the lasting impact of the project, what they see as the most important products and outcomes. This can help shape your wrap up steps, and you may even be surprised and inspired to refine, repackage, or create a whole new product.