Project Log: When Easy to Control Becomes Complicated
This week was mostly about control.
Not in the dramatic sense. More in the very literal sense. How should a person control a drone without feeling awkward, scared, or overloaded?
Most of my placement work this week sat around user interviews, early control concept discussion, internal testing support, and a bit of compliance training. I need to keep the product details abstract because of NDA, but the learning itself is still worth writing down.
The main research task was helping with interviews around different phone based control approaches for drone operation. On paper, comparing interaction concepts sounds quite neat. You show users two options, ask what they prefer, collect feedback, and then write a conclusion.
In reality, it is messier than that.
A control method is not just a control method. It carries a feeling. One option can feel more direct because it reminds people of mobile games. Another can sound more innovative, but become less attractive once the user imagines actually using it in public, under pressure, with an expensive flying object in front of them.
That was probably the clearest lesson from the interviews. Users were not only judging efficiency. They were judging confidence.
Can I understand this quickly?
Can I recover if I make a mistake?
Will this make me look stupid?
Will the drone do something I did not mean?
Those questions are not always said directly, but they sit underneath the feedback.
After the interviews, I also worked on tidying the research notes. My first instinct is often to record everything in the order it happened, because that feels honest. But a colleague reminded me that a research document is not a diary. The conclusion needs to come first, then the supporting evidence.
That sounds obvious, but it is a very product management kind of obvious. People do not always have time to dig through ten pages to find the point.
So I rewrote the structure to make the main findings easier to read. Less “here is everything we heard”, more “here is what seems to matter, and here is why”.
Later in the week, I joined a brainstorming session for a new flight control direction. Again, I cannot discuss the specific mechanics, but the conversation made me realise how many layers sit inside a single movement. Forward, backward, turning, tilting, stopping. Each one sounds simple until you have to design it for real hands, real screens, real nervous beginners, and real safety constraints.
There was also an internal AI image editing beta session. My part was not glamorous. Understanding the test flow. Sorting out access issues. Making sure I could actually enter the test environment. Annoying, but useful.
These small access problems always remind me that a product experience starts long before the feature itself. If login fails, permissions are missing, or the setup path is unclear, the AI magic never even gets a chance to appear.
The compliance training was another good reality check. Drone design is not only interaction design. It is also airspace, registration, restricted zones, safety rules, and different regulations in different regions.
I keep coming back to this. Hardware products do not live inside Figma. They live in laws, weather, public spaces, nervous users, and occasionally very inconvenient edge cases.
Outside the company work, I also had to deal with my DPS placement paperwork. Not exciting, but necessary. A small reminder that professional practice includes admin. Quite a lot of admin, actually.
By the end of the week, the main thing I took away was this. Easy to use is not the same as simple on a slide.
A simple control idea still has to survive the user’s hand, the user’s confidence, the device’s safety logic, and the surrounding rules. If any one of those breaks, the interaction stops feeling simple.
Right. A very control heavy week. Slightly dry, but strangely useful.
Leave a Reply