科技創業週報 #315:寫技術文章的「原創情結」

| |

Hihi 讀者們好,

這幾天以「置中控制狂」聞名的導演魏斯.安德森(Wes Anderson)新片《法蘭西特派週報》上映啦,編輯忍不住想推薦一款之前玩過的「置中」小遊戲,判斷小小的黑點是不是真的剛好位在各種幾何圖形的正中間,總共有十道題目。另外還有聖誕節版,多了雪花飄飄的干擾,還能輕易過關嗎?來玩玩看考驗自己有沒有設計師之眼吧!

lily


.

[Podcast] 星箭廣播 EP137 | 喜歡把問題複雜的人如何設計個人知識系統(ft. Ernest)

過去《星箭廣播》介紹過不少生產力工具,其中一部分跟筆記軟體有關,這次邀請了 PAFERS 派仕科技產品與科技整合總監 Ernest 來跟大家聊聊「如何設計個人知識系統」。

我們傾向於相信個人知識系統並沒有一套標準的做法,因此 Ernest 會提供一套他自己多年研究、使用的原則,讓想要設計個人知識系統的聽眾參考。節目會聚焦在原則的部分,Ernest 會先分享他的架構,並說明他的七步驟作法。他跟 Titan 也會討論一個問題:我們需要一套專屬於自己的個人化檔案標籤(tag)系統嗎?
[英] 蘋果新總部是最終極的設計工具(圖多)

2017 年,《Wallpaper*》雜誌進入蘋果剛落成的總部「Apple Park」採訪,時任蘋果設計長的 Jony Ive 闡述了背後的設計理念。眾所皆知,賈伯斯生前對新總部指標性的環狀設計與背後促成創新的精神寄與厚望,這樣的設計效果如何?四年後《Wallpaper*》重回 Apple Park 採訪由 Evans Hankey 和 Alan Dye 共同領導的蘋果設計團隊,帶讀者一探這個可說是業界最神秘的團隊和他們的文化,包含一部分 iPhone、Apple Watch 和 AirPods 的設計過程,當中涉及大量橫向的、跨領域合作。文章指出:「新產品催生了新的專業領域,而 Apple Park 正是設計來促成這樣的成長和『異花受粉』。」

例如蘋果大約在 2011 年著手開發 AirPods,團隊必須與學者密切合作,從外耳(耳機的佩戴)研究到內耳(聲學),團隊掃描了數千個耳朵,建立了龐大的耳朵資料庫,Evans Hankey 說他們的設計工作就是從資料庫開始,然後不斷掉地 iterate。另一個有意思的案例是 iPhone 的相機功能,團隊深入研究「肖像」這種藝術形式(繪畫和攝影)的歷史,研究油畫讓他們了解畫家們如何處理光影、焦點和背景等等。團隊甚至為內建相機 app 的介面設計專用字體「SF Camera」,其較為方正、類比的風格,讓人聯想到專業相機外殼上的字樣。(本文或許缺少了大家很期待的設計團隊辦公室照片,但一些照片的細節也夠有趣了,例如團隊圍著大木桌討論時,成員們是使用紙筆還是數位工具,以及他們全部都把手機朝下放在桌上。)
[英] Tinder 如何養成源源不絕的「供給端」?

a16z 合夥人 Andrew Chen 曾在 Uber 負責使用者成長,後來廣為人知的「成長駭客」概念就是他所提出的。在這篇文章中,他先定義了雙邊市場的「輕鬆面」跟「困難面」,通常在雙邊市場中,只有一小部分使用者會創造不成比例的巨大價值,同時也會獲得無與倫比的威力。就像社群網站中創造內容的人或 app 商店中的開發者。這一小群貢獻值高的使用者很難獲取、也很難留存。

這篇文章舉了很多例子說明如何「解決困難面」,通常困難面都是如何讓供給端源源不絕而且可以產生規模化效益,例如線上交友軟體 Tinder、租車服務 Uber 與 Airbnb 都是如此。作者認為,無論如何都要先瞄準細分市場,無論是從金字塔頂端(如最近當紅的 SuperHuman)或底端(如 Airbnb 最初提供空氣床墊給預算有限的旅人),先切進一小群人的需求,其他「困難面」會迎刃而解。

本文是 Andrew Chen 談論如何啟動跟規模化網絡效應的新書《The Cold Start Problem:How to start and scale network effects》(目前尚未有中譯本)第八章〈解決難題〉(Solve a Hard Problem)的節錄,有興趣的讀者可以搶先試讀。
[英] 網址很醜怎麼辦?「超連結」的設計眉角大集合

看到末端夾帶一串不明所以的參數的超連結時,你會不會有點不適感呢?雖然超連結看似理所當然,但要讓「連結」功能發揮得更淋漓盡致,達到告知效果、且讓使用者安心點擊,在設計上的眉眉角角可是不少。

例如,設置連結的文字應該具有自我解釋的功效,如果使用「點擊」、「點擊這裡」等代詞反而讓人混淆。另外,縮網址時最好將機器產生的亂數代碼,轉換為人類可讀的字眼;而在張貼網址時,是直接秀出整串網址、還是在文字上放置連結比較好呢?本文可以說是超連結設計相當全方位的檢核清單,只要日常生活中會常需要貼連結的讀者,都可以參考 🔗
[英] 明明這個功能是使用者要的,為什麼做了他們又不用?

「明明是使用者說的需求,為什麼做出來了卻沒人要用??」這是田納西大學電機工程和 CS 助理教授 Austin Z. Henley 以前在微軟實習發生過的真實案例。當時他的工作重點是公司內部每週三萬人在用的 code review 工具,在這之前他也花很多時間研究 code review,包括追蹤開發者的使用行為、分析數據,也對此做了訪談等等,所以作者想打造一個自動 code reviewer,除了簡化過程、自動更新,也能讓整個團隊都看到審查回饋。

因為 demo 反應不錯,好幾個團隊都決定試用,結果卻是淒淒慘慘戚戚,根本沒人要用😭但故事才正要迎來轉折點。作者沮喪之餘,還是想在所剩不多的實習期扭轉局面⋯⋯最後他是怎麼成功讓自動 code reviewer 確實提升生產力和審查的品質、收穫大量使用者好評,甚至讓其他微軟團隊也找上門來呢?

🌟作者也從這次經驗學到幾個教訓,例如使用者的工作流程就是一切;不要自己悶著頭打造東西,而是讓使用者一直參與其中。
[中] 產品施工中/Google Maps 很貴是指什麼,選擇替代地圖服務該注意的事

你的產品需要用到地圖服務嗎?如果需要,首選可能是 Google Maps,它具備完整的圖資與功能,但要價不菲。如果預算無法負擔,其實也有其他選擇。本文作者原本從事都市計畫產業,後來轉入軟體產品開發,他分享的這篇地圖服務觀察,相當具有說服力。

作者首先簡單介紹 Google Maps 「地圖」、「路徑」與「地點」三種開發者方案跟定價,接著分享自己找尋其他地圖服務的經驗談,最後則是提供了幾個替代方案的注意事項,先透露兩個重要的關鍵:「計價」、「使用體驗」。如果想研究市面上有哪些 Google Maps 替代方案、以及挑選地圖的眉角,本文非常值得參考。
[中] Feather Wu /產品經理電商規劃實錄,解構綜合性電商全維度規劃心法

疫情下許多產業紛紛投入電商,作者則從 PM 角度分享如何規劃一個中型綜合性電商專案,並嘗試在效能和易用性這兩個極端找出平衡。

作者先提到設計綜合性電商專案時一定要注意的三件事,像是資料來源若沒有先定義好,後續在和客戶和工程師溝通時會導致很多災難。接著她談到綜合性電商各單元頁面的注意事項,從登入註冊、商品內容頁、最複雜的購物車、行銷活動、會員中心到追蹤清單等九大項,當中有許多眉角,包括規劃加購品邏輯的效能陷阱、哪邊會建議先從後台規劃再設計前台頁面?光產出測試文件就會想吐的崩潰點?(㊙️作者有附上功能清單心智圖哦)
[中] Piglei/技術寫作二三事:原創情結

想寫些技術文章,但到年底打開部落格總是空空如也⋯⋯如果你也和昔日的作者一樣被「原創情結」所束縛,不妨看看過來人的建議。

作者提到,以往寫作前一定要確認自己沒看過類似的內容才會下筆,但萬一發現「撞了」其他文章的寫作思路和程式碼案例就會很沮喪,寫出原創內容帶來的那點虛榮一觸即破。或許「原創情結」讓寫作者自我要求更高,但特別是在技術寫作領域,追求原創格外困難,壞處更多。當了十幾年工程師之後,他也有些不同感觸,幫助自己擺脫「原創情結」。

💡最後以作者的寬慰與讀者共勉之:「所有主題都是好主題,不必想著寫出什麼驚世佳作,堅持寫,我們總會慢慢進步。」


.

(文章代表圖:Photo by Ryan Snaadt on Unsplash

本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出
Previous

星箭廣播 138 集——我很「邊緣」但我很好用:電腦裡的 Menu Bar 設計(同場加映 app 推薦)

它可能是個人電腦史上最重要的一張椅子:Herman Miller 和科技怎麼共同演化的?

Next
Share via
Copy link
Powered by Social Snap