> For the complete documentation index, see [llms.txt](https://www.thinkinglikeyouruser.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.thinkinglikeyouruser.com/researching-your-users.md). # Researching your users While you can do your best to imagine how to think like your user, nothing substitutes for researching your user to better understand them. You can research your users to understand their needs and use cases, how they use a feature, or how they might use a future feature. There are a number of easy and quick methods to research your users including methods you can do without talking to your users and methods you do by talking to them. While it might be intimidating, ultimately the richest, most useful feedback comes from actually talking with your users. Additionally, keep an eye out for chance opportunities to research your users. While you might think you have little interaction with your users, most developers have more than they expect. When researching your users, keep in mind who you are interacting with and how they might differ from your target user. For instance, someone who is eager to talk to you and give feedback may have more time than your target user. Or if you are looking at analytics from folks who are already using your site, it will not give you insight into how to onboard new users. ### [Researching your users without talking to them](/researching-your-users/researching-your-users-without-talking-to-them.md) ### [Researching your users by talking to them](/researching-your-users/researching-your-users-by-talking-to-them.md) ## Analyzing your research ### Record and document If you talked to a user, write down everything you can remember immediately afterward. Document where you were, when, who the person was, and what they said or general impressions. Remember to keep identities anonymous, especially if you made a recording. For all methods, write down what you observed, your thoughts, and your conclusions. Documenting this is important since your memory is not infallible and it is useful to have as a reference when making your designs and communicating about them. Remember that you don't necessarily have to do whatever your user asks you to do. While your user will give you ideas of how to enhance your tool, you should not necessarily do what they ask. It is common that a requested feature is actually a workaround for some other part of the tool that is poorly designed. Take time to truly understand why they are asking for a feature to help you to decide if you should develop it or not. ### Consider other project priorities It is important to weigh your findings in the context of other project priorities. For instance, typically you want a user to go through an application as quickly as possible. However, it may be good to slow a user down in some cases, such as if you need them to think about the implications of an analysis before running it. It is also important to think about development time and the goals of your grant and/or funding agency and how the feedback fits in with them. This is a great time to go back to your [value proposition](/thinking-like-your-user.md#value-proposition-statement) and consider how the data you've collected is informed by it. #### Navigating Out-of-Scope & Uncomfortable Feedback Inevitably you will hear uncomfortable feedback from your users. Sometimes you want to implement a great feature, but it is out of scope for your tool and/or your funding source. Maybe you learn of a feature or design that you know would make the interface more usable, but there is simply no funding to develop it. Maybe you learn from your users that a cherished feature is not something they use at all, or worse, the main goal of your tool is not something that they need. Maybe they're using your tool for something completely different than what it was intended for. These scenarios are, unfortunately, common and it can be difficult to hear. In these situations, remember that something is better than nothing. Even if you're improving the interface for a small number of users, you are still improving the interface. Where possible, spend time on the parts your users actually use. This kind of feedback can also help you to target a different audience or adjust your value proposition statement. Finally, keep track of all feedback since it can be used to help write future grants that may be more in line with users' needs. Feedback that is out of scope can help drive future new tools or collaborations and funders appreciate concrete evidence that a proposed new tool is something scientists want. ### Don't take feedback personally No matter how you research your users, it is important not to take feedback personally. While you are likely heavily invested in your tool and want it to succeed, even the best idea may fall flat in front of a real-world situation. And remember that users are often the most frustrated with tools that they really want to use but can't. Try to remain objective and remember that the feedback is on the tool, not you. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.thinkinglikeyouruser.com/researching-your-users.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.