software for federally-funded research projects
what i did, in a nutshell.
I executed the design & development of a research tool used within DFO, shipping an end-to-end demo to stakeholders in 30 days.
Being the sole developer of this tool, I owned the entire software development life cycle - from data to deployment.
the problem: lack of interactivity.
Fisheries and Oceans Canada is researching the impacts of potential offshore wind energy development on the Scotian Shelf.
The problem: no existing tool could visualize the scientists' vessel and noise data in a way that was interactive, customizable, and presentation-ready.
understanding the users.
Two primary users: DFO scientists who need to iterate on data quickly without running models manually, and stakeholders who need clear, shareable results to inform decisions.
Both groups prioritize presentable results and use efficiency over a perfect product.
speaking to users.
My supervisor relayed pain points from scientists and other research groups already relying on similar tools - mainly around speed and flexibility.
speed
Existing tools like OceanNavigator took too long to process and return data - nobody wants to wait 10+ minutes to see a result.
customizability
Every user has different preferences, and no single default view works for everyone - the interface needed to offer choice, not one fixed way of doing things.
version one: prototype
version 2: skeleton
version 3: final
Currently, this is where we're leaving this user interface - at least the design portion. My job was to create the foundational architecture for other co-op students and developers to build upon in the future.
Hence, I've been picking away at documentation, file organization, and other chore-type tasks related to the data pipeline - overall, making sure the tool fulfills its purpose of supporting scientists in their research.
demo time
Presented a demo of the completed tool to a group of 15+, involving research scientists, stakeholders and marine regulators. The unspoken cues revealed the most about where friction lived - when someone couldn't navigate from one place to another, that was my sign to iterate.
design isn't just code
I started this project the way I start everything - with code. Running into real UX friction taught me the difference between fixing a problem and preventing it in the first place.
you're not the user
You can't build a real product only from your own lens. Understanding how users actually think, and translating that into pixels, was the steepest part of this project - harder than any technical challenge.
wearing every hat
A friend once joked that I was the "SWE, PM and client" of my own work. That's the best part - I get to try things I've never done, on builds that have a real impact for research I care about.
give people choice
People change their minds - that's exactly why you build in flexibility. Letting users adjust styles, change properties, and toggle elements made all the difference, even without a rigid plan going in.
next steps
VesselViz
The first of two tools I'm building for this research initiative. It fills a gap other marine data tools can't - tailored to diagnose vessel and noise patterns in designated areas.
what's next
A tool for directly measuring offshore wind impacts, giving tangible results to inform mitigation decisions. It has a more defined problem, scope and user group - so I'm investing more upfront in speaking with users and wireframing (low-fi done, high-fi next).