精华内容
下载资源
问答
  • 评审需求文档原型

    千次阅读 2018-04-14 16:09:43
    1. 你们的项目组使用源代码管理工具了么? 应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。2. 你们的项目组使用缺陷管理系统了么? 应该用。ClearQuest太复杂,我的推荐是...
    1. 你们的项目组使用源代码管理工具了么?
    
      应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。

    2. 你们的项目组使用缺陷管理系统了么?
      应该用。ClearQuest太复杂,我的推荐是BugZilla。

    3. 你们的测试组还在用Word写测试用例么?
      不要用Word写测试用例(Test Case)。应该用一个专门的系统,可以是Test Manager,也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。

    4. 你们的项目组有没有建立一个门户网站?
      要有一个门户网站,用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现,15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。

    5. 你们的项目组用了你能买到最好的工具么?
      应该用尽量好的工具来工作。比如,应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费,所以说是“你能买到最好的”。

    6. 你们的程序员工作在安静的环境里么?
      需要安静环境。这点极端重要,而且要保证每个人的空间大于一定面积。

    7. 你们的员工每个人都有一部电话么?
      需要每人一部电话。而且电话最好是带留言功能的。当然,上这么一套带留言电话系统开销不小。不过至少每人一部电话要有,千万别搞得经常有人站起来喊:“某某某电话”。《人件》里面就强烈谴责这种做法。

    8. 你们每个人都知道出了问题应该找谁么?
     应该知道。任何一个Feature至少都应该有一个Owner,当然,Owner可以继续Dispatch给其他人。

    9. 你遇到过有人说“我以为…”么?
     要消灭“我以为”。Never assume anything。

    10. 你们的项目组中所有的人都坐在一起么?
      需要。我反对Virtual Team,也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起,好处多得不得了。

    11. 你们的进度表是否反映最新开发进展情况?
      应该反映。但是,应该用Baseline的方法来管理进度表:维护一份稳定的Schedule,再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。

    12. 你们的工作量是先由每个人自己估算的么?
      应该让每个人自己估算。要从下而上估算工作量,而不是从上往下分派。除非有其他原因,比如政治任务工期固定等。

    13. 你们的开发人员从项目一开始就加班么?
      不要这样。不要一开始就搞疲劳战。从项目一开始就加班,只能说明项目进度不合理。当然,一些对日软件外包必须天天加班,那属于剥削的范畴。

    14. 你们的项目计划中Buffer Time是加在每个小任务后面的么?
      不要。Buffer Time加在每个小任务后面,很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。

    15. 值得再多花一些时间,从95%做到100%好值得,非常值得。
      尤其当项目后期人困马乏的时候,要坚持。这会给产品带来质的区别。

    16. 登记新缺陷时,是否写清了重现步骤?
      要。这属于Dev和Test之间的沟通手段。面对面沟通需要,详细填写Repro Steps也需要。

    17. 写新代码前会把已知缺陷解决么?
      要。每个人的缺陷不能超过10个或15个,否则必须先解决老的bug才能继续写新代码。

    18. 你们对缺陷的轻重缓急有事先的约定么?
      必须有定义。Severity要分1、2、3,约定好:蓝屏和Data Lost算Sev 1,Function Error算Sev 2,界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。

    19. 你们对意见不一的缺陷有三国会议么?
       必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。

    20. 所有的缺陷都是由登记的人最后关闭的么?
      Bug应该由Opener关闭。Dev不能私自关闭Bug。

    21. 你们的程序员厌恶修改老的代码么?
      厌恶是正常的。解决方法是组织Code Review,单独留出时间来。XP也是一个方法。

    22. 你们项目组有Team Morale Activity么?
      每个月都要搞一次,吃饭、唱歌、Outing、打球、开卡丁车等等,一定要有。不要剩这些钱。

    23. 你们项目组有自己的Logo么?
      要有自己的Logo。至少应该有自己的Codename。

    24. 你们的员工有印有公司Logo的T-Shirt么?
      要有。能增强归属感。当然,T-Shirt要做的好看一些,最好用80支的棉来做。别没穿几次就破破烂烂的。

    25. 总经理至少每月参加次项目组会议要的。
      要让team member觉得高层关注这个项目。

    26. 你们是给每个Dev开一个分支么?
      反对。Branch的管理以及Merge的工作量太大,而且容易出错。

    27. 有人长期不Check-In代码么?
      不可以。对大部分项目来说,最多两三天就应该Check-In。

    28. 在Check-In代码时都填写注释了么?
      要写的,至少一两句话,比如“解决了Bug No.225”。如果往高处拔,这也算做“配置审计”的一部分。

    29. 有没有设定每天Check-In的最后期限?
      要的,要明确Check-In Deadline。否则会Build Break。

    30. 你们能把所有源码一下子编译成安装文件吗?
      要的。这是每日编译(Daily Build)的基础。而且必须要能够做成自动的。

    31. 你们的项目组做每日编译么?
    当然要做。有三样东西是软件项目/产品开发必备的:1. bug management; 2. source control; 3. daily build。

    32. 你们公司有没有积累一个项目风险列表?
      要。Risk Inventory。否则,下个项目开始的时候,又只能拍脑袋分析Risk了。

    33. 设计越简单越好越简单越好。
      设计时候多一句话,将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。

    34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子,有这两个作为基础,可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML,而不是自己去Parse一个文本文件;尽量用RegExp,而不是自己从头操作字符串,等等等等。这就是“软件复用”的体现。

    35. 你们会隔一段时间就停下来夯实代码么?
      要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw,“夯”这个字念“hang”,第一声。

    36. 你们的项目组每个人都写Daily Report么?
      要写。五分钟就够了,写10句话左右,告诉自己小组的人今天我干了什么。一则为了沟通,二则鞭策自己(要是游手好闲一天,自己都会不好意思写的)。

    37. 你们的项目经理会发出Weekly Report么?
       要。也是为了沟通。内容包括目前进度,可能的风险,质量状况,各种工作的进展等。

    38. 你们项目组是否至少每周全体开会一次?
       要。一定要开会。程序员讨厌开会,但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。

    39. 你们项目组的会议、讨论都有记录么?
      会前发meeting request和agenda,会中有人负责主持和记录,会后有人负责发meeting minutes,这都是effective meeting的要点。而且,每个会议都要形成agreements和action items。

    40. 其他部门知道你们项目组在干什么么?
      要发一些Newsflash给整个大组织。Show your team’s value。否则,当你坐在电梯里面,其他部门的人问:“你们在干嘛”,你回答“ABC项目”的时候,别人全然不知,那种感觉不太好。

    41. 通过Email进行所有正式沟通
      Email的好处是免得抵赖。但也要避免矫枉过正,最好的方法是先用电话和当面说,然后Email来确认。

    42. 为项目组建立多个Mailing Group
      如果在AD+Exchange里面,就建Distribution List。比如,我会建ABC Project Core Team,ABC Project Dev Team,ABC Project All Testers,ABC Project Extended Team等等。这样发起Email来方便,而且能让该收到email的人都收到、不该收到不被骚扰。

    43. 每个人都知道哪里可以找到全部的文档么?
      应该每个人都知道。这叫做知识管理(Knowledge Management)。最方便的就是把文档放在一个集中的File Share,更好的方法是用Sharepoint。

    44. 你做决定、做变化时,告诉大家原因了么?
      要告诉大家原因。Empower team member的手段之一是提供足够的information,这是MSF一开篇的几个原则之一。的确如此,tell me why是人之常情,tell me why了才能有understanding。中国人做事喜欢搞限制,限制信息,似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力,不在于是不是能access information/data,而在于是不是掌握资源。

    45. Stay agile and expect change 要这样。
      需求一定会变的,已经写好的代码一定会被要求修改的。做好心理准备,对change不要抗拒,而是expect change。

    46. 你们有没有专职的软件测试人员?
      要有专职测试。如果人手不够,可以peer test,交换了测试。千万别自己测试自己的。

    47. 你们的测试有一份总的计划来规定做什么和怎么做么?
       这就是Test Plan。要不要做性能测试?要不要做Usability测试?什么时候开始测试性能?测试通过的标准是什么?用什么手段,自动的还是手动的?这些问题需要用Test Plan来回答。

    48. 你是先写Test Case然后再测试的么?
      应该如此。应该先设计再编程、先test case再测试。当然,事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发,我不喜欢,因为不习惯,太麻烦,至于别人推荐,那试试看也无妨。

    49. 你是否会为各种输入组合创建测试用例?
      不要,不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚,你是否有时间去运行那么多test case。

    50. 你们的程序员能看到测试用例么?
      要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的:提高质量。

    51. 你们是否随便抓一些人来做易用性测试?
      要这么做。自己看自己写的程序界面,怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了,不方便的永久了也就习惯了。

    52. 你对自动测试的期望正确么?
      别期望太高。依我看,除了性能测试以外,还是暂时先忘掉“自动测试”吧,忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说,只能“矫枉必须过正”了。

    53. 你们的性能测试是等所有功能都开发完才做的么?
      不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正,早死早升天。

    54. 你注意到测试中的杀虫剂效应了么?
      虫子有抗药性,Bug也有。发现的新Bug越来越少是正常的。这时候,最好大家交换一下测试的area,或者用用看其他工具和手法,就又会发现一些新bug了。

    55. 你们项目组中有人能说出产品的当前整体质量情况么?
      要有。当老板问起这个产品目前质量如何,Test Lead/Manager应该负责回答。

    56. 你们有单元测试么?
      单元测试要有的。不过没有单元测试也不是不可以,我做过没有单元测试的项目,也做成功了——可能是侥幸,可能是大家都是熟手的关系。还是那句话,软件工程是非常实践、非常工程、非常灵活的一套方法,某些方法在某些情况下会比另一些方法好,反之亦然。

    57. 你们的程序员是写完代码就扔过墙的么?
      大忌。写好一块程序以后,即便不做单元测试,也应该自己先跑一跑。虽然有了专门的测试人员,做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法,程序太烂的话,测试有权踢回去。

    58. 你们的程序中所有的函数都有输入检查么?
      不要。虽然说做输入检查是write secure code的要点,但不要做太多的输入检查,有些内部函数之间的参数传递就不必检查输入了,省点功夫。同样的道理,未必要给所有的函数都写注释。写一部分主要的就够了。

    59. 产品有统一的错误处理机制和报错界面么?
      要有。最好能有统一的error message,然后每个error message都带一个error number。这样,用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因,就像SQL Server的错误那样。同样,ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。

    60. 你们有统一的代码书写规范么?
      要有。Code Convention很多,搞一份来发给大家就可以了。当然,要是有FxCop这种工具来检查代码就更好了。

    61. 你们的每个人都了解项目的商业意义么?
      要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者,或者时不时的告诉team member,这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱,这样就有动力了。平凡的事情也是可以有个崇高的目标的。

    62. 产品各部分的界面和操作习惯一致么?
      要这样。要让用户觉得整个程序好像是一个人写出来的那样。

    63. 有可以作为宣传亮点的Cool Feature么?
      要。这是增强团队凝聚力、信心的。而且,“一俊遮百丑”,有亮点就可以掩盖一些问题。这样,对于客户来说,会感觉产品从质量角度来说还是acceptable的。或者说,cool feature或者说亮点可以作为质量问题的一个事后弥补措施。

    64. 尽可能缩短产品的启动时间要这样。
       软件启动时间(Start-Up time)是客户对性能好坏的第一印象。

    65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误:太看重性能、稳定性、存储效率,但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾,协调这些是PM的工作。

    66. 你们根据详细产品功能说明书做开发么?
      要这样。要有设计才能开发,这是必须的。设计文档,应该说清楚这个产品会怎么运行,应该采取一些讲故事的方法。设计的时候千万别钻细节,别钻到数据库、代码等具体实现里面去,那些是后面的事情,一步步来不能着急。

    67. 开始开发和测试之前每个人都仔细审阅功能设计么?
      要做。Function Spec review是用来统一思想的。而且,review过以后形成了一致意见,将来再也没有人可以说“你看,当初我就是反对这么设计的,现在吃苦头了吧”

    68. 所有人都始终想着The Whole Image么?
      要这样。项目里面每个人虽然都只是在制造一片叶子,但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领,反对过分的把软件制造看成流水线、车间。参见第61条。

    69. Dev工作的划分是单纯纵向或横向的么?
      不能单纯的根据功能模块分,或者单纯根据表现层、中间层、数据库层分。我推荐这么做:首先根据功能模块分,然后每个“层”都有一个Owner来Review所有人的设计和代码,保证consistency。

    70. 你们的程序员写程序设计说明文档么?
      要。不过我听说微软的程序员1999年以前也不写。所以说,写不写也不是绝对的,偷懒有时候也是可以的。参见第56条。

    71. 你在招人面试时让他写一段程序么?
      要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等,既不偏向过于考算法,也不偏向过于考特定的API。

    72. 你们有没有技术交流讲座?
      要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得,这笔花钱送到外面去培训划算。

    73. 你们的程序员都能专注于一件事情么?
      要让程序员专注一件事。例如说,一个部门有两个项目和10个人,一种方法是让10个人同时参加两个项目,每个项目上每个人都花50%时间;另一种方法是5个人去项目A,5个人去项目B,每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂,但很多领导实践起来就把属下当成可以任意拆分的资源了。

    74. 你们的程序员会夸大完成某项工作所需要的时间么?
      会的,这是常见的,尤其会在项目后期夸大做某个change所需要的时间,以次来抵制change。解决的方法是坐下来慢慢磨,磨掉程序员的逆反心理,一起分析,并把估算时间的颗粒度变小。

    75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。
      Virtual heads意味着resource is not secure,shared resource会降低resource的工作效率,容易增加出错的机会,会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人,要强过两个只能投入50%时间和精力的人。我是吃过亏的:7个part time的tester,发现的Bug和干的活,加起来还不如两个full-time的。参见第73条。73条是针对程序员的,75条是针对Resource Manager的。
    展开全文
  • Axure8 原型工具

    2019-02-19 11:09:31
    Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • 需求文档

    千次阅读 多人点赞 2019-03-29 18:10:18
    交互原型是使用原型设计软件完成的原型,常用软件是Axure RP,通常情况交互原型的设计要早于产品需求文档,是产品经理想法推演的重要一步。通过Axure RP之类的交互原型软件制作出来的产品原型,在功能需求和交互需求...

    产品设计是一个由抽象的概念到具体形象化的处理过程,通过文字或图像等方式将我们规划的产品需求展现出来。它将产品的某种目的或需求转换为一个具体的物理或工具的过程,把一种计划、规划设想、问题解决的方法,通过具体的操作,以理想的形式表达出来。

    由于产品设计阶段要全面确定整个产品策略、外观、结构、功能,从而确定整个产品系统的布局,因而,产品设计的意义重大,具有“牵一发而动全局”的重要意义。如果一个产品的设计缺乏具体形象的表述,那么研发时就将耗费大量资源和劳动力来调整需求。相反,好的产品设计,不仅表现在功能上的优越性,而且便于执行时理解,从而使产品的研发效率得以增强。

    1、产品需求文档介绍

    产品设计的最终表述的形式被称为产品需求文档,业界常常称呼为PRD文档,这是英文Product Requirement Document的缩写。产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式,主要用于产品界面设计和研发使用。

    PRD文档是基于BRD、MRD的延续文档,主要是一份给执行层面的工作人员阅读的文档,这部分人群绝大多数是设计与技术人员。在这类人群中,设计师更多依赖于产品原型进行交互或视觉的设计,因此看这份文档的人主要是技术人员。相对于技术人员,他们不太关注产品的商业需求和市场愿景,因为在进行产品讨论立项时,产品的定义就已经向参与设计和研发的人员宣讲过,因此技术人员更多的是关注界面、功能、交互、元素等等内容,因此产品需求文档是一份详细的产品功能需求说明文档,是产品文档中最底层和最细致的文档。

    因为阅读人类的因素,所以产品需求文档是一份没有闲话,直入主题的功能说明文档。并且产品需求文档是没有标准规范的,也没有统一的模板,每个公司都不一样和每个人也不一样,这个取决于个人习惯和团队要求。虽然产品需求文档没有明确的规范,但是目的都是一样的,必须能够明确产品的功能需求,便执行人员理解任务要求。

    2、产品需求文档写作

    产品需求文档是产品经过规划和设计之后的最终执行文档,因此这份文档的质量好坏直接影响到执行部门是否能够明确产品的功能和性能。

    2.1、罗列信息(信息结构图)

    在写产品需求文档之前,我们需要先罗列出产品功能的信息内容,这一步是将想法逐渐清晰的第一步,也是帮助我们接下来设计功能的辅助信息,同时也可以辅助服务端技术人员创建数据库。因为这是第一步,所以我们不需要罗列的很详细,在之后的步骤里,我们会逐步改进和完善信息内容。

    罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主要的是能够清晰易懂,我最常用的方法就是使用思维导图软件(MindManager)罗列成结构图,因此我称这一步为“信息结构图”。

    shu-17

    上图是一张以Blog系统为示例的信息结构图。信息结构图是一种接近数据库结构的图表,在罗列信息结构时,更多的是考虑信息数据,但是他并不是真正意义的数据库结构。信息结构图是提供给产品经理自己梳理信息内容的结构图,也是方便产品经理和服务端技术人员沟通数据结构的参考图,技术人员会根据这张图表的内容再结合产品原型或需求文档,然后规划和设计出真正意义上的数据库结构。

    信息结构图中关于友情链接功能的信息数据只有“名称”和“链接”两个内容,但是在实际功能需求中,友情链接还有两个功能,分别是“显示或隐藏”和“是否新窗口打开”,这两个功能会在产品原型和需求文档中详细描述,但是在信息结构中是没有体现的,因为从产品层面上来说,这两个只是功能,并不是信息内容。但是在真正数据库中,友情链接的这两个功能分别也是有字段参数的,程序在读取该参数后便知道友情链接的属性,然后处理友情链接是显示还是隐藏,是新窗口打开还是本窗口打开。通过友情链接这个例子,我们就知道了在实际中数据结构和信息结构是不一样的,信息结构只是产品层面的数据内容。

    无论是什么样的产品类型,无论从哪里入手,我们第一步都是先要罗列信息结构,因为信息结构图不仅是辅助技术人员创建数据库的图表,也是辅助产品人员进行产品功能规划的参考,只有对信息或数据的结构了解了,我们才能更好的设计产品。

    信息结构图是我们将概念想法形成结构化的第一步,也是我们接下来几步工作的辅助文档,同时在接下来的几步工作中,我们还会不断的完善信息的结构。

    2.2、梳理需求(产品结构图)

    当我们对产品的信息结构了解后,我们就需要规整脑海中的产品需求,让想法更加结构化,因此这一步就要梳理产品的需求。在设计产品原型之前,我们首先要罗列出产品的功能结构,包括频道、页面、模块及元素。这一步依然使用思维导图软件,像绘制楼盘鸟瞰图一样将产品的结构绘制成结构图,因此我称这一步为“产品结构图”。

    产品结构图是一种将产品原型以结构化的方式展现的图表,结构内容也如同产品原型一样,从频道到页面,再细化页面功能模块和元素。所以产品结构图是产品经理在设计原型之前的一种思路梳理的方式,并不是给其他工作人员查看的文档,通过类似鸟瞰式的结构图可以让产品经理对产品结构一目了然,也方便思考。

    shu-18 shu-19

    如上图示例,“活动大全”的产品结构依次是:产品 -> 频道 -> 页面 -> 页面元素 -> 操作 -> 元素。我们换一个角度观看示例,产品结构图实际上就是一种结构化的产品原型。这样做的目的就是梳理产品结构逻辑,让我们清楚的知道产品有几个频道,频道下面有没有子频道或者有多少个页面,这些页面里又有哪些功能模块,这些功能模块里又有哪些元素。

    shu-19

    上图以我们第一步的“信息结构图”为基础绘制的“产品结构图”,有了这份结构导图,我们可以对产品进行鸟瞰式考虑和完善,当有问题时,修改起来也比原型和文档方便很多。比如在后续规划中,我们发现文章的图片等附件上传后,管理不太方便,这时就可以在结构图中增加一个“附件管理”频道。如果我们使用产品结构图的方式,那么附件管理的功能增加和修改就会比原型工具更加便捷和效率。

    产品结构图的方法同样适用于移动互联网产品的设计,并且比起Web产品更加容易梳理产品结构。

    产品结构图是一种让产品经理通过思维导图的方式梳理思路的方法,通过这种方法可以明确产品有多少个频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素,逐步的将脑海里的想法明确梳理成结构。虽然这种方法能够明确产品的结构,但是这样的思维导图也就只有产品经理自己能够看懂,因为对于设计和技术人员这是一个抽象的表述方式,如果没有详细的讲解,是很难理解的。

    产品结构图是将产品原型具体化的一种方式,只是罗列了产品的频道页面和功能,但是没有详细的进行推演,关于细化方面是否符合产品逻辑,是否符合用户体验,这些都是没有深思过的,因此我们接下来就要进行原型设计,开始具体的考虑可行性。

    2.3、原型设计(界面线框图)

    当我们逐渐清晰了产品的需求后,并梳理了产品的各个频道及页面,那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。

    原型设计是帮助我们更细致的思考,并做各项需求的评估,同时也是将自己脑海里的想法进行输出的一种方式。通过原型设计后,我们就可以进行产品宣讲了,相比较于抽象的文字描述,原型则更加直观的展现产品的需求,设计和技术人员或者老板也能够更加直观的了解到产品意图。

    原型设计是将结构化的需求进行框架化,因此原型也被称为线框图,具体的表现手法有很多种,相关的辅助软件也有很多,例如:Axure RP、Balsamiq Mockups、UIDesigner等等。

    当到了原型设计这一步时,已经不仅仅是构思了,我们需要更加深入的了解每个页面上元素和这些元素的属性。例如按钮元素,我们就需要考虑这个按钮的功能,并且这个功能操作后带给后端和前端的反馈。例如注册会员按钮,用户操作后,第一步逻辑是验证用户输入的信息是否合法,不合法则给出前端反馈;合法则和后端通信验证是否已经存在同样信息,已经存在则给出前端反馈,不存在则进入下一步,注册成功;注册成功后的反馈是跳转页面,还是弹出层提示用户完善资料,这些都是需要更详情的考虑。当然这些更细致的思考是留在需求文档撰写时的,而此时我们需要做的就是把这些元素通过原型表现出来。

    原型设计的表现手法主要有三种:手绘原型、灰模原型、交互原型。从工作效率的角度考虑,我非常建议先通过手绘的形式快速在草纸上绘制出产品的原型,推演和讨论方案的可行性。当方案的可行性被验证之后,我们再根据个人习惯或团队要求,通过软件工具进行更深入的设计。

    ① 手绘原型

    因为原型也被称为线框图,因此手绘是最简单直接的方法,也是最快速的表现产品轮廓的手法。

    手绘原型

    手绘原型在初期验证想法时非常高效,也方便讨论和重构,同时也适合敏捷开发时快速出原型。

    ② 灰模原型

    灰模原型是由图形设计软件制作而成,最常用的软件是Photoshop和Fireworks,相对手绘原型,灰模更加清晰和整洁,也适用于正式场合的PPT形式宣讲。

    灰模原型
    phone

    灰模原型也可以称之为平面原型,所以如果不会使用图形软件也可以使用Axure RP设计,相比交互原型,灰模原型只是缺少交互效果,仅仅是将产品需求以线框结构的方式展示出来,让产品需求更加规整的直观展现。

    shu-23

    ③ 交互原型

    交互原型是使用原型设计软件完成的原型,常用软件是Axure RP,通常情况交互原型的设计要早于产品需求文档,是产品经理想法推演的重要一步。通过Axure RP之类的交互原型软件制作出来的产品原型,在功能需求和交互需求的表现上,几乎和正式产品是一致的,所以有时交互原型也被称为产品Demo版。

    通常情况下交互原型是产品经理与交互设计师共同讨论确定,然后由交互设计师制作,但是绝大多数的公司是没有交互设计师这个职位的,因此这类工作最终是由产品经理来负责的。

    以上三种方法并不是渐进的流程,而是三种原型设计的方法,具体取决于你的产品需求和团队要求。

    对于产品经理来说,原型设计是为了帮助我们细致的考虑方案,并论证方案的可行性,同时也是为了产品宣讲时让听众能够清晰直观的了解产品,避免抽象的语言描述导致听众理解困难和理解偏差。产品原型也是为了确保产品在执行过程中,是按产品经理最初设想的需求和期望完成的,因此产品经理的原型是没有很高的要求的,只要对方能够听懂看懂就可以了,所以使用手绘原型是最高效率的方法。

    2.4、用例模型(产品用例图)

    用例(Use Case)是一种描述产品需求的方法,使用用例的方法来描述产品需求的过程就是用例模型,用例模型是由用例图和每一个用例的详细描述文档所组成的。在技术和产品的工作领域里都有用例模型的技能知识。技术人员的用例主要是为了方便在多名技术人员协同工作,或者技术人员任务交接时,让参与者更好的理解代码的逻辑结构。产品人员的用例主要是为了方便技术研发和功能测试时,让参与者更好的理解功能的逻辑。

    用例起源和发展于软件时代的产品研发,后来被综合到UML规范之中,成为一种标准化的需求表述体系。虽然用例在软件研发和技术工作中应用的非常广泛,但是在互联网产品规划和设计中,并不经常使用,互联网产品的需求表达为了敏捷效率,通常采用原型加产品需求文档。

    UML是英文Unified Modeling Language的缩写,中文称为统一建模语言或标准建模语言,是用例模型的建模语言,常用工具是Microsoft Office Visio。产品用例是一种通过用户的使用场景来获取需求的方式,每个用例提供了一个或多个场景,该场景说明了产品是如何和最终用户或其它产品互动,也就是谁可以用产品做什么,从而获得一个明确的业务目标。

    ① 用例图

    用例图并不是画成了图形的用例。用例图包含一组用例,每一个用例用椭圆表示,放置在矩形框中;矩形框表示整个系统。矩形框外画如图所示的小人,表示参与者。参与者不一定是人,可以是其它产品、软件或硬件等等。某一参与者与某一用例用线连起来,表示该参与者和该用例有交互。

    shu-24

    许多人通过UML认识了用例,UML定义为展现用例的图形符号。UML并不是为描述用例定义书写格式的标准,因此许多人误认为这些图形符号就是用例本身;然而,图形符号只能给出最简单的一个或一组用例的概要。UML是用例图形符号最流行的标准,但是除了UML标准,用例也有其它的可选择的标准。

    ② 用例描述文档

    用例图只是在总体上大致描述了产品所能提供的各种服务,让我们对于产品的功能有一个总体的认识。除此之外,我们还需要描述每一个用例的详细信息,这些信息应该包含以下内容:

    shu-25

    用例名称:本用例的名称或者编号

    行为角色:参与或操作(执行)该用例的角色

    简要说明:简要的描述一下本用例的需求(作用和目的)

    前置条件:参与或操作(执行)本用例的前提条件,或者所处的状态

    后置条件:执行完毕后的结果或者状态

    用例描述文档基本上是用文本方式来表述的,为了更加清晰地描述用例,也可以选择使用状态图、流程图或序列图来辅助说明。只要有助于表达的简洁明了,就可以在用例中任意粘贴用户界面和流程的图形化显示方式,或是其它图形。如流程图有助于描述复杂的决策流程,状态转移图有助于描述与状态相关的系统行为,序列图适合于描述基于时间顺序的消息传递。

    在互联网产品和设计中,用例的使用越来越少,通常有了产品原型再加上功能流程图和功能说明文档就能够将产品需求详细的表述清楚,所以也没有必须撰写用例了。但是在大公司里,往往会追求产品流程的规范性,要求撰写用例,不过在敏捷开发的时候也会采用其它更有效率的方式,不一定非要撰写用例。

    前面几步我们将产品需求逐渐细化并且通过原型的方式将产品需求形象化的展现了出来,但是在产品功能的逻辑细节方面,原型就非常不直观了,所以用例是一个非常重要的描述需求过程的文档。

    但是由于用例文档以文字为主,并且格式复杂,不适用于高效率的产品需求表述,所以展现逻辑流程的“功能流程图”是一个简洁直观的可替代用例文档的方式。

    shu-26

    (请点击查看大图)

    如上图所示,功能流程图是一种使用图形的方式表示算法逻辑的图表,因为千言万语不如一张图,通过流程图将“优惠券”功能模块的逻辑和需求非常形象直观、一目了然的展现了出来。

    流程图的展现方式也不会产生“歧义性”,便于理解,逻辑出错时也非常容易发现,并且可以直接转化为程序需求描述文档。

    2.6、需求文档(PRD文档)

    前面的几个步骤是为了帮助我们梳理需求、验证可行性和明确细节,到了这一步的时候我们已经非常清晰的了解产品需求,此时撰写产品需求文档可以大大减少和避免了撰写文档时容易忽略的细节黑洞。

    产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式,主要用于产品界面设计和研发使用。因为每个人的习惯和团队要求都是不一样的,所以产品需求文档没有统一的行业规范标准,无论以什么样的格式撰写产品需求文档,最终的目的都是让执行人员能够理解产品需求,根据需求完成产品。

    产品需求文档的表现形式有很多种,常见的有Word、图片和交互原型这三种形式,文档内容通常包含信息结构图、界面线框图、功能流程图、功能说明文档。虽然产品需求文档没有标准的规范,但是有两项是必不可少的,那就是文件标识和修改记录。文档在撰写过程中,我们可以自行不断的修改完善,但是如果正式发布或交给团队其他成员后,一旦有了修改,为了文档的同步,我们就需要标注出文档的修改内容,备注修改记录,这样可以方便大家查看和了解改动的内容。关于文件标识和修改记录,格式都大同小异。

    prd

    ① Word

    这是传统意义上的产品需求文档,主要有四个部分组成(具体根据产品要求进行划分),分别是:结构图、全局说明、频道功能、效果图。

    因为产品需求文档的阅读者主要是偏向于技术人员,因此文档的目的性非常明确,就是要描述产品的功能需求,所有产品需求文档没有关于市场方面的描述。为了保证需求的执行效率,建议大家尽量减少不必要的文字,在能够让阅读者看懂并且了解产品意图的情况下,文字越少越好。这主要是因为绝大多数人是没有足够耐心认真看完产品需求文档的,因此我们要尽量减化文档内容。

    ①-1、结构图:

    ①-1.1、信息结构图:主要是辅助服务端技术人员创建或调整数据结构的参考文件

    ①-1.2、产品结构图:主要是辅助设计和技术开发人员了解产品的全局结构。

    ①-2、全局说明:

    主要讲解产品的全局性功能的说明,例如网站产品的页面编码、用户角色,移动产品的缓存机制、下载机制,这类全局性功能的说明。这里我举一个移动产品的“状态维持与恢复”的例子。示例如下:

    状态的维持与恢复

    当用户退出产品时(误操作、Home键、锁屏、自动关机),产品需要维持用户操作前的状态,当用户返回产品时仍可以恢复到之前状态,并继续使用。

    维持状态包括流程操作、信息浏览、文本输入、文件下载。

    锁屏状态时,如果用户在产品中有下载任务时,仍然保持下载。

    ①-3、频道功能:

    以频道为单位,页面为子项,分别描述产品的频道、页面及页面模块元素的功能需求。示例如下:

    1、频道名:频道介绍及需求说明

    2、页面1:页面介绍及需求说明

    2.1、页面模块1:模块功能需求说明

    2.1.1、页面模块1-元素1:功能说明

    2.1.2、页面模块1-元素2:功能说明

    2.2、页面模块2:模块功能需求说明

    在撰写功能需求时,我们需要考虑用户的流程,例如一个“完成”按钮,我们需要描述他完成后,系统要不要给出反馈提示(反馈提示是什么样的形式反馈,内容显示成什么,有没有内容需要调取数据库),或者要不要跳转页面(跳转到哪个页面,这个页面是其他频道页面,还是这个功能的子页面,如果是子页面就需要再描述这个子页面的模块及元素内容)。

    ①-4、效果图:

    效果图是由设计师完成的产品图,和实际开发完成的产品保真度一致。

    这个示例是一个移动产品(iPad)需求文档,其中部分隐私内容已过滤隐藏,并且只保留了首页和地图找房频道的需求说明。由于工作环境没有交互设计师,所以Word文档中包含了部分交互说明。

    ② 图片

    图片形式的产品需求文档是基于效果图的说明文件,将传统Word形式的功能需求说明标注在效果图上,这种方式经常使用在移动互联网领域,实际上是图文形式的交互需求文件,只是在此基础上更深入的描述出功能需求。

    对于图片形式的产品需求文档,我们只需要另外再描述一下全局说明,其他频道页面的需求直接以图片形式展示,这种方式相对于Word文档的纯文字更加生动易读并且直观,因此有一些产品经理非常喜欢用这种方式代替Word形式的产品需求文档。

    picture_prd

    ③ 交互原型

    这里指的交互原型就是前面篇章讲到的原型设计,使用Axure PR之类的交互原型设计软件制作出来的产品原型非常真实和直观,并且原型软件还支持元素标注和导出Word文档,因此很多产品经理都喜欢使用Axure PR来代替Word完成产品需求文档。

    当我们通过Axure PR制作出产品原型后,实际上他已经是很完善的产品Demo了,因此我们只需要加上元素的标注,在标注中说明功能需求,这样导出的HTML文件相比Word文档更直观易懂,是非常高效的产品需求说明方式。

    shu-31

    无论你采用哪种方式撰写需求文档,最终的目的都是为了方便团队成员理解产品的意图,因此哪种方法能够避免细节黑洞,高效完成产品的设计和研发,那么这种方法就是最有效的方法


    展开全文
  • Step1:原型(Prototype)设计的第一个阶段,我们称之为原型设计,主要是设计产品的功能、用户流程、信息架构、交互细节、页面元素等等。如果你觉得听上去这些概念都比较悬的话,我就用大白话来说:原型设计,就是...

    Step1:原型(Prototype)
    设计的第一个阶段,我们称之为原型设计,主要是设计产品的功能、用户流程、信息架构、交互细节、页面元素等等。如果你觉得听上去这些概念都比较悬的话,我就用大白话来说:原型设计,就是完全不管产品长得好不好看,只把它要做的事情和怎么做这些事情想清楚,把它怎么和用户交互想清楚,而且把所有这些都画出来,让人可以直观地看到。

    至于怎么画出来,那就随你了。用纸笔画,用白板水笔画,用Photoshop画,用Visio画,或者像我们一样用Axure画,都可以。只要把上面提到的这些都事无巨细地表达出来。

    在原型的交付物(Delivery,也就是某个阶段的产出物)中,最重要也最常见的就是线框图(Wireframe),这玩意儿不用多解释了,看下面这张图就明白:

    在画线框图的时候,要把握好细节的刻画程度。有些东西只要画个框就行了,而有些东西需要把文案都设计好。以免你的老板或是需求方揪住角落里的广告banner该有多大这种问题与你纠缠不休,而忽视了最重要的页面主体部分。

    此外,还要牢记:原型就是用来让人改的。它存在的价值就体现在被修改了几次,被更新了几次,以及它的下一步被少改了几次。

    Step2:模型(Mock-up)
    在原型被大家接受之后,就该关心产品长得好不好看了。我们以“模型”这个词来统称该步骤的交付物。和原型相比,它关注于产品的视觉设计,包括色彩、风格、图示、插图等等。

    要清楚的是,这不是一步由“美工”来“美化”的工作。视觉设计师需要对原型设计有深刻的理解,对交互设计和尚未进行的HTML/CSS/JS的Code都要有充分的了解。如果不能从全局的角度来做视觉设计,则只能是做做把水晶效果改成金属效果这样的“自娱自乐”,而对产品本身没有任何有价值的帮助。如果原型说:“在这个页面上,A比B重要。”,那他的脑子里就要有十七八种可以表现“A比B重要”的视觉语言可供选择。这是对设计模型的视觉设计师的基本要求。

    更高一些的要求,才是视觉设计的“原始功能”。“到底是选水晶效果还是金属效果?”,“这个按钮选什么颜色好?”等等。这一类的思考和选择,应着眼于产品的气质、品牌等等,在各种产品间保持一定的统一,在用户心里打下视觉的烙印。其实要做到这一点是很难的,特别是还要满足上一点的要求。一般来说,如果能90%的把交互设计的成果和品牌形象表达出来,已经是很好的结果了。从我自己来说,就常常很郁闷不能用好的视觉语言来表达自己在原型设计中的想法,总是做完模型就打个七折:(

    更更高的要求,有些问题用交互设计是很难解决的,这时就需要一个有创造能力的视觉师,可以从视觉设计的角度来创造性地解决问题(一时还没想出好的例子,想出来再补上)。

    总的来说,模型设计是件非常困难的事情。它的工具是感性的,但设计过程又要求非常理性,必须在各种约束条件中解决问题。而目前能从较高的角度来来看“视觉设计”的人还不多,大多还停留在“效果”、“风格”等表面议题上。个人以为在“Web标准”和“用户体验”之后,视觉设计是Web设计专业化运动的第三波,市场的需求已经存在,只差有人推动一下。

    模型的设计一般来说都是用Photoshop了,下是是个例子(与原型的例子对应):

    Step3:展示版本(Demo)
    这步我就不多说了,Demo就是按照原型和模型用xHTML/CSS/JavaScript等等前端技术实现出来,以便后端的开发工程师可以接手编码。这个过程让小马、正淳专门起个新帖来详细介绍吧。只提一点,前端开发在有些公司是不放在设计团队的,而我们认为前端开发从很大程度上来说是对用户体验的提升和保证,开发只是它的一个手段和形式。所以就把这块工作一直留在我们团队,现在看起来这样很棒:)

    展开全文
  • 原型设计工具

    2019-04-15 17:37:27
    Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • java 项目需求文档要怎么写?

    千次阅读 2021-02-12 15:24:02
    产品需求文档的在项目中的重要性已经不言而喻。那么对于产品经理来说,有哪些技巧可以更好地完成产品需求文档的撰写呢?产品需求文档包含哪些内容?通过下图,我们可以简单了解产品需求文档需要呈现的基本内容。请...

    传达产品开发需求;

    保证团队成员沟通顺畅;

    制定产品质量控制标准。

    产品需求文档的在项目中的重要性已经不言而喻。那么对于产品经理来说,有哪些技巧可以更好地完成产品需求文档的撰写呢?

    产品需求文档包含哪些内容?

    通过下图,我们可以简单了解产品需求文档需要呈现的基本内容。

    c6bbb8d23684c2bef94284cd522542b6.png

    请点击输入图片描述

    请点击输入图片描述

    1.产品概述

    产品需求文档的第一部分,首先需要对整个项目的研发背景及整体规划进行说明,让阅读者可以快速理解需求背景和产品定位。其次是对产品需求文档本身进行阐述,在每一次修订后都需要进行记录,方便阅读者了解产品需求文档的修订更新。这一部分主要包括以下内容:

    项目概述

    词汇表

    文档修订历史

    版本说明等

    2.功能范围

    这一部分需结合用户、业务规则及市场环境,对产品的用户和市场需求进行分析梳理,找出差异性和优势,制定业务流程和需求清单。可通过业务逻辑图、流程图、产品结构图等图表,让产品逻辑和功能以最简单的方式陈列出来,团队成员可根据这一部分了解用户信息、行为信息等,也有助于对产品进行进一步的理解。

    3.功能详情和原型

    首先是列举功能总表,将产品功能进行逐条梳理,每一条功能都能对应前面的产品目标。

    其次是功能详情展示,通过Mockplus等原型工具快速绘制原型,配合关键部分的批注说明,详细描述业务模块的展示、交互和数据逻辑,以供开发人员查看和理解。

    4.全局说明

    这一部分包括设计规范、数据统计、通用规则说明等信息,方便设计师和开发人员查看产品细节信息。

    5. 测试需求

    产品一般在正式上线前都有BETA版本或者内测版本,产品经理需要定制测试产品的功能或者性能。

    6.非功能性需求

    非功能需求为用户常规操作产品时的极端情况,涉及很多内容,包括产品性能、安全性、可靠性、拓展性等方面。

    7. 产品运营和市场分析

    完成产品开发并不是终点,产品的最终目的是要赢得市场。产品上线后如何运营?建议的推广策略是什么?产品经理和运营人员该如何协作?等等问题。

    产品需求文档撰写技巧

    如何高效完成产品需求文档的撰写?我们可以从以下四个方面展开说明:

    理清文档结构

    详尽叙述每一个细节

    语义明确,没有歧义

    搭配原型图或设计稿进行说明

    1.理清文档结构

    一份产品需求文档的内容往往多而复杂,因此,产品经理在撰写产品需求文档时,必须理清文档的结构,才能提升产品需求文档的可读性,让阅读者可以快速了解文档的思路和查阅重要信息。

    将一份产品需求文档看做一个产品,首先需要梳理出它的结构,如上文中所呈现的文档内容,然后再按顺序进行撰写,这样才能写出结构清晰,层次分明的产品需求文档。

    2.详尽叙述每一个细节

    当我们站在产品经理的角度思考问题时,往往会出现这样的误区:产品的这一功能模块逻辑非常简单,业内常见,开发人员也一定能懂,不用再进行单独说明。

    产品经理对于产品的功能及逻辑往往非常了解,但如果从开发或测试人员的角度来看,往往对于许多产品的细节和逻辑关系都不太了解。因此产品经理在撰写产品需求文档时,一定要做到事无巨细。不仅需要详尽叙述页面逻辑、交互逻辑、数据逻辑等所有细节,还需要从开发、测试等角度检查是否有遗漏或错误,才能保证后续开发工作有条不紊。

    3.语义明确,没有歧义

    在撰写产品需求文档时,要做到语义明确,不能出现让阅读者产生歧义的词汇或语句,如:大概、可能、似乎等词语。另一方面,对于产品定义的表述方式,必须做到全文统一。比如在撰写一份APP的产品需求文档时,前文写了“首页轮播图”,后文就不能再使用“首页Banner”、“横幅”等名称。

    4.搭配原型图或设计稿进行说明

    产品需求文档往往包含大量文字描述,团队其他成员在阅读某些功能细节时,往往无法完全理解文字内容。此时如果使用原型图或设计稿进行说明,就可以补充文字内容很难描述的信息,帮助阅读者快速理解产品功能和内在逻辑。因此产品经理在撰写产品需求文档时,需要配合原型图或设计稿进行说明。

    一款产品的原型图或设计稿通常会进行反复修改,产品需求文档必须同步更新,才能让阅读者及时了解到项目的最新动态。但如果每修改一次原型图或设计稿,产品经理都必须手动去替换文档中的配图内容,那效率就太低了!其实,使用高效的产品需求文档撰写神器即可解决这一难题。

    产品需求文档撰写神器

    随着产品开发流程的不断发展,Office等传统办公软件已无法满足产品文档的撰写需求。今天为大家推荐的,是一款专门面向产品经理的文档工具——摹客:网页链接。除了上述图文同步的难题外,摹客还能解决审阅沟通、版本管理等产品需求文档的写作困境,让产品经理可以更高效地创建专业的产品文档。一起来看看~

    1.富文本撰写,充分表达产品需求

    摹客全新的富文本在线写作模式,符合产品经理日常编辑习惯,可以快速完成文档撰写。撰写内容自动保存,可随时查看历史版本,方便对比修改。此外,产品经理也可以直接上传本地产品文档,会自动解析目录,并生成文档树,方便查阅。

    请点击输入图片描述

    2.与原型图、设计稿深度结合,相互说明论证

    产品经理在撰写产品需求文档时可插入设计稿,当对设计稿进行了更新修改,可在文档中设置内容同步,无需重复插入。另外,团队成员在设计稿上打点评论时,也可以引用文档进行说明,让团队成员可以一目了然地查看相关信息。

    请点击输入图片描述

    3.实时审阅,高效沟通

    文档编辑完成后可以通过链接一键分享给团队成员,团队成员可选中文字增加评论,对文档进行在线审阅,清晰表达项目意见,实现产品开发团队的高效沟通。

    9030fad1e8f2aace87e724275fdb3d1b.png

    请点击输入图片描述

    请点击输入图片描述

    4.追踪修改记录,备份历史版本

    通常,产品需求文档的写作不会一步到位,往往会根据团队成员的评审意见进行反复修改,因此会产生大量的迭代版本,对于产品经理来说,如何管理产品需求文档的历史版本,是一个很大的难题。在摹客

    撰写产品文档,每一次修改都可以自动生成历史版本,可以随时跳转查看和恢复,管理便捷。

    92748be6e79eb73ec23cf1174b0781fa.png

    请点击输入图片描述

    请点击输入图片描述

    5.在线预览、分享更便捷

    在摹客中在线撰写或上传的产品需求文档,可通过链接快速分享给团队成员,团队成员获得链接后可自由查看,当产品需求文档有修改时,团队成员仍可通过链接查看最新版本。

    请点击输入图片描述

    使用摹客等高效便捷的产品文档撰写工具,可以简化产品文档撰写流程,提升产品经理的文档撰写能力,让产品经理事半功倍。

    总结

    产品需求文档作为产品开发团队的重要沟通文档,文档的质量好坏会直接影响到各部门是否能够明确产品的功能和逻辑。一份简洁易懂、逻辑清晰的产品需求文档,可以让团队沟通更加高效,从而有效提高产品开发团队的工作效率。

    展开全文
  • Axure原型设计工具--产品经理必备

    千次阅读 2019-09-15 19:36:58
    目录 Axure教程 Axure学习:严丝合缝的设计...Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站...
  • 【实用工具原型图绘画工具推荐

    千次阅读 热门讨论 2016-11-20 22:19:24
     前几天验收机房的时候说到了原型图的画图工具,当时的我有点蒙圈,因为之前几乎没怎么用过和花过原型图,更多的是看,所以对于他们说的那几个软件我都不是特别的熟悉,或者应该说是非常的陌生。但是也不能说这是一...
  • 让我们以不分先后的顺序看一下当今可用于Web设计人员的一些原型制作工具: 成帧器 Adobe XD Adobe After Effects Adobe Animate CC Craft.io原型 原理 原子 原型 贾斯汀·明德 折纸 富林托 ...
  • 产品需求文档(PRD)

    千次阅读 2019-09-17 16:47:00
    产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。 一、什么是产品需求文档 该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然,这个定义针对...
  • 假如产品需求文档(PRD)是一个产品,如何做出一个拥有良好用户体验的PRD? 先来考察下PRD的用户群体(User Persona): 主要是开发人员,在繁忙的开发任务中最希望看到**“简洁易懂”的产品需求文档**。 梳理下PRD...
  • 制作原型工具Want to learn UX from the ground up? Get an entire collection of UX books covering fundamentals, projects, tips and tools & more with SitePoint Premium. Join now for just $14.99/month....
  • 软件原型设计工具介绍;思考需求分析的难点;原型的定义; 原型法主要价值是可视化强化沟通降低风险节省后期变更成本提高项目成功率 对于较大型的软件来说原型系统可以成为开发团队的蓝图 另外原型通过与客户交流还可以...
  • 需求文档(PRD文档)

    万次阅读 多人点赞 2018-03-05 22:11:21
    它将产品的某种目的或需求转换为一个具体的物理或工具的过程,把一种计划、规划设想、问题解决的方法,通过具体的操作,以理想的形式表达出来。由于产品设计阶段要全面确定整个产品策略、外观、结构、功能,从而确定...
  • 需求文档(PRD文档)应该怎么写?

    千次阅读 2019-05-13 19:43:10
    它将产品的某种目的或需求转换为一个具体的物理或工具的过程,把一种计划、规划设想、问题解决的方法,通过具体的操作,以理想的形式表达出来。 由于产品设计阶段要全面确定整个产品策略、外观、结构、功能,从而...
  • Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • WeTest-腾讯质量开放平台 ...国产,最好用的原型设计工具,快速构建移动应用原型与线框图,云端保存、实时手机预览、多种手势动画特效、一键导出工作流以及团队协作管理功能。 Demoo-移动端原...
  • 每个公司对产品经理这个职位的定位都会有所不同,但一般都会涉及到需求调研、画原型、写各种文档等工作。说到画原型图,原型设计工具是必不可少的。 当然了,如果你已经上升到了产品经理的最高境界,那这些工具对...
  • 一款优秀的产品原型工具必不可少。如何才能选择一款适合自己的原型工具呢?Benson特意整理了11款产品原型工具以供参考,并学习曲线,性价比,功能优缺点等方面进行了简单的介绍。希望能够帮助大家挑选一款称心如意的...
  • 是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具,它能快速、高效的创建原型,同时支持...
  • Axure RP是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具,它能快速、高效的创建原型,...
  • 产品经理(PM)常用原型图设计工具

    千次阅读 2015-01-20 15:03:36
    与一般针对产品功能的介绍不同,本文以亲身的设计需求为出发点,通过对产品整理和提供相关的链接,帮助解决从业人群对做产品页面原型的直接需求。可以为做产品设计的童鞋提供一些参考和下载帮助。 天天和产品打...
  • 原型法: 把系统主要功能和接口通过快速...(原型是一个演示系统,原型是一种工具原型法进行的步骤: 确定用户的基本需求(如功能、界面的基本形式、所需要的数据、应用范围、运行环境等) 构造初始原型 运行...
  • 常用的快速Web原型图设计工具

    千次阅读 2017-08-11 11:15:17
    做产品原型是非常重要的一个环节,做产品原型就会用使用各式各样的工具。在PM朋友们的推荐下使用了很多各种各样的软件,当然选择一款真正适合自己的工具也是很重要,在这里就把我使用过的工具都介绍一下。  主要...
  • 5款高效的原型设计工具

    千次阅读 2016-06-21 10:41:26
    你需要一个向导为你指明方向- 这就是原型。 什么是原型原型可以概括的说是整个产品面市之前的一个框架设计。设计师可以利用它引导每个人都参与到项目中来。原型展示了各个部分之间的比重以及各个部分之间的...
  • Axure RP是美国Axure Software Solution公司旗舰产品,是一个专业的快速原型设计工具,让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。...
  • 项目过程管理(五)需求文档

    千次阅读 2019-02-28 16:12:43
    写作说明 写作思路和本模板的设计原理,请参考《如何写出受技术欢迎的需求文档》...全体评审时,需求文档上应该是设计稿,而不是原型图。 如果是基于旧需求的补充完善,把旧需求复制到新版本,加上修订记录并标记修...
  • 原型设计是确认需求、设计产品最重要的沟通工具。 一、原型设计的发展历史 原型设计最初是一种快速开发模式,逐步演进成来今天的原型设计工具。让产品经理不需要会编程知识,就可以低成本、高效率的确认清楚产品...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 41,084
精华内容 16,433
关键字:

原型需求文档工具

友情链接: sockets.rar