Remington Williams

Going to Finland

Four of us from Pace's NYC Design Factory, one of only 30 Design Factories in the world, joined Aalto University's yearlong Product Development Project. Our client was Prinsys, a Finnish startup working to bring a battery free leak detection sensor to market.

Our team of 11 brought together students from New York, Pakistan, the Netherlands, India, Colombia, and France. We met the Prinsys team and its investors in Helsinki. We spent several days prototyping in the ProtoBunker. It had electrical tools, plumbing equipment, and 3D printers. The trip was also filled with team development and collaborative brainstorming sessions, and it is where our research began.

Prinsys service blueprint mapping customer, front-of-stage, back-of-stage, and support processes

Service Design

Before we built an app or any hardware, we mapped the user journey and designed the service end to end. Prinsys was not just selling a battery free water leak sensor, but an entire service connecting sensors, software, people, and processes to prevent water damage.

Our service blueprint maps each customer touchpoint to the people and systems behind it. It follows a building from assessment and quote, through installation, to a dashboard fed by sensors that continuously check themselves.

The biggest question was what happens when something goes wrong. A malfunction and a leak both notify the customer and Prinsys, but only a leak sends maintenance to repair it. That line decided what Prinsys was liable for and outlined everything we built next.

Wireframes

The U.S. team owned the front end, and we refined the wireframes with Prinsys. We created high fidelity, WCAG aligned screens across three flows. We went with a mobile first approach.

Property Monitoring includes a map. The app is designed for owners of apartments and hotels who manage many buildings. The Installation Guide took the longest to troubleshoot. Barcodes let maintenance teams register sensors with a phone camera for ease of use. Account Management covers alerts and support.

I built the app in Vue.js, converting real blueprints into SVG floor plans with clickable sensors. A separate team of 8 CS students at Aalto built the backend and mocked our data, so we could test every alert.

Admin Panel
Entity Relationship Model

RF Circuit Schematic

A building full of sensors needs a receiver to collect their signals, and the Finnish team designed its circuit. As the only engineer on the U.S. team, I became the link between their hardware and our software.

They started from a reference circuit built around the PT4455 chip, which runs at 315 or 433.92 MHz. A crystal oscillator locks the signal to one frequency, and a matching network shapes the output so it leaves the board cleanly. The team then rebuilt it in KiCad, wiring each part to the chip's pins, power and ground rails, and connectors for PCB layout. Every alert in the app begins as a signal on this board.

The Prinsys receiver hardware, handed off for continued development

The Handoff

At the end of the year, we handed Prinsys a service design, a receiver prototype, and a working app. Prinsys took the Vue.js app I built for continued development, and the receiver prototype is being refined for production.

Prinsys had always been building the sensor. Before this project, the sensor was one piece of a business. Our team built the service, software, and hardware around it, and gave Prinsys a roadmap to a finished product. We presented the final work at Aalto University's Product Development Gala.

Paper knot pieces cut from multicolored craft paper

Knots in Pieces

While hand drawing knot diagrams for this research at Pace University, advised by Dr. Jonathan Williams, I noticed that knots could be broken into segments. I used this method to speed up my drawings of knot diagrams for the project.

The segments came from a figure 8 knot. I put them to the test, and they built a series of other standard knots. The research received a full year Research Experiences for Undergraduates grant from the Computer Research Association.

My first puzzle was physical. I designed, printed, and cut pieces from multicolored craft paper, then asked users to rebuild a knot from an image. It worked early on, but the layered paper was hard to handle and many shapes went unused, so I reduced the pieces and made them more modular.

Methodology

This research followed a research through design methodology, where making artifacts is the main way knowledge gets produced. The research is about both the product and the process of making it, so each prototype was also an experiment.

My second prototype simulated a digital interface in Google Slides. Users saw a completed knot on one slide, then rebuilt it on the next from stacked PNG pieces in an open work area. I ran the play tests over Zoom. The prototype showed real promise for a dedicated interface. The tests also let me reduce the set to only two modular shapes, which put the focus on recognizing and manipulating them.

Drag, Rotate, Layer

The third prototype became a real web interface. Flask handled the routing and served a single page. JavaScript carried the interaction logic, so users could drag pieces, rotate them with the keyboard, and change their layer order to make one strand cross over another.

After an instructions page, users worked through seven knot puzzles. I ran iterative user testing and analyzed the performance and interview data in an 11 page research paper.

Participants built the knots successfully. They learned the visual language through tracing, shape recognition, and manipulation, and tracing stood out to me as a universal cognitive tool. Users also reported more awareness of their spatial reasoning and felt the puzzles could help them tie real knots.

AI Crossings

Once the puzzle worked in 2D, the project naturally needed to evolve into 3D. I tried turning my vector diagrams into 3D models in Adobe Illustrator. In 2025, Adobe introduced a Beta AI tool that could rotate vector drawings, and I was very excited to try it.

The program did not understand the crossings that defined a knot. Without knowing which part of the rope lies over or under, it was just another piece of loose rope. AI was advancing in a lot of areas, but it was not going to tie these knots for us.

3D knot models built from the wireframe drawings

3D Ties

The Associate Dean of Seidenberg took an interest in our work and wanted to take it into virtual reality. The knots needed real 3D form for that, so I found open source 3D models that matched some of my existing diagrams.

Neither of the professors I worked with had experience in 3D modeling. I learned it on my own and shared what I learned along the way, while they guided the research with their years of experience. In weekly meetings they handed me wireframe drawings, and I replicated them in Unity.

Unity

Holding my first knot in VR was a pivotal moment. I started this project with paper, and two years later I was holding a virtual knot in my kitchen.

I designed an interactive Unity XR environment with 25 modeled knots for an observational user study. I also trained a Teachable Machine image classification model on 1,500 images of 3 knot types. I integrated it with Python, JavaScript, and HTML, so the Meta Quest 3 camera could recognize each knot and automatically advance the instructions.

The model successfully detected the crossings that define each knot, the same crossings the Illustrator AI could not understand. Before this project I had never done formal research, and it led to multiple IRB approved studies.