产品设计_产品设计规范 - 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。

    展开全文
  • 产品设计思维:电商产品设计全攻略》具有系统全面的电商产品设计构建实例,帮助你建立起完整的产品视野,洞察全局,获得战略思维与统筹意识,从而进行高屋建瓴式的战略规划,并据此进行产品竞争战略的制定和实施。...
  • 标准的产品设计工作流程

    千次阅读 2011-11-08 15:04:37
    每个产品团队都会有自己的工作流程,无论这个工作流程是否最高效、是否体现最大价值,但是我认为只要这个流程能够为实现工作目标提供过程的保障就可以算是好的流程。 对于流程本身而言,可以因团队不同或工作任务...

    每个产品团队都会有自己的工作流程,无论这个工作流程是否最高效、是否体现最大价值,但是我认为只要这个流程能够为实现工作目标提供过程的保障就可以算是好的流程。

    对于流程本身而言,可以因团队不同或工作任务不同而有差异。一个成熟度的产品团队可以在保证工作质量的前提下轻松适应任务的变化,也就是说能够依据不同的工作要求调整对应工作的流程。也只有这种团队才能正真体现最大的价值,称得上是一个敏捷的、能快速响应变化的团队。

    那么,我们先来看看以前做产品设计时的团队工作流程。我总结为是一个相对normal的流程。大多时候,一个PM,一个美工,一两个写Html的工程师就足够了。

    如下图所示:

    工作流程包括:

    Ø  当产品经理做好了产品的需求分析和功能实现批次计划后,开始计划产品迭代过程。

    Ø  PM做好产品的线框设计,交给前端工程师(Front-End);

    Ø  前端工程师开始依照产品经理的线框做HTML开发,同时要肩负一些交互设计工作,比如,导航,搜索,查询,弹出页面或层设计,menu等;

    Ø  同时,美工开始依照线框,做页面的视觉设计,比如,色彩,按钮,logo,icon等;

    Ø  当HTML和美工设计都ok了,就可以交给Javaer、PHPer等做前后台整合了;

    Ø  然后是产品的一系列测试,包括可用性测试,功能性测试,性能压力测试,产品集成测试,发布测试等。

     

    然而,随着产品精细化设计的要求,特别是web2.0的一些标准逐步引入到产品设计范畴。以注重用户体验,注重以人与系统的交互为设计重点,崇尚简约和适度的设计理念被提出来,并逐渐引领了产品设计的主流思想。

    在新的产品设计过程中,为了体现web2.0的UE设计元素,实现产品设计的工作精细化,我们逐步优化了新的产品标准工作流程,并定义了产品工作流程的标准输出成果。

    如下图所示:

     

    新的产品设计团队标准工作流程被划分为两个领域:

    1、 产品功能设计领域;

    2、 产品视觉交互设计领域;

    这种划分的意义在于把产品不再仅仅看作一个由代码构成的系统,而更是一组由用户行为构成的服务集合。从系统角度来看设计更看重的是功能,而从服务角度来看设计更看重的是体验,所以,我们在产品设计的过程中,一条线去关注产品的功能设计,一条线去关注产品的体验设计。

    只有两个领域都做到了精致,做到了极致,一个产品才称得上是好产品,才有机会帮助投资人获得盈利的可能。

    产品功能设计领域包括以下一些环节:

    Ø  制定工作计划

    Ø  用户需求调研

    Ø  产品功能分析

    Ø  信息架构设计

    Ø  原型制作

    Ø  内部评审

    Ø  出资方评审

    产品视觉交互设计领域包括的环节是:

    Ø  交互呈现调研

    Ø  视觉风格调研

    Ø  视觉设计

    Ø  视觉内部评审

    Ø  资方评审

    Ø  裁图及前端实现

    从UE的五层要素设计思路来看,用户需求调研过程是对应的Strategy和Scope层;产品功能分析过程对应了Structure层;交互呈现调研、原型制作对应了Skeleton层;视觉风格调研和设计对应了Surface层。信息架构设计则对应了Structure层的信息架构和Skeleton层的信息设计。

    下面对每一个流程进行简要的介绍和描述:

    1制定工作计划

    主要参与角色是PM-产品经理;主要的标准成果物是《工作计划》

    第一步非常重要,可以理解为是产品路线图上最为关键的一个阶段计划。熟话说万事开头难,好的开头是确保成功的第一步。一个成功的产品在其生命历程上,会包括:

    创意阶段---设计阶段---实现阶段---运行阶段---更新升级---消亡

    这里制定的工作计划是设计阶段的工作计划,这个阶段计划的目标是把产品的创意变成可实现的产品设计语言,确保产品的创意和目标得以在实现过程中完美体现出来。

    同样,在计划的过程中,PM也要考虑工作任务的特性,结合工作流程做出适应和改变。

    我在制定工作计划时使用的工具一般是MS的Project或者Excel,计划内容要明确至少四大要素:

    1、 任务:要完成的任务最好能做合理的细分,可以参考WBS的定义。

    2、 时间:任务开始和结束时间;

    3、 资源:投入到任务的资源,要责任到人;

    4、 产出:标准的产出物是什么,这是检验其工作成果的最好载体。

     

    2用户需求调研

    主要参与角色是PM-产品经理;主要的标准成果物是《调研问卷》和《调研分析报告》

    对于有特定目标用户的研发型产品,往往都需要PM在产品设计之初对用户做详尽的调研,调研的内容包括:

    Ø  总体性调研

    产品价值目标,用户的业务目标,用户的组织架构,与产品相关的流程,规章制度,出资人对于产品认定的成功标准等。

    Ø  功能和非功能性调研

    产品用户角色,产品功能需求,用户对于产品功能的需求优先级,产品内容需求,产品约束,运营需要,性能要求,其他特性等。

    在进行调研的时候,调研问卷是必不可少的一份文档。在准备调研问卷时,PM可以通过问卷明确调研的方向和把控范围;被调研者可以了解调研重点,并准确的给予响应,明确提供有价值的信息范围(深度和广度等)。

    需求调研完成后,PM要及时完成调研分析报告,并与用户进行确认。

    调研分析报告是将调研过程中形成结论的内容按照一定的逻辑格式规整成文后,方便用户进行逐条确认。

    调研分析报告一般着重体现五点内容:

    1、 产品的战略目标和价值体现

    2、 产品的核心业务形态

    3、 产品的功能分布和描述

    4、 产品的非功能需求(不包含交互和视觉部分内容,这部分将单独调研)

    5、 产品的内容需求(作为信息架构设计的基础)

    如果调研报告能将上述的五方面内容说清楚了、说准确了,我们会认为调研工作是成功的。

     

    3产品功能分析

    主要参与角色是PM-产品经理;主要的标准成果物是《产品需求文档》,有个洋名字为PRD。

    产品需求文档是对产品的需求分析后,以设计语言进行描述,将作为开发阶段的主要输入物之一。

    如果是通用型产品,在PRD的分析过程中还可以借鉴MRD。在这类项目中,PRD在产品项目中是一个承上启下的作用,对上是基于MRD内容的深化和落地,对下是要把MRD中的内容设计语言化和技术化,向研发人员说明产品的功能特性和性能指标。

    在这里,我们抛开市场元素,只从产品本身的功能特性来看,我们约束PRD要体现以下的一些内容:

    Ø  产品生命周期模型

    Ø  实现进度安排规划

    Ø  产品技术路线

    Ø  对产品feature详细描述

    Ø  feature优先级

    Ø  产品release计划

    Ø  用例(use cases)设计

    Ø  产品部署设计

    Ø  产品性能设计

    至于产品的需求分析方法,可以参考我前面的文章《探讨APP的分析过程》。

    4信息架构设计

    主要参与角色是PM-产品经理或IA-信息架构师;主要的标准成果物是《信息架构设计》。

    产品的信息架构设计文档主要包括:

    Ø  信息架构策略

    Ø  信息架构蓝图

    Ø  内容映射

    Ø  内容模型

    Ø  原型(着重体现四大体系:导航,搜索,标签和组织)

    具体可以参考我前面的文章《信息架构的设计思路》。

    这里需要说明的是:特别对于互联网产品而言,信息架构不是一个简单的工作,不能把它作为产品需求设计的一个附属任务来完成,而是要将其作为一个独立的工作任务,安排有经验的专家来负责把控。因为,我见过很多因没有重视产品的信息架构设计,而到后来不得不推翻重做的产品,这种劳命伤财的过程希望不要再发生了。

     

    5原型制作

    主要参与角色是PM-产品经理和UE交互设计师;主要的标准成果物是《低保真原型》和《高保真原型》

    很多产品经理都是十项全能,画线框,画原型,做分析,做设计…….但是真正检验一个产品经理的业务能力和设计素养的就是他做的prototype。

    为什么这么说?

    因为,软件行业的产品经理,往往身上都背负着产品创新和设计的重任,这种能力最好的体现方式就是通过原型来展现,一个有想法并能将想法快速展现出来的PM,具备成为一个合格PM的基础。

    在不同的团队,PM的工作略有不同。有的产品经理只画线框,然后把线框交给UE,由UE完成prototype的制作,因为在UE的工作中还包括了交互的设计。

    有的产品经理则需要一把抓,从功能设计到交互设计全部搞定,当然这样的产品经理虽然累,但综合能力将会更为突出一些。

    再来说说线框和prototype的区别:

    Ø  线框是静态的;prototype可以是有交互能力的;

    Ø  线框是思路;prototype是思路的具体实现;

    Ø  线框包括静态页面和说明;prototype是页面和行为展现;

    Ø  线框更多体现框架、组织、结构、功能划分及布局等;prototype更多体现:逻辑,细节,元素,整体,色彩,交互,内容等。

    Prototype又分为低保真和高保真两种:

    Ø  低保真原型反应页面的框架逻辑,导航逻辑,交互逻辑,标签逻辑,内容组织逻辑等。

    Ø  而高保真原型在低保真原型的基础上,还加入了信息内容,视觉元素,交互细节等。

    两种原型的用法也略有不同:

    一般在产品团队中,内部更看重的是低保证原型。因为,在设计之初,最怕的是偏离设计方向而浪费资源,所以通过低保真原型可以快速的发现问题,通过不断的迭代设计完善产品框架和主体构造。

    一般在与外部进行产品工作成果说明和演示时,用高保真原型更好。因为,sponsor或用户更喜欢关注产品的实际模样,因为他们骨子里是代表未来实际使用者的利益,如果他们觉得色彩不好,交互细节有问题,那么他们会坚持要求团队做出响应,直至他们满意为止,既然如此,我们最好将这个过程安排的越早越好,至少不要因为他们的意见而导致后期的开发工作重复。

    6内部评审

    主要参与角色是Product Owner;主要的过程产物是《评审报告》

    在一个以自有产品销售为主的企业里面,产品的研发和销售往往是两个体系。我们将产品的研发负责人称为PM,而将销售的负责人称为Product Owner。

    PO熟悉客户,知道客户为何需要这个产品,也知道市场的很多方方面面,所以,他们参与产品的内部评审是非常有必要的。

    在内部评审过程中,我们要做好评审报告的记录。对于评审过程,我认为有以下几点要特别记录:

    1、 一致认同的问题。在会上就要给予明确的响应措施,谁负责响应,多长时间响应,谁来检查等;

    2、 不能落实的问题。在会上要形成跟进方案,谁来跟进,找谁获取资源,争取什么时候获得结论等;

    3、 形成的结论。会议上形成了什么结论,后续有何安排等,都需要详细记录。

    4、 这份会议纪要将发送给谁,抄送给谁。

     

    有时候,产品团队和销售团队不总是一团和气,一碰面总容易擦出火来。这是因为,一旦争论到产品的细节,产品团队总认为销售方面不懂产品,不懂技术;而反过来,销售团队又会责备产品团队不懂用户,不懂需求,自以为是。

    说实话,这种情况不太好处理,但一个有经验的产品经理如果会审时度势,做出明智的决定,也许可以化解一些矛盾。

    比如,

    亲自去再摸一次需求,而不是一味的火拼,甚至找到老板来协调;

    做出两套方案,待与用户参与的评审时,确定最终的需求;

    如果明知自己是对的,则冷处理,将类似的问题全部挂起,并尽快整理一份书面澄清函,由PO提交用户逐一回复。

    7出资方评审

    主要参与角色是Sponsor,Product Owner,PM等;主要的过程产物是《评审报告》

    内部研发型产品的sponsor一般是分管产品研发的副总或CTO,有时候CEO,销售副总也会作为干系人列席;交付型产品的sponsor一般是用户方的业务负责人。

    在这种级别的评审会议,PM要非常的细心准备好每个细节,熟话说:台下十年功,台上三分钟。如果不能通过会议让sponsor认为出资是值得的,那么团队的日子将非常难过,对整个team的信心将是沉重的打击。

    所以,在准备过程中,我认为有以下一些要点是特别要注意的:

    1、要有P3组合。PPT+Prototype+Plan。

    Ø  Ppt着重介绍产品的主要设计细节,核心技术方向,产品亮点,有必要还需要包括用户调研的数据分析成果,外部的可靠来源数据依据等。

    Ø  Prototype主要展现产品的外观模样,主要展现的是功能性,交互性,以及视觉性。

    Ø  Plan主要展现,截至目前阶段产品研发的过程到了哪个环节,一共花费了投资人多少钱,成本是否在可控范围内,后续还要投入多少资源等等。

    2、要有问题应答表。

    Ø  PM要准备好sponsor可能会问道的一些问题,并做好准确、真实的答复准备,以随时响应sponsor的提问。

    Ø  如果PM不能cover所有的方面,就一定要做好分工,不同的人准备回答不同的问题。

    3、要准备现场的一些记录工作。

    Ø  安排特定人做现场的录音或记录工作。

     

    会议中,一般会形成一些重要结论,比如:目前的工作是否正常,是否可以继续到下一个阶段;是否需要做出修改和调整;是否要停止下来,等待其他条件满足后再继续。

    不管怎样,PM要做好各种应对的准备,随时与各方面做好沟通和传递。

     

    8交互呈现调研

    主要参与角色是视觉设计师和交互设计师;标准成果物是《交互呈现调研报告》

    在交互呈现调研过程,主要是明确用户群体的特性,包括了解其使用习惯,特殊偏好,在用产品操作过程的友好或缺陷之处等等。

    在调研过程中,我们常常将会用到一些可重用的资源来作为调研的辅助,比如:

    1、 框架体系;

    2、 设计模式;

    3、 组件;

    这些可以被用来作为调研的资源,为我们快速的理解用户的实际需要有很大的帮助。因为在调研过程中,有很多时候用户会告诉你,他们看过的某某网站,某某产品的某些表现形式很好,可以借鉴。但是,哪些表现元素是真正可以被借鉴的,哪些是不适合被借鉴的,都没有明确下来,包括如何借鉴,如何和用户的实际需求结合起来,都只是一些非常空洞和概念的想法而已。

    所以,我们会用到一些被我们沉淀和积累的资源来作为调研过程中的案例标准来展现和承载探讨。

    Ø  框架体系

    框架体系指产品依据展现业务的不同而设计的有着内在联系的各种页面展现框架集合。举个例子,一个购物网站有注册框架,支付框架,购物流程框架,商品展现框架。同时,为了支撑购物的良好体验,一般还会有商品的论坛框架,评价框架,搜索框架,比较框架等等。

    那么,如果是个着重于信息的管理产品呢,则有信息发布框架,信息聚合展示框架,信息搜索框架,栏目展现框架,详细信息页框架等等。

    如果我们能过将这些框架示例按照一定的逻辑组织和整理起来,在调研过程中,依据用户的不同需求,有针对的展现相类似的框架示例,那么就可以方便直观的基于示例进行探讨,明确用户的意图,形成调研结论。

    Ø  设计模式

    设计模式是一种常见问题的常用解决方案。

    比如,用户忘记了密码怎么办,那么我们可以提供一个密码找回模式,这个模式是通过输入注册的邮箱地址后,我们将用户的密码发到该邮箱。相应的,还有登录模式,各种搜索模式,分页模式,日期输入模式,图片切换模式,评论模式,留言模式……

    有很多企业都建立了自己的模式资源库,也就是将各种设计模式的文档经过整理后,分类保存,在网上或企业内部进行公开。

    比如,雅虎的设计模式库:http://developer.yahoo.com/ypatterns/

    Ø  组件

    组件是页面最通用的组成元素,比如,文本,链接,按钮,复选框,图片等。一般模式可以在不同产品中通用,然而组件却往往只适用于特定的产品,因为,组件是确定了展现形式的成品,可以直接被使用。

    组件资源库和模式资源库一样,可以采用很多方式来管理和收集,比如wiki的方式。也有很多公共的资源提供网站,比如,http://www.webdesign.org/,上面就有很多最新的组件资源

     

    9视觉风格调研

    主要参与角色是视觉设计师和交互设计师;标准成果物是《视觉风格调研报告》

    视觉风格调研工作在交互呈现调研的基础上,调研产品的实际用户群体的熟知的文化理念,以及现有在用产品的生命原色,产品隐喻,所在地方的政治约束,社会元素等众多因素,为后期设计适合本产品的特有视觉风格提供依据。

    调研过程中要关注的一些要点包括:

    Ø  企业CI

    Ø  企业内部的视觉设计规范

    Ø  现有系统的视觉设计

    Ø  企业文化

    Ø  用户群体特性

    Ø  操作使用环境

    Ø  操作使用习惯

    有时候,用户会要求你去改变现有产品的视觉设计,那么还需要调研清楚,他们为什么要改变,原来的视觉有什么不足之处。

     

    10视觉设计

    主要参与角色是视觉设计师;标准成果物是《页面效果图》,《视觉设计规范初稿》

    在视觉调研完成后,VI进入设计阶段。在设计之初,PM、UE首先要与VI确定工作内容和计划。

    比如,

    Ø  哪些页面要做效果,这些页面的确定稿分别在何时会提供给VI。

    Ø  哪些组件会被使用到,有多少种组件需要做效果,这些组件何时会确定提供给VI。

    除了页面的效果图,还要形成视觉设计规范的初稿,在这份规范中,要形成视觉设计的各种标准。比如,

    Ø  页面栅格系统

    Ø  视线流

    Ø  框架布局的大小

    Ø  各个元素的大小,色彩,对齐

    Ø  各种留白

    Ø  交互defalt样式,鼠标划过样式,点击样式

    Ø  文字规范,字体,大小

    Ø  图片样式,大小,格式,显示处理等

    在这个阶段VI的成果只能称为视觉设计规范的初稿,这是因为只有在得到sponsor评审确认后,设计的标准才能最终确定下来,成为后续工作的基线和准则。

     

    13裁图及前端实现

    主要参与角色是前端工程师,F.E;标准成果物是《静态页面》,《视觉设计规范》

    前端工程师的最主要工作分为两个部分:

    1、 切图。

    2、 编写页面JS和CSS等实现脚本。

    下面是一个前端工程师交给PM的成果目录结构:

    后续工作将交给PHPer,Javaer完成前后台的渲染。

    到此,整个产品设计工作将完成阶段性任务,后续则是产品开发工程师实现代码,产品测试工程师完成测试和集成,最终发布;产品进入运营阶段。

     

    本文参考了:

    《WebAnatomy:Interaction Design Frameworks that Work》

           By Robert Hoekman,jr.  Jared Spool

    展开全文
  • 软件产品设计

    2019-01-19 16:52:20
    Axture8.0pjb_downcc
  • 比如,前几天跟同事们针对产品设计中“+”功能所运用的场景、展开形式进行讨论,发现这是一个挺有意思的话题。 所以跟大家分享下,我的一些相关思考。   1. “+”的运用场景  我们常见的产品中,采用“+”...
  • 序号 方法 应用场景/说明 1 先使用文字陈述出所有已知信息,再进行精简 界面Label定义 文字描述 2 将信息结构化 ... ...
  • 产品设计师”常用软件推荐
  • 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 -*- ...
  • 数据字典的设计

    万次阅读 热门讨论 2007-03-16 16:50:00
    本文讲解一般数据库系统中经常使用的字典的设计:字典表(Dictionary) 字段名 类型 说明
  • 【Python】存储字典的四种方法

    万次阅读 2020-05-08 21:22:38
    Python存储字典的四种方法0.直接字典和被字符串包裹的字典1.eval + str2.json3....d = {'技术': {'后端开发': ['Java', 'C++', 'PHP'], '移动开发': ['HTML5', 'JavaScrpit']},'产品':{'产品经理': ['产品经理'...
  • 从10个经典工业设计案例来看什么是工业设计,很多人都知道工业设计这个词,但是却不知道工业设计到底是设计什么的。说到这个话题,首先让我们来看一下工业设计的定义(理论知识很枯燥,看完你也是云里雾里,建议直接...
  • 产品设计必读书籍推荐

    万次阅读 2014-10-09 12:05:04
    经常有朋友在微信公众号里问我,对于互联网产品设计尤其是移动产品设计,有没有一些比较值得一读的书来推荐。我结合自己的经验,同时参考了其他一些朋友的答案,把这个问题梳理下。 移动产品设计,目前最主要的是...
1 2 3 4 5 ... 20
收藏数 886,723
精华内容 354,689
关键字:

产品设计