> 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/bringing-ux-to-your-organization.md). # Bringing UX to your organization UX is often a core value of a company in industry because enhancing product usability directly results in more users and better sales. Scientific software, in contrast, is typically funded through grants from federal, state, or even corporate institutions. These funding bodies want software that solves cutting-edge problems using innovative techniques. Consequently, superior usability does not automatically yield additional financial support and thus has less priority over other objectives. Despite the lack of priority, it is still often possible to do UX. Scientific software developers operating within academic or governmental institutions often enjoy greater latitude to experiment with novel approaches. It is often best to proceed proactively—favoring action and seeking forgiveness over awaiting explicit permission. ## Advocating for UX For both people and funding organizations, the most important thing is to understand what is important to them and then to see how UX can help them achieve those goals. Include UX in grant applications whenever you can. Also keep in mind that some funding agencies are more interested in funding UX activities, such as CZI's EOSS. Some arguments that may help you to make your case: * UX is proven to reduce development time, reduce user support needs, reduce needed documentation, and more users (which you can show to funding agencies). [This infographic has citations of studies showing the power of UX.](https://frankspillers.com/making-a-strong-business-case-for-the-roi-of-ux-infographic/) * A great looking front page that clearly shows what the tool is for and how a user would start with a tool can help persuade funding agencies to fund a tool. * UX is innovative in the scientific software field. Very few scientific software organizations do UX, which makes this work unique. ### Publish papers and present at conferences The good thing about UX not being widely practiced in scientific software is that your UX work is innovative. Consider publishing a use case, even if it's only a preprint. Publishing is a great way to help your manager to see the benefit of UX, show value to funding agencies, and advance your own career. Some example papers that have been published include: * [Rose, et al. 2026 Understanding the Needs and Challenges of Cancer Registry Stakeholders.](https://ascopubs.org/doi/10.1200/CCI-25-00168) * [Paine et al. 2019 Experiences with a Flexible User Research Process to Build Data Change Tools](https://openresearchsoftware.metajnl.com/articles/10.5334/jors.284) Some good journals to target are: * [F1000](https://f1000research.com/) * [Computing in Science and Engineering](https://openresearchsoftware.metajnl.com/articles/10.5334/jors.284) Presenting at a conference is also a great way to show your manager and your funding agency what you are doing. Submit an abstract for a talk or poster about a UX project you did, even if it is small, to a conference like US-RSE. Apply for travel funds if needed. ## Common push-back #### 'We don't want to change the interface because our users are used to it and we don't want to lose them' Make the first project you take on something small that isn't on the main pages of the tool. Show how the process works and how it will ultimately help users, even if they have to spend a little time learning the new interface. You could also offer to do workshops for existing users. #### 'We already know what users want' Point out the ways in which your user is different from folks in your organization. Even small things like knowing what terms they use to refer to different types of data or analyses can make a big difference in the usability of your tool. #### 'We already do surveys' While surveys are a good start they are necessarily limited in what they can show. Users don't talk about why they answered a survey question a certain way, making it easy to misinterpret findings and difficult to know how to improve an interface. #### 'Just make the UI look better' Focusing on just the aesthetics limits the impact of your work. UX involves understanding users’ thinking so that you can make it easier and more enjoyable for them. #### 'User experience work is too expensive/takes too much time' In the end it's less expensive and takes less time to do it right from the beginning rather than fix it later down the road. View UX as a preventative measure or an investment that saves you time and work later. ## Mini Case Studies Developing mini case studies are a great way to keep track of what you've done, for your manager, your funding agency, and also for yourself. Document what was it before, what did you do, what was the outcome, and what was the impact of your work. Note interesting things you learned. Offer to share the document with your manager so that they can use it for grant reports and other places. You may decide to do a lunch presentation or similar on your mini use case so that others in your group can see how UX works and how they might also apply UX methods. This is also a great way to get more folks to join [your UX group](/support-yourself.md#start-a-group). --- # 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/bringing-ux-to-your-organization.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.