By Simone Panja
We all see the world through the lens of our own experiences and the lessons we’ve learned along the way. But when multiple perspectives come together, how do you arrive at a single, shared solution?
This was one of the most meaningful challenges I faced during my summer at Phase Dock working with Chris (the owner and manufacturing engineer) and Matt (the industrial engineer). (See the classic cartoon below! It is not far from the truth!)
In our first meeting, the goal seemed straightforward: design a human-machine interface (HMI) that would electronically operate two valves: a vacuum valve and a compressed air valve. The user would simply turn the system on or off, while the upper and lower pressure limits would be hard-coded into the system.
However, by the end of the summer, the solution looked very different. The final HMI allowed users to configure their own upper and lower limits and electronically controlled only the compressed air valve. Clearly, things had changed along the way.
What changed was understanding.
Having operated the vertical machining center for years, Chris possessed an intuitive grasp of how the system behaved in practice. That intuition, however, wasn’t yet formalized into a clearly defined process, much less an actionable requirements specification. As someone new to manufacturing environments, I quickly realized that building an effective HMI required more than technical implementation; it required a deep understanding of the machine, the workflow, and the problem it was meant to solve.
That realization led me to develop pages of questions, such as:
- How does the machine behave under different conditions?
- What were the past failure points?
- What constraints mattered most?
- What did “success” look like from an operator’s perspective?
At every meeting, Matt and Chris helped steer me in the right direction. With each discussion, the scope of the project evolved into something clearer and more intentional.
Through this process, I developed a requirements specification for the HMI that outlined system functionality, external interfaces, scalability, compatibility, and usability. As the project continued to change, this document became an anchor, helping me refocus on the core problem the system needed to address, rather than the initial assumptions we started with.
Real world problems are messier than academic exercises.
This experience stood in sharp contrast to my university coursework, where project requirements are typically predefined and static. In the real world, I learned, projects are anything but fixed.
Midway through the summer, a one-way or “check” valve was added to the machine, automatically handling vacuum valve control. This single change fundamentally altered the HMI’s role and eliminated the need to electronically operate the vacuum valve altogether.
The evolving requirements didn’t just affect system design, they rippled across both software and hardware decisions.
On the software side, I experimented with multiple approaches to handling rotary encoder input, from the Arduino IDE built-in digitalRead() and attachInterrupt() functions to the AiEsp32RotaryEncoder library.
On the hardware side, the interface evolved from a 20×4 character LCD to a 480×320 SPI-driven TFT display, while the microcontroller shifted from an Arduino Uno to an ESP32 to meet new performance and interface requirements.
Each change forced me to rethink assumptions, refactor logic, and adapt the backend to new constraints. Along the way, I leaned heavily on documentation, developer forums, conversations with experienced engineers, and even AI tools–learning how to ask better, more precise questions with each iteration.
Successful engineering starts with listening.
By the end of the summer, the result was an HMI that met Phase Dock’s needs while reflecting a deeper understanding of the process, the customer, and the problem itself.
More importantly, the experience taught me that successful engineering starts not with implementation, but with listening: understand the system, the people who use it, and be willing to let solutions evolve.
