以用户为中心的产品设计实例
上次写的“构建产品的五个层面”主要是强调，自下而上的产品设计非常重要，面对客户或各种需求方提出的功能，用上来就画线框图满足对方需求的方式做产品是非常危险的，然而上篇写的太形而上了，大家看完纷纷表示然并卵，所以写个实例，凭空想象一个产品，如果能说清楚，对我自己也是提高，希望大家一起讨论。
昨天刚打完台球，就做一个和台球相关的产品。算是垂直领域，故事讲起来也相对靠谱。
目前打台球的人很多，但是大多数人都是只在固定的小圈子玩耍，想进一步提高的同学们如何找到高手切磋？如何证明自己是高手呢？成为高手后去哪儿炫耀呢？打球是有成本的，台费谁付呢，信任机制在哪里？
这些都是用户实际遇到的问题，产品的本质就是一种服务，是用来解决问题的，所以对这个产品的描述是城市约球平台。
实际操作
战略层：就是确认用户想要从我们的产品那得到什么，而我们又想通过产品从用户什么得到什么。
1、用户需求：扩大打球圈子（与高手切磋）、台球社交、炫耀
2、产品目标：通过提供增值服务，完成盈利。
PS：但是战略层绝不简单是这两句话而已，分析用户需求需要对用户进行细分、画像、进行可用性研究；产品的目标也包括了品牌识别和里程碑的建立等等。每一个细节都需要仔细的推敲，“经济基础决定上层建筑”都懂的哈，一个道理。今天只捞干的写
范围层：当把用户的需求和产品目标转化为产品应该为用户提供什么样的内容和功能时，战略就转化为了范围。（也有人喜欢叫这层为功能层）
扩大打球圈子和高手切磋，首先得找到这些人，确定是高手那么积分榜肯定是少不了了，如何炫耀，打球战绩分享到各大社交平台也是必备功能。
这个产品更偏向于功能类平台型产品，所以
功能规格：【寻找与发现】GPS定位，关注，热门推荐，战力排行榜；【炫耀】战力排行榜，分享（图片，短视频），平台内分享（阅读、赞、评论、回复），【约战】战力匹配、IM，【积分系统】评分规则，【基础功能】个人页面（介绍，设置等），用户系统（注册、登录、支付）等。
PS：范围层确定需要做的功能，有一个比较重要的点是确认优先级。不是所有的功能都能完成，也可能完成的不是你想象中的样子，这时候就需要制定功能的优先级。
我比较喜欢的一个方法推荐给大家。
对功能的重要程度进行排序，P1、P2、P3依次递减。
GPS定位 【P1】（为了找到附近的球友，就近约球）
战力排行榜 【P1】（炫耀的核心功能）
关注【P2】（建立弱关系链条）
支付【P3】没有积累大量用户之前，做支付没有意义。
。。。
功能的重要程度确定了，但并不是马上要根据重要程度开始进行开发了，因为和重要程度不同维度的“实现难度”也需要考虑进去。
对功能的实现难以程度排序，D1、D2、D3依次递增。
到这里了还需要再等等，我们需要技术和产品再碰依次，以上的需求，是否有可替代方案，或者说是产品和技术再次探讨需求背后的真正意义。因为产品的思路是考虑功能是否能解决问题，这里的核心是解决问题。而工程师再技术层面可以给出更好的解决方案，这样会很大程度的提高开发效率。比如GPS定位，是否需要适时，精度是否需要那么高？高精度的GPS服务器端处理要复杂一些，如果只是为了找到附近的人，用一段时间所在位置的模糊地位是否可行？
这些需求都确认好了之后，开始做功能排序1、2、3.....当然是先做1啦，又好实现又重要。
P1 P2 P3
D1 1 2 5
D2 3 4
D3 6
结构层：将散落的功能串联起来，确定要呈现给用户的“模式”和“顺序”
交互设计，为用户提供结构化的体验；信息架构，提供结构化的内容。这部分的内容可以简单的理解为流程图。
举个例子
这只是简单的一部分，实际情况比这个复杂的多的多的多。
对于信息架构的构建，其实就是组织结构化的内容，方法一般是两种，
“从上到下”：从战略层所考虑的内容（产品目标和用户需求）直接进行设计。先从最广泛的、有可能满足决策目标的内容和功能开始进行分类，然后再根据逻辑关系细分出次级分类。
“从下到上”：根据对内容和功能的需求分析开始，将所有内容都放在最低的层级，然后再讲他们分别归属到较高一级的分类，从而逐渐构建出能反映我们产品目标和用户需求的结构。
两种方法各有利弊，从上到下容易忽略细节，从下到上则非常注重于反映现有内容，不容易灵活的为以后的战略升级做兼容。根据实际情况自己权衡即可。
信息架构的基本单位是“节点”，书中把它描述成信息片段或组合，小到数字，大到图书馆。而我更喜欢把他理解为“对象”（不是处对象的对象，而是面向对象编程中的对象，一种对客观事物的抽象）。组织结构化内容其实就是组织“节点”。
信息架构组织出来的内容（这些节点）一般都是“层级结构”（树形结构），他们之前有着父子层级的关系。不是每个节点都有子节点，但是每个节点都有它的父节点，直到最顶端的根节点。这是最常见到的一种结构。
上面是在网上找的图，可以说明节点、结构化信息这些内容。
当然还有更多其他的结构。
矩形结构：允许用户在节点与节点之间，沿着两个或以上的“维度”移动。犹豫每一个用户的需求都可以和举行中的一个轴联系在一起，因此举行结构通常使用在“带着不同需求而来”的用户，使他们能在相同的内容中，找到自己想要的东西。
比如淘宝上商品列表的过滤，有人买衣服按照牌子，有人买衣服按照价钱，有人买衣服按照颜色。这种信息结构做过滤可以，但是做导航的时候就要小心了，因为维度多人脑很难可视化这些信息，不信问问周围的人，有几个能理解思维空间的。
还有两种比较少用的，“自然结构”和“线性结构”，自然结构就是节点是按照自然顺序链接起来的，没有什么分类的概念；线性结构类似于看书，一条道走到黑（这种结构非常适用于要展现的内容需要按顺序呈现的产品，比如教科书）。
这样搭建产品是有原因的，因为所有的需求，都是有根的，勿忘初心方得始终。
如果有一天有人向你提一个需求，恰好这人是你的大老板，升值加薪全靠他，他说：东啊，我想好一个好点子，你看这功能是不是亮瞎你，巴拉巴拉。。。。。如果老板能言善辩或者你不习惯拒绝别人，很可能你的产品就此就走上了歪路。这时候应该做的是，将老板提出的功能放在范围层或是结构层，看看这个需求是否能满足战略层的要求，如果不行，你作为产品经理要对产品负全责的，这时就果断的、有理有据的拒绝。
感觉写的有点多了，就先写这三层吧，在往上的两层基本就是画线框图和做UI设计了，其实没什么太多要讲的，可能以后再写一个框架层的导航设计。
欢迎讨论。