功能的确定

产品的功能并不是在确定了产品之后才开始考虑的，功能与创意选择其实是一个“你中有我，我中有你”的关系。为了体现产品设计的阶段性，我才将它单独提出来分析。

这里讨论的产品功能，是建立在选定了某个基础之上的。比如我们之前选定了天气预报，那么就将产品功能围绕天气预报讨论。

头脑风暴

一开始，我们可以对产品进行一次头脑风暴，找出它的核心功能和可以拓展的外延。

什么是头脑风暴？

简单来说，就是给定一个主题，让一群身份不同的人漫无边际的想一些点子。之后将这些点子归类整理，进一步讨论它们的可行性和重要性，最后形成一个提案。

在我们这里，可以简单的理解成：为了挖掘产品的潜在的功能，我们先不管能不能实现，不管实现了有多大的意义，不管要付出多大的代价，是把我们能想到的功能都找出来。

进行头脑风暴的人最好由不同行业、不同背景的人组成，这样考虑的问题就能多角度，更全面。不过即使只有你一个人也行，毕竟你要做一个能让自己满意的产品才会感觉到快乐，对吧。

方法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接口获取，例如阿里提供、雅虎提供、腾讯提供或者百度提供。

假如我能获取到第三方的数据，那么我是否需要自己建设一个提供天气信息的服务器呢？

就我个人来讲，我希望使用自己的服务器提供天气数据，把收集到的数据都整理到自己的服务器上，一旦某一处的数据出现问题，还可以自动切换到别处的，拥有更好的健壮性。

此外，我也可以自己定义天气数据的查询方式和回传内容，可操控性更好，不会担心数据源的格式发生改变，造成应用获取数据出错的问题。

因此我决定搭建一个服务器，为大家提供这样的数据获取方式，就不麻烦大家将精力分散到与安卓入门开发关系不大的领域去了。

不过，我这里提供的数据都是构造出来的，并不能真实的天气数据，目的只是为了帮助大家学习开发一款应用。毕竟去抓取网络数据有要花费额外的心思，偏离了我的本意。

至此，我们不需要为数据展现的内容而担心了，只要能想到的数据，我都可以在服务器端通过构造产生。之后的界面设计，就需要根据这些能获取到的信息来设计，

数据项	描述	取值
实时温度	当前查询时的天气温度	整数数值
实时风力	当前查询时的风力大小	0-17级
实时风向	当前查询时的风向	东 西 南 北 东南 东北 西南 西北
实时天气	当前查询时的天气状况	晴天、雨天、多云、多云间晴、雾、雪
当日温度范围	当日温度范围	整数数值范围
实时空气质量	当前查询时的空气质量	优 良 轻度污染 重度污染 不利于生存
空气湿度	当前查询时的空气湿度	0-100%
运动指数	当前查询时的运动指数	非常适合 适合 不适合
紫外线指数	当前查询时的紫外线强度	强 中 弱
未来5天预报	未来5天天气状况、最高最低温度

功能筛选

下面，我们就来分析一下这些功能，并为它们的重要性和难易程度作出评价。评价的原则很简单：我们只是为了展现开发的各个关节，所以尽量把功能做的简单，降低我们第一次的学习门槛

• 外观类：

项目	分析	难易程度	重要性
静态图背景	放一张静态图片即可	易	中
动态图背景	设置循环的动画效果	难	中
显示温度、湿度、风向等天气指数	具体显示哪些数据依赖于数据源	易	高
天气变化的曲线表示	这需要一个做曲线图的特殊组件	难	中
桌面小工具	安卓系统提供了桌面工具的框架机制	中	中

• 功能点：

项目	分析	难易程度	重要性
通过网络获取天气数据	这功能必须有，不然就没有显示的内容	易	高
多个天气数据源的选择	访问自己架设的服务器，不需要用户去选择	易	低
多个地点的位置设定	刚开始简化一点，只提供当地的天气预报，由服务器决定	易	低
桌面小工具	安卓系统提供了桌面工具的框架机制	中	中
提醒功能	需要网络端支持主动的推送数据	难	低
多天预报	天气类App的标配	易	高
历史天气查询	意义不大，用户更关心未来的天气	中	低

我们把重要性低的、开发难的功能暂时放一放，于是得到了下面的功能清单：

1. 通过网络获取天气数据；
2. 显示天气预报的位置；
3. 显示当前时刻的：温度、温度变化范围、湿度、风向、风力、天气、紫外线指数、运动指数等信息；
4. 未来5天天气预报，包括天气状况、温度变化范围；

此外，为了近一步简化开发，我们还可以假定：所有的数据都是从网络获取，如果没有网络，那么就不能获取到天气信息。也就是说获取到数据不需要存储到手机上，这一点又降低了开发的难度。

功能流程

确定好功能后，就要根据这些功能，为应用设计一套使用的逻辑，比如需要几个界面，每个界面做些什么事情，这些界面都要覆盖到所有的功能点。

天气预报的流程也许就是这样：

1. App启动之后，自动去网络获取信息；
2. 当日天气信息和近日的预报信息需要展示到界面上，但是具体怎么展示就要看设计阶段的设计方案了；

流程的设定和设计阶段有一定的交集。前者只是一个原则上的草图，而后者将会从设计的角度打磨出一款精品。

这时候的草图叫做框线图，就是一个手稿，一个示意图。这张图还要交给设计师，和设计师一起讨论设计的方案，再由设计师重新操刀，进行大刀阔斧的修改，将草图蜕变成真正的产品形态，最后形成高保真图、产品原型和UI素材。

下一版功能

对于那些我们没有被选定进来的功能，我们可以将它们放到该App下个版本当中。例如，位置的设定，桌面小工具，天气预报的曲线图等等。

未来版本的天气预报App不仅需要修复之前存在的设计缺陷，也要加入新的功能，让用户获得更好的使用体验。