> 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/home.md). # Thinking Like Your User A practical User Experience Design guide for busy scientific software developers. You are a busy developer with little time and few resources but you still want your tool to be intuitive for researchers and scientists who will use it to advance their field. You may never have heard of User Experience Design, or if you have, you might worry that it will take too much time or resources. Or maybe you are interested in User Experience Design but you're not sure where to start or how to convince your organization to let you do it. If so, *Thinking Like Your User* is for you. ## What is User Experience Design (UX)? User Experience Design (UX) is a mindset where you consider the perspective of your users (i.e. think like your user) when developing a tool. It is also a set of practices and methods to help you achieve and center this mindset. Ideally, you would have this mindset from the beginning of development, including the initial conception, but it can be applied anytime during the development process, including after it has been released. There is no one agreed-upon definition of UX, but a useful one is: UX is design that is based upon an explicit understanding of users, tasks, and environments and is refined by user-centered evaluation. ## Why UX? UX is a research-backed method to improve the usability of software, including scientific software. In traditional software spaces, UX is a well-recognized, core engineering practice, complete with university-level degrees, teams/departments within companies, career ladders, and more. [UX is proven to reduce development time, reduce user support needs, reduce needed documentation, and get more users.](https://frankspillers.com/making-a-strong-business-case-for-the-roi-of-ux-infographic/) ## Key components of UX **1. Think like your user.** Except in very unusual circumstances, you are not your user. Even if their background is somewhat similar to yours, your user doesn't have your exact knowledge, skill set, or experience. Thinking like your user starts with understanding what makes folks want to use your tool. What does it do that they need? **2. Evaluate your tool.** Take your users' perspective and bring it to your tool. Try to see the tool through their eyes. Understand where your tool functions well and where it could be improved. **3. Research your user.** Learn about your user, their needs, their goals, their thinking, through research. This can be done by both talking to them and also without having to talk to them. **4. Have a design.** Don't start coding and hope for the best. Spend time thinking about what the final product will look like and how it will work for your user. What is the layout? How will the user move through the tool? ## What UX is not … **Making it look pretty.** UX is about how the tool helps users to achieve their larger goals, how a user moves through the tool, and how the tool fits in within the larger ecosystem. A tool can be visually appealing but still difficult to use. **Getting a list of feature requests from your users.** While you will get feature requests from your users, UX is about understanding how your user thinks. This deeper understanding will enable you to prioritize functionality that will actually help your users. **Ignoring other project priorities.** Some features that would greatly improve the usability of your tool are simply not feasible. Priorities like development time, project scope, and funding requirements are just as important as UX and need to be kept in mind. --- # 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/home.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.