从0到1设计一款产品，我的反思与总结

                                                本文作者结合自己的经验，总结了产品从0到1设计过程中的一些反思，与大家分享，希望可以给大家一些启发。

2015年的夏天，我以实习生的身份来到现在的这家公司。刚到公司时，我在一个已经比较成熟的部门项目下做着用户研究的工作，直到有一天，领导让我做一个关于XX的竞品分析报告。当我找遍资料写完报告交给老板时，虽被领导找出了一千个不足之处，但一番“痛骂”教导后，对我说“1.0的需求原型、周五前给我个初稿”。我好像一个毛头小兵，突然被委以重任，便开启了从0到1的产品设计之路。
在这个项目中笔者参与了iOS端APP以及PC官网、后台的设计，那么我着重会以iOS端APP的产品设计进行举例分析。
如何把原型需求做得更好
关于如何收集与整理用户需求、如何绘制原型、如何写一份优秀的需求文档，网络上优秀的干货文章不胜枚举，在此笔者不再赘述。
值得一提的是，对于需求文档的撰写，我并不注重偏形式化的东西，文档的命名格式以产品名/功能名_版本号_撰写日期即可，一份需求文档则是一款产品，那么开发人员则是使用它的用户。如何让用户体验好，才是产品经理在撰写文档时更应该注意的。
一份需求文档可能会被前端开发、API开发、后台开发、测试等不同的技术人员阅读，在文档中应该体现针对不同角色而对应的不同阅读模块。简单来说，ios开发需要阅读文档中的整个功能需求模块，而PHP开发只需要阅读所需接口需求模块，因为对于PHP开发来说，如何实现一个翻页操作是他毫不关心的。在文档中，针对不同角色分段说明，开发能明确知道自己的开发任务、阅读体验更好，也能有效提高开发效率。当然，内容条理、逻辑清晰是需求文档的基础。我也经常会问开发，你需要什么样的需求文档？开发说“我可以完全按照你的需求文档开发，不需要再做任何思考”。那这其中要求的是产品经理将各方面考虑详尽，但在实际操作中，产品经理难免也会有遗漏之处。
在1.0原型初稿出炉之后，我面临了职场的第一次鄙视，来源于隔壁组支援的UI设计大兵。我仍记忆犹新，在个人中心页面上，有一个登录及我的订单入口。而我居然遗漏了未登录状态下点击我的订单入口时的情况。这几乎对所有产品经理来说，是一个不可能犯的错。我被大兵鄙视了一番“你这原型画的，我都没心情设计”，这也着实给了我一次较沉重的打击。事后我一直在反思，怎样才能让自己在做需求设计时考虑的更全面呢？
[ol]

借助思维导图、流程图等工具

0与1 、和1到多法则

犯错后的反思总结
[/ol]
思维导图是一个非常简单但极其有效的帮助思考工具。在思维导图中，你可以将产品的功能进行分类再分类、深入到每一个细枝末节。它不仅能帮助你深入思考、而且记录下思考过程。在绘制原型时你可以遵循思维导图进行设计，尽可能避免遗漏任何一个枝节，而流程图的绘制对于页面操作交互、流程的设计十分有利。我们所期望的是用户能够在我们的产品中进行转化（注册、下单等），那么要求所设计的任何一条路径都是能够通向目标的，如果在流程图中发现有一条走不通的路径，那这里的问题就是产品经理应该去考量的。
0与1、和1到多法则指的是思考时应该针对每一个页面或功能分析它的对立面和多种情况。有人就会说，“如果我真的能考虑到多种情况，那就不会出现遗漏了”。让每个人都能考虑所有情况不是一件容易的事，而我这里想说的是你需要培养自己的思维模式。在设计事，按照0与1、1到多的步骤去进行思考每一种情况，不断地锻炼加强的自己的思考能力。
在产品设计中的遗漏和出错对于产品经理来说，总归都是一次经验教训，失误之后的分析和总结是必不可少的。而最基本的要求是不能在同一个环节步骤设计上失误两次。
版本开发时，我应该做什么？
在经历了产品评审、技术评审会议后，1.0需求在修修补补后终于尘埃落定，提交给技术大哥们进行开发了。在研发阶段，我也必须要完成后续一系列的工作。
任务拆分和时间排期
在技术评审会议结束后，我将产品的功能模块拆分成一个个小的任务，然后以表格形式下发给技术人员，技术人员各自在每个任务后填写对应的开发周期及开始时间、结束时间；在安排前后端开发时，能够根据开发需求调整任务的先后顺序，得到一个较为合理的排期。
及时沟通和解决问题
在产品开发过程中，沟通是必不可少的。所以在产品开发之前，产品经理与开发人员需达成共识：在需求文档不完善或有疑问的情况下，开发人员需要主动与产品进行沟通；而在需求发生变动的情况下，产品经理也需要第一时间告知开发人员。
而我深感在实际开发过程中，经常会出现一种“我以为我说的，别人就能明白”的沟通方式。这种先入为主的思想，会使诉说方的措辞表述不清，传达的信息不准确，继而影响问题的解决。
常见的错误沟通方式有：

产品经理小红为了省事将问题页面截图加红色标记，“这里有问题！”后直接甩给开发。在开发的视角里，他还需要去猜是什么问题？是如何出现这个情况的？应该怎么修改？所以在沟通中，产品经理针对问题明确的表达方式是应该【操作步骤+结果+期望】，什么样的操作步骤，造成什么样的结果，它应期望实现的效果是什么？

开发小明问“这里有问题吗？”这句话看似没毛病，但在实际揣测时，你会发现它涵盖了再次确认问题（是否还有问题）、对问题不理解（有什么问题）或不认可（这里没问题）的多层意思。汉语的博大精深让人捉摸不透，而在项目沟通时尽量避免使用模棱两可的问句，尽可能通过陈述语句直截了当的表达出自己的问题或看法。

“这个需求很简单，怎么实现我不管”这是一句流传于IT圈的产品经理名言，实际上大部分负责的产品经理是不会是以这样工作态度和开发进行沟通的。产品经理作为一个和部门各岗位都需要打交道的职务，心态尤为重要，并不要因为“经理”这个虚名就认为自己比其他团队人员级别更高，在与开发及其他技术人员进行沟通时，应该用谦逊请教的态度，听取各方意见，避免在开发一半后发现一些潜在问题。

这句名言中指出的另外一个问题是：产品经理是需要了解产品功能的实现过程的。举个很简单的例子，修改文案。对于网站来说，可以在代码中进行修改、发布上线；而如果在开发前产品经理进行要求该文案是可以通过后台进行编辑操作的，那么运营人员直接可以自主修改并发布文案。对于移动端应用来说，如果是在接口中写入的信息，那么可以通过修改接口中内容达到目的。而如果该文案被开发写死在客户端中，那这一个简单的修改文案是需要通过重新发版本才能完成。这时候产品经理就该烧香拜佛祈祷这个文案并不会对产品有太糟糕的影响。所以，产品经理对于实现方法的把控也至关重要。
下一个版本迭代工作
在技术人员紧锣密鼓的进行开发工作时，我也开始着手准备下个迭代版本的需求原型。在1.0的需求当中，我仅仅是优先实现了基础功能，而忽略了数据的投递工作。在领导的提醒后，我开始研究如何做APP的埋点设计。
数据统计一般分为两个方面，一方面为基础数据例如新增人数、启动人数、活跃人数、用户留存等，还有崩溃率（很重要）；另一方面则为衍生数据，页面的浏览人数次数、操作的人数次数、页面转化率等。我采用的方法便是，列出所有的功能页面、操作按钮、加入人数和次数两个指标，直到现在我还是这样做的。

当我正在电脑前构思1.1版本的需求原型时，领导问我“APP发布上线的资料准备的怎么样了？”
APP发布的准备工作
当然是提交APP到应用商店的审核资料。
App store开发者帐号或安卓应用商场帐号的申请
因公司而异，有些公司是需要产品经理/运营去申请开发者账号的；申请APPstore的开发者账号流程较慢，需要提前进行申请，切勿版本开发完之后才一拍脑袋发现帐号没申请！具体的申请流程可百度查阅。
应用截图
在1.0快上线的最后几天，我才发觉还没有应用介绍页的设计图。于是，我只能带着一杯奶茶求隔壁组UI大兵加加班。应用截图一般是尺寸1242*2208、png格式的3~5张图片，在APPstore中针对不同尺寸只需上传一个尺寸的文件通用即可。
应用介绍（内容提要）
应用介绍是用户对产品的“第一印象”，简明扼要的告诉用户为什么我们的产品比别家的要好。在APPstore中展示时仅展示前五行内容，需要用户点击更多后才能查看完整内容，所以前五行的内容相对比较重要。而在具体内容的撰写上，我有以下几个建议：
[ol]

产品属性定位到使用场景：你可以试着这样进行分析“一个XX产品——>一个为XX用户设计的XX产品——>一个可以帮用户完成XX操作/行为的产品”

从用户利益角度出发：通过介绍产品中的一些优惠项、福利活动、个人定制、专属服务等吸引客户。例如“注册赠送38888元礼包”、“你可以拥有属于自己的直播间”、“打赏功能”···

加强产品的社会认同程度：在应用介绍中可以介绍该产品曾经获得的奖项（全国十佳之一）、上榜优秀应用或拥有千万级别用户量等被社会认同的成绩，让用户产生一种“它应该不错”的概念。

加上客服热线/官方网址：在应用介绍的末尾可以加上客服热线或网址，能帮助用户快速的联系到我们。
[/ol]
ASO优化：
当领导跟我说ASO的时候，我是懵圈的。我默默的百度了一下，“ASO是手机应用商店优化的简称，是提升你APP在各类APP苹果电子市场排行榜和搜索结果排名的过程。”在这个方面，我一般是借助了ASO优化相关的工具。通过工具分析调整关键词和应用名称，提高APPstore的排名。
值得注意的是，APP store经常会发布相关APP审核的最新规则制度，例如最近的禁止使用热更新以及应用名称禁止出现“免费”字眼，产品经理都应及时关注并调整应用的相关内容。
1.0上线之后
2016年1月6日是这款产品上线APPstore的时间，至今为止已更新迭代15个版本，每个版本的研发周期在1个月左右。其中四月份到六月份，我回学校进行了毕业答辩。
在整个产品研发、迭代期间，我会将每一次版本的开发周期、上线的时间以及其中发生的事件（服务端客户端bug）均记录在工作本中。

记录版本的迭代历程，就好像看着项目产品在一步一步的成长，同时可以帮助你去分析版本间数据差异的原因；

记录期间出现的事件或bug，发生时间、起因和解决方案能够帮助在以后的开发过程中避免出现类似的问题，当然在领导问你“前几天的服务器是出了什么问题？”，你也不至于丈二和尚摸不着头脑。



写在最后
很感谢领导能够让我参与到这个项目中来，从一开始的我和领导到现在线上开发团队也已有二十来号人。还记得在项目刚开始时，我每天下班之后也要盯着工作群，生怕领导在群里艾特我，说哪里出了问题。那段时间头发都掉了好几根。压力大，责任也大，成长得也越快。