
Mobile app that helps users discover, book, and manage flights with real-time updates and seamless UX.
Role
Aviation · Digital Solutions
Platform
UX & UI Design
Deliverables
3 Months
Status
Live and in active development
PROBLEM
Building a motor costs real time and money
Motor designers, manufacturers, and mechanical engineering students all need to know how a motor will perform before it's actually built. Right now, that means machining parts, winding coils, and testing on a bench, and only then finding out if the motor overheats, misses its torque target, or wastes energy. By that point, fixing the design means starting over.
Students face a different version of the same problem. Most don't have access to real motors or lab equipment to test on, so they're stuck learning motor behavior from theory alone, with no way to see how their own designs would actually perform.
SOLUTION
Simulate the motor before committing to materials or manufacturing.
Pi-CADS Motor lets users simulate a motor's performance in the browser, before anything gets built. Enter EV and motor specs, run the simulation, and get a Machine Summary, Winding Diagram, Flux Density Plot, Air Gap Flux, Analysis, plus cost and weight for that configuration. Designers and manufacturers see how the motor performs and what it costs, without machining a single part.
Students get the same simulation, but use it to learn. With no lab or real motor to test on, sample vehicles let them run real inputs, see how the outputs change, and build an understanding of motor behavior that theory alone doesn't give them.
key ux Decisions
Breaking the workflow into steps
The redesign focused on clarity and scalability, ensuring a smooth user journey and a cohesive digital identity.
It made a messy process easier to follow. Students didn't feel lost. Designers and manufacturers still had every setting they needed, just organized instead of dumped on one screen.
Defaults you can question, not follow blindly
Every field starts with a sensible default. So a student who doesn't know what value to enter yet can still run something and learn from what happens.
Nothing is locked. Anyone can change any default. It's just there so you're not staring at a blank field wondering what to type.
Sample vehicles instead of an empty screen
New users get real sample vehicles they can open, mess with, and rerun. It's a faster way to learn than reading instructions — you see how a change to one input moves the output.
Manufacturers use the same samples to check if the tool's logic makes sense before they trust it with their own numbers.
Logs that actually show what's happening
In most software, logs are something only developers look at. Here, they're for everyone. Solver progress, warnings, errors — all visible, not buried.
This matters more for manufacturers than it sounds. If a simulation is going to inform something they'll actually build, they need to see what the tool is doing, not just wait for an answer.
Results you can act on, not just read
A result on its own isn't that useful. So I built the results screen around what people do next: export it, generate a report, change something and rerun, or dig into what went wrong.
A manufacturer exports and moves on. A student reruns to see what changes. Same screen, different use.
refinement
The gap I missed
In the early design, you couldn't tell what state a simulation was in. Someone would start a run, step away, come back expecting results, and only find out it had failed after clicking all the way through to the end.
01
Added real status to each simulation
02
Made actions match the state
03
Gave each vehicle its own log access
04
Added sample vehicles
This was not part of the original scope. It was found during iteration, after watching engineers use the product and noticing where the workflow created uncertainty. The flow was then corrected by making simulation state, actions, and log access visible earlier.
impact
Less input overwhelm
Setup felt easier to follow. Beta users found the simulation setup clearer after dense motor parameters were split into guided stages.
10%
10%
Faster first simulation
Blank-start friction reduced. Sample vehicles and default values helped new users reach their first simulation run faster. stages
0 x
0 x
Input doubts
Inline parameter guidance. Info buttons reduced student confusion by explaining each parameter directly at the point of input.
<0%
<0%
Note - Metrics are based on beta customer feedback, internal prototype walkthroughs, and usability observations. They are usability indicators, not post-launch analytics.

REFLECTION
Aerolink’s previous platform was difficult to navigate and didn’t effectively communicate the brand’s innovative value.
The redesign focused on clarity and scalability, ensuring a smooth user journey and a cohesive digital identity.
Pi-CADS also pushed me to work closely with engineers - sitting with terms I didn't know, asking what they actually meant, and figuring out how to turn that dense product logic into a workflow someone could actually move through, step by step.

