從好的站內信設計開始討論（雖然沒有發(fā)現(xiàn)很出色的站內信設計），然后是“站內信解決了什么問題”，分清了站內信的需求層次，最后給站內信下了一個較為完整的定義：一個網站的用戶向其他用戶發(fā)送的具有一定即時性和一定私密性的消息。所以站內信的設計，便是提供滿足這個過程的功能。
在書友會快要結束的時候，我忽然覺得我們陷入了功能規(guī)格的漩渦，整個下午的收獲就是給站內信下了一個定義！雖然這個定義還挺像樣的。（這個定義拋棄了網站發(fā)給用戶的通知，認為是借尸還魂，此處僅一提，略去不談）
從使用情景上思考
站內信是一個很特殊的話題，特殊的地方在于它像是大部分網站的標配功能。這個特殊性，很容易讓我們陷入功能本身的討論中去，而不展開并深入到用戶層面。怎么講呢，用戶才不會管你是叫站內信，還是郵件，還是短消息，還是留言等等。重要的是當用戶想起要給其他用戶發(fā)消息（見順帶一提：粒度的問題）時，有一個按鈕、有一個鏈接在那里，能滿足這個需求。
大部分用戶（哪怕是專家）都會選擇成本最低的方式來操作。比如我給你發(fā)個私信，你很大可能使用私信回；我給你打個招呼，你很大可能不會用私信回。同時，當你想發(fā)消息給我，必然會選擇成本最低的方式，比如頭像邊上正好有一個發(fā)私信的鏈接、或者正好在看一篇日志于是回復之。
還有些相反的（退出使用）情況。比如，當我發(fā)短信給你，你覺得短信溝通成本過高，于是直接打電話。這種情況同樣可以對應到站內信中。又比如，我給某MM站內信（為什么不用留言，是因為留言沒有站內信私密，見下文“私密性”）道：美女，QQ號多少？于是就放棄站內信而使用QQ了，因為站內信溝通成本太高。
于是這就涉及到用戶對這個功能的期望。這點在書友會上有提及，我們分兩個維度：即時性和私密性。對私密性沒有要求的，用戶會選擇在個人資料頁上留言；對即時性有很強要求的，用戶會選擇換IM（如果可能）。這話說的不嚴謹，應該是交叉的四個象限來看，這里簡單點就略了。然后，并不是越私密就越好，也不是越即時就越好，這里面有一定的層次。
順帶一提
粒度的問題：發(fā)消息已經是很具體的意象，再往上就是更寬泛的溝通層面。談到溝通就會涉及到內容的形式，比如文字、圖片、音頻、視頻。本文講發(fā)消息，特指文字。
即時性的問題：很多朋友會覺得站內信沒有即時性。這需要看站內信是怎樣推送給接收方。在接收方在線的情況下，能即時PUSH站內信，就是即時的，這也就是站內IM的雛形。接收方是否在線，不能作為評判標準，因為IM也有離線消息，但不能說IM不是即時通信。我們以木桶的最長邊來看待這個問題。
站內信的擴展：有朋友覺得做個動作是站內信的一種外延。對此我持保留意見，理由就不贅述了。不過，打招呼還勉強能算。
對設計的幫助
用戶想要的是發(fā)個消息，而不是去用站內信功能。我們不能為了討論站內信而討論站內信，也不能為了設計站內信而設計站內信。一心想著提高即時性等特性，卻忽略了需求層次。
把未來的情景描繪出來，而不要陷入功能規(guī)格的漩渦。針對情景中不同的需求層次、期望，通過不同的途徑（界面和功能）去滿足。招呼、站內信、通知、留言等等如此應運而生。他們的存在有一定道理，但我這里提到并不是說在你的SNS產品中就必須得有這些功能。
考慮成本問題。一方面是經濟成本，在此次書友會上討論到的BP機被手機取代的例子，就是因為手機短消息成本很低。另一方面是接入成本，用戶會使用馬上能用、在手邊的功能，而不是到處找站內信在哪兒。
把未來也同樣描繪給用戶。需要以顯性的方式告訴用戶，使用這個功能能達到什么效果。比如站內信，需要提示用戶對方會怎樣收到提醒、在哪里看到內容，等等。這樣可以有比較一致的期望（即時性、私密性）。
--
以上。
記述的稍微有些亂、羅嗦。希望讀者能夠明白，歡迎參與討論。歡迎來參加 UCD 書友會。
另，站內信話題還可以寫以下文章，歡迎各位參與：
用戶與用戶之間溝通的層次
站內信與站內IM vs Email與IM
站內信是否是歷史的過渡？站內IM會取代站內信嗎？
等等
原文：http://www.junchenwu.com/2008/09/private_message_design_and_thoughts.html
粵公網安備 44010402000282號