最近為了在技術鏈條中選擇合適的模塊,我看了比較多的技術文檔,發現不少產品的文檔真是不咋地,屬于“純技術思維”的文獻,似乎就沒考慮用戶這邊的感受和想法。

文檔直接決定了開發模塊的學習曲線是否陡峭。學習曲線平緩,才讓人感覺好用,易用,方便入坑。學習上的認知障礙是怎么產生的呢?為什么用戶看了會覺得“稀里糊涂”,覺得上手犯難,有挫敗感呢?因為里面引入了太多“從天而降”的概念而不去解釋,想當然的默認用戶應該了解、知道,這怎么可能。

我認為,一個好的、正常的文檔,應該是問題導向的。畢竟用戶使用它,就是為了解決問題而來。應該先闡述的是大家面臨的公共問題和需求,還有它能解決什么問題,到什么程度,在什么地方用,怎么用,再說明我們用什么方法做到的。

后面,再順帶引出,我們制造出這些方法,必須引入的概念和設計思路,這些概念背后是什么意思。這樣,大家就容易理解其用意了。

然后,提供入門教程,順帶詳細解釋,里面涉及到的自造概念的方方面面。它能帶來什么,這么設計好處是啥,等等。后面有進一步的深入教程、接口手冊、FAQ等等。

接口部分,除了介紹接口的具體使用,更應該有的,是整體的運行邏輯的說明和Demo。告訴用戶,這些API,是如何組合起來完成任務的,可以操縱的是哪些,在什么時機。如果沒有這些,用戶很容易“只見樹木不見森林”,不知道整體的結構和設計邏輯,因為API只是“單詞”,不是更有深度的“句子和段落”。而如果知道這些使用方法,就會對產品更有信心,也更容易掌握它的使用方法。

一般我認識一個產品或者模塊,都是先檢索產品名字 + 入門、教程,有了初步概念,再尋找最佳實踐,Faq,而文檔應該提供這些內容,才稱得上合格。

我認為這才是順著認知心理規律的文檔設計。而我看到的不少產品文檔,都做不到這一點。典型的例子是:產品有一部分自我介紹和特性宣傳,提供了一個簡單的入門教程案例 – 有一些連這個Demo都沒提供。然后就是API羅列了,中間還夾雜著自造的一些概念名詞。

作為剛剛接觸這個產品的用戶,第一反應常常就是:它怎么用呢?那些突然出現的“概念名詞”啥意思?為啥用它呢?估計不少用戶已經開始打了退堂鼓,不知道怎么上手。

不得不說,即便是做技術,產品思維也是很重要的審視習慣,用戶視角必不可少。

作者博客