需求到功能的设计,如何规划原型?

需求整理出来了,,然后怎么转化为具体的功能点? 有什么具体的方法吗?
回答 15 排序
pengideas 杭州 产品汪

15年底写过一篇文章《产品设计:需求和原型中间隔着一堵墙》,还是比较契合这个问题的,当时也是刚刚做产品不久,经历了一些实践之后的思考,希望能有所帮助


需求与原型之间有堵墙?

很多产品新人,一般都习惯整理好需求之后直接动手画原型,在画原型的过程中再不断的回过头看需求,然后对原型进行修改或增添内容,偶然还要为某个突然想起的需求点在原型上不断打补丁。在这样一种没有严谨思路的情况下,制作出来的原型图不仅容易遗漏数据或功能,更重要的是很容易没有清晰的系统逻辑性和结构性,这样的原型无论是对于开发人员还是最终的用户都是很令人头疼的事情。

也许,出现这种情况的原因与产品经理所要求的产出物有关:产品需求文档 和 产品原型图(没有专业的交互设计师来完成的情况),所以造成了产品新人惯性的思维,完成需求文档之后,马上就去制作原型图,这是个误区。其实需求和原型之间还隔着一堵墙,如果很生硬的翻墙而过必然会造成一定的损伤,我们只有通过一定的手段把这堵墙一砖一瓦的拆解掉,才能从需求顺畅的过渡到原型,设计出的拥有行云流水般体验的产品。


设计规划:需求到原型之间的过渡

拆解需求和原型之间这堵墙的过程,我们可以称之为设计规划,这个过程虽然没有很必要的产出物,但其实无论是在我们的脑海中还是借助一些工具表达,都是需要我们经过深思熟虑、不断对比取舍,对产品设计形成一个严谨的系统性的规划方案,然后最终只是把成熟的方案通过原型图表现出来而已。

那设计规划的过程具体有哪些手段呢,我感觉可以总结为两个步骤、一个思想。两个步骤分别是:组织信息结构、设定任务流程;一个思想是说要时刻通过思考用户场景的手段,来帮助自己更好的融合以上两个步骤的成果,从而制作出优秀的交互原型。

fetch_file0584886fb27732e14a36e332946917ca-picture


步骤一:组织信息结构

首先说第一个步骤——组织信息结构。所有的产品必然都对应的着实体对象,而每一个实体对象必然又对应着不同分类或属性。比如谷歌搜索对应的实体对象可以看为是一个个的搜索结果,而搜索结果有网页、图片、视频等各种分类,同时图片等搜索结果也可以看成是一个实体对象,对应着图片格式、分辨率等不同的字段属性。组织信息结构就是需要将这些实体对象以及对应的分类属性进行系统的组织、划分、归类,从而对产品的所有涉及到的元素有个统筹的认知。

fetch_file97a0f11ec35ab7f57b24742ab57a3d05-picture

以在线购买电影票产品为例,最重要的两个实体对象就是电影和电影院。其中电影按照上映状态可以分为正在热映和即将上映两类(因为是购票类应用,所以排除了那些历史电影),然后每个影片都对应着不同的属性值,包括:电影名称、类型、评分、上映时间、导演、演员、剧情、剧照、预告片、用户评论等等;电影院则可以按照地理位置行政区进行划分、或按照影院品牌等分类方式划分,每个电影院同样可以包含不同的属性值:影院名称、具体地理位置、联系电话、评分、用户评论、距离用户距离等等;然后影片和电影院一一对应后,就会有场次时间、价格、座位选择情况等等信息。

我们首先要对所有这些产品中可能要呈现出的信息进行分析组织,然后要进一步从产品全局的角度进行考量,通过信息重要性等因素出发,进行分类规划则可以初步形成整个产品的导航结构。这个步骤的产出物可以是信息E-R图或者思维导图,不仅能帮助我们整理思路,同时也可以作为文档中很好的沟通资料。


步骤二:设定任务流程

然后是第二个步骤——设定任务流程。用户使用任何产品肯定都是抱着一个目的而来,而为了达到这个目的用户都需要按照产品设定流程采取一系列的动作来不断趋近最终想要的结果。比如用户想到淘宝中买一双跑步鞋,他首先需要打开淘宝页面,然后在搜索栏中输入“跑步鞋”点击搜索,可能会通过选定品牌、尺码等条件进一步筛选,接下来就是一个个查看搜索结果,直到找到喜欢的一双鞋加入购物车,最后就是填写收货地址,确认下单后付款。设定任务流程就是需要将不同的静态信息内容用一条条线串联起来,引导用户无障碍的来实现他们的最终目的。“无障碍”是最基本的要求,强调的是任务可完成,不能设计成一个迷宫一样,用户像个无头苍蝇一样不知道下一步该如何做,所以设定一个无障碍的任务流程也是画原型图之前非常重要的一个步骤。

fetch_filee7c5b6a944d99491e1bf3680ab9ecb18-picture

同样以购买电影票整个流程为例。用户涉及到的任务可能是这样一个流程:选择影片->选择电影院->选择场次->选择座位->确定手机号->确认订单->付款。其中每个任务可能还包含着一些子任务,比如选择影片时用户可能希望能查看影片简介或者查看用户发表的影评等等;选择电影院时可能需要通过行政区县进行筛选、查看影院是否提供停车服务等等。

每个任务都有不同的优先级,可以从潜在用户数、使用频率、重要程度三个维度进行综合考虑。通过梳理产品中包含的任务流程以及主要任务和次要任务的区分,可以明确业务流程,加上第一个步骤梳理的信息结构,进一步可以得出页面流程(跳转逻辑)。可以看到这个步骤的产出物就是业务流程图以及大致的页面流程,从某个角度来看也就是通过一个个的用例将需求、信息、页面串联起来,其中用例所区分的概要层、用户层也就是对应着主任务、子任务。


一个思想:思考用户场景

有了以上两个步骤的准备,我们则可以进入到原型设计阶段。我们先看一下截止目前都做了哪些工作:

  • 组织信息结构——让我们对产品中包含的元素有了清楚的认识并且形成了严谨的结构,在此基础上进一步可以形成初步的导航体系;
  • 设定任务流程——让我们从每一条任务线出发,将用户行为按照次序有逻辑的串联了起;

基于此,制作原型就是将成熟的思考内容,即将这两个步骤的成果融合在一起,用界面形式表达出来而已:信息结构+任务流程=交互原型。在画原型的过程中,我们要时刻牢记一个思想——思考用户场景。

fetch_file27c8655fd032627bc615e4bbd992baa7-picture

站在用户的角度去考虑,可能会在什么场景下使用我们的产品,能够让我们明确在原型交互上如何更好的支持不同场景。比如买电影票时主要存在两种场景:一种是先选择电影然后再选择电影院;另一种可能是先确定电影院再挑选该影院上映的影片。那在产品的信息结构中就很有必要将「影片」「电影院」这两个实体对象放置于应用中(无论是appbar tab,还是bottom tab)平级对立的两个位置。

站在用户的角度去考虑,在完成任务的流程过程中哪些信息是非常重要的,能够让我们明确信息在展示上的重要程度来进行组织分类。比如在选择电影院时,电影名称、地址、以及上映的影片和场次对购票用户来说是比较重要的信息,而该电影院评价、联系电话等其它属性信息则是相对无关紧要的信息,那么则可以把这些信息归集到深一层页面进行展示。

站在用户的角度去考虑,我最常用的功能可能是哪些?能够让我们明确哪些功能可能需要提供快捷入口。比如电商类的应用,在浏览商品的时候随时都有可能需要快速到购物车页面,那么提供一个购物车的快速通道是再好不过的了。

时刻思考用户场景,能最大程度上让制作的原型更具人性化,人性化的另一层含义就是更好用。当然,站在用户场景下能帮助我们考虑的问题不止以上提到的三点,还可以有很多细节的层面,主要的是要养成这样一种习惯,但是要注意不能钻入到自己主观的用户想法中不能自拔,否则很容易设计出“只有你以为很好用的交互功能”。


总结

本篇文章主要探讨了一下在需求和原型之间,我们到底有哪些工作需要做,而不是上来就一头扎到原型图中。当我们在设计规范阶段思考的足够多足够详细,画原型就成很了很轻松很高效的一项内容。

那如何快速制作原型呢,欢迎阅读我的另外两篇文章

如何用Axure快速制作APP交互原型

如何用sketch制作精致的APP原型

匿名
丹哥 Teambition Product Designer

屏幕快照 2017-07-12 下午8.11.59.png

需求有了之后,需要进一步拆解,我自己是按照上图的思路来的,供参考:

1、定义角色

有了需求之后,先抽象角色,把需求按照角色进行拆解,比如「报销系统」的角色可抽象成:

员工、部门负责人、财务、CFO 

2、拆解需求

Story → 功能模板 → 功能清单

我自己是通过「先写 story 再最终细化成具体功能清单」的思路来拆解需求的。之所以先是 story,主要是为了保证其完整性以及便于理解。还拿「报销系统」举例子。角色定义之后,为每一个角色创建 story:

员工:提交审批部门
负责人:一审,通过后提交二审 / 驳回
财务:二审,通过后提交三审  / 驳回
CFO :终审,通过后提交财务打款  / 驳回

Stroy 完成之后,则是抽象功能,抽象的过程,其实就是回答「一定要具备哪些功能,这个 story 才能达成」的过程。

以「员工:提交审批」这个 story 为例:

员工:提交审批

填写报销单标题、填写报销理由、添加证明附件、提交审核

3、着手原型

场景就像是电影剧本,演员有了剧本也就知道怎么演戏了。对于我们而言,有个场景,就知道该如何规划原型,让用户实现目标了。

功能案例就是道具,帮助演员更好的演出。对于我们而言,功能就是帮助用户实现目标的辅助手段。

当然,其实在「着手原型」之前,「优先级」的定义也是非常有必要的,这个题外话了。

希望对你有帮助~

匿名
狂奔中的乌龟 学生 产品经理助理

推荐看一下几乎所有人都看过的书《破茧成蝶》,看到这个问题我首先想到的就是这本书,里面有个章节就是描述如何从需求到界面,@pengideas  的答案已经很棒了,我看完后又复习了一遍,不过在这里我也想在我看完破茧成蝶后我的想法,主要针对以移动端在线购买电影票为例分析设计中任务的设定。顺便让我自己在巩固一下,因此摘抄了一些原文内容

一、从需求到界面,隔着一扇门

在做设计的时候,有一个很不好的习惯,但我们准备了需求文档后就开始试着用软件画界面,后来把界面设计做的很好看,但页面逻辑却一塌糊涂,或者有时候发现设计过程中逻辑关系问题却迟迟得不到更好的解决办法。

从需求到界面,中间其实还隔着一扇门。因为我们忘记了什么是设计规划过程:根据需求来设计相关的信息和任务,通过组织信息结构,引导用户完成任务得到一系列相关的界面草图,然后细化草图为具体界面,在这个过程中考虑如何让用户轻松、愉悦、高效的浏览和操作;最后赋予界面一些魔力,让用户难以忘记使用产品的体验。

二、任务设定

一个界面上如果存在太多功能或内容,会让用户迷茫并且感到不知所措,因此设计师需要站在用户的角度做进一步的优先级筛选,通过设计用户任务,并确定主要任务和次要任务,可以帮助我们快速判断界面上的内容的主次关系。通过梳理信息结构,可以把主要功能、内容组织起来,通过分析任务流程,把剩余的部分整合在一起。

如何抓住用户注意力,引导用户关注于页面的主要任务,则是通过分解用户任务、排列任务优先级、组织合并相关任务等方式,是用户可以专注于主要任务。

分解用户任务

以在线购买电影票为例来描述用户使用过程并且进行任务分解。(不考虑支付流程)

对于在线购买电影票这个功能来说,主要任务流程可以是:选择影片--选择电影院--选择观影时间--选择座位--输入接受电子票手机号--确认订单。通过界面草图把用户完成主行为流程表现出来,接着分解每段主任务下的子任务。

1.jpg

这是基于一定数据分析出来的用户主任务,当然也有一部分人选择周边影院在选择影片,在此我只举第一个用户任务流程为例。从上图中分解出的用户行为可以看出,其实每一个子任务都可以对应到一个产品功能、一个界面模块,接下来就是排列和组合这些功能模块。

排列任务优先级

突出用户的主要任务,就是要对这些子任务所对应功能的优先级进行排列,用量化的标准来衡量哪些功能优先级高。大多数用户需要用到的功能和使用频率很高的功能则需要重点突出。所以通过使用人数,使用频率和重要程度这三个维度来排布优先级。

2.jpg

通过对使用人数使用频率重要程度这三个维度的分析,可以将子任务优秀级分为三个层次。

第一优先级:浏览影片列表,选择要观看的影片,选择观影区域,电影院,日期,场次,座位图,点击确认购票

第二优先级:浏览票房排行,浏览优惠推荐,浏览订票详情

第三优先级:浏览影片简介,浏览影片点评详情,观看预告片(上表格中由于描述不恰当,详情不仅仅是指影片内容还包括影评)

优先级并非是出现的先后次序,而是在页面中的重要程度。这些任务出现的次序,要按照主行为流的次序排列。比如,浏览影片列表一定在点击确认购票之前等。

组织合并相关任务

一个在线购票,包含了15项子任务,需要将这些子任务合理的组织起来,便于用户理解和使用。将次序相同,操作类似,界面类似的任务组合在一起,合并在同一组模块展现在用户面前。由于最终要呈现给用户的是界面,可以直接分解出子任务转化为界面,前期只需要想好每个页面的大致设计用来组织用户任务。

模块一,影片列表顺序 (界面模块如下)

3.jpg

通过选定排列顺序,包括评分排行票房排行以及上映时间排序

模块二,浏览影片列表

4.jpg

模块二包含子任务有优惠推荐影片简介评分

模块三,影片详情

4.jpg

6.jpg

浏览影片详情,包括预告片,用户点评,评论详情

模块四,观影日期

7.jpg

模块五,观影区域

8.jpg

模块六,观影场次

9.jpg

模块七,选座

10.jpg

模块八,输入手机号

11.jpg

模块九,确认购票

12.jpg

组织合并后,每个模块对应了不同的子任务,接下来就需要依据这些模块的优先级,将它们排到手机页面中去。在页面中,对于不同级别的任务,要有不同的展现形式,一级任务一级展现,二级任务二级展现。由于移动端页面的限制,因此一个页面不能过多展示任务,否则用户会对密密麻麻的选项感到力不从心,将主任务一一定下来后接着以合适的形式与分配将子任务穿插进去,在保证用户能完成主要任务同时也满足用户不同需求。使用较强烈的对比突出重要信息和操作来引导用户。

通过上述,可以得到大致的页面原型。如下图

13.jpg

图一展示列表页(上图)

14.jpg

图二展示影片详情页

15.jpg

图三展示地理位置以及影院列表

16.jpg

图四展示影片场次以及时间

17.jpg

图五提示用户所选定场次日期是否正确

18.jpg

图六选座页

19.jpg

图七支付页

以上是将要呈现的大段信息分解并进行模块排列组织,根据“用户看到什么”和“我们想让用户看到什么”为内容模块排列优先级,在根据用户浏览习惯将不同优先级的信息放置到相应的页面位置。遵循“分解-排列-组织”的原则。当这些进行完成后,接下来就到界面设计任务流程当中,通过有效的引导以及优秀的界面逻辑帮助用户完成任务。(看了破茧成蝶里面的内容想自己练习一下关于这方面的知识,学而不思则永远学不到,多做多练才是提升实力的最佳路径。)

匿名
小明的同学 海外/工具/隐私 产品经理

看了大佬们的回答感觉特别专业

然鹅~毕竟野路子产品经理套路也当然要够野才行,那么规规矩矩这么做事,大佬们的逻辑顺着梳理下来未必是你自己的方法论。

个人最大的体验就是,作为一个产品或者说想成为优秀的产品,必须有自己的方法论,而且不断验证不断修正。

废话不多说,简单的来说过去两年里我形成的需求到原型规划的套路很简单

1.确定核心用户场景:谁,在哪里,做什么,会经过大致哪些步骤,本质需求是什么

一般这个过程我会在草稿纸上完成,了解完业务和用户在此场景下的行为以后,在草稿纸上复原,绘制出基本的流程图

最重要的点是,用户的这些操作的目标指向是什么,也就是常说的问题的本职到底是什么,因为大多数时候问题是表面的,那个更快的马的梗,产品狗们应该都知道的。

2.梳理各个分场景下的业务流程:

根据上面的场景,在xmind上梳理出业务流程,每个环节开始有明显的操作和跳转,这时候用户大概的过程应该已经在心中了,此时最好还要想象一下这个页面大致的结构

然后,功能比分先后这个大家都懂的啦,功能源于场景,因此还要对他们排个优先级

建立功能框架,结合优先级,脑海里基本上有了整个产品的思路了。

3.画原型,画原型,画原型!!!

经验告诉我,作为产品小屁孩,真的要多花点时间多看看其他家的产品,无论App、网页还是各种乱七八糟的产品,反正我是啥都看,记得住好作品的也记得住垃圾,甚至记得自己当时的理解,然后再上网扒一扒他们的资料,进一步加深了解。

收~

原型帮助产品理解需求和流程是非常有用的,这时候不需要细致,一般来说我会把业务流程图放在边上,对着流程图一边画一遍构想业务场景,画完一条以后再进一步的调整原型和业务流程,如此反复几次可以很好的修正自己的想法,完善业务逻辑

4.验证,验证,验证

一定一定一定验证!!!

做完原型的线框以后,找到你的目标用户,求证想法,然后进一步修正,这是必须要的~

5.完善

交互的细节

异常状态的处理

提示信息

其他小细节

6.制作成型的文档

一般我是直接axure完成文档的,文档结构就不说了,大家都差不多那些,能说清楚就好了


——————————————————————————————————————

上班偷个懒写的,有大神或者同学觉得还不错的可以一起交流,有人认同的话,再花时间再把回答修缮完整些,好久没有整理笔记上的东西,凭感觉写了~

匿名
蚂蚁呀嘿 快没了 要换了

模块定义

方式:5W2H,what,why,when,who&whom,where,how to do,how much。

思路:先明确你这么分析是为了什么目标。再来逻辑填空。

特性规划

基于用户心理模型(而非业务模型或工程模型),自上向下,结合角色-在本模块内的核心诉求-实体3要素分析。通过分析不同角色的核心诉求抽象出来实体。此时产出特性。

需求提取

用户怎么用产品,是多样的。不同的场景,不同的目标,不同的角色,会产生许多的流程。所以用户流程分析和事件分析组合分析,会更全面些吧。

用户流程分析:画流程图或者脑图(组词方式“操作-实体/角色”)。根据流程分析出来事件,再进行事件分析。或者反过来都可以。互相补充吧。

事件分析:卡片分析,卡片内的事件、背景、场景、情节等多元素灵活组合运用。

以上两个分析走完了之后,怎么归纳总结需求,结合产品架构进一步规划模块架构吧。

需求分析与攫取:基本就是抽象归纳共性。包括信息架构的共性,和功能交互的共性。

优先级分析:KANO模型还是挺好用的,基本型需求、期望型需求、兴奋型需求,无法判断的就扔到无定义需求吧。

需求细化

主要包括3项内容,需求描述、交互流程、样式。需求描述是没有规范的,重点一定要有,该有的也一定有。比如消息提醒的满足方式呀,内容呀。交互流程,要考虑上下文、使用场景、功能和信息层级的设计。样式不用多美观多专业的表达,但信息优先级一定要明确。突出啥信息要明确。

这时候还是要进一步分析的,怎么分析也不算有规范的。用得多的是分析实际使用场景,使用流程图就出来了。基本分析产出成果可能会有大家都比较熟悉的,总体架构图、功能结构图、信息结构图。

匿名
无语凝咽 衡泰信 产品设计

从需求到功能可以根据五导家设计理论去推导。根据业务需求分析对应的业务目的和业务目标,而后将业务目的转化为用户行为,通过用户行为来帮助产品实现业务目标。比如业务需求是:在APP首页引导用户去APP Store去评分,业务目的是提升APP在APP Store的排名,提高下载量,而业务目的是让更多的人到APP Store写好评。这个时候用户行为就是点击”好评“。这个好评按钮就是功能点。

而从功能到原型的设计,最高票同学回答的比较详尽。从信息架构,流程设计再到页面布局。信息架构和页面布局一般用卡片分类法较多,而流程设计从用户使用场景提炼出接触点,梳理接触点后就可以输出流程设计,再根据流程设计输出交互稿。

匿名
诈尸O_O专业户 南方周末网站 交互设计师

要制作一个优秀的后台原型,我认为主要就分为三个部分:

1.对于后台功能模块的结构和页面逻辑有清晰的认识
2.能够熟练的使用原型工具
3.优秀的设计风格和设计规范

1是基础,2是进阶,3则是让原型变得出色的点缀。

  • 那么首先聊聊怎么样保证后台的功能结构和页面逻辑的清晰合理。
    很多人画原型都有一个习惯,就是不管想没想好,直接就开始打开原型工具先拉几个框,或者就照一个自认为非常不错的网站后台开始照葫芦画瓢,这在我看来都是极其危险的。网页后台不同于一般的web界面,他对于功能模块的划分和页面的逻辑要求是非常高的。一方面网站后台的层次结构相比之下要复杂的多,另外一方面,网页后台的功能更偏向于对前端页面的管理,这就导致了功能之间的关联性和引导可能就要弱得多,这样的情况下,如果没有很好的理清后台的结构就开始画原型,那么最后做出来的后台管理系统很可能就是功能的堆积,功能易用性和操作的流程性都很难得到保障。

再来说说原型应该怎么玩
虽然最近各种在线原型工具层出不穷,但是守旧的我还是习惯用Axure+PS的方式来完成高低保真原型的工作,具体到后台管理页面的原型绘制,我觉得一分钱的交互动效都是没有必要的,那么你需要做的只是拉框拉线罢了。

匿名

简单说就这么几句话

  • 构建需求的用户实现场景;
  • 从场景出发分析业务流及功能点;
  • 场景从简,流程从简,功能从简;——这个从简不是指的设计,而是用户接受和用户使用!
匿名
鹿先生 打杂的 产品狗

产品经理的主要职责有两个:

评估产品需求

定义开发产品

这个问题刚好卡在需求转化开发的过程,甚是尴尬。为了避免装逼失败,还得从头梳理一遍。


需求变,产品变

初期不清楚基于什么标准判断需求是否靠谱,失败几率很大。应先明确产品原则,用于指导产品团队做出正确的决策,使相关部门形成共同的价值观,在产品的认知上保持一致。基于共同认知,能最大程度避免部门间相互撕逼,确保产品朝着大家希望的方向走。

有了产品原则的护盾,才能在不违背原则的情况下根据以下提问评估产品需求。当然,仅靠产品经理评估的产品需求肯定会有偏差,及时求助相关专业人员才是明智的选择(又到了考验产品人际关系的时候)。

产品要解决什么问题?(产品价值)

为谁解决问题?(目标市场)

成功后机会有多大?(市场规模)

如何判断产品成功?(衡量指标)

有哪些同类产品?(竞争格局)

为什么我们适合做这个产品?(竞争优势)

时机成熟吗?(市场时机)

如何把产品推向市场?(营销组合策略)

成功的必要条件是什么?(解决方案的前置条件)

根据以上问题评估产品机会。(继续or放弃)

终于得出一堆还算靠谱的需求,如果全部一起做肯定需要3个月甚至更长的时间,所以产品初期建议只规划满足基本需求的产品(MVP),基于MVP概念得出需要开发的需求。


导演!可以切回正题了!需求到功能的设计,如何规划原型?

哎,那个交互设计,界面设计过来一下,帮我画一下这几个需求的原型,下周一给到我。

哦,公司没有交互设计和界面设计啊。


根据产品原则确定原型的基本要素,是要体现安全?还是体现操作的便捷?并参照行业标杆操作,根据自家产品进行修改。

如果是先行者,只能大量尝试不同方案,没有别的捷径。保持以下原则即可,让产品多思考,用户少操作(以达成目的为前提)。


等等,还没下课!

完成原型不代表产品通过验证,未通过验证即开发的产品就是耍流氓!!!用原型征服开发人员和用户(完成以下测试),才能进入开发阶段。

可行性测试:重点让开发人员寻找产品设计里难以克服的障碍,别等到开发中发现问题才改需求,很容易被打的我跟你讲。

可用性测试:突出产品功能特性,让不同用户都能明白如何使用,观察用户如何设法完成必要的操作。

价值测试:可与可用性测试同时进行,重在观察用户是否喜欢这些功能和是否满意功能的实现方式。

匿名
huohuo 环球漫游 测试工程师

很多产品新人,一般都习惯整理好需求之后直接动手画原型,在画原型的过程中再不断的回过头看需求,然后对原型进行修改或增添内容,偶然还要为某个突然想起的需求点在原型上不断打补丁。在这样一种没有严谨思路的情况下,制作出来的原型图不仅容易遗漏数据或功能,更重要的是很容易没有清晰的系统逻辑性和结构性,这样的原型无论是对于开发人员还是最终的用户都是很令人头疼的事情。

也许,出现这种情况的原因与产品经理所要求的产出物有关:产品需求文档 产品原型图(没有专业的交互设计师来完成的情况),所以造成了产品新人惯性的思维,完成需求文档之后,马上就去制作原型图,这是个误区。其实需求和原型之间还隔着一堵墙,如果很生硬的翻墙而过必然会造成一定的损伤,我们只有通过一定的手段把这堵墙一砖一瓦的拆解掉,才能从需求顺畅的过渡到原型,设计出的拥有行云流水般体验的产品。

拆解需求和原型之间这堵墙的过程,我们可以称之为设计规划,这个过程虽然没有很必要的产出物,但其实无论是在我们的脑海中还是借助一些工具表达,都是需要我们经过深思熟虑、不断对比取舍,对产品设计形成一个严谨的系统性的规划方案,然后最终只是把成熟的方案通过原型图表现出来而已。

那设计规划的过程具体有哪些手段呢,我感觉可以总结为两个步骤、一个思想。两个步骤分别是:组织信息结构、设定任务流程;一个思想是说要时刻通过思考用户场景的手段,来帮助自己更好的融合以上两个步骤的成果,从而制作出优秀的交互原型。

 

匿名
Bruce·K 环宇体育 产品经理

看你提的问题,应该是小白吧。刚开始由于缺少产品设计经验,可以直接去参考同类产品对此功能的设计。再者,需求整理出来了,但是你需要再做一件事情,整理所有需求的信息架构,进而梳理出功能流程图,然后根据流程图来做设计。

匿名
一支小红花 MBA中国网 产品经理

1.整理需求

2.做文档,给出需求功能结构图

3.思考需求,怎么实现,在纸上画出逻辑

4.考虑用户怎么用怎么合适

5.有没有更好的逻辑

6.自己体验一遍,检查逻辑是否通顺

以上就是我的步骤

匿名
隔壁的小黑 贤利智科技有限公司 产品经理

这个问题是相当复杂的。不是一种思维或者一两种方法可以解决的,我推荐一本书,《需求分析与系统设计》。

匿名
斯陌菁 乙方 交互设计师

前期进行用户研究,可以得到用户需求及用户画像。通过用户使用场景,用户目标,使用情境,来细化功能点,对页面和流程进行设计规划。

匿名
Andysen 上海携程计算机有限公司 高级产品经理

分三阶段过渡,需求梳理,系统梳理,原型设计。

第一,首先需要搞懂业务怎样进行的,有哪些主要的场景。也就是要做什么事情?其中哪些事情需要在系统上进行?这里梳理的主要是业务关系。

第二,在梳理完一的基础上,进一步根据操作习惯,用户体验,设计架构,设计流程,切分板块和子流程,梳理系统功能。

第三,做好前两个,开始设计产品原型,丰满细节。

匿名

发表评论,请先 登录 · 注册

合作伙伴

诸葛IO
薪人薪事
拉勾
 阿尔法公社
测试兄弟
Growing IO
BOSS直聘
环信
外包大师
CSDN