故事樣設計——怎樣像使用者一樣思考？

初次設計互動產品是一件很令人糾結的事情。小專案還好，一旦遇上了複雜的情況，就算有再好的工具和團隊溝通也不好使，甚至思路都被打亂。現在很多創業者都面臨著同樣的問題。因此在這裡我想分享一些通過改變設計流程來處理複雜產品的經驗。

我的插畫設計經歷

回想大學時代，我們主要設計海報，書籍封面，網頁，還有其它一些插畫。做這些工作通常使用Adobe Illustrator或Photoshop，它們非常適合設計插畫內容。批評是非常有益的，因為批評本身就是建立在對產品有一定了解的基礎上：對於一樣從未見過的東西，使用者必須花幾分鐘去了解它才能發表意見。就一張海報而言，它在設計人員和讀者的眼裡並沒有什麼兩樣。

後來我搬到舊金山並開始設計應用程式介面，但我的習慣依然沒有改變：我先設計一個介面（也可能是一組介面），然後讓其他團隊成員提提意見。這種方式我稱之為“介面式設計”。

介面式設計並不適合應用程式開發

如果你正在開發一個比較複雜的應用程式，你不可能像看海報一樣把它的結構在腦子裡整個回憶一遍。在開發過程中，我注意到多數團隊只專注於某一個介面，命名其它介面只是為了便於跟蹤。卻沒有考慮應該怎樣讓介面和功能互相配合。

通常開發過程中，我們把產品設想為一組介面。但這樣做有一個缺點：它無法真實反映人們的使用情況。實際上，使用者每次使用產品的時間並不長，在30秒到幾分鐘之間不等。

首先，使用者會在搜尋結果中注意到你的軟體，花上一分鐘左右瀏覽它的相關資訊，之後退出。接下來他們可能會再次開啟軟體，註冊，然後退出。或許他們會收取一封電子郵件，開啟軟體，完成購買，然後退出。這些例子生動說明了使用者實際體驗產品的方式。

一個好產品不能簡單把介面堆在一起——要讓它們互相聯絡起來。

如果你和你的團隊還只是單獨考慮該如何設計各個介面，而沒有把它們聯絡起來，那麼你就很難感受到使用者的真實使用情況。

故事樣設計

只要我能真正像使用者一樣思考，一切問題似乎都能迎刃而解。但我還是跳不出這個怪圈——無法把各個介面聯絡起來。

因此我開始嘗試用其它方法打破固有的設計模式。例如更換開發工具，改變開發方法以及團隊合作方式等等。下面來談談其中四種。

方法1：建立一個故事情節

設計開始之前，我思考了一些對產品的成功至關重要的東西。產品核心可能由數十個部分構成，我只需選擇其一入手即可。然後，我把它想象成一個故事情節：就像一集漫畫。如果這漫畫的結構已經確定了，那麼可以把一個使用者介面看作一幀情節。有時還能更抽象一點，把一個互動功能（類似於使用者讀取或是點選操作）看做一幀。

雖然這種開發方式速度並非最快。但它確實很有幫助，它的優點在於：

• 它能讓我集中精力設計所有的介面——甚至是搜尋引擎或者電子郵件頁面。
• 它讓我始終以使用者的目的為主要思路，因為它能真實展現使用者的使用過程。
• 一旦確定某些情節是整個故事中的重點，它們能讓我們優先考慮對應介面上的功能。
• 故事情節還能讓我注意介面之間的轉換。一個按鈕的意義不僅在於讓使用者切換介面，還應該讓使用者知道下個介面上有些什麼。

使用這種方法最大的好處是：我可以重複使用同樣的故事，這樣可以大大提高工作效率。如果我想給其它團隊成員展示我的介面設計思路，我只需要告訴他們這個故事。當使用者初次使用時，我們可以把這個故事用一系列圖片表示，這樣使用者能更好理解使用方法。如果我們需要演示產品或者為產品做一個視訊介紹——你猜對了——用這個故事就行了。

方法2：使用Fireworks描繪整個故事

設計過程中，大多數設計師使用Photoshop或者Illustrator。對於視覺化設計來說，沒有什麼比它們更好了。但我們應該注意每個介面的排版應該和使用者最終看到的效果一樣。這些故事可能包含20到30個介面，在photoshop中建立它們會比較困難——因此多數設計師不希望這麼麻煩。但不用Photoshop的話，介面之間還是沒有聯絡。幸運的是，Fireworks有一些巧妙的功能能夠在這種情況下完成故事樣設計：

• 內建式頁面：你可以用一個檔案容納整個故事內容。使用Pageup和Pagedown鍵可以翻閱它，使用者最終看到的效果一目瞭然。
• 符號：如果一個標題或者圖示在幾個頁面上多次出現，你可以用一個符號代替它。如果需要更改圖示，就不必單獨修改每個檔案了。
• 查詢和替換：設計過程中要臨時更改某些功能的名稱？它能夠做到。
• 高保真：從草稿到最終排版都可以在Fireworks中完成。故事基本設計完成後，你可以使用Photoshop修飾細節部分。

方法3：使用紙質檔案

設計團隊最終審查時，我從不單獨展示每個介面。相反，我會把整個故事中的所有介面都列印出來，然後按順序平鋪在會議桌上或是在牆上掛成一列。

這種方法的巧妙之處在於整個團隊都能近距離觀察每個介面的細節。他們可以隨時返回，檢視相鄰的介面以及介面間的切換，還能看到整個故事。這方便所有人對於介面功能和使用者目標達成一致。

當我把結果展示給其他設計師時，我會用電腦演示代替紙質文件——效果差不多。但是紙質文件對於那些不是整天做設計的工程師和專案經理實在是太有用了。用紙質文件的好處是：你可以隨時在上面寫下修改意見，方便參考。

方法4：拋棄實體模型，改為錄製截圖視訊

這是我用過的方法中最奇怪但卻是最有用的。我曾經嘗試在電子郵件中解釋介面之間的關係。我附上了一組介面，然後艱難地解釋它們是如何結合在一起的。這不僅寫起來痛苦，讀起來更是毫無樂趣。

因此我試著用ScreenFlow軟體錄製截圖視訊。所有介面在Fireworks中建立完畢之後，我只需要像使用者一樣做出點選的動作，跳轉到下個介面，然後描述跳轉過程中發生了什麼就行了。第一次錄這種視訊花了我不少時間，但操作過幾次之後就熟練多了。錄這樣一段視訊比用電子郵件描述要快得多。

這個軟體非常令人驚訝：在這些視訊中就能真正體驗到產品。因為它能非常好地模擬真實產品，這非常有利於收集使用者反饋——就像使用者給一張海報提意見一樣。

---

這只是我和我的團隊進行“故事樣設計”的一些方法。另外我好奇的一點就是：其他人有沒有注意到”介面式設計“和”故事樣設計“的區別？或者你們有沒有其它”故事樣設計“的方法？期待你們的分享。

原文連結：http://www.designstaff.org/articles/story-centered-design-2012-03-22.html