pyRTC

To view full case study, please use tablet or desktop device.

SHARP Imaging Lab Logo

Team

Myself (UX Designer)

Brian Ho (UX Designer)

Emma Luo (UX Designer)

Overview

Redesigned a command-line based open-source software during a Master's level capstone project for adaptive optics astronomer towards a new target demographic of new researchers.

Timeline

4 Months (Jan—Apr 2026)

Tools

Figma, Tailwind CSS, Lucide Icons, Microsoft 365

Contributions

UX Research, User Interviews, Data Analysis, Visual Design, Stakeholder Presentations, Prototyping

Contributions

UX Research, User Interviews, Data Analysis, Visual Design, Stakeholder Presentations, Prototyping

Highlights

A customizable, unified, drag and drop dashboard for increased efficiency.

A customizable, unified, drag and drop dashboard for increased efficiency.

The SHARP Imaging Lab requested a modernized UI with a lower barrier to entry for new users. We delivered three core user flows covering onboarding, the dashboard view, and an API reference library, alongside a full brand redesign built from scratch.

The SHARP Imaging Lab requested a modernized UI with a lower barrier to entry for new users. We delivered three core user flows covering onboarding, the dashboard view, and an API reference library, alongside a full brand redesign built from scratch.

Beginner dashboard view

Beginner Dashboard

Loading screen with pyRTC logo and log-in prompt

Landing Page

Onboarding step 4, asking user "what do you want to do most?"

Onboarding

API Reference library screen

API Reference

What is pyRTC?

A locally run, open-source software for adaptive optics (AO) combining python and real-time controller (Taylor J., Swanson R., & Dungee R.).

Adaptive optics is a technology that corrects atmospheric blur, artificially making telescopic images clearer, containing multiple live monitored components customized based on the setup.

python coding language logo
circut icon
py
RTC
Python
Real-time
Controller

Proposed Problem

Adaptive optics software's are complex, fragmented ... and outdated.

Adaptive optics software's are complex, fragmented ... and outdated.

No current AO software is as versatile or easily customizable as pyRTC. Most competitors are built on C (1972), which creates a steep learning curve for researchers who aren't dedicated software developers. pyRTC's Python foundation lowers that barrier significantly.

No current AO software is as versatile or easily customizable as pyRTC. Most competitors are built on C (1972), which creates a steep learning curve for researchers who aren't dedicated software developers. pyRTC's Python foundation lowers that barrier significantly.

Discovery

How might we turn this into a unified, simplified space to foster learning?

How might we turn this into a unified, simplified space to foster learning?

Outdated Keck observatory competitor dashboard example with old interface design and crowded windows

Source: J. Lyke, "AO Overview: Night Operations," W. M. Keck Observatory, July 8, 2021.

Primary Users

Early career astronomers

Secondary Users

Expert researchers

Primary Stakeholders

pyRTC creators, Graduate students

Secondary Stakeholders

Early career astronomers

Source: J. Lyke, "AO Overview: Night Operations," W. M. Keck Observatory, July 8, 2021.

Lab Field Visit

To properly immerse ourselves into the hands-on operations of adaptative optics users, we visited the Dunlap Institute of Astronomy and Astrophysics to receive a tour of a typical workspace, take reference photos for design inspiration, and better understand any unfamiliar concepts. We found users tend to work in isolated, dark, environments and with optical tables simulating telescopic blur.

Note: Photography was restrictive due to proprietary hardware being developed in the facility.

Note: Photography was restrictive due to proprietary hardware being developed in the facility.

User Interviews

Methodology

Methodology

Three virtual interview sessions were conducted between 30-45 minutes each, two individual interviews and one group interview, transcribed and recorded with consent. Participants were industry experts at various institutions (UHawaii, U of T, Caltech).

An interview script guided topics including current workflows, tool usage, pain points, and GUI expectations, with follow-up questions.

Three virtual interview sessions were conducted between 30-45 minutes each, two individual interviews and one group interview, transcribed and recorded with consent. Participants were industry experts at various institutions (UHawaii, U of T, Caltech).

An interview script guided topics including current workflows, tool usage, pain points, and GUI expectations, with follow-up questions.

Personas

Personas

Tiffany Kim Persona Profile
Ryan Chen Persona Profile

What did we discover?

Interview responses were coded and clustered into themes across workflow patterns, environment, competitor tools, and documentation gaps. Five recurring pain points emerged, directly informing our problem definition and design priorities:

Interview responses were coded and clustered into themes across workflow patterns, environment, competitor tools, and documentation gaps. Five recurring pain points emerged, directly informing our problem definition and design priorities:

  1. Inefficient Workflows

Routine tasks require repetitive command-line inputs, slowing down even experienced users.

  1. Non-interactive Data

Data streams are visible but not interactive. Values can't be inspected or replayed without manually saving each.

  1. Unavailable Documentation

Knowledge is scarce and often verbally passed down, leaving newcomers dependent on supervisor guidance.

  1. Optical Tables, not Telescopes

Most users interact with pyRTC on optical tables (contrary to our previous assumption) in lab settings, so the interface needs to support an experimental, tinkering workflow.

  1. Error Prevention

Small code errors can disrupt an entire loop and cause data loss, making clear feedback and error recovery essential.

So, we shifted our focus …

How might we design a unified, simplified space that makes AO tasks *efficient* for researchers at every level?

How might we design a unified, simplified space that makes AO tasks *efficient* for researchers at every level?

Design

Ideation

Early Concept Board

To centralize workflows and reduce reliance on external tools like Notepad and VS Code, we focused on a customizable bento-box dashboard that keeps command-line access available but out of the way for new users.

To centralize workflows and reduce reliance on external tools like Notepad and VS Code, we focused on a customizable bento-box dashboard that keeps command-line access available but out of the way for new users.

pyRTC Early Concept Wireframe Board for Dashboard Layout

User Flow Wireframes

  1. Onboarding

Role-based setup to personalize the dashboard on first use.

  1. Dashboard Interaction

Modular data viewing with flexible layout controls.

  1. Glossary and Tooltips

Embedded documentation for navigating pyRTC functions without leaving the interface.

Branding and Visual Identity

Logo

Following the field visit, I sketched concepts for a new logo. The final design depicts two lens flares and a simulated star, with colours derived from a photograph of the optical table wavefront sensor.

Following the field visit, I sketched concepts for a new logo. The final design depicts two lens flares and a simulated star, with colours derived from a photograph of the optical table wavefront sensor.

Dunlap Lab Visit Lens Flare Surrounded by Logo Ideation Sketches
pyRTC New Logo with Start and Two Lens Flares

Icons

Alongside Lucide Icons, I created custom icons specific to adaptive optics and repurposed existing ones to fit the hardware schema of pyRTC.

Alongside Lucide Icons, I created custom icons specific to adaptive optics and repurposed existing ones to fit the hardware schema of pyRTC.

  • Wavefront

    Sensor

  • Deformable

    Mirror (DM)

    *custom

  • Science

    Camera

  • Interaction

    Matrix

    *custom

  • Wavefront

    Slopes

  • Adaptive

    Optics ON

    *custom

  • Adaptive

    Optics OFF

    *custom

  • Strehl

    Ratio

  • Turbulence

  • Guided

    Star Source

    *custom

  • Point

    Spread

    Function

  • Error

    Alert

Design System and Style Guides

Design System and Style Guides

A complete set of documentation of style guides including colour palettes, icons, typography, spacing, and Figma components.

A complete set of documentation of style guides including colour palettes, icons, typography, spacing, and Figma components.

pyRTC Sample of Figma Design System and Style Guide Reference Pages

Solution

Design Decisions

After collecting feedback from the usability testing the mid-fidelity prototype, we implemented minor changes to the final hi-fidelity prototype, resulting in these 4 features:

After collecting feedback from the usability testing the mid-fidelity prototype, we implemented minor changes to the final hi-fidelity prototype, resulting in these 4 features:

  1. Optional Command Line Access

  1. Optional Command Line Access

When selecting a data block component, a command line terminal pops up on the dashboard and jumps to the corresponding line of code to the hardware. This was an early idea that users reported enjoying using because of familiarity.

When selecting a data block component, a command line terminal pops up on the dashboard and jumps to the corresponding line of code to the hardware. This was an early idea that users reported enjoying using because of familiarity.

Coding terminal pop up on left side of pyRTC dashboard redesign, pushing data blocks towards the right side
  1. Targeted Start/Stop Controls

  1. Targeted Start/Stop Controls

Added per-component controls for each data block in response to user feedback, and replaced tooltips with a quick access menu after accessibility concerns were raised in peer critique.

Added per-component controls for each data block in response to user feedback, and replaced tooltips with a quick access menu after accessibility concerns were raised in peer critique.

  1. Dark vs. Light Mode

  1. Dark vs. Light Mode

All four interviewees reported working across a variety of environments and times of day, so we incorporated both a light and dark mode to accommodate those conditions.

All four interviewees reported working across a variety of environments and times of day, so we incorporated both a light and dark mode to accommodate those conditions.

Cursor clicking between light and dark mode
Older glossary prototype screen
  1. API Reference Library

  1. API Reference Library

During testing, a glossary seemed to be underwhelming and Jacob Taylor (creator) suggested added an API reference within the settings instead, changing the entire function of the third user flow.

During testing, a glossary seemed to be underwhelming and Jacob Taylor (creator) suggested added an API reference within the settings instead, changing the entire function of the third user flow.

Hi-Fidelity Prototype

Learnings

Designing for specialists.

Entering this role with no astrophysics background, I had to build empathy from scratch. A lab visit to the Dunlap Institute and structured interviews with researchers helped me understand user needs and how they interact with both the existing tools and our prototype.

Entering this role with no astrophysics background, I had to build empathy from scratch. A lab visit to the Dunlap Institute and structured interviews with researchers helped me understand user needs and how they interact with both the existing tools and our prototype.

Open-source, developer ready hand-off.

We made the deliberate decision to use the open-source tools for an open-source software: Lucide icon library, Tailwind CSS-compatible colours, and safe accessible typography so that any developer picking up the files could extend the design without friction.

We made the deliberate decision to use the open-source tools for an open-source software: Lucide icon library, Tailwind CSS-compatible colours, and safe accessible typography so that any developer picking up the files could extend the design without friction.

Unexpected stakeholder inputs.

Mid-way through the design phase, we discovered that Jacob Taylor (pyRTC creator) had independently started vibe-coding a version of the dashboard himself. It was validating that our design decisions aligned with his instincts, but also meant pivoting quickly to reconcile two parallel directions. This reminded me that design rarely stays static, continuously improving.

Mid-way through the design phase, we discovered that Jacob Taylor (pyRTC creator) had independently started vibe-coding a version of the dashboard himself. It was validating that our design decisions aligned with his instincts, but also meant pivoting quickly to reconcile two parallel directions. This reminded me that design rarely stays static, continuously improving.

© 2026 Rea Sahi.

© 2026 Rea Sahi.

© 2026 Rea Sahi.