使用者也是人#
大多數工程師花費大量時間建構軟體，卻很少思考真正使用軟體的人。本章探討工程師與使用者之間的關係，以及如何打造使用者真正喜愛的產品。
管理公眾認知#
行銷不只是行銷部門的事，工程師也需要關心。認知即現實（Perception is reality）——使用者對你產品的感受，比產品的技術細節更重要。
- Apple 的成功不僅來自技術優越性，更來自情感上的吸引力
- 使用者選擇產品時，情感因素往往大於理性分析
- 工程師應該與行銷團隊合作，而非對抗
你可以打造世界上最好的軟體，但如果沒有人知道它的存在、或者人們對它的印象不佳，那一切都是白費。
重視第一印象#
第一印象至關重要。問自己：一個新使用者在接觸你的軟體的前 30 秒，感受到什麼？
- 你的軟體是否讓人感到歡迎？
- 是否讓人立刻知道該怎麼開始？
- 還是讓人感到困惑和挫折？
少承諾，多兌現（Underpromise and overdeliver） 是建立好印象的關鍵策略。Google 長期奉行不預先宣布功能的政策——等到功能真正準備好了再發布，讓使用者感到驚喜，而非失望。
你的軟體有多好用？#
除非你正在開發給開發者用的工具，否則你不是你自己的使用者。工程師在評估自己軟體的易用性方面，表現出了極差的判斷力。
工程師最常犯的錯誤，就是假設使用者跟自己一樣理解系統的運作方式。
Google 的座右銘說得好：
「專注於使用者，其他一切將隨之而來。」（Focus on the user, and all else will follow.）
你需要跳脫工程師的視角，用使用者的眼睛來看你的產品。
Figure 6.1: 用使用者的眼睛看你的產品
選擇你的受眾#
使用者的技術能力呈現鐘型曲線（Bell Curve） 分布：
Figure 6.2: 使用者技術能力的鐘型曲線分布
- 左側：技術能力較低的一般使用者
- 中間：具備基本能力的普通使用者
- 右側：技術能力高的進階使用者
大多數軟體應該致力於將易用性的門檻向左移動——讓更多人能夠使用。
以版本控制系統為例：
- Subversion：相對容易理解，入門門檻較低
Figure 6.3: Subversion 的易用性定位
- Git：功能強大但學習曲線陡峭
- Mercurial：試圖在功能與易用性之間取得平衡
Figure 6.4: Mercurial 與 Git 的易用性比較
選擇你的目標受眾，然後為他們設計——而非為你自己設計。
降低進入門檻#
讓使用者的第一次使用體驗盡可能簡單，是成功的關鍵。
- PHP 的成功很大程度上來自其極低的入門門檻——寫幾行程式碼就能看到結果
- TripIt 的範例：只需將確認信轉寄到一個 email 地址，就能自動產生行程表。不需要手動輸入任何資料
降低門檻的具體做法#
- 不要強迫使用者在開始前就註冊帳號
- 不要要求複雜的前置設定
- 讓使用者先體驗到價值，再引導他們深入
- 速度至關重要——延遲會直接扼殺使用者的參與度
Figure 6.5: 延遲增加時，使用者參與度下降
想像你的使用者正站在門口猶豫。你的工作是把門打開、鋪好紅毯，而不是設置重重障礙。
衡量使用量，而非使用者數#
下載次數是一個虛榮指標，真正重要的是活躍使用量。
- 7 Day Actives（7 日活躍使用者）：過去 7 天內使用過產品的人數
- 30 Day Actives（30 日活躍使用者）：過去 30 天內使用過產品的人數
這些指標才能真正反映你的軟體是否持續為使用者提供價值。一百萬次下載但只有一千個活躍使用者，代表你的產品有嚴重問題。
不要貪多#
做一個烤麵包機，而不是瑞士刀。
- 不要試圖成為萬能工具
- 專注於解決常見問題，並且把它做好
- 功能膨脹（Feature Creep）是軟體品質的敵人
Figure 6.6: 不要試圖成為萬能工具
試圖取悅所有人，最終會讓所有人都不滿意。找到你的核心價值，專注做好它。
不要偷懶#
不要因為「對工程師來說比較方便」就走捷徑，犧牲使用者體驗。專注於使用者需要什麼，而非你寫程式時什麼最方便。
Figure 6.7: 功能過多讓使用者不知所措
成功的產品會隱藏複雜性：
- Apple 的 iTunes/iPod：背後有龐大的技術複雜性，但使用者看到的是極簡的介面
- Google Search：背後是全世界最複雜的系統之一，但使用者看到的只是一個搜尋框
工程師的工作是承擔複雜性，讓使用者享受簡單。
管理與使用者的關係#
使用者最基本的需求是被聽見。
Figure 6.8: 使用者最重要的需求是被聽見
「客戶服務是一種哲學，而非一個部門。」（Customer service is a philosophy, not a department.）
與使用者溝通的原則#
- 即使你不同意使用者的意見，也要先認可他們的感受
- 提供直接的溝通管道：Bug Tracker、Mailing List、開源社群
- 讓使用者感覺他們的聲音被重視，而非被忽略
Figure 6.9: 使用者數量與產品複雜度隨時間成長
Figure 6.10: 使用者的技術能力下降與絕望感上升
認可不代表同意。你可以說「我理解你的困擾」，同時解釋為什麼某個設計決策是合理的。
不要傲慢#
使用者不笨。 他們只是擁有不同的詞彙和不同的心智模型。
- 使用者用他們自己的方式理解世界，這不代表他們的理解方式是錯的
- 要有耐心，嘗試用使用者能理解的語言溝通
- 經典的故事：奶奶把 Mac 的 CD 槽當成削鉛筆機——這不是奶奶笨，是設計沒有防呆
Figure 6.11: 奶奶的 Mac 與削鉛筆機
工程師需要放下技術優越感，真正尊重使用者的視角。
建立信任與驚喜#
信任就像銀行帳戶——需要長時間慢慢存入，但可以在一瞬間全部提光。
信任的脆弱性#
- Netflix 漲價事件就是一個經典的反面教材：突然大幅調漲價格，且溝通方式讓使用者感覺被輕視，導致大量使用者流失和品牌信譽受損
用驚喜取悅使用者#
- Google Doodles：在首頁放上各種創意 Logo，讓使用者每次造訪都有小驚喜
- April Fools 活動：用幽默感與使用者建立情感連結
Figure 6.12: 給使用者一點小驚喜
在不破壞信任的前提下，適時給使用者一些意料之外的愉悅體驗，能大幅提升他們對產品的好感度。
記住使用者#
與使用者建立良好關係的三大支柱：
- 行銷（Marketing）：管理認知——使用者如何看待你的產品
- 易用性（Usability）：降低門檻——使用者能否輕鬆使用你的產品
- 客戶服務（Customer Service）：維護關係——使用者在使用過程中是否感到被重視
軟體工程不只是寫程式。你的程式碼最終是為人服務的。忘記這一點，你就失去了做這件事的意義。
這三者缺一不可。技術再好，如果使用者不知道、用不了、或感覺不被尊重，產品就不會成功。工程師需要拓展自己的視野，超越純技術的思維，真正把使用者當成一個完整的人來對待。