從信息架構談起—更好地理解產品策劃

4 評論 24602 瀏覽 55 收藏 14 分鐘

精華速讀:

隨著互聯網的來襲,策劃者們總是在絞盡腦汁得做著各種優質的產品。然而總是避免不了各種問題,本文主要談談互聯網產品涉及的幾大層面:

一、信息架構:從需求方入手,抓住核心主干,滿足需求方的目的;

二、產品結構:從產品元素、數據類型、表結構清晰定義產品整體邏輯;

三、布局規劃:從整體角度進行模塊劃分,始終考慮產品擴展性;

四、視覺分析:第一印象,符合大眾化的感官,做出合理的設計風格。

讓我們一起探索產品策劃的本質,解決實際的問題!

長文:

互聯網浪潮已有20余年,人們已經過渡了web、app、硬件層面,未來的形態可能會越來越多。拋開應用形態來講,所有的產品本質上都一樣:如何更好得服務大眾化。就像人們所看到的那樣,在現實與網絡世界的結合中,人們總是在嘗試接受新的事物,探索新的刺激,從某種意義上講,這些事物會具體到某件產品上面,無論它是否可觸摸的,所帶來的服務已經記錄在大眾的思考中。

一件衣服,一支筆,一款應用,一臺硬件設備等等都會被稱為產品。事實已經證明夸大的說法與吸引大眾化的言辭并非能真正讓用戶喜歡它,這只是短時間的,產品的好壞會決定大眾對它的持久耐性。本章只想從互聯網角度談談產品的誕生,傳統行業也會有借鑒的地方。

一個好的idea,一個好的執行力,似乎已經是互聯網產品最初的雛形。然而,隨著產品的快速發展,必然會走向規范的流程,也許這會局限某些思維,事實上,也的確存在這種情況。但不可否認的是,業務規范性至少不會出現大層次的錯誤。做為產品人,也許寫寫文檔,畫畫原型,做好協調就能完成產品的正常部署節奏,這始終是理想階段的層面,在實際的業務流程中,總會遇到各種各樣的問題。從產品設計的角度,該用怎樣的思維方式與表現更好達到產品規范呢?還是從四個維度談起:信息架構、產品結構、布局規劃、視覺分析。

信息架構篇:說起信息架構,似乎更偏向于工程層面上。實際上,對于一款產品而言,信息架構是綜合各種因素考慮的結果,并非一個簡單的idea就可形成。對應實際的場景便是需求方、實現程度、后期擴展等層面。經常會遇到棘手的問題,可能在某次評審會上,可能在策劃中,被各種業務邏輯搞得繁雜,這樣從信息架構就可很好得梳理思路與后續發展。

對于產品策劃人士而言,落到實地的更多其實是需求,這也是產品的根基,怎么解決,如何解決,存在的問題等一系列的因素。首先得明確一點,產品一定是有需求方的,無論在大小公司還是自己單干,你的需求方就是產品要解決的問題。需求方總是來自于很多方面,比如運營人員、商務人員、boss、資本方、用戶等等,當然,也可能來自于產品策劃者本身。

面對如此復雜的需求方,的確會有寫混亂。遇到這種問題,有個好的處理方式,即列出所有需求的根源,需求方要達到的目的,實現的效果等。但主線卻是唯一的,即產品策劃負責本身,最終的產品形態只會體現出各個需求方的元素,但很大程度上,他們未必是一級需求。主線不能亂,特別是在復合型的環境下,如果沒有主題枝干,那么會因為需求方的各種壓力而使得產品擁擠。比如運營要加活動入口,商務要加廣告入口,技術構建框架等,那么在產品形態中用一些元素體現出來即可,如焦點圖,web擴展等,隨著需求的不一致,表現的形式也是多樣化,總之始終有策略性的方式來解決,但表現方式從主觀上不會影響主線,即給用戶帶來的服務。很多時候策劃者會一直遇到取舍問題,一般來講,每一次迭代與擴展突出的重點會很精益,只需要理出主干,同時在表現形式上滿足于需求方的目的即可。實際過程中,需求方提的需求很多,把確定做的需求列出來,再進行策略上的改變,這也是從信息架構考慮的目的。

總之,信息架構的出發點是抓住主干,同時考慮好需求方的實現形態,無論產品經過怎樣的擴展,都能很好的解決,本策略一定是在需求明確的情況下。

產品架構篇:與信息架構不同,產品結構是非常實際的東西,具體到產品的整體形態,無論是研發還是設計都能實際運用的東西。在搭建結構的過程中,實際上將每個需求體現的要素都具體化。好比一顆大樹一樣,枝干、葉子、樹干等,每個模塊都將元素具體化。從根本上來將,常常所說的需求側露等問題往往由于細節性的元素沒有很好的連貫性。

對于策劃者而言,每個產品的模塊劃分、具體頁面體現的元素都是產品架構最根本的問題。將產品架構放在布局之前也是有原因的,首先需要梳理好各個元素直接的關系,才能進行整體的布局。無論是web還是app,每個頁面體現的元素將取決于整體的結構劃分。如果一上來就做整體性的工作,比如直接做原型,出策劃方案,很出現很多問題,因為總有考慮不周全的地方。拿社交類的產品舉例,用戶昵稱、性別、頭像、簽名等都是產品結構的元素,正是由于這些細小的元素,才最終為整體體系搭建好基本工作。初期這項工作可能會很繁瑣,

但其作用是很明顯的,最透徹的問題在于考慮不周全,遇到實際的開發流程,則出現需求遺漏,策劃者本身就要對細節性的東西負責,一開始花時間做結構是有必要的。無論輸出的結果面向誰,至少不會存在元素混亂等現象。對于研發人員來講,知道每個模塊的元素,能夠更好的建表,知道各個業務的元素關系,則更好的整合數據庫,包括對字段等細節的處理;

對于設計人員來講,模塊的元素的量化將影響整體的設計思路,在后期的協調當中,設計與技術的對接對于需求更容易明確,無論是切圖還是數據類型的展現,都是關鍵點。

總之,產品結構更多體現在產品的元素整合上,每個頁面,每個模塊體現哪些數據類型,哪些用戶要素,都能很好得處理。從整體開發而言,業務流程的負責人會對本身的需求體現更容易理解,這始終是件有益的事。

布局規劃篇:當產品的要素形成具體量化后,則需要從整體角度考慮產品布局。本流程會對具體的產品形態進行定義。按理來講布局將劃分到產品結構上,之所以單獨拿出來,是為了理順業務邏輯,方便后期更好得擴展產品。舉個例子,在前期策劃,如果僅考慮功能實現,也許該周期能夠很好得完成,但不會利于產品擴展,一旦設計模塊布局頁面等的改動,可能就牽扯邏輯,從研發角度看,這可能是非常影響進度的事情。

建議從一開始布局就合理化,不僅適用于目前的需求展現,也適應于后期的擴展。一旦遇到需求增加等問題,總能很好的解決。近兩年,無論是web還是app開發,都出現一種較為規范的形式,就是在前期就將布局搭建的很合理,后期的擴展增加模塊只會增添新的功能與子模塊,不會對整體樣式進行大的調整。當然也存在問題,就是前期的版本從模塊劃分看來,顯示得很空,但由于快讀迭代以及敏捷開發模式的出現,使得產品形態越來越完善。

從整個產品生命周期看來,布局的條理化也是大大提高了進程。從這時起,布局與操作流程就已經相互融合,畢竟所有的操作流程都是通過布局體現。

布局規劃主要從擴展性以及合理化去考慮,也是產品具體的形態?;旧蠌谋倦A段開始,研發與設計人員已經處于交集中,保證整體的協調性。

視覺分析篇:從產品使用者角度看,視覺其實感官,印象層面的東西。也常常將“第一印象”作為產品的優良。大多數的使用者是沒有耐心的,他們本身也看不到產品背后復雜的邏輯,當然,也無需看到。產品所有需求體系在視覺上都會形成相應的區域,對于使用者本身而已,只需要通過視覺層面快速理解產品的本質。

從最初的三維化,到扁平化,以及極簡主義的視覺趨勢,已經看到產品的使用者對產品的態度。在信息復雜化的今天,如果通過簡單的設計來體現復雜的流程,更加艱難與重要,也是應了那句話:越簡單的東西越復雜?;旧?,產品的視覺層面由產品的基因基本決定,無論是色彩搭配還是元素設計體現,都會收到產品基因的影響,當然,這其實也符合規范的。對于設計人員而講,風格往往是最難定義的,往往會看到做某個模塊會大花大量時間,整個產品的視覺層面也較混亂,往往是因為最初的風格沒有搭建好。簡單來講,產品的風格定格會極大減少設計層面的問題,風格便是整體的設計理念以及突出點。無論做怎樣復雜的模塊,可完全按照風格來走,無論是app還是web,產品在頁面上也會保持統一性。該階段主要由策劃者與設計師共同參與完成。

總結

作為一名產品策劃者,有必要從整體的角度去看產品的具體流程。理想化的策劃方式在實際中總會遇到很多問題。面對技術、設計、領導層等各方持有問題,如果沒有完整的產品思維,那么很難協調好對應的流程化問題。當然,沒有最合理的方式,只有適合業務流程的方式,好的東西只能去借鑒,但具體怎么做需要看實際情況,總之探索與策略的實施是必要的。

#專欄作家#

Oneto,人人都是產品經理專欄作家,專注于分享優質的原創信息,關注互聯網、文化、知識等領域,只為傳遞好的見解。個人博客:www.oneto.top,一點時代。愿以大家一同發現互聯網的價值信息,共同進步!?興趣:下棋、讀書,研究好的產品。

轉載請保留上述作者信息并附帶本文鏈接

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 頂 起

    來自北京 回復