Sailing Through the Fog

Hi everyone,

It’s been a few months since I last wrote a blog post. Life has been busy, but I finally found a little time to reflect and share some thoughts from a recent project at work.

Not sure if any of you follow a design process like “discovery, design, development”? The project I joined recently started as a lift and shift. We were migrating an existing product to a new service. In theory, the design wouldn’t change much. But in reality, it felt like sailing a ship through thick fog. We quickly found that the articles on this new service’s website weren’t up to date. It turned out our parent company was already using newer versions internally. We had to go back and forth to figure out which information was actually reliable. On top of that, we realized our update would impact other teams’ business goals, and everything was more interconnected than we expected.

Even though it was supposed to be a simple migration, every small step required careful alignment. It felt like we cleared some fog, only to realize we still couldn’t reach shore and begin development.

One day, I paused and laid out all the design files and notes. I tried to pinpoint what was really blocking us. That’s when I realized our communication might not be working. Verbal updates weren’t enough to get everyone on the same page. So I started building a presentation deck. I mapped out technical constraints and possible flows under different scenarios, and paired it with interactive prototypes. I even made screen recordings and turned them into GIFs so stakeholders and leadership could quickly grasp the key points. High-fidelity design files can sometimes lead people to focus too much on the details. But in this case, the slides helped bring the discussion back to what really mattered: timeline, technical limitations, design trade-offs, and decisions that needed to be made. I also added a section listing all related questions, resolved answers, open questions, and pending decisions. This helped bring clarity to the whole situation. Eventually, the deck helped leadership understand the key differences. The team found a way to resolve blockers across groups. We were finally able to move forward with design and development. After weeks in the fog, our ship had finally reached land. I felt a huge sense of relief.

Beyond this experience, I picked up a couple of other takeaways I want to document:

Don’t skip early research just because the project feels limited

At first, I didn’t do much competitive analysis. I spent most of my time syncing with internal designers who were working on similar projects and confirming all the technical and design constraints. But a few weeks in, leadership started asking deeper questions, especially things like “How do other companies approach this?” That’s when I quickly pulled together industry examples and patterns. I realized our flow wasn’t that unique. It only looked simplified because of technical limitations. This made me realize that even when a project feels restricted, early research is still worth doing. It gives you a reference point and helps you explain design decisions with more confidence.

Later on, I saw another designer create an inspirational analysis and a North Star version of a similar flow. At first, I thought, “None of this applies to our project. We can’t build it anyway.” But then I realized that even if we can’t build it now, it’s still valuable. It gives us something to aim for. These types of explorations help define a long-term vision.

A question tracker isn’t just for PMs, it helps me think too

When the project first started, I kept daily logs of what I worked on and saved Slack discussions to track progress. But as things got more complex and more people got involved, the number of open questions kept growing. I started to lose track. Eventually, I sat down and created a question tracker in Google Sheets. I listed everything I could think of: what information we needed, what was still unclear, which questions were related to research, which ones were technical blockers, who I needed to follow up with, and which answers had changed over time. For example, an engineer once told us a feature wasn’t possible. Later, we discovered another team had already implemented it. After double-checking, it turned out it was indeed possible. If I hadn’t written that down, I would’ve lost track of the full story. This reminded me of something a former manager once suggested. At the beginning of a project, create a shared Google Sheet where everyone can list their questions. Then the product manager can help clarify what’s already known and what needs more research. This time, I created the tracker halfway through the project, but it was still incredibly helpful. It kept me organized and gave me something concrete to refer to when making decisions.

Final thoughts

This foggy journey reminded me that being a designer is about more than creating screens. It’s also about connecting information, helping teams move forward, and creating clarity when things feel uncertain. I hope the habits I practiced here, building clear decks, doing early research, and keeping a question log, become part of my muscle memory. I’m planning to bring them into my next project. Thanks for reading, and see you next time.

Long

嗨大家好，

好幾個月沒有寫網誌了，這段期間忙於各種事情。最近終於有點空檔，想寫下最近工作上的一些感悟。

不知道大家的設計流程是什麼？是類似「探索－設計－開發」這樣的結構嗎？我最近參與的專案，起初是因應技術更新，把原有的產品搬遷到新技術平台上，理論上設計不會有太大改動。但實際進行時，就像是一艘迷航的探索船，在一片霧裡摸索。我們發現從公開網站查到的技術資訊不是最新的，反而母公司內部正在使用的是更新的技術。來來回回釐清後，才搞懂什麼是確實可用的方案。我們也逐漸意識到，這次更新牽涉到其他團隊的年度目標，整個案子牽一髮動全身。

即使理論上只是搬遷，現實中每一小步都需要再三確認，導致我們像是撥開雲霧後，還是無法真正靠岸開發。

某天我靜下心來，把所有設計稿和相關資料攤開來整理，思考到底是哪個環節卡住。我發現也許是溝通方式出了問題，只是口頭討論無法有效對齊認知。我開始製作簡報，將整體流程與技術限制的比較列出來，搭配設計圖做成互動原型，甚至錄成影片轉檔成 GIF，讓利害關係人與主管團隊能一目了然地理解問題。雖然高保真的設計稿有時會讓討論陷入細節，但這次的簡報反而讓大家聚焦在真正該解決的點上，像是時間安排、技術限制、設計考量與決策方向。我也把大家常見的問題、已釐清的答案，以及未解決的問題與待決事項統整在一頁，協助大家一起思考與討論。這份簡報後來幫助主管釐清整個差異點，大家也集思廣益解決了原本牽動其他組的爭議，讓我們終於可以啟動開發。這艘探索船，總算靠岸，真的鬆了一口氣。

除了這個經驗，還有一些延伸的學習想記下來：

不要因為「限制很多」就忽略前期設計研究

這次我一開始沒有做太多外部競品分析，主要把時間花在與母公司內部做類似專案的設計師確認技術限制與實作方式。但幾週後，主管團隊開始提問，尤其是「其他公司怎麼做」時，我才開始補做研究。後來我整理了業界案例，才發現我們的流程其實沒有那麼「特別」，只是因為技術限制，表現上看起來比較簡化。這時我才意識到，即使受限，也應該提前準備這些資料，不僅是作為佐證，也幫助大家更理解設計決策的背景。

另外，也看到其他設計師針對類似流程做了趨勢分析與 North Star vision 的設計版本。一開始我也覺得這些東西我們根本沒辦法實現，但後來換個角度想，其實它們是我們未來可以努力的方向。即使現階段做不到，這些資料也提供了值得參考的願景。

問題整理表不只是 PM 的工具，也能幫助自己思考

剛開始專案進行時，我習慣用時間順序記錄每天做了什麼、Slack 上有哪些討論。但問題越來越多，相關人員也越來越多，許多問題的答案還會隨時間改變，讓我記一記就沒記了。直到某天我靜下心來整理資料，才決定開一份問題清單，把所有問題條列出來：需要什麼資料、還有哪些資訊不清楚、哪些是研究問題、哪些是技術限制、要問誰、甚至哪些是重複問過但答案不同的項目。例如，有些工程師一開始說某功能做不到，後來我們發現其他團隊做過，他們再回去查，才說其實可以實現。這種資訊的變化如果沒記下來，很容易讓人失焦。這也讓我想起以前主管建議的作法：在專案初期開一份 Google Sheet，讓大家把一開始的問題列出來，讓 PM 判斷哪些已知、哪些需要研究。我這次是從中期才建立，但發現即使是後補也很有幫助！不但讓我更好追蹤整體進度，也讓設計與決策更有依據。

這次的迷霧航行，讓我更加提醒我設計師的角色也是串接資訊、釐清方向、協助團隊前進的推進者。希望這些練習可以成為我下個案子的基礎與肌肉記憶。下次見。

Long