功能的確定

產品的功能並不是在確定了產品之後才開始考慮的，功能與創意選擇其實是一個“你中有我，我中有你”的關係。為了體現產品設計的階段性，我才將它單獨提出來分析。

這裡討論的產品功能，是建立在選定了某個基礎之上的。比如我們之前選定了天氣預報，那麼就將產品功能圍繞天氣預報討論。

頭腦風暴

一開始，我們可以對產品進行一次頭腦風暴，找出它的核心功能和可以拓展的外延。

什麼是頭腦風暴？

簡單來說，就是給定一個主題，讓一群身份不同的人漫無邊際的想一些點子。之後將這些點子歸類整理，進一步討論它們的可行性和重要性，最後形成一個提案。

在我們這裡，可以簡單的理解成：為了挖掘產品的潛在的功能，我們先不管能不能實現，不管實現了有多大的意義，不管要付出多大的代價，是把我們能想到的功能都找出來。

進行頭腦風暴的人最好由不同行業、不同背景的人組成，這樣考慮的問題就能多角度，更全面。不過即使只有你一個人也行，畢竟你要做一個能讓自己滿意的產品才會感覺到快樂，對吧。

方法1

可以將我們風暴的內容，寫到小紙條上，貼在黑板上，

風暴結束後，將這些小紙條按照內容進行分類整理出來，

最後按照功能的重要性、相關性，形成我們的功能列表，

方法2

在電腦上用思導圖軟體，將風暴的內容寫在上面，例如使用Mac平臺上的MindNode，

然後通過拖動的方式將它們進行整理，

最後再形成功能列表。

除了頭腦風暴，我還可以去軟體市場下載同類型的產品，逐個研究它們具有哪些功能，對那些確實優秀的功能點加以優化，做出修改，進行微創新。

舉例

我們先來風暴一下天氣預報要有些什麼樣的功能：

1. 能夠連線網路，從網路獲取資料，用來顯示；
2. 能夠將獲取的資料，例如當日的溫度、溼度、風向、是否晴天下雨、紫外線指數、穿衣指數、汙染指數等等，顯示出來；
3. 可以顯示當日之後多天的預報，採用曲線圖的方式呈現；
4. 可以顯示當日之前任何日期的實際天氣情況；
5. 能夠設定當前的位置，獲取天氣情況；
6. 能夠配合當前的天氣，顯示一張合適的背景，比如下雨的時候，背景就是一張雨景的照片；
7. 能夠配合當前的天氣，顯示動態的背景，比如下雨的時候，背景就是雨水滑落的動態效果；
8. 能夠接收提醒，比如下雨了，發出一個通知提醒使用者帶雨傘；
9. 能夠提供一個桌面小工具，在桌面就能檢視到天氣資訊；
10. 天氣資料到的源可以選擇，阿里提供的、雅虎提供的、騰訊提供的、百度提供的，都可以切換；

雖然我們還可以風暴出很多天氣預報可以具有的功能，但是作為第一個例子，我們暫時就列出這麼多吧。

接下來將功能分類，有的分類項也許有重疊，但是沒有關係，

• 外觀類：

  1. 配合天氣顯示的背景：動態圖或者靜態圖；
  2. 顯示溫度、溼度、風向、天氣、紫外線指數、穿衣指數、汙染指數；
  3. 未來天氣的預報，採用變化的曲線表示；
  4. 桌面小工具；

• 功能點：

  1. 通過網路獲取天氣資料；
  2. 多個天氣資料來源的選擇；
  3. 多個地點的位置設定；
  4. 桌面小工具
  5. 提醒功能；
  6. 多天預報；
  7. 歷史天氣查詢；

選定功能

列出一堆的功能後，我們就要考慮給他們排列個重要程度了，確定哪些功能是必須的，哪些是可選的，他們實現起來複雜度有多大。

對於複雜度很高的功能，我們可能還要進行一次頭腦風暴，理清楚它的重要性，看能不能把它分解成相對簡單的功能來加入。如果不能，那麼可能就得暫時放棄了。

有的功能可能還要依據現有的素材，看能不能提供，例如紫外線指數，如果網路端都沒有這樣的引數，那寫在功能列表裡面也是沒有用的。由此我們也可以看出，頭腦風暴之後，多種成員參與的重要性，如果有一位開發者，他可以很快的判斷這個功能點從技術上講實現起來是否可行。

技術驗證

坦白的講，技術驗證並不是在功能確定之後才開始進行的。它應該在確定功能的時候給予技術上的配合，告訴方案的提出者：“這樣的功能從技術上講是可以（不可以）辦到的”。

能越早回答這樣的問題，就能越早發現並減少專案的風險。

在天氣預報當中，最需要驗證的並不是設計出一個介面設計出來後能不能做出來，而是去哪裡獲取天氣資料。

天氣資料才是功能的核心。從哪裡獲取資料呢？

我們沒有自己的觀測站，所以資料肯定是要從其他公開的渠道獲取：通過網路蜘蛛爬取；通過第三方提供的標準API介面獲取，例如阿里提供、雅虎提供、騰訊提供或者百度提供。

假如我能獲取到第三方的資料，那麼我是否需要自己建設一個提供天氣資訊的伺服器呢？

就我個人來講，我希望使用自己的伺服器提供天氣資料，把收集到的資料都整理到自己的伺服器上，一旦某一處的資料出現問題，還可以自動切換到別處的，擁有更好的健壯性。

此外，我也可以自己定義天氣資料的查詢方式和回傳內容，可操控性更好，不會擔心資料來源的格式發生改變，造成應用獲取資料出錯的問題。

因此我決定搭建一個伺服器，為大家提供這樣的資料獲取方式，就不麻煩大家將精力分散到與安卓入門開發關係不大的領域去了。

不過，我這裡提供的資料都是構造出來的，並不能真實的天氣資料，目的只是為了幫助大家學習開發一款應用。畢竟去抓取網路資料有要花費額外的心思，偏離了我的本意。

至此，我們不需要為資料展現的內容而擔心了，只要能想到的資料，我都可以在伺服器端通過構造產生。之後的介面設計，就需要根據這些能獲取到的資訊來設計，

功能篩選

下面，我們就來分析一下這些功能，併為它們的重要性和難易程度作出評價。評價的原則很簡單：我們只是為了展現開發的各個關節，所以儘量把功能做的簡單，降低我們第一次的學習門檻

• 外觀類：

* 功能點：

我們把重要性低的、開發難的功能暫時放一放，於是得到了下面的功能清單：

1. 通過網路獲取天氣資料；
2. 顯示天氣預報的位置；
3. 顯示當前時刻的：溫度、溫度變化範圍、溼度、風向、風力、天氣、紫外線指數、運動指數等資訊；
4. 未來5天天氣預報，包括天氣狀況、溫度變化範圍；

此外，為了近一步簡化開發，我們還可以假定：所有的資料都是從網路獲取，如果沒有網路，那麼就不能獲取到天氣資訊。也就是說獲取到資料不需要儲存到手機上，這一點又降低了開發的難度。

功能流程

確定好功能後，就要根據這些功能，為應用設計一套使用的邏輯，比如需要幾個介面，每個介面做些什麼事情，這些介面都要覆蓋到所有的功能點。

天氣預報的流程也許就是這樣：

1. App啟動之後，自動去網路獲取資訊；
2. 當日天氣資訊和近日的預報資訊需要展示到介面上，但是具體怎麼展示就要看設計階段的設計方案了；

流程的設定和設計階段有一定的交集。前者只是一個原則上的草圖，而後者將會從設計的角度打磨出一款精品。

這時候的草圖叫做框線圖，就是一個手稿，一個示意圖。這張圖還要交給設計師，和設計師一起討論設計的方案，再由設計師重新操刀，進行大刀闊斧的修改，將草圖蛻變成真正的產品形態，最後形成高保真圖、產品原型和UI素材。

下一版功能

對於那些我們沒有被選定進來的功能，我們可以將它們放到該App下個版本當中。例如，位置的設定，桌面小工具，天氣預報的曲線圖等等。

未來版本的天氣預報App不僅需要修復之前存在的設計缺陷，也要加入新的功能，讓使用者獲得更好的使用體驗。

本文是《從設計到實現-手把手教你做android應用開發》系列文件中的一篇。感謝您的閱讀和反饋，對本文有任何的意見和建議請留言，我都會盡量一一回復。

如果您覺得本文對你有幫助，請推薦給更多的朋友；或者加入我們的QQ群348702074和更多的小夥伴一起討論；也希望大家能給我出出主意，讓這些文件能講的更好，能最大化的幫助到希望學習開發的夥伴們。

除了CSDN釋出的文章，本系列最新的文章將會首先發布到我的專屬部落格book.anddle.com。大家可以去那裡先睹為快。