Pyret Programming Language
Team
1 Project Lead, 2 Tech Leads, 1 Design Lead, 2 Designers, 4 Developers
Impact
Led design direction of Pyret
Pyret was introduced in Fall 2025 at Northeastern, its new launch leaves us with zero historical data on how students actually use the language.
About
Pyret is a beginner programming language with education designed at its main goal. It's used across Brown, Northeastern, and WPI, and also by middle and high school students nationwide. At Northeastern alone, 850+ students have utilized the language so far. The language is under active design and development.
As the Design Lead, I worked directly with engineering leads to understand the logic of Pyret's unconventional LSP (Language Server Protocol)* features, successfully mapping these into initial design flows.
The Pyret maintainers wanted to improve the student experience but lacked any user data to inform those decisions.
*An LSP is like an universal translator that allows code editors (like VS Code) to speak to specialized "language intelligence" tools; providing features like autocomplete, error checking, and "go to definition" across different text editors, making writing code much faster.
Problem Statement
How might we establish a research foundation that centers actual student needs before any design work begins?
Research & Process
With no previous technical background in Pyret, my team and I took some time to delve into the three ways students can access Pyret by coding in Pyret and exploring its features.
code.pyret.org (CPO) or Pyret's in-browser editor
github embedded CPO
VScode
It was extremely crucial we understood our product and who we were designing for: beginner programmers.
Because Pyret’s impact on the new curriculum is so large, we needed to make sure we were solving the right problem and separating the natural difficulty of learning to code from the unnecessary friction caused by the interface
Our Research Goal: Figuring out student delights & pain points with the Pyret experience.
I led the team in conducting a full user research initiative for students in the CS2000s class, which used Pyret. This was significant because the course had just launched in the fall — there was no existing user data, no feedback, nothing. We were building that from scratch.
I started by identifying the goal of our research: to figure out what students loved and didn’t love about Pyret… and most importantly why.
I built a Google Form for broad quantitative data and conducted 13 in-depth interviews with students, 3 TAs, and 1 professor.
Common themes that emerged:
Our user interviews revealed three pain points from our users.
Problems with error messaging
Split 60/40 of people who thought it was straightforward v. not
Potential Cause: difficulty in assignment or concept practiced
Challenges navigating the documentation
Potential Cause: Documentation fails to consider all edge-cases of searching scenarios
Wanting to transition to Python earlier
Potential Cause: Don't see use of Pyret beyond classroom
Reflections
Design Solutions:
The findings presented issues in the user experience of the docs. I proposed 3 potential changes:
Structure changes (3 panels)
Upon doing initial user testing, the 3 panel approach wasn't as effective as we thought it was. Adjusted it back to 2 panels.
Stylistic changes: CSS tweaks
Authoring changes: Need more examples, re-design navigation
Designing Around Technical Constraints:
To effectively design for Pyret, I needed to know their language
Took initiative to learn basic Pyret code & collaborated directly with TLs, giving me a deep understanding of limitations, ensuring the designer's proposals were implementable
Leadership Means Being a Translator:
Engineers and designers often speak two different languages
I actively translating tech-heavy jargon into simplified, understandable design tickets; allowing my design team to work efficiently without feeling overwhelmed by the technical scope