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.