Project Log: Tiny UI Details and a Very Real Security Reminder
This week was less dramatic than field testing, but probably just as useful.
A lot of my work sat around the flight control app: reviewing UI issues, sorting interaction problems into something more manageable, joining a control method brainstorm, and helping with competitor device testing. It was one of those weeks where the work looks small from the outside. Text colour. Font size. Touch area. Button behaviour. Playback logic. Device states.
But the more I worked through it, the more I realised these small things are not small at all.
For the app UI review, I helped prepare and organise a list of interaction problems before the meeting. The discussion slowly split into two types of issues: visual readability and actual operation. Some problems were about whether the user could clearly see information on the screen. Others were about whether a control was easy to tap, drag, or understand under pressure.
That distinction helped. A messy problem list can make everything feel equally urgent, which is usually how nothing gets solved. Once we separated “can the user read this?” from “can the user operate this?”, the work became easier to discuss.
Later in the week, I joined another brainstorm about new control methods. Again, I need to keep the actual mechanics abstract, but the core question was familiar: how can we make manual flight control feel more natural on a phone screen?
I suggested a couple of interaction directions, partly inspired by mobile games and touch screen gestures. It sounds playful, but there is a serious layer underneath it. Game controls are interesting because they teach complex movement through repeated, almost physical habits. Your fingers start to understand the system before your brain writes a formal explanation for it.
The difficult part is that a drone is not a game character. If the interaction is confusing, the result is not just a bad score. It could be a safety issue.
That tension keeps appearing in this placement. We want control to feel intuitive, but we also need it to be predictable, limited, and safe. A clever gesture is only clever if the user can recover from mistakes.
I also spent time on competitor testing and device state checks. This was quite dry work: testing what happens in different conditions, recording how media can be viewed or managed, checking what changes when the device is connected in different ways. It is not glamorous, but it is the kind of detail that quietly shapes a product. Users rarely praise a clean file management flow. They just get angry when it behaves strangely.
The most uncomfortable lesson this week came from information security.
While debugging an AI assisted workflow, I used a network access tool that was not appropriate for the company environment. I was reminded by the security team, stopped immediately, and took it as a very direct lesson. Speed is not an excuse. Even if the task feels harmless, a company managed device is still a company managed device.
That was a bit embarrassing, honestly. But also useful.
I have been thinking a lot about AI tools as a way to move faster, especially with coding and prototyping. This week reminded me that “faster” sits inside rules: security rules, permission boundaries, device policies, and basic professional trust. If I ignore those, then the speed is not really productivity. It is just risk arriving early.
So this week was about control in two senses.
One kind of control was on the screen: how a user taps, moves, reads, and understands a flight interface.
The other kind was professional control: knowing when not to use a tool, even if it would make the work easier.
Annoying lesson. Good lesson.
Leave a Reply