产品设计_产品设计文档 - CSDN
精华内容
参与话题
  • 今天这篇好文全篇都是细节,特别是对于各个岗位的职能以及上线流程都非常明晰,相信每一个产品设计师们都可以从中有所收获。  看完本文你会学到:  1. 产品设计全流程  2. 用户体验部门职能  3. 跨...

    今天这篇好文全篇都是细节,特别是对于各个岗位的职能以及上线流程都非常明晰,相信每一个产品设计师们都可以从中有所收获。

      看完本文你会学到:

      1. 产品设计全流程

      2. 用户体验部门职能

      3. 跨部门如何协作

      一. 前言

      「当你给予一个好的设计流程以信任,一切的结果都将变得简洁而美好。」这是 Facebook 的产品设计负责人 Julie Zhuo 对于设计流程的描述。她甚至认为一个完善的设计流程足以改变整个项目团队的 DNA。

      那么当我们面对一个繁琐的项目需求,用户体验设计团队该遵循怎样的设计流程产出高质量的交付物,将业务方的想法落地实现,并在产品上线后进行验证和反馈?同时,在此过程中的每一环节,我们又该分别和哪个团队进行合作沟通?

      我们将整个产品设计过程按照顺序分为五个阶段:

      需求定义

      需求设计

      需求开发

      产品提测

      产品上线

      下面我会依次介绍每一个阶段,用户体验部门的具体职能与合作对象。

      


     

      二. 需求定义

      


     

      在最起初,项目需求源自于业务方的愿景和战略。产品团队应在最初的需求评审会上给出清晰的目标描述,这其中包括了需要解决的问题、提供的服务和达到的目标。同时,还应提供需要关注的关键数据指标,比如常见的意向UV、UV点击率、购买转化率等。

      在这个阶段,用户体验团队,尤其是用户研究员和交互设计师,需要完成的是根据产品团队所提出的需求,进行全面完整的需求分析。这其中包括了用户场景分析、产品现状走查、数据分析和竞品分析等。

      用户场景分析:细分目标用户类型、明确使用场景(who/when/where/what)、定位痛点、需求点、决策点,确定场景优先级。

      产品现状走查:具体的方式可以是用户访谈、用户测试、用户体验地图、眼动追踪和KANO分析等,用于了解产品的功能、性能、内容和体验。

      数据分析:包括全流程各环节数据、业务转化漏斗、用户行为数据和竞品相关数据。

      竞品分析:分别从范围层(功能对比)、结构层(功能结构与流程)、框架层(界面信息布局)三个方面进行分析研究。

      三. 需求设计

      


     

      进入到设计阶段,交互设计师首先需要根据具体需求完成交互初稿、原型设计和最终交互定稿方案,交付物在完成组内交互评审后,与产品经理对接,完成评审确认。与此同时,视觉设计师可以进行风格探索尝试、素材搜集整理和初稿的构思设计。在交互方案确认后,视觉设计师开始视觉层面的定稿设计,完成后需要交付给交互设计师和产品经理分别进行评审,确认后完成视觉资源输出(包括切图标注等)。

      交互初稿设计:分别从范围层(确定展示功能和功能优先级)、结构层(确定功能结构与流程及页面数量)、框架层(梳理页面元素、确定页面元素优先级与基本布局)三个方面进行设计。

      交互原型设计:明确关键页面&流程、基本交互操作,完成可用性分析/测试(包括用户场景自查、用研专家快速评估、快速反复测试及评估等)。

      交互定稿设计:生成交互文档(包括详尽的交互说明、埋点要求及说明等)、高保真原型。

      视觉定稿设计:产出设计定稿图,进行可用性测试(包括专家测试及评估,快速反复可用性测试及评估等)。

      四. 需求开发

      


     

      交互定稿完成后,交互设计师需与产品经理、相关开发团队成员一起进行技术评审,完成整体方案的开发估时。

      在视觉方案最终确认后,视觉设计师需与产品经理、相关开发团队成员一起进行需求方案宣讲和技术评审,确认开发团队的最终排期。设计部门需配合开发联调 UI 视觉样式,提前确保设计质量。

      五. 产品提测

      


     

      通过交互全流程走查、视觉还原走查、提出界面实现上的视觉问题 (UI bug)、提测阶段全面解决,来保证设计稿精确还原。

      六. 产品上线

      


     

      对上线数据进行验证,进行数据的收集、分析和总结,了解各种数据指标及相应的意义,利用数据分析结论指导设计。收集、分析、决策用户反馈,对整体项目进行总结复盘,为下一阶段迭代优化做准备。

      总结

      一个完善的设计流程不仅能帮助我们了解完整的设计周期,同时还能明确我们每个个体在整个项目周期中所扮演的角色,并以此判断所在团队在当前流程的应用情况。每个个体在这个完善的流程下各自展现自身能力,实现自我价值。同时,个体又通过这严密的「工作流」聚合成为一个整体,一起朝着共同的目标而努力,最终打造出拥有高颜值、良好用户体验,同时又能切实解决用户实际问题的好产品

    转载:http://www.admin5.com/article/20171211/807378.shtml

    展开全文
  • 产品设计师常用网站

    千次阅读 2019-09-18 20:19:36
    (打不开请使用VPN) 一、寻找灵感类的 1、https://dribbble.com 2、https://www.behance.net/ 3、http://www.siiimple.com/ 4、http://reeoo.com/ 5、http://www.calltoidea.com/ 6、http://www.ui.cn/ ...

    (打不开请使用VPN)

    一、寻找灵感类的
    1、https://dribbble.com
    
    2、https://www.behance.net/
    
    3、http://www.siiimple.com/
    
    4、http://reeoo.com/
    
    5、http://www.calltoidea.com/
    
    6、http://www.ui.cn/
    
    7、http://www.zcool.com.cn/
    
    8、http://www.uisdc.com/
    
    9、http://designmodo.com/
    
    10、https://www.google.com/design/spec/material-design/introduction.html
    
    二、素材收集
    1、http://www.imooc.com/
    
    2、http://www.w3school.com.cn/
    
    3、https://github.com/
    
    三、新闻资讯
    1、https://www.designernews.co/
    
    2、https://medium.com/
    
    四、软件工具
    1、http://www.sketchcn.com/ 			(软件技能)
    
    五、具字体icon
    1、http://www.iconfont.cn/ 				(icon收集搜索)
    
    2、http://www.youziku.com/ 				(在线字体制作)
    
    3、http://sketchrepo.com/ 				(sketch 素材网站)
    
    4、https://design.google.com/icons/ 	(谷歌的)
    
    六、Web UIKIT
    1、http://www.getuikit.net/ 			(UIKIT可用于H5和web)
    
    2、http://www.bootcss.com/				 (bootstrap 中文资料网站)
    
    3、http://materializecss.com/ 			(material design uikit)
    
    七、新产品发布网站
    1、http://next.36kr.com/posts/
    
    八、PNG 无损压缩
    https://tinypng.com/ 					(用于轻量化软件)
    

    向前走: https://blog.csdn.net/lishichao706/article/details/51488484

    展开全文
  • 互联网B端产品设计经验总结

    万次阅读 2017-12-20 19:30:30
    一、什么是B端产品 B端产品,可以概括为:在供求关系中,给供给端使用的产品或系统。 B端产品区别于C端产品的特征是: C端产品,侧重满足个人生活需求,给用户提供愉悦感(满足便利、新鲜感、虚荣心、...

    一、什么是B端产品


    B端产品,可以概括为:在供求关系中,给供给端使用的产品或系统。


    B端产品区别于C端产品的特征是:

    • C端产品,侧重满足个人生活需求,给用户提供愉悦感(满足便利、新鲜感、虚荣心、欲望冲动),好玩。

    • B端产品,侧重满足组织生产需求,帮用户提升效率(发现并解决业务问题),有用。


    有一个段子讲“手机那么好玩,还找什么女朋友呀”,这里的好玩,多数来自C端产品给用户的愉悦感。


    而贯穿B端产品迭代发展的落脚点是:在业务流程中发现问题、解决问题,并提升效率。


    二、我的B端产品设计经验


    写这篇总结的基本思路是:如果要做一个独立且相对复杂的B端产品系统,该如何开展产品设计工作?


    主要包括以下几个方面:

    • B端产品系统设计的基本原则(指导思想)

    • B端产品系统设计的五个步骤(具体怎么做)

    • B端产品系统设计中需要避免的误区(不要那么做,或不要做成那样)


    (一)基本原则


    1.“产品思维,业务导向”


    先说“业务导向”:产品系统是为业务服务的,所以要尊重业务的发展规律,最终让产品帮助到业务的发展。产品经理要到业务中去了解业务的宏观与细节,根据业务抽象系统逻辑,用互联网的方式系统性的解决问题或提升效率。


    再说“产品思维”:产品经理有责任把原来自己可能不熟悉的业务,熟悉并抽象成产品需求且把事说清楚,并能够提供合理化的解决方案,不能只做需求的传声器——“他们给我提了一个需求,我们就做这么一个功能”,避免为了做而做。


    由于业务快速发展,有些组织中没有“产品经理”的角色,又或者其他角色的成员主动承担了“产品经理”范畴内的工作,岗位名称无所谓,是否有经验无所谓,重要的是在承担这个事情的时候做到“产品思维,业务导向”,这是把事做好的基础。


    2.用使用者角度去思考


    所有的产品经理都知道“用户体验”,不过很多人理解的“用户体验”偏重在前端交互、视觉文案上。对于B端产品来说,只关注这些是不够的。所以我喜欢用更普通直白的说法——关注“使用者角度”。在设计产品的时候,想一想真正的使用者他们需要一个什么系统?他们会怎么用这个系统?现在的实现方式对他们来说好用吗?


    很多B端产品,当产品经理离开办公室作为一个普通用户的时候,是想不到或者用不到的,所以极端的情况会出现,在需求开始之前产品经理没有用过相关产品,系统上线之后产品经理也不会用自己做的产品。B端产品经理,一定要走入具体工作场景,观察真正的产品使用者在具体的业务氛围中是怎么工作的。我一直相信一点:只有沉浸其中,才能更好的理解。


    在小度掌柜(百度外卖商户端)电脑版上线第一周,我去一家商圈头部商户的后厨蹲点了俩小时,看餐厅的工作人员是怎么接单、处理订单的,在现场我发现我们的“接单”按钮有点小、不够明显。回来之后,我和视觉设计师沟通优化方案,给他们描述我们产品使用的具体场景:8平米的小屋(拥挤嘈杂),配置不高的组装电脑(显示屏分辨率不高),工作人员站着处理三四个平台的订单(紧张慌忙)。在这样的场景下,还需要工作人员俯下身去“寻找”操作按钮是不够效率,也不厚道。以此说服视觉设计师愿意接受“不符合设计规范”的大号按钮。


    还有一个案例,是在优化客服系统之前,我去百度外卖的客服工作区,站在客服同学的背后,看他们怎么接电话、怎么记录信息、怎么解决投诉,只有这样才能了解客服人员在使用系统的时候需要什么功能,在哪些环节浪费了时间。


    针对和内部使用者的沟通合作,个人觉得可以重点做好以下几点:


    • 产品经理是来解决问题的,不要担心一锤子买卖(而提海量的需求),开发资源是有限的,我们可以一起来排需求优先级(不是所有的功能能一下子全上线);

    • 建立好信息同步机制,固定时间固定方式同步关键进展(当然所有信息同步方式里,面对面沟通效果是最好的);

    • 不要依赖业务方提需求,要帮业务方想方案,由于角色的不同、思维方式的不同,业务同学不一定能提出自己真的需要的功能,产品经理要主动去思考业务中的问题,并形成需求;

    • 通过一两个项目,建立互信,形成互相支持的关系。


    3.考虑系统的延展性与弹性


    业务肯定是发展的,而当前的资源和时间是有限的,一个版本的需求,不会解决所有问题,迭代是必然的。怎么增加系统的延展性与弹性,减少后续研发的开发难度、减少使用者的后续学习成本就很重要。尤其是在设计1.0系统的时候,更考验产品经理的这项能力。


    • 一方面,需要增加对业务发展的预见性,当前业务是怎么样的,以后一到两年会怎么发展,甚至未来五年的形态是什么样?没有人能保证自己的预测一定是对的,但是尊重业务规律,去思考业务可能的发展方向,提前想到的越多,在设计系统的时候能考虑到的延展性与弹性就越多。用“谋全局”的高度去思考一个系统,才会生成更合理的当前“谋一隅”的一版需求。

    • 另一方面,在具体的产品方案里,针对这个系统的核心业务落脚点、基本单位尽量做到“模块化”——方便组装、方便基于这个标准模块叠加逻辑。下文的“定义最小颗粒度”会详细阐述这块的思考。

    总之,一个好的产品系统要做到适合延展、有容纳新功能的“弹性”,B端产品经理要有这个自我期许。


    (二)五个步骤


    1.确定产品系统的目标


    接到一个需求,首先要想:这个系统给谁用?要做哪些事(解决什么问题)?系统的边界是什么(需要覆盖到什么范围)?

    在这个大目标下,开展后续的工作。


    2.梳理业务流程(用逻辑把系统串起来)


    业务流程中包含哪些角色、包含哪些关键节点,从头到尾的顺向流程是怎么样的,从尾到头的逆向流程是什么样的,中间的分支流程是什么样的,从上到下、从下到上各类角色怎么配合……

    梳理业务流程要做到以下几点:要闭环(不能有半逻辑,不能有停留在某个环节走不下去的流程);要看到底(不只是宏观上合理,最底层的细节逻辑也要覆盖到),要有边界(一个全的系统是什么,不是没边没延)。


    争取用一个大的业务流程图,把整个系统要解决的问题包含进去。这样做的好处是,可以把功能想全了,防止有重大逻辑缺陷,或遗漏功能。


    3.定义最小颗粒度(基本单位)


    基于上述业务流程,会发现有一个“基本单位”可以从头到尾、从尾到头、从上到下、从下到上顺畅的在这个系统里流转。


    • 这个基本单位就是需要我们定义的“一件事”,拆解到合理大小颗粒度的“一件事”——这个系统主要解决的问题的基础组成部分,靠这些最小颗粒度的“一件事”组成整个系统。

    • 这个“一件事”在系统存在、流转有哪些“节点”,这个“节点”对应的是系统里的关键状态;

    • 不同的人,在这个系统里存在,就是系统里的“角色”;

    • 有哪些“角色”可以针对“一件事”的“节点”产生影响,针对哪些内容产生哪些影响就是“权限”和“数据范围”。

    根据业务流程,抽象出:基本单位“一件事”、关键状态的“节点”、使用者的“角色”、“权限”、“数据范围”。这个系统就基本成型了。


    以客服工单系统为例:


    • 最小颗粒度的基本单位“一件事”是指“一个投诉”,不是一个电话(太小了),也不是一个人的所有投诉记录(太大了)。

    • “节点”:就是工单的状态,从投诉开始、到流转到相关部门或负责人、到最后投诉解决,工单的每一次停留都可以作为一个“节点”。

    • “角色”:除了一线客服、小组长、客服负责人,还有其他配合部门的角色等,凡是参与到这个系统的人都可以概括到某类角色里;不可概括的参与者或需要细化分工的参与者,需要增加角“角色”以适应需要。

    • “权限”和“数据范围”:各个角色能做哪些操作、操作哪些内容、造成哪些影响就构成了“权限”和“数据范围”。


    一个好的基本单位就像集装箱一样,具有普适性(可以灵活被处理)、具有弹性(方便添加功能)。定义好一个系统的最小颗粒度,系统就成功一半了。

    我见到的B端产品设计里,做的不好的多数就是由于最小颗粒度的定义不合理,造成系统逻辑不全或延展性很差。


    4.建立框架与归类(用页面把系统串起来)


    根据不同的角色、不同的功能,进行归类,进而组合成一个整体框架,用页面的形式呈现出来,就可以形成交互稿。


    从第二步到第三步,从第三步到第四步,是一个拆解再组装的过程,先拆解了、揉碎了再用产品思路组装起来以形成最终的产品形态。


    5.撰写需求文档


    将上述梳理的过程和内容,用文字的形式将产品逻辑、图表、页面、功能点串起来,并进行丰富细化,就形成了需求文档。


    好的需求文档应该:逻辑严谨,条理清楚,文字简练,能把事说清楚。


    每个角色(交互、视觉、开发)都能准确理解需求的背景、目标、实现方式,大到流程逻辑,小到功能细节。可以针对不同角色,提供侧重点不同的需求形式。


    尽量用平实的语言(而不是形容词)描述需求,挤压任何歧义空间。


    (三)需要避免的误区


    1.看不到底


    一个新用户,第一次使用系统但通过自己的琢磨看不懂这个系统(不会用、不知道都有哪些功能),我觉得这个系统不算好系统。好的系统,可以通过页面功能或者不多的介绍,就能把底层逻辑和边界看明白。


    看不到底的伴生现象是特殊逻辑多,造成的问题往往是枝蔓太多。产品逻辑用打补丁的方式,解决某个问题可能很快捷,但长期来看,这种方式影响产品系统的简洁性和条理性。


    看不到底的坏影响是,一方面使用者(尤其是新人)学习成本高;另一方面新增功能时容易挖到“电线”,增加了维护与迭代成本。


    2.延展性差

    上面的文字已经提到,由于初期考虑的不周全(业务理解的前瞻性不够,或者最小颗粒度定义不清楚等)造成系统延展性差,增加一个功能就像给系统做一次大手术。所以尽量在产品设计初期,考虑的多一些,每一次迭代都想着为后续迭代提供便利。


    3.所有问题都想着用产品系统来解决

    一个系统不能解决所有的问题,也不是所有的问题都适合用产品系统来解决。有些事(需求)从投入产出比、灵活性上来说,通过管理规范、SOP、Excel去解决可能比做一个系统更适合。


    三、B端产品经理的自我修炼


    在和那些令人佩服、事业有成的前辈/领导一起共事过程中,还有我这几年的工作感受,我觉得B端产品经理需要持续沉淀的能力有:


    1.理解业务


    无论是O2O也好,互联网+也好,B端产品要解决好业务的问题,必须要去理解业务,要了解这个行业的历史与现状、关注行业的发展。


    除了垂直的业务逻辑,多数的互联网+都会涉及到商业问题,经济管理、市场营销这些知识会帮助产品经理开阔思路、提升商业思维。


    2.沟通协调


    B端产品多数业务链条比较长,涉及角色较多,一个B端产品的成功,离不开相关角色共同努力与相互支持。


    通过一两件事,建立与合作部门的互信,是后续合作的基础;建立固定的信息同步机制(与研发团队的每日站会,与业务部门的每周周会等),是合作顺畅开展的保障。


    在工作中,能够发现资源、利用资源都是一种能力。


    3.持续学习


    让我佩服的那些前辈,平时办公桌上都会有一本书。一个人能力很强不可怕,可怕的是他还一直在学习。


    无论是这个时代,还是互联网行业,都发展太快了,我们需要持续学习。


    主要结论总结


    • B端产品是指:在供求关系中,为供给端提供服务与支持的产品。

    • B端产品系统的核心价值在于:发现问题、解决问题,提升效率。

    • B端产品系统设计的基本原则:“产品思维,业务导向”;用使用者角度去思考;考虑系统的延展性与弹性。

    • B端产品系统设计的五个步骤:确定产品系统的目标;梳理业务流程;定义最小颗粒度;建立框架与归类;撰写需求文档。

    • B端产品系统设计中需要避免的误区:看不到底;延展性差;所有问题都想着用产品系统来解决。

    • B端产品经理应该持续沉淀的能力:理解业务;沟通协调;持续学习。


    作者:刘玉强,腾讯OMG内容平台部,高级产品经理。之前在百度外卖任高级经理,陆续负责了商户端、客服系统、供应链系统、电销系统等B端产品的策划与管理工作。作者公众号:theorangly。

    展开全文
  • 通过6个章节,19个小课时,阐述到底中台是个什么样的东西,他能够帮助我们解决什么样的问题,他又是如何去解决的,提供哪些的解决方案,中台能带来哪些价值,产品定位是什么,要建设中台他的核心要素包括哪些,最后...
  • 产品设计

    千次阅读 2014-11-04 13:57:23
    产品设计是一个由抽象的概念到具体形象化的处理过程,通过文字或图像等方式将我们规划的产品需求展现出来。它将产品的某种目的或需求转换为一个具体的物理或工具的过程,把一种计划、规划设想、问题解决的方法,通过...

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

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

    1、产品需求文档介绍

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

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

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

    2、产品需求文档写作

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

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

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

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

    shu-17

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

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

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

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

            

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

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

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

    shu-18shu-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

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

    展开全文
  • 软考中级软件设计师难不难 重点 (Top highlight)I have a confession to make. As a young Design ‘pioneer’ in many tech companies, I always felt like I had to deal with some sort of unfairness: all I ...
  • 导读:酷壳网的陈皓给大家介绍了软件设计的一些原则,作者认为一个好的程序员通常由其操作技能、知识水平,经验层力和能力四个方面组成。软件设计的这些原则,每一个程序员都应该了解。相信大家从中能够从中学了解到...
  • 软件设计概述

    万次阅读 2016-08-28 19:58:21
    概述 软件设计是把需求转化为软件系统的最重要...在此,主要阐述软件系统设计的5个核心内容:体系结构设计、用户界面设计、数据库设计、模块设计、数据结构和算法设计。旨在帮助开发人员搞清楚“设计什么”以及
  • 本文为大家介绍软件设计中的一些原则,都是经过长期经验总结出来的知识,每一个程序员都应该了解,相信对大家在进行软件设计的过程中会有很大帮助。 Don’t Repeat Yourself (DRY) DRY 是一个最简单的法则,也是最...
  • 本文为大家介绍软件设计中的一些原则,都是经过长期经验总结出来的知识,每一个程序员都应该了解,相信对大家在进行软件设计的过程中会有很大帮助。 Don’t Repeat Yourself (DRY) DRY 是一个最简单的法则,...
  • 产品设计师”常用软件推荐
  • 10款优秀的产品包装设计欣赏!

    万次阅读 2017-07-28 05:03:27
    何为优秀,第一要与众不同,第二历久弥新、百看不腻。下面就一同来欣赏下10款优秀的产品包装设计吧!
  • 产品经理——产品原型设计规范

    万次阅读 多人点赞 2018-08-29 14:35:42
    1 术语与解释 表 1 1术语表 2 概述 2.1 前言 由于多种因素,在需求分析阶段得到完全、一致、准确、合理的需求说明存在困难。在获得一组原始需求后,如何快速地使其“实现”,通过原型反馈,加深对系统的理解...
  • 工作中用到的设计模式

    万次阅读 2019-12-22 14:10:44
    人工智能,零基础入门!... 1、单例模式 Spring容器中的 bean默认就是单例的 2、桥接模式 JDBC连接数据库 ...定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动...
  • 在查看了您的简历之后,我们希望您能参加我们的产品实习生的面试。请问下周您什么时候有空呢?” 在看到这封邮件后,你心跳加快,呼吸急促。在投出这么多份简历之后,你终于,终于在产品...不论如何,产品设计是一个...
  • 设计开发前的产品原型图

    万次阅读 2017-11-30 20:37:50
    设计开发前的产品原型图?   原型图的绘制并不是为画图而画,我们在画原型图的同时相当于对产品进行初次设计,将产品经理提供的需求融合在界面中。原型图的设计是一个对整体的把控和思考的过程,前期确定好产品...
  • 【Python】三种方法字符串转字典

    万次阅读 2020-05-08 21:23:23
    Python 三种方法字符串转字典 eval:不安全,容易被用户恶意操作 ast.literal_eval:安全,专门用于字符串类型转换其他类型 json:只能转换外单引号,内双引号的字符串 # -*- coding: utf-8 -*- ...
  • 【Python】存储字典的四种方法

    万次阅读 2020-05-08 21:22:38
    Python存储字典的四种方法0.直接字典和被字符串包裹的字典1.eval + str2.json3....d = {'技术': {'后端开发': ['Java', 'C++', 'PHP'], '移动开发': ['HTML5', 'JavaScrpit']},'产品':{'产品经理': ['产品经理'...
  • 两种常见电商sku的设计

    万次阅读 2016-06-29 17:56:28
    在电商系统中,商品sku和sku模型至关重要,是整个电商系统的重要组成部分之一,下面通过一些简单的知识整理和分析,讲解一下sku属性管理和常见的建模方式。 一、sku的定义及概念的统一 1、什么是sku?...
1 2 3 4 5 ... 20
收藏数 877,255
精华内容 350,902
关键字:

产品设计