Using Markdown
Last updated on 2025-10-30 | Edit this page
Estimated time: 12 minutes
Overview
Questions
- What is user experience research?
- What is user experience design?
- How can user experience research help solve usability and user problems and difficulties in software?
- How can user experience research be done in an effective and lean way in scientific software?
Objectives
- Understand the concept and importance of user experience research
- Learn meanings of key terms like ‘user experience’ and ‘research’ in the context of user experience research
- Recognize how user experience research can be applied to software in order to solve user problems and difficulties.
Introduction
User experience research is part of the larger ‘design’ or ‘Human computer interaction’ (HCI) field. This field includes both researchers in academic institutions and practitioners working at organisations and businesses. The practice of ‘User Experience Research’ is informed by its academic siblings but often evolves through both research and hands-on, commercial practice.
User Experience is a broad term used to refer to any and all users’ (humans typically) experience and interactions with software, technology or tools. User Experience Research is thus used to refer to the act of researching or investigating the subjective experience of users when interacting with software, technology or tools. This is done through a variety of methods and practices in order to gain insights and knowledge on how to make software, technology or tools work ‘better’ for those users.
Different approaches to definitions of User Experience Research exist e.g. Participatory Design, Co-design, Action Research, Usability Research etc. When we use the term ‘User Experience Research’ we are using this as a ‘catch-all’ term to describe whichever form of User Experience Research is most specifically relevant to you and your explorations.
User Experience Design can be described as the process of ‘designing’ (thinking about, planning, drawing, building, deciding etc.) a software, technology or tool’s ‘experience’. This includes, but is not limited to: What an interface looks like, what content/text is being shown/displayed to a user at what point and in what sequence, what sequence of actions is a user prompted to do via commands/buttons, etc.
Users can be defined in many ways, as builders, configurers and end-users of software, technology or tools. Exploring these definitions and characteristics are part of developing your own relevant and appropriate User Experience Research.
Problem scenario
Zarah has created open source scientific software as part of their research studies that performs image analysis specifically for plant science. This open source science software helps users to measure plant traits (aka phenotypes). At a scientific conference, Zarah meets Ester who has used her open source scientific software when conducting her own research on ocean-based plant life. Ester wrote a paper citing Zarah’s software, forked their repository and also logged a number of ‘bugs’ and ‘problems’ they had when using the open source software on underwater plants.
One of those ‘bugs’ was that using images of underwater plants while they are still underwater means that image recognition can become inaccurate and there is no way of letting the software know that the plant is in water when the image was taken.
Is it a technical bug or is it a usability bug?
This bug has some aspects that are user experience problems/challenges that can begin to be solved by understanding the user experience through research and addressed by making user experience better for this user’s specific case.
[Insert image/comic of a dev calling a bug a technical bug and a designer yes-and-ing it as a usability bug]
Using user research to understand the ‘bug’ more.
Let’s return to Zarah and Ester. Zarah was surprised when they saw a number of ‘bugs’ written by other people about the software she created. Zarah herself has only ever studied plants that grow ‘outside’ of water, so she never needed the image recognition software to do anything but be able to consider humidity of the air and perhaps water droplets on recently watered plants.
Zarah spends some time looking at these bugs in Ester’s forked version of the software. She notes down some common themes and categorizes them in order of what she knows the most about and least about in terms of water-based plants and image recognition. From this prioritised list of what she most wants to find out, she’s able to form some questions she could ask Ester (and other water-based plant scientists) about how they use the open source scientific software. She now has a list of questions, most are related to the bugs and some are more broadly about how others use the open source scientific software.
[Insert image/comic of notebook paper and a list of questions and plant drawings]
Zarah is about to email Ester and arrange a meeting to ask these questions. But she pauses and wonders how others ask these kinds of questions. She takes a moment to search online and discovers that there’s multiple methodologies that people use in order to ask questions to people that use software. Using the method of ‘Contextual Inquiry’ as guidance, Zarah sets up a time with Ester in the lab that she does her ocean based image research and watches Ester use the open source scientific software while asking questions from her list at the appropriate times Ester uses certain functions or comes up against ‘bugs’. Zarah discovers that while some ‘bugs’ are functional, some are that Ester uses the open source scientific software differently to achieve the same or similar conclusions. For example, Ester has to ‘hack’ the data to include different environmental criteria for the ocean-based plants and Zarah thinks this is more about offering flexible data entry options for people like Ester rather than assuming everyone enters the same data as Zarah does.
[Insert image/comic of two scientists in front of a computer with an ocean tank in the background with an interested lobster]
When Zarah is back at her own lab she looks at the data from speaking with Ester again. She notes that it’d be good to speak to more people that are using the open source scientific software differently to her and uses the information she gather from speaking with Ester to better contextualise existing bugs in her software repository as technical bugs or user experience bugs, where she then describes (without using Ester’s name) how the open source scientific software’s functions could be used differently and adapted to fit Ester’s use case and those like hers.
Inline instructor notes can help inform instructors of timing challenges associated with the lessons. They appear in the “Instructor View”
Discussion
What do you think Zarah’s next steps could be with her user experience research?
Discuss with a fellow learner what you’d be looking to do next if you were in the same or a similar situation.
Practice
Thinking about your own open source scientific software or a software you use regularly, what ‘bugs’ can you remember?
Which is the most prominent and do you think it’s a technical bug only or also a user experience bug and why?
Key points
- User Experience Research can have many associated terms and words with it depending on academic research or practice and the popularised terms.
- User Experience Research is largely about finding out about how users interact with software, tools and technologies and how that can inform changes and enhancements to software, tools and technologies.
- There are different methods that can be selected from to conduct User Experience Research as well as different data collection methods, insight generation from data and applications of those insights to software, tools and technologies.
- User Experience Research isn’t about discounting or discrediting the creators or maintainers own experiences of software, tools and technologies and is more about supplementing and enhancing them.
References
Citations and links to outside sources go here.