Integrating UX Design in Astronomical Software Development: A Case Study

TL;DR

ASTRON addresses the problem of under-emphasized UX in astronomical software by embedding a dedicated UX designer into the development process since 2023. The paper describes the approach of building a UX vision with personas and user-journey mapping, using clickable mockups for rapid feedback, and establishing a design system to support consistent UI across services such as data discovery and data access. Key contributions include a practical, repeatable workflow for integrating UX into scientific software and guidance for adapting these practices in other projects. The work demonstrates that a dedicated UX role and structured UX artifacts can improve accessibility, usability, and interoperability of astronomical data services, with broad implications for the community.

Abstract

In 2023, ASTRON took the step of incorporating a dedicated User Experience (UX) designer into its software development process. This decision aimed to enhance the accessibility and usability of services providing access to the data holdings from the telescopes we are developing. The field of astronomical software development has historically under emphasized UX design. ASTRON's initiative not only improves our own tools, but can also be used to demonstrate to the broader community the value of integrating UX expertise into development teams. We discuss how we integrate the UX designer at the start of our software development lifecycle. We end with providing some considerations on how other projects could make use of UX knowledge in their development process.

Figures (3)

• Figure 1: Outside the dashed area: Example of a user persona we define, in this case an optical astronomer named Sarah Jackson. Inside the dashed area: Except from the analysis exercise for the Data Discovery and Access function of our system, based on Sarahs needs. From top to bottom, the stickies of different colour represent different granularity of components, if appropriate or needed.
• Figure 2: An example of a mockup for a data query interface. By making the mockup clickable, users can be asked for feedback on the behaviour of the application before implementing any logic.
• Figure 3: View on the design system used in our development process. In this figure, the Button object is selected. The first element, called Docs, describes the type of object, shows how it looks and provides the user with all options that can be chosen (e.g. colour, icon, function), which then shows the actual code that can be used in the application. Below it in the menu, different types of button with specific properties can be shown (e.g. a submit button, or a button with an icon).