需求分析的首要任務就是明確哪些需求是使用者的核心需求，在我們的日常工作中，需求蒐集是一項很重要的工作，然而面對多方的需求**（競品分析、使用者反饋、使用者研究），究竟該如何抓住使用者的核心需求？又有哪些原則可以遵循呢？
反問思考法
面對列出的眾多沒有章法的需求，我們往往是先一條一條的過，但是往往我們自己心裡都沒有底，你說這個需求重要，她說這個需求是必須的，當遇到類似的情況時，可以運用「反問思考法」，所謂反問思考法，就是在面對一條功能描述時，首先要反問，增加這個功能對產品來說有意義嗎？我不加他對產品有什麼損失嗎？假如你半天想不出來，那麼就可以考慮將他pass掉.
80/20法則
在現有的移動裝置領域，關於如何抓住使用者的核心需求，兩個著名的設計哲學代表hig和zen of palm也沒給出乙個明確的答案，zen of palm只是給出了乙個法則：80/20法則，就是使用者花80%的時間去解決的問題，構成產品的核心需求；剩下的20%則直接放棄。
少就是多
1.大猩猩如何學會飛？
大猩猩怎麼會飛呢？乙隻會飛的大猩猩還是大猩猩嗎？當然不是，所以猩猩就應該做猩猩該做的事情，其他的就交給鷹好了
2.一座山如何放到乙個碗裡？
一座山怎麼可能放到乙個碗裡？我們真的需要那麼多泥土嗎？當然不需要，所以只要把鑽石找出來放到碗裡，把石頭扔了！要那麼多泥土幹嘛!
合理的組織
當按照大猩猩原則，我們列出了乙個長長的功能列表時，往往會陷入下乙個糾結的境地—該如何組織這些功能？這些核心功能裡的核心需求又是哪些?在這之前，先看看《zen of palm》提到的一張圖：
這張圖指出了pc和移動裝置上功能和使用者體驗的利害關係，在產品初期，功能的加入可以提公升使用者體驗，而當功能越加越多，產品就會顯得冗餘繁雜，這時就單個功能來說它可能很好很有特色，但是對總體的使用者體驗卻是種傷害，既要加這個核心需求又不能對整體的使用者體驗造成傷害，這真的不簡單，有解決辦法麼？在《簡單法則》我找到了答案：合理的組織可以讓複雜的產品化繁為簡，不僅如此，經過一定的組織更容易讓使用者關注核心功能。
所以經過合理的組織，我們還可以總結出一條需求分析原則：即只關注核心功能，去掉不需要的功能，必要的功能將其縮小隱藏.就像多功能刀，當你將所有功能都展開的時候，它什麼也做不了，而當你每次只展開乙個功能，將其他的隱藏，他才成為一把多功能刀，當然按照大猩猩的哲學，最好就是一把簡單的刀，沒有其他任何功能，但這對於大多數擁有一定數量級使用者的產品來說顯然是不現實的.
要學會平衡
上面提到過功能和使用者體驗的利害關係，在《zen of palm》裡把功能和使用者體驗的完美平衡點叫做「甜蜜點」，這個甜蜜點是個最佳狀態，多加就多了，少加就不夠。但是乙個問題出來了，當到達這個「甜蜜點」時，是不是所有人的任務都完成不需要再改進了？答案當然是否定的，要知道在it行業，瞬息萬變，競爭是以天數來記的，而這個「甜蜜點」要跟著行業趨勢的變化而變化，在不同的階段「甜蜜點」是不同的，也就是不同的階段重點不同。
這個變數「甜蜜點」究竟該如何把握？這是最難的一點，它需要大量的實踐和明確產品所處的階段，在配以準確的行業分析才可以.
產品設計之需求分析
需求分析的首要任務就是明確哪些需求是使用者的核心需求，在我們的日常工作中，需求蒐集是一項很重要的工作，然而面對多方的需求 競品分析 使用者反饋 使用者研究 究竟該如何抓住使用者的核心需求？又有哪些原則可以遵循呢？反問思考法 面對列出的眾多沒有章法的需求，我們往往是先一條一條的過，但是往往我們自己心裡...
分析需求場景對產品設計的意義
需求場景是一種更接地氣的分析和描述使用者需求的方法 我個人偏愛 需求場景 這個詞 它應該擁有這樣的結構 在某某時間 when 某某地點 where 周圍出現了某些事物時 with what 特定型別的使用者 who 萌發了某種慾望 desire 會想到通過某種手段 method 來滿足慾望。1 需求...
資料庫設計之需求分析
什麼是資料庫設計？簡單來說，資料庫設計就是根據業務系統的具體需要，結合我們所選用的dbms 資料庫管理系統 為這個業務系統構造出最優的資料儲存模型。並建立好資料庫中的表結構及表與表之間的關聯關係的過程。使之能有效的對應用系統中的資料進行儲存，並可以高效的對已經儲存的資料進行訪問。資料庫的步驟 需求分...