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.
Leave a Reply