Staffing Model Simulation GUI
Summary
Due to an NDA with ASML, I can't share my actual designs — the visuals shown are recreations I built independently, with most text removed.
Only 3 people at ASML could run staffing simulations, because doing so required writing code. I designed and built a no-code interface that expanded access to over 50 users across global teams.
I led user research, owned the end-to-end workflow design, and built the frontend.
- My Role
- Frontend Developer Intern
- Timeline
- June 2024 - Sept 2026
- Tools
- Microsoft VisioQtDesignerPyQT
- Skills
- User researchWireframingUX engineering
Background
Why staffing matters at ASML
ASML doesn't just sell lithography machines; it services them. Over 9,500 Field Service Engineers (FSEs) worldwide install upgrades and perform routine maintenance at customer sites.
Because every hour of machine downtime is costly for customers, FSE staffing has to be planned precisely to keep service quality high.
Target users
- Field Service Managers (FSM)
- Plan staffing to minimize equipment downtime across repairs and maintenance.
- Data Analysts in Operational Efficiency
- Run staffing simulations on request for FSMs worldwide and send back results as .html files.
Research
Key insights from user interviews
Goals: Understand how FSMs and analysts use the staffing simulation today, where it breaks down, and what they need.
Field Service Managers
4 interviewed (South Korea (2), Taiwan (1), Netherlands (1))
- Long waits: Simulation results took months to a year to arrive.
- Hard-to-use results: Results came as .html files that couldn't be easily downloaded or saved.
- Unclear reasoning: FSMs couldn't see how staffing recommendations tied to business goals.
Data Analysts
3 interviewed (San Diego)
- Scattered data: Historical files lived on local machines in deeply nested folders.
- Code-only access: The simulation ran only from a Python terminal.
- No control over long runs: A full request could take hours, and the only way to stop it was to kill the process.
Problem
3 analysts, requests from around the world
Today’s process:
An FSM requests a simulation for a given year and set of conditions.
An analyst runs it locally in Python.
The analyst sends back the results as an .html file.
Simple on paper. But with only 3 analysts handling requests from FSMs worldwide, the queue can back up for months.
How might we let FSMs run their own staffing simulations, without needing code?
Design process
From Visio sketch to Python GUI
Mapping the user’s sequence
Users enter inputs for each location they want to simulate. The tool runs a staffing simulation on each location's historical data, then shows results side by side for comparison.
I capped the first version at 4 locations to keep runtime manageable while still giving users enough to compare.
Sketching the structure
My early sketches focused on fitting inputs and results on one 1440×1024 screen. I prioritized clear labels and layout so first-time users could learn the tool quickly.
Prototyping in QtDesigner
I wireframed in Microsoft Visio, the tool ASML had available, then built the prototype in Qt Designer, configuring each widget's behavior and styling it with Qt Style Sheets to match the design system.
Engineering the interface
I converted the Qt Designer layout into Python, then wired up every button, widget, and input field to the simulation.
Solution
Turning a terminal script into a tool anyone can use
Start from smart defaults
Each simulation is tied to a location and pre-filled with core inputs from that site's historical data (now stored in a SQL database). Users can run it as is or adjust inputs to fit their scenario, with up to 4 simulations side by side.
Keep advanced options out of the way
Non-essential inputs live in a separate modal. They also come with defaults, so users only open it when they need finer control.
Run, compare, and download
Users can run one simulation or all at once. Results appear alongside the inputs for easy comparison and can be downloaded in multiple formats, not just .html.
Impact
Faster answers in more hands
3→50+
users who can run the simulation
FSMs worldwide can now run their own simulations without code or waiting on analysts.
75%
faster runtime
Automatically matching each location's historical data to its inputs replaced a manual, error-prone step buried in legacy code.
Phase 2
green-lit for future release
I presented the working prototype to 100+ stakeholders, including FSMs from around the world, at ASML's global conference, and the project was approved for its next phase.
Key takeaways
Understand the whole system
I spent several weeks on research before designing: interviewing users, reading the legacy code, and mapping the local file structure.
It felt slow, but knowing who the users were, what they needed, and what the code could do let me design something that worked in practice, not just on screen. I learned that for technical tools, understanding the system is part of the design work.
Same role, different needs
All the FSMs I interviewed held the same title and managed similar machines, yet their needs varied by location. Language, time zones, and labor regulations shaped how each of them worked.
This was my first time designing for an international audience, and it taught me not to treat a shared job title as a shared experience.
