一个项目带你走进产品经理的世界设计确认

　　上一篇我们围绕产品的第一个版本展开分析，接下来，我们继续来看下设计确认的过程。
　　设计确认
　　首先我们来看下设计确认的含义。
　　设计确认包括原型确认和UI确认两大步，这是研发和测试可以开始工作的前提。也就是说，原型和UI确认了，研发团队才能干活。
　　那产品经理和UI确认图的时候，研发在干什么呢？划水吗？
　　一般来说，设计确认提前一两个开发周期完成，以确保研发工作不会出现断档。也就是说，研发在做上一个开发周期的功能时，产品经理和UI就要开始下一个周期的设计确认。
　　曾经年少的我认为研发出现断档，让大家在一段忙碌期后休息休息也是好事。直到有一天Leader和我核算了一下我们部门的成本，研发断档一天的成本是5k（10个人平均一人一天500块），我才开始认真对待这件事情。关注成本可以说是产品经理的必备技能之一，而这也让我对一些事情的看法和之前相比有了明显的不同。
　　原型确认
　　原型确认就是需要确认原型啦。嗯，这是一句正确的废话。不过，需要说明的是，这里的原型确认是产品经理确认的、并经过评审的下一个开发周期的原型。
　　为什么需要评审？一方面避免产品经理自嗨，另一方面多方评审可以保证整个团队在做最重要的事情。谁来参加评审呢？这个每个公司的要求不一样，一般会有技术、产品、UI等多方角色参与。
　　1。功能打包
　　对于我们的产品简报生成器来说，由于简报的信息源因为实现而导致无法让用户自定义，导致产品的核心和我们之前所理解的有所不同。所以，我们在做下一期的功能列表的时候，需要重新评估，也就是所谓的功能打包。
　　每个开发周期都是需要重新评估功能列表，重新审视之前的产品规划，以保证下一个开发周期做最正确的事情。因为在产品开发过程中，我们总会遇到一些问题，从而导致周期调整或者功能调整，甚至在上线后也很难保证所有已知的Bug都被解决。而这些遗留问题都需要记录在案，进入功能列表中，以待下个开发周期被选择或被解决。
　　由于简报信息源的问题，导致简报生成器的功能更偏向于简报的信息展示，信息源的添加需要产品经理提需求，程序去实现，才能保证对应信息可以展示。
　　因此，简报生成器下一个阶段最重要的两个功能点是：信息源的添加和信息的展示。而不是我们之前规划的简报设置，甚至说简报设置这一大类都不复存在了。
　　这么看起来，简报生成器这个产品名字似乎不太合适呢，更准确地叫法应该是简报。相应地，产品的定位也会相应随之改变，一个提供简报信息集合的产品。按理说，产品的定位修改后，要重新进行竞品分析什么的，这里我们就暂且略过，可能和之前的文章分析内容不太一样，但是分析的思路和方法是一致的。感兴趣的朋友可以翻看之前的文章。
　　接下来，我们继续分析：信息源的添加和信息的展示这两部分。
　　（1）信息源的添加
　　首先，信息源的添加是不需要画原型图的，只需要产品经理提供信息获取的规则。那对于简报来说，首先需要提供如下几类信息：
　　互联网产品
　　开发者资讯
　　创投融资IPO
　　热门问答
　　我们以互联网产品为例，给出具体的信息提取规则。从信息源上来讲，互联网产品包括以下几个类型：小程序、产品文章、iOS应用、Android应用、MacOS应用、Windows应用。小程序从知晓程序获取，需要获取每日最新的小程序名称及说明。如果你是这么写规则的，那么你一定会被挑战。
　　开发同学：知晓程序是个网站吧？我需要全网爬吗？这个工作量有点大哦
　　产品经理：当然不是啦，只需要爬取首页的最新，谁让你全网爬了。
　　开发同学：那你不说清楚。另外，我怎么知道什么是每日最新？
　　产品经理：点小程序进去，不是有个发布时间吗？它等于昨天就是最新的。
　　开发同学：还要点进去，好吧好吧那什么是小程序说明？
　　产品经理：就是点进去那个产品介绍啊
　　开发同学：
　　额，这下终于明白要把事情说清楚是有多么重要了吧。整理一下，小程序类信息的获取规则如下所示：
　　URL：https：minapp。com
　　爬取的内容：首页里的Tab为最新的内容，需要爬取对应的小程序名称、小程序说明、小程序的发布时间、小程序的URL。其中完整的小程序说明和发布时间可通过点击对应的小程序进入详情页查看。
　　爬取的时间：至少能查到昨天和今天的数据即可。
　　其实，就算你这么写了，可能还是会被挑战，比如他们会问我一次爬多久的数据啊、爬取的数据怎么存储啊、对爬取的数据格式有没有什么要求啊问题是列不完的，只能遇到一个解决一个喽。
　　剩下的几类可按照与小程序同类的需求描述即可。一般我会把需求写在Axure的页面里（一般是新建一个页面，将其命名为需求规则描述），一方面团队成员不用频繁切换软件查看，二来规则和原型也在一起也方便自己查看。
　　（2）信息展示
　　接下来，我们来看信息展示这部分。这部分肯定不能只描述需求规则啦，原型图肯定是要画的。
　　那一般用什么软件来画呢？常见的软件为Axure。产品新人大多会花很多时间学习软件的使用，很关注怎么用Axure画出漂亮的界面什么的，却常常忘记了最重要的一点，工具是用来表达想法的，能熟练使用Axure是产品经理的必备技能，但不代表熟练使用Axure就能成为产品经理，大家千万不要本末倒置。
　　要画好信息展示的原型，需要了解有哪些信息（和第一步信息源的添加息息相关，也可以反过来帮助我们检验第一步规则是否存在缺失），其次是需要展示哪些信息，最后才是怎么展示。这里也可以发现怎么展示也就是Axure画原型是最不重要的一步，之前的思考分析过程才是最重要的。所以很多人认为产品经理就是画原型的，那我只能说你怕是对产品经理有什么误解。
　　经过一系列的分析，我把原型图画出来了，如下图所示。当然这里的图只是其中一个界面，你可不能只给研发同学一个界面就当作原型图啊。筛选什么的效果怎么着都得画出来。
　　2。UI沟通
　　如果你想要和某一个人高效沟通，那你一定要了解对方关注的点在哪里。
　　那么UI关注的点在哪里呢？
　　对原型图的颜色、字体、间距、排版、布局等信息UI一概不关注，因为产品经理给出的这些信息，经UI之手后可能面目全非，会更加精致、美观。
　　那UI到底关注什么？
　　信息的关联性。哪些信息是有关系的，这样他们设计的时候会考虑将其放在一起。
　　信息的重要程度。哪些信息是需要用户特别注意的或者说用户最关注哪些信息，这将意味着他们会出现在界面的哪个位置。
　　信息的长度或边界值。哪些信息可能会比较长，这会对页面的布局以及元素的长度有影响。
　　特殊状态。必填项未填写时的报错提示、完成提示等。当然，这里UI只负责给出具体的样式，文案还是需要产品经理提供的。
　　很多时候，UI可能并不关注产品的业务逻辑，但是一个优秀的产品经理还是会为UI解释产品的业务逻辑，一来了解产品知识会促使UI设计出更合理的界面；二来UI也可以帮助产品经理出谋划策，也就是俗话说的众人拾柴火焰高，产品设计遇到难点的时候，也多个人可以讨论。
　　和UI沟通清楚之后，就是UI自由发挥的时间了。对了，还有一个很重要的点，就是要和UI沟通设计完成的deadline，并及时跟踪设计进度。请记住，没有deadline，基本等于没有沟通。因为大多数人的心理就是这样，你不说什么时候要，那就代表你的事情不着急，我可以无限拖。
　　（1）PRD（Productrequirementsdocument）文档
　　当产品经理和UI沟通完之后，产品经理就可以着手编写PRD了。当然，如果产品经理时间足够，PRD完成之后再转交UI也是再好不过的事情了。因为沟通之后一些细节，UI想要回顾的话，看PRD是再好不过的事情了。
　　关于PRD，我想到之前文章后小宝的留言：如何产出一份高质量的PRD？
　　当时我的回复是这样的：
　　首先，需要明确PRD是给谁看的？为什么要写PRD？
　　最后，针对看PRD的人，只要他们能理解你要表达的意思，就是一份高质量的PRD。
　　至于格式、形式都不是很重要，达到沟通的目的最重要，不要为了写一份高质量的PRD而去写PRD就好。
　　平时工作中，我会在原型图的旁边标注关键的点，以最终形成用于团队成员沟通的PRD。我基本很少写十分详细的PRD的文档，一来长度太长，只有测试会仔细看，开发大多都不愿意看；二来即使写了很详尽的PRD，团队之间的沟通过程也是无法避免的。所以，根据当前团队成员的习惯，我选择了在原型图旁边标注的方式写PRD。
　　网上有很多大佬会写很漂亮的PRD文档，我不清楚他们平时工作中是否也是这么写的，也不清楚与之合作的团队成员是否真的有耐心读完这样的PRD。我只是觉得，PRD并不能完全替代沟通的过程。不过，详尽的PRD还是有好处的，用于归责。如果产品经理的PRD写了，研发最终没实现，那就可以甩锅了。但这种情况可以通过项目管理的方式解决。
　　（2）UI评审
　　UI完成UI图后，产品经理一定要参与评审（验收），以确保UI图完备、准确。完备是指UI提供了所有该提供的界面，包括各种特殊状态；准确是指UI图可以准确表达产品设计的理念和想法。
　　很多时候，404界面（以及403、500界面）、空页面、搜不出结果的页面等UI可能会有遗漏，导致不够完备。也有的时候，UI在设计界面时会偏离产品设计的意图或者按照自己的想法莫名添加一些需求出来，产品经理一定要及时纠正。
　　比如我们在设计一个数据展示界面的时候，UI加了一个全屏的界面，实现上他跟研发咨询过了，可以直接调浏览器的全屏接口，然后他就很骄傲的和我讲他的设计。
　　UI小哥哥：我们系统里的数据不是太多了吗，我设计了一个全屏的功能可以全屏显示数据，可以隐藏导航栏和侧边栏，就可以多展示几列数据。
　　产品经理：多展示几列有必要吗？
　　UI小哥哥：有啊，本来放不下的数据全屏的情况下都可以展示出来了，横向滚动条也省了。
　　产品经理：那你知道用户用的都是多大的屏幕吗？
　　UI小哥哥：不管他们用多大的屏幕，我都可以支持啊。是不是很厉害。
　　产品经理：据我所知，使用这个系统的用户都是1920的屏幕，完全不存在你说的数据展示不完的问题，这样的话，这个功能似乎没什么必要呢？
　　UI小哥哥：那当我没说，图已经删了
　　其实还是要看具体的应用场景，在当前场景下的全屏功能，展开后其实也没多几行数据，不太影响用户查看数据。但是如果是在网页看博客之类的，可以全屏显示博客内容，不看周围的广告，就是一个很好的设计。就是不知道，公司的广告收入会不会因此而减少。
　　（3）设计确认阶段的产出
　　设计确认阶段会有两大比较重要的产出：PRD和UI图。
　　PRD可以和原型一起提供，这样方便团队成员查看。
　　UI图可以上传到蓝湖（常见的设计软件：Sketch、PS、XD等软件蓝湖都是支持的），方便团队成员在线查看，以减少UI和研发设计图不统一的情况出现，提高双方沟通的效率。
　　总结
　　1。产品规划和功能打包之间的关系是什么？
　　或许你会说，产品规划不是已经把每个迭代需要做的功能列表确认了吗？为什么这里又冒出来一个功能打包，不是多此一举吗？
　　并不是多此一举啦。首先，我们做的每个决定都是基于现有的认知信息之上的，当我们做产品规划时也是如此，我们尽可能做出最优的决策。但是随着产品的不断迭代、用户的不断增加，可能导致之前的产品规划不再适应当前的产品版本。
　　换句话说，之前觉得很重要的功能，现在变得无关紧要；之前觉得可有可无的功能，现在成了必不可少的功能。这就要求产品经理在每个版本开始的时候，重新审视产品规划，合理地做功能打包，给出当前版本最适合开发的功能列表。
　　可以这么理解，产品规划是产品的长期规划，需要好几个产品版本逐渐去迭代实现，而功能打包是包含在产品规划内的，是当前产品版本需要实现的功能。
　　当然或许你会疑惑，为什么产品经理在做产品规划时不能考虑得长远些呢，让产品规划更加不容易变呢？
　　只能说这个要求很难做到，需要你有足够的眼界，预测未来可能会出现什么情况；以及过去做产品的经验，能够判断这里可能会有什么坑；以及一点点的运气。
　　2。功能列表VS产品规划VS功能打包
　　之前的文章评论里有人问过这个问题，这里我们来简单说明下这三者的区别。
　　场景：假设你刚收到消息，你的闺蜜一会要来你们家吃饭。
　　产品经理：家庭主厨。
　　用户：你的闺蜜。
　　需求：直接需求是吃饭，满足生理需求。间接需求可能是来谈心（吐槽），附加需求可能是晚上睡这里。
　　功能列表：好比冰箱里的食材，有菜、肉、虾等，对应一个个小的需求。
　　产品规划：好比利用这些食材，可以做是素菜、大荤、小荤、爆炒虾等。产品规划类似一个菜单，规定了每个菜需要哪些食材，对应需求组的集合。
　　功能打包：好比关于这一顿饭，因为闺蜜对虾过敏，虾肯定不做了。只能素菜、大荤、小荤了，对应当前版本的需求集合。
　　3。需求池管理
　　既然每个版本都需要重新做功能打包，那是不是会有一个功能列表，以方便我每次从中挑选出最合适的功能列表。嗯，这个东西就是业内所说的需求池。不过需求池里不只有功能列表，还有上期遗留的Bug及用户反馈等信息。
　　也就是说，需求池和功能列表是包含关系，或者你也可以将需求池理解为动态变化的功能列表，这个池子里可以增加新的功能列表，也可以剔除一些功能列表。
　　一般情况下，我们所说的功能列表是第一版时提出的需求的集合，到后期产品迭代、需求发生改变之后，功能列表也就变成了现在的需求池。
　　一般我会和研发团队使用同样的软件来管理需求池。比如：我们现在在用Jira，我就会用Jira充当需求池管理软件，把收到的需求记录在内，并标注优先级、编写需求描述，以方便团队沟通。和研发团队使用同样的软件的好处是不用担心信息不同步，因为记录在别的地方研发不一定会关注，同时产品经理也不会忘记更新。
　　4。需求不需要评审吗？
　　看公司要求以及产品经理所负责的产品的难易程度，比如我在工作中遇到的2B产品，都是拿着UI图去和用户评审，而不是需求评审。当然，在UI评审之前，产品经理已经就产品规划和用户达成一致。
　　如果需求需要评审，设计确认的步骤就会调整为如下图所示。也就是说，UI沟通会在需求评审之后进行。
　　下一篇我们将重点关注研发测试过程，敬请期待。
　　好的，今天这篇文章到这里就结束了，我们的《一个项目带你走进产品经理的世界》系列文章完成进度如下：黄色为当前进度～
　　相关阅读
　　一个项目带你走进产品经理的世界（1）：从收到一个需求谈起
　　一个项目带你走进产品经理的世界（2）：需求分析
　　一个项目带你走进产品经理的世界（3）：从用户需求到产品功能
　　一个项目带你走进产品经理的世界（4）：产品规划
　　一个项目带你走进产品经理的世界（5）第一个版本：MVP？MDP？