原型需求文档

作者： 阿bin，一位走在路上的B端产品人。 前言：产品需求文档一般有3种输出形式：纯原型、原型+文档、纯文档。3种方式各有利弊，这里不再赘述，选择哪个主要是看公司、团队的要求。这3种输出形式笔者都经历过，这里选择的是原型+文档（Axure+Word）的形式。选择的产品则是笔者设想的一款人事管理-HRM系

原型图、需求文档对于IT产品经理已是耳熟能详家喻户晓，但是有多少团队的管理者能够真正的重视起来/站在项目管理的角度来看，原型图、需求文档是一个公司的组织过程资产，如果组织过程资产不规范或者残缺不全那么项目团队必定会不断暴雷采坑。尤其是当你新接手了一条产品线，后来你发现这条产品线的原型图和需求文档要么是版本功能残缺不全，

主要介绍一款用于共同编辑的应用，被一位同事否定了这款产品，但我觉得文档的创作以及原型的绘制还是具有一定意义的~以下为需求文档的部分内容，具体关于产品的功能及原型会提供链接哦~一、产品介绍1.1产品名称Co-Edit1.2.产品logo1.3.项目背景目前一般工作人员对文件管理没有太多良好的习惯，且没有一个专用的系统或者

作者整理了一套后台系统原型模板，与各位PM分享，希望给大家的工作带来些帮助。后台系统的原型模板早在做APP模板前就已经使用了很长一段时间。后台原型不需要也不适合太多特殊的交互设计，大部分页面无非列表、表单、查看页中的一种，其实更适合使用模板元件来节省工作量。个人经验，灵活使用这套模板和元件，起码可以节省50%以上的工作

每次产品与UI、技术、测试等相关人员的沟通，他们根本不会在意你的文档写的如何，他们需要的是他们关注的内容。产品的用户价值是什么？产品的内部逻辑如何？产品的细节如何从产品层面实现等。在快速迭代的敏捷开发模式下，每写一次需求文档对产品经理来说都是一件头疼的事。抓住重点，抓住规范。这些你都遵守了然而也写不出优秀的需求文档。如

从最开始的对于产品经理这个职位不屑一顾，认为不接触代码、不做设计，工作主要建立在沟通打杂这件事上，工作室会比较轻松，但后来真正实现入门，在相继接触多年的产品工作后，发现以前的认知完全错误，一个需求分析或者写需求文档就足够让我深入学习很久。在此，多年走过的坑，以及熟知不再犯，给大家一些参考意见。需求分析做需求分析的时候，

【文章摘要】做一个密码管理类的app是我萌生已久的一个idea，起初我只是在网上查了下密码管理类app的市场，发现都是国外的几款产品占据着大部分市场，本地化的优化还不是很好，正好我最近在寻求产品类的工作，打算做出点东西来，于是就有了现在这个“密码管家”的产品原型。在这里把制作的过程分享给大家，共同探讨这个产品可能性。写

上一篇文章 我们通过思维导图将想法进行了结构化梳理，接下来我们就需要进行方案的可行性推演，验证产品功能是否可行，预估项目要花多少人力物力，因此我们就要通过原型设计进行相关需求的论证。一开始就撰写PRD文档，我们很难对产品进行各方面的评估，也无法得知方案的可行性，并且无法直观细致的考虑产品。