架構架構，顧名思義就是框架結構，信息和內容有主次、有分類、有前后邏輯。什么樣的框架結構能夠滿足業務和用戶兩者的需求，那就是一種好的框架。

好像又是一句正確的廢話。

舉個例子，書店里的書，如果按照常規主次、分類和邏輯來規劃的話，那估計就賺不到什么錢，但如果我們調研過經常來逛書店的用戶群體特征的話，我們就可以重新調整書籍的分類擺放區域以及設定一些特殊的展示，比如用戶對某個類別下的書很感興趣，但是這個類別是屬于一個很小的分支，按照常規分類那只能在角落里，這時候就要單獨拿出來進行擺放，才能提高曝光。但如果用戶想要什么都單獨放出來，整個結構又會雜亂無章，所以信息架構設計是一門繁瑣的學問。

所以，信息架構設計離不開用戶的心智。我們常聽到的是，信息結構可以分為自上而下而下或者自下而上，那和用戶心智有什么關系呢？我也用一個很通俗易懂的舉例告訴大家。

自上而下的意思就是，我把分類的類目標簽分好了，你只需要把內容根據自己認為的分類放進去就好，比如我給你蔬菜、水果和肉類三個標簽，然后把帶有西瓜、胡蘿卜、西紅柿、桃子、豬肉、魚肉、雞肉….這樣的標簽卡片交給你，讓你根據我分好的3個類目進行歸類，是不是很簡單。

反過來，自下而上的意思就是我把標簽卡片給你，讓你自己來分類。那有同學說，那不是很簡單，我也會分為蔬菜、水果和肉類啊。所以心智在這里就體現出重要性了，每一類用戶群體的心智是不同的，我可以按照物體本身的類目來分，也可以按照物質的功能作用來分，比如西紅柿和雞蛋可以組成一道菜，不同的食材做出不同的菜肴或者菜系，我還可以按照食材的新鮮度來分，顏色來分…..

數字產品的UX設計師要學的東西很多，如果讓各位根據規范做做UI視覺，你仔細研究一下那些大廠產品的設計規律和細節，很快按葫蘆畫瓢自己就可以領悟出一些不錯的技法。但唯獨研究用戶心智以及如何將用戶與產品做到更加高效和緊密的連接，光靠界面精致是遠遠不夠的。

說到信息架構，很多人覺得這個可能是產品工作者的范疇，但簡單琢磨一下，又覺得信息架構和交互也是密不可分的，所以我們不要太糾結崗位帶來的界限，能力是沒有界限的，你只要有興趣和好奇心就挖的深入一點去學，總不能說，哦信息架構師產品的活我不需要碰我就不去了解了，寫原型交互說明是交互的活，我是產品我也不管了，大家都這樣把自己的一畝三分地劃分的很清楚，那將來你們團隊就不會有一個人來統籌大局。

如果只是講一個大概念，大家肯定會覺得味同嚼蠟，所以不妨來跟著我一起思考一個案例。

產品的功能規劃是比較宏觀的，這個不容易講，那么我們可以聚焦到某一個功能點，比如我們如何設計一個舉報的功能。這時候讓你來設計這個功能的結構，你會怎樣思考?，F在只有這樣一個“概念”，對于舉報的入口、頁面劃分、內容布局都完全沒有頭緒，該怎么設計呢？

萬事開頭難，關于框架結構，總是會出現這幾種，比如樹狀結構、線性結構還有立體結構以及自由結構，大家直接根據字面意思理解就可以了，那么像舉報這樣的功能，是屬于一種比較支線并且使用頻率較低的功能，同時是一個快速用完即走的場景，所以也就不會涉及到立體以及自由結構。

在做功能設計前，務必要對業務背景有足夠的了解。比如舉報入口，就像我剛說的，舉報是一個低頻、即用即走的支線功能，入口弱化就可以了。那如果現在換成我整個應用產品就是為了做舉報而存在的呢，app的名字就叫“12315”還有“國家反詐中心”，這時候入口還是和之前一樣嗎，那肯定不是。

所以在前期就要帶著這些問題去思考：

1.為什么要做舉報功能

2.舉報誰/什么

3.舉報流程中需要包含哪些信息內容

4.用戶的舉報場景是怎樣的

1.為什么要做舉報功能

這個問題對于信息架構的影響在于，我們期望找到做該功能的原因，以及該功能在整個結構中的優先級

2.舉報誰/什么

舉報對象的不同對整個功能結構也會有很大的變化，比如看下方的幾個案例分別是：愛奇藝、公眾號、追書神器、抖音。舉報對象的不同意味著舉報類型的不同與多少，同時還意味著舉報場景的深入還是只是為了輔助篩選優質內容，最后決定了我們做交互是應該用什么框架來搭建這個流程。

比如公眾號的舉報類型就非常多，并且還有很豐富的二級舉報類型，那么它和愛奇藝就不同，愛奇藝的舉報單純是為了更加粗略的希望通過篩選來判斷內容是否優質，而公眾號對于文章的舉報會更加的嚴格和仔細，因為懲罰力度對于作者來說也比較嚴重所以該流程需要對舉報人的舉報內容和類型要求更高。

再說追書神器，那這個舉報就更加“簡單了”，小說在上線之前就會通過編輯審核，基本上很少會出現低質量內容，但也不能沒有，那就做一個更加方便快捷的舉報流程即可。

3/4.舉報流程要包含哪些信息內容和場景

信息內容取決于用戶需求以及業務需求，比如愛奇藝在舉報流程中會增加一個專門針對版權內容的申請刪除以及恢復刪除的入口。還有像12315在舉報時需要實名填寫舉報人信息以及處理單位選擇等等。同時，專門用來舉報的應用還會有“舉報記錄”的查看，而其他應用則并不會提供舉報記錄，這點很明顯吧。

所以基于前面這幾點的考慮，就可以把大致的框架劃分出來了：1.點擊舉報 2.選擇舉報類型 3.填寫舉報內容 4.提交

這里劃分框架其實就是根據用戶的場景和行為來制定的，你看我寫的是點擊舉報而不是滑動舉報，寫的是選擇舉報類型而不是點輸入舉報類型，同時有了點擊舉報才能去選擇類型，而不能一上來就選擇舉報類型或者將填寫舉報內容和選擇類型換一個順序。

當然這些節點并不意味著就是一張張界面，因為你會發現有的產品把2、3做在一起，而有的則是分開。一般如果類型多，需要填寫的內容復雜那就分開做成兩步，反之則合并。

那么在這里流程也是屬于信息架構設計環節中的一部分，所以想要定義整個產品的框架其實是十分復雜的，因為信息架構是需要跟著產品周期隨時調整的，很多人覺得自己信息架構能力不行，其實并不是這樣的，你如果很抽象的想象一個從未接觸過的業務，你肯定是想不出來的，就像造房子和車子一樣，沒有人能從一開始就知道產品的終極形態，能解決當下核心問題或需求的產品和功能遠比在一開始就花大量時間去思考完整形態要重要的多。

作者：應駿
來源：站酷