Author: Henry Xian

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.

January is nearly over. The discussions these past few days have been… erratic. We’ve jumped from hyper-specific physical parameters straight into abstract life goals.

We’re essentially trying to solve two problems: teaching the glasses to understand human physical habits (like, what actually counts as “looking up”?), and teaching the AI to understand human intent (like, “who do I want to become?”).

It sounds grand when you say it like that. But in the documentation, it’s just endless arguments about “angles,” “tags,” and “reset buttons.”

The HUD: Translating “Angles” into “Comfort”

We hit a classic “Engineer Mindset vs. User Mindset” wall while designing the “Look Up to Wake” feature.

The original idea was quite hardcore: ask the user to set a specific trigger angle. But who actually knows the difference between looking up 15 degrees and 20 degrees? It’s a blind spot for users.

On Monday, we decided to scrap the numbers. Instead, we’re mimicking the FaceID setup logic—a calibration flow.

• “Look straight ahead and click.” — Sets the 0-degree baseline.
• “Look up comfortably and click.” — Sets the trigger threshold.
• “Look up as far as you can and click.” — Sets the accidental trigger limit.

We have to admit that everyone’s neck flexibility and line of sight are different. Rather than forcing the user to adapt to the machine’s parameters, we should just let the machine record the user’s natural movement.

The Goal System: More Than Just Tagging

Wednesday afternoon, Wang Yi and I got into a rather metaphysical discussion: How involved should the AI be in a user’s life goals?.

If we let a user set a goal, say, “I want to learn Japanese,” that shouldn’t just be a static tag. It needs to change how the AI filters the world.

• When the glasses catch relevant content, it should be more aggressive with Suggestions.
• It might shift from being a passive assistant to a “Japanese study supervisor.”

We debated “Preset Tags” (Occupation/Hobby) vs. “Free Text” for ages. Presets are efficient, but free text carries more… desire. The consensus was: this isn’t just a fill-in-the-blank exercise; it’s giving the AI a “backstory.” If the AI knows I’m a Product Manager trying to survive, its answers shouldn’t sound like a cold encyclopedia entry.

By the way, I made a joke in the meeting: “After all, I’m just a typist.” Watching my laptop heat up from running too many docs… sometimes the gap between us and the AI doesn’t feel that big.

That Button to “Reset Everything”

Monday also brought up a very practical issue: The Reset.

As features pile up—multi-device connections, cloud sync, custom settings—the side effect of complexity is that bugs can hide anywhere. Just like the iPhone’s “Reset Network Settings,” we need to give the user a Panic Button.

When Bluetooth won’t connect, notifications won’t pop, or the glasses just feel “stupid,” users don’t need to know which line of code broke. They just need a button that says: “Restore settings to default, but don’t delete my data.” It’s not sexy, but it’s the last line of defense for system stability. We even argued about the difference between “Unbind” (forgetting completely) and “Disconnect” (just a temporary break). That semantic distinction often determines whether a user feels anxious or reassured when things go wrong.

Closing Thoughts

The vibe this week… it feels like we’re trying to give these glasses a bit of “humanity.”

It needs to know if your neck is tired (HUD calibration), it needs to know what you want to learn (Goal System), and it needs to offer you a “regret pill” when you mess up the settings (Reset).

That’s hardware, I suppose. You think you’re writing code, but really, you’re translating an understanding of human behavior, line by line, explaining it to a stone.

If the previous phase was about drawing the blueprints, then these last two weeks? It feels like we’ve been paving a road in the mud.

It’s the details. The ones that look insignificant until you actually dig in and realise there’s a massive sinkhole underneath. We’ve spent the last ten days or so dealing almost exclusively with Edge Cases—connection drops when switching devices, cross-border data compliance, and that Android permission headache that just won’t go away.

It’s a bit tedious. Maybe even a bit maddening. But I suppose this is just the reality of shipping hardware.

The Boundaries of the Physical World (And That Wall)

The most “absurd yet real” discussion this week was about data storage and networks.

When we designed the Global Version, we took it for granted that the “Cloud” is omnipresent. But reality is… the world is chopped up by invisible borders. We were debating a specific scenario: What happens if a user registered in the US flies to China with their glasses?

We were half-joking in the meeting about VPNs, about “tunneling out” or “swimming back”. While we know the technical side—latency, data residency compliance—there’s something quite jarring about having to write code that checks “Are you in China right now?” to decide which server to hit.

The conclusion was pragmatic: We have to keep data where it was registered (e.g., APAC data stays in Singapore) to follow the law. As for the latency of accessing it across borders? That’s physics. We just have to try and optimise it.

The Cost of “Double Dipping” (Multi-Device Support)

Another one that’s causing headaches: Multi-device support.

A user might have two phones, but only one pair of glasses. When they switch between iPhone A and iPhone B, what happens to the audio they’re currently recording?

We thought this was a simple Bluetooth switching issue. Turns out, it’s more like “data surgery”. If Bluetooth cuts out, the glasses cache a chunk of audio, the phone has another chunk. When the user reconnects to this (or the other) device, we have to stitch these fragments back together like a jigsaw puzzle.

We argued for ages: Auto-repair? A pop-up asking for confirmation? We even got into the weeds of a “Repair and Transcribe” button logic. My gut feeling is to hide the complexity from the user as much as possible, but the technical boundaries are there—if it breaks, it breaks. We just need to find a way to patch the gap so it doesn’t look too ugly.

Who Are You? (AI Memory & Preferences)

On the feature side, we’re pushing ahead with the Personalization module.

To make the AI actually smart, we need the user to feed it some “Facts”—job, nickname, or just “Tell me more about you”.

It’s tricky, though. We want the AI to be clever, so we need data; but asking a user to fill out a “Who am I?” section feels a bit like a census interrogation. We went back and forth on the UI—tags or free text? We’re leaning towards giving the AI a “Persona” entry point. Tell it “I’m a Product Manager,” so its answers sound like a capable assistant, not a search engine.

That Annoying “Forced Update”

Finally, the infrastructure work we can’t avoid—Forced Updates for the App and Firmware.

The ecosystem gap between Android and iOS is… vivid here. To ensure users are on a critical version, we need various pop-up strategies. Full-screen block? Standard pop-up?

Honestly, I detest that “update or don’t use it” logic. It feels aggressive. But reviewing the Product Update Page, I have to admit… sometimes for safety (or to stop a critical bug), we have to be the “bad guy.” All we can really do is make the pop-up text sound sincere and make the changelog clear. At least let the user know that the 10-minute wait is worth it.

Closing Thoughts

The documents from these past few weeks are full of “What if…?”

• What if the net cuts during recording?
• What if they haven’t enabled Bluetooth permissions?
• What if the user has two accounts?

Product management is sometimes just battling these 1% probabilities. It’s exhausting—arguing all afternoon over the logic of a single pop-up. But seeing these holes get plugged one by one… it brings a bit of peace.

This is “filling in the cracks,” I suppose. The road still needs paving.

If the last few weeks were about… cutting things down, finding out what we couldn’t do… then this week? This week has felt more like… filling in the cracks. Or maybe digging up the foundations and pouring the concrete again.

We’ve moved away from the high-level concepts now. We’re in the weeds. The gritty, invisible stuff that—if we get it wrong—is an absolute disaster.

The Pairing Process: A bit of a rethink

I’ve been obsessing over the pairing flow. We had this Version 1.0, and looking back at it… well, it was a bit of a monster, honestly. We were trying to get the user to do everything—notifications, AI permissions, data sharing—before they’d even really used the glasses. It was just… too heavy.

So, we scrapped it. We’ve gone for a Version 2.0.

The intuition here was simple: just let them connect. We’ve decoupled the “connection” from the “setup”. All those permissions—the notifications, the contacts—we’ve pushed them back. Let’s wait until the user actually needs them, or when they enter the Dashboard. It feels… lighter, somehow. Less of a barrier. I think it’s the right call. It gets them to that “magic moment” of connection much faster.

The Invisible Safety Nets

Then there’s the stuff that keeps me up at night. The “infrastructure.”

We spent a ridiculous amount of time on Account Security. It sounds dry, I know. But when you’re dealing with overseas markets… the GDPR stuff is a minefield. We had this whole debate about how to determine a user’s region—IP address versus manual selection. We settled on a mix.

And it gets oddly specific. Like… did you know we have to build specific logic just to stop a teenager in Italy from using the LLM features?. We have to verify their birthday in the backend and silently gate those features if they’re under 18. It’s a lot of logic for something you hope most users never notice.

The Fear of the “Paperweight”

Firmware updates (OTA). This is the one that makes me nervous.

We had a review on the update logic, and the mood was… cautious. Rightly so. We’re basically terrified of “bricking” the device. So we’ve put in these strict gates: battery must be over 50%, network must be stable.

But the big one is the MD5 integrity check. We’re now forcing a local self-check after the download. Basically, the app checks the package hasn’t been corrupted before it even thinks about sending it to the glasses. It’s a necessary safety rail.

We also figured out the Beta channel. I’m quite keen on this. It lets us push updates to the enthusiasts (and ourselves) without risking the general public. But the version sorting logic… making sure a Beta user can slide back to a Stable release without things breaking… that was a headache.

Closing Thoughts

It’s been a week of arguments, honestly. Arguing with Rongke and Jialiang about pop-up logic or error codes. But seeing the PRD evolve from that bloated 1.0 to this sharper, safer 2.0… it’s satisfying. In a quiet way.

It’s like building a road. No one thanks you for the tarmac, do they? They only scream if there’s a pothole. We’re just trying to make sure there aren’t any potholes.

Next week… privacy policies. Joy.

Onwards.

This week has been focused on moving from the “what if” phase to the “exactly how” phase. We’ve been locking down complex logic flows, defining edge cases, and making sure the core user experience is airtight for launch.

The Command Centre: Finalising the Controls The highlight of the week was the detailed review of our hardware control page within the app. This is the user’s primary interface for managing their device, and we’ve aimed for a balance of visual feedback and utility. We finalised a design featuring a 3D model that reflects the device’s status in real-time.

Key adjustments reviewed include:

• Visual Precision: Refining how users adjust display brightness and the perceived position of content within their field of view.
• Quick Toggles: Ensuring stable entry points for core modes, such as focus/DND settings and recording features.
• Interaction Standards: Aligning hardware controls, such as scroll wheel directions and head gestures, with established mental models to ensure the learning curve is as flat as possible.

Smart and Secure Updates Defining a reliable firmware update process was a significant part of our logic discussions. We’ve established a robust sequence of checks—verifying battery levels and network stability—before any transfer begins. To guarantee security and package stability, we are implementing a local integrity check to prevent corrupted data from being sent to the hardware. We also mapped out a channel system that allows for distinct update paths for standard users versus those on early-access beta versions.

Experimental Foundations While not every feature will launch on day one, we spent time building the foundation for data-driven iteration. We discussed the infrastructure needed for A/B testing different hardware algorithms. This allows us to potentially split user groups to compare performance in areas like audio capture or display clarity, ensuring that future updates are backed by real-world usage data.

Privacy and Stability We continued to refine focus modes to ensure user privacy. Discussions focused on “locking” the device display when removed or put into specific silence modes, requiring a phone-based re-authorisation. We also confirmed granular privacy controls for hardware sensors, giving users clear visibility into which specific functions are accessing data at any given time.

Closing Thoughts It was a week of deep dives and technical scrutiny. The product is becoming leaner and more defined. While some of the more complex customisation features were trimmed to focus on launch stability, the vision for a solid, intelligent assistant remains clear.

Next week, we turn our attention to finalising the remaining UI elements and syncing with the hardware teams on feasibility for our refined control schemes.

This week has been a lesson in the harsh reality of product management. If I had to sum it up, it would be: “The Art of the Cut.”

We went from high-level dreaming to the granular, sometimes painful, ground reality of shipping a Version 1.0 product. Here is the breakdown of a week spent navigating compromises and complex logic.

Killing the Darlings (Again)

The biggest headline this week is a tough one. Remember the modular, widget-based homepage I was so excited about? The one that would allow users to fully customise their dashboard?

It’s been cut from Phase 1.

Leadership reviewed the scope and decided it was too heavy for our initial launch timeline. We are reverting to a simpler, static list structure. I won’t lie—I’m gutted. Seeing weeks of interaction logic and design work get “deprioritised” (read: put in the freezer) is a bitter pill to swallow. But, stepping back, I understand it. Stability and speed must come first. We need to ship a solid product, not a perfect concept that never launches.

The “Invisible” Mountain: Login & Permissions

With the fancy UI features trimmed, my focus shifted to the unsexy but critical backend logic: Onboarding.

You wouldn’t believe how complicated “just signing up” can be when you’re building a global product. We spent hours debating:

• Region Selection: We can’t just let users sign in; we have to route them to the correct server cluster (GDPR, etc.) before they even enter a password. We explored using IP detection vs. manual selection to make this seamless.
• Age Restrictions: We had to implement logic to handle users under 18 in certain regions (like Italy), restricting access to specific LLM features while keeping the rest of the device functional.
• The “Email vs. Social” Matrix: Handling edge cases where a user signs up with Google, then tries to sign in with the same email address manually. It’s a logic maze.

Android vs. iOS: The Notification Nightmare

We also dove deep into the Notification System. The disparity between iOS and Android continues to be my biggest headache.

iOS gives us neat categories (Social, News, etc.). Android? It’s the Wild West. We had to design a fallback logic where we maintain our own list of app packages to categorise notifications intelligently.

We also made a firm decision on Replies. We debated letting users reply to messages directly from the glasses. Ultimately, we decided no. The interaction cost is just too high with our current hardware controls. It’s better to offer a perfect viewing experience than a clumsy, frustrating replying experience.

Team Banter & Reality Checks

Despite the cuts, the team spirit is still there. I had some long sessions with the development team (and some solid banter with my colleague Shaozheng). There’s a running joke now about the “intern shield”—if things go wrong, I’m just here to learn, right? (Though in reality, the pressure is definitely on).

We wrapped up the week feeling exhausted but clearer. The product is leaner. The logic is tighter. The “bells and whistles” are gone, but the engine is being built properly.

Next week: locking down the final UI for the simplified dashboard and hopefully getting some of these logic flows approved by legal.

Onwards.