| Hihi 各位讀者， 我冒著被氣死以及砸壞電腦的風險為大家隆重介紹 User Inyerface，這是比利時設計公司 Bagaar 的企劃：打造令人抓狂的註冊登入流程，真的，超級，痛苦！我光要進入 Step 1 就被惹毛——Please click HERE to GO to the next page，到底要我點大寫、底線還是變色的地方啦！如此荒謬的設計還一直跳出計時視窗催催催 “ Hurry up, time is ticking!” 會不會人太差😠 這麼惱人的網站絕對不能只有我被氣到，各位體驗完每個會讓你理智線斷裂的細節後，保證會對人性化設計感恩惜福！ ⚠️服用說明書：高溫炎熱，小心上火🔥 Julie |
| [英] Paul Graham 談「如何努力工作」 Paul Graham 最近寫了一篇文章談「如何努力工作」（How to Hard Work）。他先拆解了成就偉大事業的三個要素：天賦、練習和努力，雖說具備其中任意兩點你大概就可以把事情做得很不錯，但若要做到最好則缺一不可。而天賦問題我們既無法控制，也不太能改善，所以能做的事情就很清楚了：努力工作。難道沒有任何方法靠著聰明才智躲避努力工作這件事嗎？PG 認為答案就是沒有。 PG 認為「努力工作」並不是一個開關或旋鈕這麼簡單，而是種複雜的動態系統。他結合自身經驗、來自對別人（Bill Gates、Patrick Collison 和數學家 G. H. Hardy 等）的觀察，建議讀者要把「努力工作」做對之前，應該先了解你要努力的「工作」到底長什麼樣子 ，並由此衍生出幾個他認為很困難的問題：如何辨識真正的工作？要花多少時間投入？才能與興趣跟想要努力的課題相稱嗎？（要確定自己的興趣比發現才能要困難得多，前者的種類太多了。）如何衡量自己做得好不好？（如果領域很新，可能連什麼是「好成果」都不知道。）以及何時該放棄並且轉換領域。（有太多案例顯示人們會誤判自己工作的重要性。） [Podcast] 星箭廣播 EP114 | 這樣聽音樂更好玩：聊聊幾個（其實是很多）有趣的專案和 app 你喜歡聽音樂嗎？繼 108 集〈聊聊我們怎麼聽音樂〉之後，我們要再來聊聊幾個讓聽音樂這件事情更有樂趣的網站和 app。首先是跟別人一起聽音樂，相信不少聽眾最近都悶壞了，Liz 會介紹一個跟朋友/網友一起聽音樂的網站「JQBX」（聽說過去一段時間多了很多新的台灣使用者），還有讓你自製「混音帶」的服務。在社交之外，Julie 會介紹兩個探索新音樂的網站，而且都跟地圖有關：Radio Garden 和 Radiooooo（五個 O！），後者還在地圖上加入年代的維度。 接著 Julie 跟 Liz 會介紹一些很有趣的音樂專案，包括一個有點惡搞的「How Bad Is Your Spotify?」歡迎大家去試試看 XD 而 Titan 想要介紹幾個跟歌詞有關的網站，除了他很愛的 Genius 之外，還有他最近發現、專攻台語歌詞的網站。最後三位主持人會跟大家聊聊幾個聽音樂的話題，例如日本麥當勞的歌單、數位音樂的 meta data 問題。 [英] 「北極星」只能有一顆嗎？Airbnb 前產品經理教你如何制定北極星指標 如果你正在打造「成長型」的產品，制定「北極星指標」是很重要的一步，正如其名，這個指標的作用是為公司導航，避免走上歧路。曾任 Airbnb 產品經理的 Lenny Rachitsky 寫了一篇堪稱北極星指標入門大全的指南，案例、框架、手段一應俱全。 他收集了40 間公司的北極星指標，例如 Airbnb 的北極星指標是「過夜數」，Spotify 則是「付費訂閱人數」以及「活躍使用者數」，而在 podcast 方面則是「聆聽時長」。他並詳細說明這些公司採取不同北極星指標的原因，以及建議使用「jobs to be done」的概念來訂北極星指標；他也提到人們常有的疑問：北極星只能有「一顆」嗎？ |
| [中] Keith Yang／Tech Design Review: 軟體架構設計審查 或許你也聽說過專案到最後一刻才來改規格與實作的災難，所以 iCHEF 工程團隊在產品開發的流程中，藉由分享實作前的架構設計，讓團隊先體驗、提前溝通並發現可能的驚奇（驚嚇？），確保品質之外，「pull request 也更容易被 approve 了。」 作者在本文說的架構設計類似於技術審查（Technical Review），主要是為了溝通與探索技術實作的最終模樣，通常沒那麼正式，他分享在什麼時機和階段開始做、怎麼進行，而且幾次下來體驗到架構設計經驗的好處包括：提早發現遺漏重要情境或規格因外部關鍵因素需要重新設計，都免去後續的心力損耗等等。 |
| [英] 想獲得有品質的回饋，先準備好你的問題與心態 尋求回饋的過程是一場折磨，對提問方來說尤其如此。由於自尊、脆弱的心理，導致害怕收到回饋。產品設計師 Hoang Nguyen 在本文中給了幾個建議：怎麼有效地接收到高品質的回饋，同時在一來一往之間，促進提問者與回饋者同理對方的態度。 其中一個常見的問題是，接收到負面的回饋時，設計者（提問者）也許會不自主升起「防禦心態」，為自己辯護，接著淪為個人品味之爭。Hoang Nguyen 建議，更好的作法是站在解決問題的角度解釋，例如，當回饋者提出「這設計看起來很單調」，「為了形塑品牌高雅的調性，我將色彩限縮在三種，你覺得橘色應該再突顯一點嗎？」的回應，就比「這是簡約風」來得好。 |
| [英] GitHub 買了我的 App，但我買回它又賣掉它 這是一個有點曲折離奇的故事，John Nunemaker 回顧了他因興趣使然開發的簡報產品「Speaker Deck」兩度轉手的歷程。 2011 年 John Nunemaker 帶著「Speaker Deck」在 RubyConf 首次亮相，GitHub CEO Chris Wanstrath 親自寫信求收購，讓他歡欣不已。但加入 GitHub 後產品卻成了孤兒，接著又被公司放上待售清單，最終他決定自己買回自己的產品，而且為它做了幾番整修。但最終因又因有其他產品在身，缺乏多餘心力照護，所以又賣給了能夠好好呵護它的朋友。 John Nunemaker 的行文趣味生動，但也時而夾雜他學到的技巧，例如在收到第一次收購報價時先按捺不動、保持沉默是在對話或談判時的超能力。 |
| [中] 黃翎／進入顧問公司 Design Agency 之後，可以期待的兩件事 🥰 「In-house 和 Agency 有什麼區別？該怎麼選？」這題是 AJA 大予創意 UI 設計師黃翎在 UIUX 設計講座最常被台下學生問到的題目之一，所以她從自身角度分享進入顧問公司的優點和缺點，幫助還在觀望的求職者們來做評估～ 總體來說，在台灣設計顧問公司能接觸多樣設計題目，新專案就等於一個新領域，且能了解 to C 和 to B 的產品情境差異，是新手設計師快速建立自身 UX 資料庫很好的機會；除了比 In-house 設計師更常面對「跨公司」合作，內部團隊也會隨專案彈性調整規模，需要適應不同角色。最後黃翎認為，設計顧問公司適合具有三種特質的人⋯⋯🤫 |
| [中] Yang Hsing Lin／當工程師十年的心得感想 本文作者 Yang Hsing Lin 回首當工程師十年的心得，他在每份工作都會設定不同目標，像是「在沒有特定 title 下，成為一個 10x 工程師」，進入另一間公司、開始帶團隊後，目標則轉變為「塑造一個『沒有我也可以自我成長的團隊』」。他發現 TDD、Feedback Loop 這些工程領域的概念也能運用在引導團隊上。 實踐目標的過程中，自我學習是很關鍵的一環。他設計了一個由「專業相關性」以及「理論 vs. 實作」兩個維度組成的矩陣，決定學習的內容跟深淺。最後他也提到自己如何使用科學思維解決商業或生活中的其他問題。無論是不是工程師，這篇文章都相當值得閱讀～ |
（文章代表圖：Photo by 青 晨 on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出