Hi friends,
This week, I want to share some work-related challenges I’ve faced over the past few weeks and the lessons I’ve learned from them. I’ll also be sharing a video about “From Ambiguity to Clarity,” which resonates strongly with my recent design challenges.
Work-Related:
The past few weeks have been a bit chaotic. It started in the last design review when a senior leader asked if I had used a certain design as a reference. She pointed out that the current design might not follow the best practices, which set off a chain reaction. This project is heavily tied to legal requirements, and the initial documents were really vague, so there wasn’t much I could do with the design at first. It took a lot of back-and-forth with the team to figure out what was even possible. The leader’s question highlighted areas that still needed work. Even though she just raised a small question, it caused me a lot of anxiety. I started having different conversations with colleagues, reached out to other teams to see how they were solving similar problems, did some design research, and finally wrote a detailed response. I explained what the project was about, what other teams were doing, the suggestions from the leadership, and how all of that led to the current state of the design. Then, in this week’s design meeting, I presented everything in that same structure and managed to smooth things over.
Lessons Learned Over the Past Few Weeks:
- Explore more design options: When I first get a requirements document and start sketching, I need to explore more ideas, even if they don’t all work out. That way, when people give feedback, I can say, “Yes, I’ve looked into that,” and explain why certain things won’t work. Last time, I only showed the current design and got questioned about whether I’d explored other resources, which I hadn’t done enough of, leading to follow-up issues.
- Collaborate more openly before presenting: After being questioned, I had several discussions with colleagues, each offering helpful suggestions. Some were more knowledgeable about certain aspects, like project managers or strategists, and their input was crucial in helping me answer questions more effectively.
- Consider what the audience should take away: This time, I structured my presentation to cover what the project is, the user problems, the business needs, what other teams are doing, how we can apply it, my exploration process, why some ideas didn’t work, and our current progress. Last time, I was proud of simplifying a vague and complex legal requirement into clear visuals, but I didn’t dive into the details enough, which led to more questions and issues.
- Be clear about what feedback I need: In the latest presentation, I made sure to clearly state what kind of feedback I was looking for, rather than just giving a broad overview and asking for general thoughts. I specifically asked for feedback on the issues we’re currently facing in the design, which helped keep the discussion focused and avoided unrelated questions.
- Respond better to feedback: In the past, I wasn’t great at handling feedback, but this time I used the AAA approach: Acknowledge — I hear you; Answer — Here’s what we’ve explored and the challenges we’ve faced; Action — I’ll discuss this with the team and get back to you. Using this framework helped everyone see that I was listening and understood their concerns.
Sometimes I think, being a designer really requires a bit of everything. Beyond design skills, communication is super important. I can’t just rely on the requirements document—I’ve got to talk to stakeholders, understand their perspectives, and turn that into design. Plus, it’s important to document why things are done a certain way at every step, so you can refer back to specifics during presentations or discussions.
Design Finding but Not Work-Related:
Regarding the Metropolitan Museum ticket incident I mentioned last week, I wrote to their customer service and got a reply saying that I needed to fill out the correct information and click “Save Changes,” after which I could proceed to checkout. Last time, I clicked “Save Changes” several times, but it didn’t work—this time, it suddenly did. I still think a simple prompt could solve this issue instead of leaving users confused.
Interesting Links:
I watched this video where the speaker shared his story and talked about his three principles, each backed by stories or product experiences. Three principles:
- Learning by making, not talking. Ambiguity to clarity. Great product teams learn by making. He used the example of YouTube’s “Skip Ad” button, which everyone was very skeptical about. After boldly testing it, it became a widely adopted feature.
- Create cathedrals, not bricks. He starts with a story. (Clarity means clear for everyone, not just for you.) This is like creating a vision board with the team, ensuring everyone understands the goal and is working towards it.
- Create systems, not goals. He cited an example where a colleague listed problems and the level of interest from various participants, using a simple chart to help all stakeholders understand and explain it with broader thinking.
I really like the topic “From Ambiguity to Clarity”. It perfectly applies to the crisis I’ve been dealing with over the past few weeks—how to concretize vague matters, test first, and then discuss. I’m starting to think, whether in life or work, there should be some guiding principles. What are mine?
Long
嗨，讀者朋友們，
這週我想和大家分享這幾週的工作危機，以及我從中學到的經驗。同時，我也會分享一個關於“從模糊到清晰”的Youtube影片，這個主題非常契合我最近的工作挑戰。
工作相關：
過去幾週一直在處理一場危機。起因是在上次設計會議上，一位高層問我是否有參考過xxx的設計，並指出目前的設計並非最佳解決方案，這個問題引發了一系列連鎖效應。這個項目涉及法律層面，最初拿到的需求文件很模糊，設計能做的有限，來來回回的跟團隊合作才摸出到底可以做什麼。而高層的問題剛好指出還沒做到的部分，為了回應，來回跟同事討論接下來該怎麼做，跟其他團隊詢問解決方案，接著進行一些設計研究與探索，最後寫了一篇回覆給這位高層，分段寫出目前的進度、其他團隊的解決方案、高層建議的探索、跟我們目前的解決方式。接著，在這週的設計會議上用同樣的架構進行發表，終於化解了整場危機。
這幾週學到的事：
- 永遠多做設計探索：在拿到需求文件後，開始進行研究和草稿時，我應該多做一些探索，提出不同的想法，並記錄下為什麼這些想法可行或不可行。這樣在大家給予反饋時，我能夠清楚地告知進行過哪些探索，哪些點子不可行。上次發表時，我簡述過程，僅展示當前設計，但被質疑是否有充分探索其他資料來源，無法即時回答，引發了後續事件…
- 發表前，應該跟同事開誠布公的合作：被質疑之後，我跟相關的同事多次進行討論，每個人都提供了改進的建議，有些是專案經理的領域，有些則是策略師的領域，讓他們來幫助回答問題。
- 發表前，要考慮聽眾的收穫應該是什麼：我這次的發表的架構是：這個案子是什麼，用戶問題是什麼，商業需求是什麼，與其他組的解決方案，我們可以怎麼應用，我的探索過程有哪些，為什麼不可行，最後帶到我們目前的進度。上次發表時，我原本很滿意自己把模糊的需求和複雜的法律需求轉化為簡單的圖示，並說明我們面臨的挑戰和未來方向，但卻少講了這些細節…
- 發表的時候，要明確的要求具體回饋：這次在發表時很清楚的講出希望獲得哪一方面的回饋，而非給一個很廣泛的框架，上次提到對目前設計有什麼疑慮，對未來設計有什麼建議等等，這次很仔細地描述我們目前的設計上的問題，希望針對這個問題進行討論，既可以聚焦討論，也不會被問到其他不相關的問題。
- 更好地回應設計反饋：過去我真的不太會回應大家的反饋，但這次我學到可以使用AAA的方式：acknowledge（認可）——我聽到你的回饋了；answer（回答）——我們目前做過的探索、遇到的困境、你提出的問題很好，我不清楚；action（行動）——我會去和團隊討論後再回應你。這次我運用這個框架回答問題，終於可以好好回答。
有時我會想，設計師真的是一門雜學，除了各種設計技能之外，溝通能力非常重要，不能只依賴需求文件來工作，而是要到處溝通，了解每個利益相關者的想法，並將其轉化為設計。此外，在每一步驟都要記錄下為什麼要這樣做，無論是在發表還是討論時，都要具體地引用。
生活上的設計發現：
上週提到的大都會博物館買票事件，我寫一封信給他們的客服，收到的回覆是需要填寫正確的資訊並點擊保存變更，就可以結帳了。上次我怎麼點保存變更都無法成功，但這次突然就可以了。我還是覺得只要有一條提示就能解決這個問題，而不是讓使用者感到困惑。
有趣的連結：
這段影片 主講者分享了他的故事，並談到了他的三個原則，每個原則他都用一些故事或他之前的產品經驗來闡述。例如：
- Learning by making, not talking. Ambiguity to clarity. Great product teams learn by making. 他用YouTube的跳過廣告按鈕為例，一開始大家並不看好，他們大膽推出測試之後，應用到了現在。
- Create cathedrals, not bricks. Let’s start with a story. (Clarity means clear for everyone, not just for you) 這就像是和團隊一起創建願景板，讓所有人都清楚目標，並朝著目標前進。
- Create systems, not goals. 他舉例某個同事列出了哪些問題以及哪些人想要參與的程度，通過一個簡單的表格讓所有利益相關者理解，並用更廣泛的思維來解釋。
非常喜歡這個”從模糊到清晰”的主題，這完全可以應用在這幾週的危機，所做的事情就是將模糊的事情具體化。我在想無論是人生還是工作，都應該有一些準則，我的準則是什麼呢？
Long