Project Log: Interviews, Test Flights, and Accidentally Becoming a Tiny Product Team
The last two weeks have been… a lot.
Not in a dramatic, cinematic way. More in the “my calendar is quietly trying to murder me” way.
I have been switching between user research, drone testing, interview scheduling, internal coordination, and then — slightly unexpectedly — building a small macOS app and a project-management Agent prototype on the side. Looking back, it feels like these two weeks were split between two very different kinds of work: understanding how people interact with hardware in the real world, and understanding how AI might help teams organise messy work before it collapses into chaos.
As always, I need to be careful with the details here. A lot of what I am working on sits under NDA, so I will keep the product, algorithm and internal process details fairly abstract. But I can still talk about what the work taught me.
Turning People into Research Groups — Carefully
The first part of this period was mostly about recruitment and interview preparation.
That sounds simple enough. Find people, invite them, interview them. Done.
Except, obviously, it is never that simple.
We spent quite a bit of time refining how to group participants for a drone-related user study. The main challenge was not just finding “enough people”, but finding the right balance of people: different levels of drone familiarity, different gaming habits, different confidence levels with control-based interaction, and a reasonable gender balance.
This is where research starts to feel less like “asking people questions” and more like building a small, slightly fussy ecosystem. One change in the screening logic affects the entire sample. A coefficient shifts, one person drops out, someone does not reply, and suddenly the carefully balanced structure starts wobbling.
A lot of my work was around coordinating spreadsheets, checking candidate pools, clarifying permissions, and making sure the team agreed on how to classify different user types. It was very unglamorous. Very spreadsheet-heavy. Very “why is this person blue in this table but not in that one?”
But it also taught me something important: research quality is often decided long before the interview begins. If the recruitment logic is messy, the later insights become shaky. You cannot build a clear conclusion from a sample that was assembled in panic.
The Interview Room: Control, Trust, and the Fear of Looking Stupid
The middle of the first week was dominated by interviews.
We spoke with users who had different levels of experience with drones, games, and control-heavy devices. Some were comfortable with physical controllers; others were more open to phone-based or touch-based interaction. Some cared about precision. Some cared about convenience. Some simply did not want to feel like they were going to crash something expensive in public.
That last point really stuck with me.
When we talk about interaction design in a meeting room, we tend to use language like “control scheme”, “input method”, “learning curve”, “operation efficiency”. But when a real person talks about it, the emotional layer becomes much clearer.
They are not only asking:
Can I control this?
They are also asking:
Will I look stupid using this?
Will I panic if something goes wrong?
Can I trust the device not to betray me?
One recurring theme was the tension between physical feedback and screen-based flexibility. A physical controller gives confidence because your hands understand where things are. A screen interface is more flexible, but it can also feel fragile: brightness, accidental touches, finger position, and visual attention all become part of the experience.
It reminded me that “easy to use” does not just mean fewer buttons. Sometimes “easy” means giving the user enough physical certainty to relax.
This is something I keep rediscovering in hardware work. The interface is not just on the screen. It is in the hand, the wrist, the light, the wind, the battery anxiety, the social embarrassment of standing in a public space trying to make a machine behave.
Testing Outside: Where The Spreadsheet Goes to Die
The second part of this placement work moved back into field testing.
Again, I cannot go into specific test values or internal algorithm behaviour, but the broad picture is this: we were trying to understand how different flight conditions and control modes affect the product’s safety logic and user experience.
And the real world, naturally, refused to behave politely.
One device had positioning issues and needed to be swapped. Some behaviours only became clear after repeating the test under different conditions. A controller setup behaved differently from what we expected. At one point, a test incident caused minor hardware damage, which was annoying but also weirdly useful as a reminder: unlike Figma, physical products do not let you press Command + Z.
Field testing is humbling. In a document, logic looks clean. In the air, it becomes weather, signal quality, surface conditions, battery level, human reaction time, and whether your hands are steady enough that day.
There is something almost brutal about testing drones. You cannot hide behind a polished interface. If the behaviour is unclear, it becomes visible immediately. If the mental model is wrong, the user feels it in their body. If a safety mechanism is too aggressive or too subtle, the product suddenly feels either overprotective or irresponsible.
I think I am starting to understand why hardware teams are so obsessed with edge cases. In software, an edge case can be an error message. In hardware, an edge case can be a broken propeller.
A Small Detour: Vibe Coding and the Joy of Making Something Actually Run
Alongside placement work, I also joined a Vibe Coding training session, which opened up a very different track of thinking for me.
I have used AI for writing, research, summarising and product thinking before, but this time I wanted to test something more concrete: could I, as someone from an art and design background without formal programming training, use AI to build a real working tool?
So I made PomodoroBar.
It started as a very small idea: I wanted a simple macOS menu bar Pomodoro timer. Nothing huge. Nothing trying to “revolutionise productivity”. Just a tiny tool that sits quietly at the top of the screen and helps me focus.
But the process became more meaningful than the app itself.
I went through the full loop: idea, interaction decisions, AI-assisted code generation, compiling, bug fixing, feature iteration, packaging, and publishing the project publicly on GitHub. By the end of this sprint, the project had become a working macOS app with countdown states, focus and break modes, notifications, sound alerts, bilingual interface support, local focus-count storage, and packaging scripts.
For a non-programmer, that felt slightly ridiculous.
Not because the app is technically groundbreaking. It is not. It is a Pomodoro timer. The world has survived many of them.
But for me, the important part was that the idea crossed the boundary from “I wish this existed” to “I can install this on my computer and use it.” That boundary used to feel enormous. It felt like the place where design students hand things over to “real developers”.
Now it feels more porous.
AI did not magically remove the need for judgement. I still had to decide what the product should feel like, what features mattered, what was too much, and whether something was usable. But AI made the engineering side less like a locked room. It became a conversation. A frustrating one at times, yes, but still a conversation.
ProjectPilot: Trying to Distil a Project Manager
The other major experiment was connected to a team project for an AI / collaboration-tools competition.
The basic question we started with was:
What if an Agent could act less like a chatbot and more like a project manager?
Not a motivational, “How can I help you today?” chatbot. More like something that can sit inside a team’s existing workspace and help convert messy conversations into structured project assets.
We started exploring how an Agent could use native collaboration-platform abilities — documents, knowledge bases, messages, tasks, calendars, meeting notes, databases — to support real project work. The direction we landed on was not “AI answers questions about a project”, but “AI helps produce the project system itself”.
The first function we tried to validate was simple in theory: take the notes from a kickoff discussion and generate the initial structure of a project knowledge base.
In practice, this is a very interesting problem. Meeting notes are loose. People jump around. Someone says “we should probably do this later”, another person mentions a risk, someone else casually defines the MVP without calling it the MVP. A human project manager naturally catches these fragments and turns them into structure.
So our Agent needs to do something similar.
The first prototype created a project workspace containing things like the project one-liner, MVP loop, demo scope, story flow, knowledge-base structure and next steps. It is still early, but it proved the core assumption: an Agent can extract project shape from an unstructured meeting and turn it into a workspace the team can actually continue using.
That feels powerful.
Because project management is often not about having more documents. It is about making sure the right things become visible at the right time: tasks, risks, owners, decisions, blockers, deadlines. The Agent does not need to be clever in a theatrical way. It needs to be quietly useful.
The Permission Problem: AI Needs a Body
One thing I learned very quickly while working on this Agent idea is that AI does not only need intelligence. It needs an identity.
That sounds a bit dramatic, but I mean it very practically.
When an Agent reads a document, creates a task, sends a message, or updates a knowledge base, it has to do so as someone or something. Is it acting as a bot? As a user? With what permissions? Can it access a private document? Can it edit a page? Can it see a meeting note?
This became one of the biggest technical and product lessons of the week. It is not enough to ask “can the model understand the task?” The better question is:
Can the Agent act inside the correct permission boundary?
That changes how I think about AI product design. A lot of AI demos focus on the model output, but real workplace AI is also about access, trust, scope, and accountability. The Agent needs to know not only what to do, but where it is allowed to do it.
Otherwise it is just a very confident ghost.
What These Two Weeks Taught Me
Looking back, the placement work and the AI experiments are weirdly connected.
The drone research taught me that real products live in messy human contexts. Users do not interact with a “feature”; they interact with fear, confidence, habits, light, physical feedback, time pressure, and the possibility of failure.
The Agent project taught me that teams also live in messy contexts. Projects do not fail only because people lack ideas. They fail because decisions disappear into chat histories, meeting notes do not become tasks, risks are noticed too late, and nobody has the energy to maintain the structure.
In both cases, design is about making invisible friction visible.
For drones, that friction might be the gap between an engineer’s control logic and a beginner’s shaky hands.
For project work, that friction might be the gap between a good meeting and an actually executable plan.
And for myself, honestly, the friction is still speed.
I am still fighting my instinct to make things complete before showing them. But these two weeks forced me to work differently: test first, interview first, prototype first, make the rough version visible, then improve it.
PomodoroBar helped with that too. It reminded me that a small working thing is often more valuable than a perfect imagined thing.
Closing Thoughts
There is a strange confidence that comes from making something run.
Not just writing a proposal. Not just drawing a flow. Actually running.
A drone in a field.
A research session with a real participant.
A bot responding inside a workspace.
A tiny timer ticking away in the menu bar.
None of these things are perfect. Some are barely stable. Some are held together by scripts, workarounds, test notes, and mild panic.
But they exist.
And maybe that is the main lesson from these two weeks: professional practice is not about waiting until the idea is elegant enough to deserve reality. It is about dragging the idea into reality early enough that reality can start arguing back.
Right. That is probably enough for now.
Also, it rained violently in Shenzhen at the end of the week, which felt appropriate.
Leave a Reply