《iOS應用軟體設計之道》—— 1.4 列出提綱時的更多輸入

本節書摘來自華章出版社《ios應用軟體設計之道》一 書中的第1章，第1.4節，作者：（美）william van hecke ，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

除了厘清頭緒外，要列出提綱還有許多輸入源。你可以通過開會來推敲出某項功能的細節。提綱是個随你所想，跟蹤所有話題、子話題、問題和決策的極好方式。

如果你能直接與現有使用者溝通（因為你正工作于已有産品上），或者與目标閱聽人中的成員溝通，就可以擷取海量的深層次資訊。畢竟，你不能一個人想到所有東西，與使用者溝通（來自支援郵件、評價等）能夠讓你關注自己的不足，而不是對其需求表現出全面、均衡的表達。

可供你收集那些應用軟體的使用者的看法的辦法很多，下面是最常用的一些。

會面：這既可以是正規的，你邀請目标閱聽人中的成員參加有組織的對話，在此你記錄資料，随後分析；也可以不是正規的，你事先準備幾個關鍵問題，在會議或行業展覽上遇到某個使用者，就問問他。如果你擅長從人們那裡得到誠實的答案（隻要他們真誠待你，這很容易），與某個熱心使用者交談15分鐘，其效果比在機關内部開一星期的會效果還要好。

情景探究：倘若你在尋求幫助人們做某件特定的工作，這會是個深入探究你要處理問題的極佳辦法。在情境探究中，你在使用者工作時拜訪他們，觀察他們的工作過程，盡可能地擷取他們的說明。如果你對這種做法感興趣，可以看看hugh beyer和karen holtzblatt合著的《情景式設計》（contextual design），此書是這種做法的鼻祖。

競争分析：如果你想做個東西，擠進業已存在的産品市場，就一定要做些工作，找出現存産品沒有做到的地方。你的應用軟體做的哪些事情其他應用軟體也做到了？依你看，這些開發者為何選擇這樣的功能集，做出這樣的設計決定？什麼是他們知道的，而你卻不知道？更重要的是，你的應用軟體有什麼優勢，讓人們願意買你的軟體而不是别人的？系統地考慮這些問題，能夠讓你更深入地了解如何把你的産品差異化，做出真正有價值的東西。

ideo方法卡（在前言中做過說明）有好幾種做法，可供你搞清楚使用者真正希望和想要的東西。

一旦你做出來産品，供這個世界使用，提綱和缺陷資料庫就是個記錄使用者回報和研究使用者的結果的好辦法。倘若沒有資料庫，即使你閱讀了有關應用軟體的全部郵件和推特資訊，隻是偶爾做一下使用者測試，你也很難讓使用者告訴你有關應用軟體的喜愛與讨厭之處。

在儲存記錄時，你可以實際檢視人們是否愛抱怨如何使用某些功能，或者測試參加者與裝置互動時是否存在麻煩，而不是依賴令人讨厭的選擇性記憶。但是，一定要記住，你得到的使用者回報并不精确代表使用者對你的應用軟體的所思所想！它代表的是人們體驗的一部分，人們的體驗會被樂意寫信反映問題的少數使用者曲解。在第10章中，我們會詳細講解開發人員與使用者的關系。

如果你開發過軟體，就可能熟悉版本控制系統（如subversion或git），它維持一個團隊所有源代碼變動的中心倉庫。版本控制不僅對代碼有用，還可以放入所有設計資源。能夠通路你的設計思路曆程是無價的，不至于讓你回想已經丢失的草圖，而需要再畫一張圖。

版本控制系統不必是必需的；如果你用的不是指令行方式，可以使用諸如black pixel的圖形用戶端versions（其可視化比較工具kaleidoscope用來檢視不同版本的設計文檔，效果非常好）。另一個傑出的工具是layer vault，是專門為設計人員創作的基于網頁的版本控制系統。