Blog

Project Log: Looking for User Needs Before the Interview Room

This week was mostly research before research.

That sounds a little odd, but it is probably the most accurate way to describe it. Before a formal interview starts, there is already a lot of work happening: deciding what to look for, checking what users have already said in public, turning scattered complaints into themes, and making sure the actual interview does not waste the participant’s time.

One of my main tasks was collecting public user feedback around glasses based drone control. I went through different social platforms and forums, looking for comments about what people liked, what felt awkward, and what they still wanted from the experience. I cannot share the internal document or product details, so I will keep this at the method level.

Online feedback is useful, but it is also noisy.

A user might write one angry sentence after a bad setup experience. Another user might praise the same feature because it worked perfectly in their specific situation. Some posts are emotional. Some are vague. Some are probably written after the person has already forgotten the exact steps that caused the problem.

Still, patterns start to appear if you read enough of it. People care about comfort, setup friction, clarity of status, and whether the system behaves in a way they can predict. They also care about small transitions: connecting, switching modes, recovering from confusion, finding media, understanding what the device is doing.

Those transition moments are easy to overlook in a feature list. They are harder to ignore when users keep complaining about them in public.

I also helped coordinate another round of demo interviews for an experimental interaction direction. The actual mechanism is under NDA, but the work around the interview is safe to talk about: scheduling, preparing the flow, checking the task order, handling time changes, and making sure the participant can focus on the experience instead of the logistics.

I used to think of interview coordination as admin. Some of it is admin, obviously. Calendar work is calendar work. But this week made me treat it more seriously. If the participant arrives confused, rushed, or unclear about what they are being asked to do, the data gets weaker before the interview even begins.

A bad setup can create bad feedback.

There was also some quick reading around HCI experiment methods, interviews, and questionnaires. I needed to understand the difference between collecting opinions, observing behaviour, and designing a small test that produces usable evidence. These methods sound similar when described casually, but they answer different questions.

An interview is good for understanding how someone explains an experience. A questionnaire can scale a narrower question. An experiment needs more control, but it can show behaviour more clearly if the setup is designed well. Mixing those up is a good way to get confident-looking data that does not actually support the decision.

I also spent some time thinking about my own AI workflow setup, especially how skills and plugins should be organised. That is a more personal tooling layer, but it connects to the same issue: tools only help when the boundaries are clear. A messy toolchain just creates another place to lose time.

The thread running through the week was preparation.

Preparing a public feedback scan so it is more than a pile of screenshots.

Preparing an interview so the user can actually respond to the experience.

Preparing a method so the team knows what kind of evidence it is collecting.

It is not the most visible part of product work, but it changes the quality of everything after it. The research starts before the recorder is on.

Project Log: When a Name Starts Changing the Picture in Your Head

This week was a strange mix of product testing, naming research, AI coding discussions, and final competition work.

The most interesting part was probably the naming research.

I used to think naming was mostly about choosing a word that sounds clear. Short, memorable, not too technical. Done.

This week made that feel a bit naive.

For a drone related feature, we were trying to test how different names shape what users imagine before they even see the function properly. The key question was not simply, “Which name do you like?” That kind of vote can be shallow. A user might pick the prettiest name without understanding what it implies.

So we shifted the research logic. Instead of asking people to choose a favourite, we tested whether a name could guide their visual intuition. When users saw different images or examples, what kind of movement or composition did the name make them expect?

That was much more useful.

It also made the survey harder to design. We had to adjust the number of images, rewrite questions, and test the logic with a small group first. A weak survey can make everyone look confident for the wrong reason. People answer the question you give them, even if the question is slightly broken.

I am starting to see questionnaire design as interaction design in disguise. The interface is just made of words.

There was also more hands on testing around drone control behaviour. I cannot share the specific mechanism, but one test exposed a safety related problem that forced us to rethink part of the testing process. It was not exactly a pleasant moment. These things never are.

But it was useful in the brutal hardware way.

In software, a bug can hide behind a loading state or an error message. In hardware, the bug becomes physical very quickly. Something moves when it should not. Something fails at the wrong second. The room gets quiet.

That kind of test makes the word “edge case” feel less abstract.

I also joined another AI coding sharing session. The examples were practical: UI development, bug fixing, hardware debugging, internal skills, and engineering workflows. What I liked was that nobody was pretending AI magically replaces the work. The better examples were more modest. AI helps write a first version, checks repetitive logic, speeds up debugging, or turns a rough pattern into something reusable.

That feels closer to my own experience.

AI is useful when I know what I am asking for. It is much less useful when I am vague and hoping it will rescue me from thinking. Annoying, but fair.

The badminton AI project also continued this week with final submission and presentation preparation. That project still feels very different from the company work because I can talk about it more openly. We were polishing the story: not “AI sports analysis” as a cold performance dashboard, but a small tool for helping amateur players keep better memories of a game.

I like that direction. It is less obsessed with judging people.

By the end of the week, I felt that most of the work came back to the same lesson: framing changes behaviour.

A feature name changes what a user expects.

A survey question changes what kind of answer you get.

A test setup changes what kind of risk becomes visible.

A demo story changes whether people see a product as useful or just technically busy.

Tiny framing decisions. Very real consequences.

That is probably the quiet theme of this placement year: the product is not only the thing we build. It is also the way we explain, test, name, and limit it.

Project Log: Naming Things, Building a Badminton AI Demo, and Remembering That Scope Is Everything

This week split into two very different tracks.

One side was still placement work: feature naming research, quick interviews, survey design, and trying to turn vague feedback into something the team could actually use.

The other side was a competition project: a badminton social and AI analysis app that I built with a teammate. That one was public enough to talk about, which felt oddly refreshing after weeks of writing around NDA shaped holes.

The badminton project started with a fairly simple question: after people finish playing, what do they actually want to keep?

Not another bloated sports platform. Not a chat app with payment and social features glued onto it for the sake of looking complete. We kept pulling the scope back to one core experience: finish a game, record the good moments, and leave with a small, positive memory of how you played.

That meant cutting quite a lot.

We focused the first version on instant matching, camera recording, highlight clipping, and a lightweight positive profile of the player. I liked that phrase, “positive profile”, because it stopped the AI from becoming another cold scoring machine. In badminton, especially amateur badminton, people are not always looking for brutal judgement. Sometimes they just want to see that one rally where they moved well, or that one smash that made the whole evening feel worth it.

Scope control was the real work. Every new idea sounded tempting for about ten seconds. Chat? Payment? Club management? Rankings? Sure, all useful. Also all dangerous. A demo version dies very quickly when it tries to become five products at once.

So we kept asking: does this help someone keep the memory of playing badminton?

If not, it went into the freezer.

Back in placement work, I spent a lot of time on feature naming research for a drone related function. I cannot share the exact feature details, but the work itself was interesting. We were trying to find a short Chinese name that felt clear, natural, and not too technical.

Naming sounds like a small task until you actually test it.

A name that makes sense inside a product team can be completely flat to a user. A name that sounds clever can create the wrong expectation. A name that is technically accurate can feel like reading a settings menu. We ran quick interviews and a short survey, then adjusted the questions when people were clearly interpreting things differently from what we expected.

That was the useful part. The misunderstanding was data.

I used to think user research was mainly about collecting answers. This week reminded me that it is also about watching where the question itself fails. If people hesitate, ask what a word means, or choose an option for a reason you did not expect, the problem may not be the user. It may be the framing.

I also joined an AI workflow sharing session inside the company. The examples were very practical: meeting note automation, small data processing tools, agent based coding workflows, and different ways teams are using AI to reduce repetitive work. It was not the glamorous “AI will change everything” version. More like: here is a boring task, here is a small tool that saves an hour, here is where it breaks.

Honestly, I prefer that version.

The whole week made me think about AI as a practical assistant rather than a magic layer. In the badminton project, AI helped shape a more playful sports memory. In the workflow session, AI helped with internal productivity. In naming research, AI was less important than real human confusion, which is also a useful reminder.

Not every problem needs a model. Some problems need twenty people to look at a name and say, “I have no idea what this means.”

By the end of the week, our badminton project had made it into the final round. That felt good. Slightly unreal, but good.

I think what I learned this week is that making a product smaller is not the same as making it weaker. Sometimes the smaller version is the only version with a clear pulse.

A focused demo.

A name people can understand.

A survey that asks one thing properly.

A feature that does not pretend to be a whole platform.

That is the difficult bit, really. Not adding more. Knowing what to leave out.

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.

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.

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.

Overview of the Week: This week has been incredibly hands-on. I transitioned from organizing internal data to actually getting out into the field, observing how users interact with our products in real-world scenarios. It’s been a fantastic learning curve in understanding the end-to-end process of product testing and user research.

1. Field Testing & Observation

• The Action: Mid-week, I went to a local park to act as an observer for our latest drone internal testing. I shadowed users to see exactly how they operated the device in an outdoor environment.
• The Insight: It was highly valuable to see the gap between lab expectations and real-world application. For instance, I documented specific feedback regarding the environmental sensor systems (like obstacle avoidance) when exposed to complex natural surroundings, and quickly synced these findings with the development team.

2. User Research & Interviewing

• The Action: I spent a significant chunk of the week conducting and analyzing user interviews, particularly focusing on interactive features like gesture controls.
• The Insight: Working alongside the team, I helped refine our interview guidelines to better capture the motivations and usage scenarios of our target demographic (specifically the 23-27 age group). I even utilized AI tools to brainstorm and tailor different sets of questions for varying user profiles. It really showed me the importance of asking the right questions to get actionable data.

3. Data Management & Team Coordination

• The Action: Behind the scenes, I collaborated closely with team members to process survey data and filter candidates for upcoming tests. We successfully managed the outreach to over 30 potential interviewees and coordinated the logistics and equipment distribution for the testing phase.
• Bonus: Finished off the week by moving to a new desk setup with my colleagues—a fresh environment for the upcoming tasks!

Reflection for the Week: This week taught me that a product designer/researcher’s job is as much about logistics and clear communication as it is about creative problem-solving. Capturing a user’s real-time frustration or joy during a field test provides insights that you simply can’t get from a spreadsheet alone.

Project Log: Stripping it Back and Speeding it Up

My mentor told me last week to, well, speed up. To stop trying to hold my breath until I had this massive, “perfect” solution ready. And this week… I think I’m finally starting to catch the rhythm of what she meant.

It’s quite a jarring feeling, honestly. Part of you wants to make the logic absolutely watertight, and the other part is just acutely aware of the developer schedule ticking away in the background. I’ve basically spent the last few days bouncing between those two extremes: obsessing over interaction details on one hand, and frantically pushing the user research forward on the other.

I have to be a bit careful about what I say (NDAs and all that, as I mentioned), but I can talk broadly about how the week actually felt.

Hiding the Complexity: Doing Less with Templates

A massive chunk of my time went into figuring out the “layering” logic for the drone’s shooting templates.

How to put it… when we first discussed it internally, the technical breakdown was incredibly granular. For instance, user movement states were chopped up into five highly precise categories. From an engineering standpoint, it’s brilliant. But intuitively? If I’m just an average bloke who’s just unboxed a drone, I don’t have the patience to figure out if I’m in “restricted movement” or “free movement”. I just want to shoot a decent video.

So, in the meetings, we spent ages just… cutting things away. Stripping those complex categories down into language a human might actually understand.

Then there was the issue of combining features. You can layer some extra effects over basic tracking shots. But if you’re already doing something intense, like ski tracking or cycling… well, we decided to just not support layering for now. It’s about making the decision for the user, really, to stop them from Frankenstein-ing together a shot that’s completely unusable.

To make this obvious, I sketched out a new selection page. Just three simple tabs, and I added a timeline for the templates you can layer. Honestly, when you take a tangled mess of backend logic and squash it into a simple interface with a few buttons… it’s a very strange feeling. I probably still need to churn out the interaction mocks a bit faster, but the general direction is sorted.

Hearing Real Voices: The Quagmire of Research

The other half of my week was essentially spent drowning in user research.

We’re trying to understand people who play control-heavy games (shooters, action games) and figure out their habits when using hardware like ours. Sounds simple, right? Just send out a survey.

But… tweaking a questionnaire is soul-destroying work. You constantly have to second-guess what the respondent is thinking when they read a question. I went over it several times with the UX research team this week. We added all those dry, structural questions you just have to ask (the who/what/where/when), and changed the final question from single to multiple choice, just to scrape a bit more useful data out of it.

Collecting the surveys and screening people was maddening, too. We had to actively filter out anyone linked to R&D, and keep a strict cap on the number of interns, just terrified of polluting the sample and ending up with fake conclusions. We scheduled a maximum of 5 interviews a day. It doesn’t sound like a lot, but trying to stay hyper-alert for an hour, digging into the real motives behind people’s subconscious habits… it completely drains you.

A Few Closing Thoughts

There’s still a lot of invisible “friction”, of course. Having to explain my intern status, navigating the labyrinth of getting administrative forms signed off, chasing people in group chats to approve the survey… sometimes, in a big company, pushing even the smallest task forward feels like fighting a boss battle.

But I think I’m starting to get what my mentor meant by “fast”.

If I were still doing a university project, I’d probably still be agonising over the phrasing of a single survey question, or exactly how rounded the corners on that Tab bar should be. But now? Just sort the core logic, get the survey out, lock in the interview list. Getting the wheel actually turning, completing the loop… I suppose that’s the more pragmatic approach. Allow for some rough edges and imperfections to exist, and fix them when you actually get real feedback.

Next week is heavy on offline interviews. Hopefully, we actually unearth something valuable.

Right, that’s it for now. I need a bit of a breather this weekend.

Right, so it’s been a while. I suppose an update is well overdue.

February was… well, it was February in China. An endless blur of the Spring Festival, visiting relatives, and trying to keep up with the social obligations. It was incredibly busy, but in that specific way where absolutely nothing of substance actually happens. Honestly, there just wasn’t anything worth writing down.

The first half of March, though, was exhausting in a completely different way. I spent it trying to hand over my work at the last place. I genuinely didn’t expect the offboarding process for an intern—especially one whose contract had simply reached its natural end—to be so… labyrinthine? I had to chase down sign-offs from people in departments I didn’t even know existed. It felt a bit ridiculous, honestly, dragging out an exit like that. But I suppose it’s a good, if annoying, lesson in corporate bureaucracy. Glad that’s sorted.

So, onto the new chapter. I’ve joined Insta360.

I’m working on a completely new product line for them—drones. I’ve signed a fairly strict NDA, naturally, so I’m going to have to be quite careful about how much I actually share going forward. It’ll be a bit of a tightrope, figuring out how to talk about the work without actually talking about the work.

These last two weeks have mostly been about getting my head around the industry. It sounds brilliant on paper—I’ve literally been out test-flying drones, putting together a massive industry research report, and starting on some interaction designs.

But… yeah. I’ve hit a bit of a wall.

My mentor sat me down recently and basically told me I’m moving far too slowly. Because of my pacing, we’re missing the windows to get things on the developers’ schedules. It’s… quite frustrating to hear, to be honest. I’ve been trying to make sure everything is comprehensive, covering all the edge cases before handing it over. But her advice was blunt: stop trying to make it “big and complete”. Just make it fast.

It stings a bit, letting go of that desire to have everything perfectly mapped out before showing it to anyone. But I suppose she’s right. The rhythm here is just entirely different, and I need to adapt my perfectionism into something a bit more pragmatic.