公海堵船贵宾会 > 公海堵船贵宾会 > 杭州亚信UED交互设计实习小结,初次了解产品

原标题:杭州亚信UED交互设计实习小结,初次了解产品

浏览次数:142 时间:2019-09-14

原标题:大龄产品经理,到底有哪些优势?

大家好,我是IT修真院北京总院第26期的学员,一枚正直纯洁善良的pm

来到亚信实习,已经三个多月了,总结一些实习的心得与收获,以及经验与不足。

     产品经理在不懂的人的眼里不明白是做什么的,或者说经理级别的,好高大上,其实你要是跟别人说你是做app的,那么许多人就了解了。

忘记了是谁曾说过,人每走的一步都算数。此话用来概括本文主题“产品经理的经验有什么用?”亦是可以的。

今天给大家分享一下,修真院官网pm任务1,深度思考中的知识点——产品经理是什么?

这学期是研二的下学期,上学期由于学校的安排,没能出来实习,是很遗憾的一件事。不过上学期把很多毕业论文开题相关的事情做掉了,这学期这方面的压力轻松很多。回到学校先整理了开题报告,改好了简历,之后一边整理完善优化之前的作品集,一边找实习和面试。

  其实通过上述的一个小例子来说,在产品的角度上讲,如果你诉说的对象是公司里其他部门的人,比如开发,测试等等,如果不说清问题的本质的话,是很难让工作继续下去的,因为你首先要一针见血的表述出你想让开发做的需求,或者你跟测试或者交互交代清楚各个功能模块的功能设计,而并不是模棱两可的去说你的需求。

图片 1

1、产品经理是什么?

这个部分我通过和项目经理的对比来阐述;

误区:产品经理和项目经理混为一谈

在知乎上看到一段话觉得很精准;

产品经理——靠想。产品经理是做正确的事,那什么算是正确的事呢,包括但不限于:考虑其所领导的产品是否符合市场的需求,产品核心需求、是否能给公司带来商业价值等方面;

产品经理必须要能够规划整个产品的架构和发展路线,能够确定产品的定位和用户群体,能够预计产品真正的价值和效益。

项目经理——靠做。项目经理是把事情做正确,把事情作得完美,在时间,成本和资源约束的条件下完成目标。

项目经理核心负责项目时间、在规定时间内完成目标才是首要目的;

小结:

所以回到主题,产品经理到底是什么?

产品经理是发现需求、管理需求、设计一套方案一款产品解决需求的职位;

但是不同阶段的产品经理不能一概而论,又分为产品助理、初级产品经理、高级产品经理、产品总监;

我把这部分结合第二个主题,产品经理要做什么来一起讲;

这时候正好杭州亚信在招实习生,于是投了简历,之后收到了面试通知。

  产品周期,产品周期一般分为四个时段,探索期、成长期、成熟期、衰退期。而在探索期到成长期之间版本迭代是非常频繁的,在这里产品不要局限于本次的迭代,而应该在本次迭代成功后,即即将上线的时期,就要筹划下一次版本迭代的内容和时间,并通知各个相关部门。在产品的设计和上线后,一定不要考虑近期的效益,因为产品是一个循序渐进的东西,在你设计时,并不一定要着急去做某个模块的设计或者需求分析,而是从一个大的层面考虑为什么要做这个产品,做这个能干什么,后期如果做了怎么去运营,如果确定好了以后,也不要着急的去做具体的设计工作,而是熟悉你要做这个产品核心业务的业务流程是个什么样子的,它的业务逻辑是什么样子的,在熟悉后要详细的对用户做需求分析,在这里可以运用“五个为什么”的方法去询问,并且用黑箱子的方法去引导用户说出他的核心需求并整理出一份需求文档,(提一句这个需求文档所包含的需求不只是包括使用人群,比如还有老板、客户、运营、销售等等方面的需求综合在一起),并且分析出1-3个核心需求,因为你在做产品的时候不会一下做许多需求,而是围绕自己的核心需求去做功能,(提一句,再最后确认好需求后,再将需求产品化,并且应该讲每个核心需求用官方语言概括出来,这个是后话啦),核心功能确定好以后,要做的就是梳理核心业务流程,画流程图和脑图写需求文档和画原型,当然别忘了在这之前,要好好的跟开发和设计师以及测试好好的进行沟通,告诉他们你是怎么想的,当然啦,你也可以开一个需求分析会,将自己整理的一些想法或者一些草图给开发设计以及测试看,这时要好好梳理业务流程和需求的取舍,因为在好的想法遇到现实也是骨感的,因为得考虑技术的可实施性,以及在交互时会不会产生不必要的麻烦或者对用户造成不必要的操作上的重复或者复杂。

时间过得很快,一转眼我入行做产品已经有7年的时间,在公司里已不能被称之为“小王”。不知什么时候开始,发现很多公司招人的时候都会写上对年龄的要求,类似于90后优先考虑这样的字眼,因此也让我因为年龄有了一种危机感。

2、产品经理要做什么

产品助理:

产品助理是产品生涯的起步,做的事情比较细化和重复性,比如写一些需求文档、说明、文件等,在一些小公司里甚至是要担任测试的一部分任务,但不可否认测试确实是了解产品梳理功能的快捷途径,可以让我们早期见识到一个真正的产品原型规范、包含的内容、标注等,所以修真院的第一个pm任务就是了解测试流程,编写测试用例;在后来的学习过程中我也发现了这么设计的用意,测试用例的模块分级和需求文档有相似之处,可以帮助一个早期的pm快速了解产品的功能和模块划分;

在这一阶段我们要做的就是总结积累,弄清楚产品的工作到底是什么,规范和流程怎样,熟练使用原型工具,撰写PRD文档等,以及培养自己的产品感觉;

初级产品经理:

初级产品经理一般会有自己负责设计小产品或模块,需要考虑的内容也相应增加了很多,如整理需求,根据产品定位将需求分级管理,进行用户调研,如:用户画像、调查问卷、线下访谈等形式;将用户需求转化为产品需求,将产品需求转化为产品功能,画出原型,再和项目有关人员进行评审,将功能落地实现,快速迭代;

这个过程中我们就需要具备推动力,不仅是推动自己进行调研思考,还要推动整个团队的开发和进度,要有足够的依据和调研去说服其他人你的功能是符合市场适合用户的,这是一个产品经理初备的技能;

高级产品经理:

高级产品经理我认为就是接触到战略层的职位了,要根据公司的发展,面向的核心用户,来奠定产品的基调,构建整个产品的框架以及后续的发展;

我觉得高级产品经理就像老大所说的,一个好的产品经理设计出的不只是一个网站,一个app,而是一种商业模式;如果不想只是一个画原型的产品经理,就需要在行业中沉淀下来,真正的去思考当前用户最需要的是什么,垂直于一个领域,多去思考细节;

题外话:

有的东西是产品经理的份内工作,是职责,而还有些东西只是产品需要了解的一些知识。比如我们都说PM需要了解一些交互,需要了解一些运营,但是并不代表PM就是做交互的。

很多刚刚入门做任务的比我们还新的小萌新,大多数都会经历一个沉迷交互无法自拔的阶段,而且劝也没用;我能理解这种心理,毕竟带有交互的原型和高保真看上去逼格非常有,但是我也遇到过开发漏掉了交互隐藏的页面,大多数开发只会看你的原型图设计的功能和标注,而不会点击你的原型按钮,因此可能会漏掉功能;我觉得最直观的方式就是把页面都罗列出来,做好详细的标注才是最重要的;

当然,你可以在闲余时间进行学习高保真等,毕竟技多不压身,但是当你的熟练度和速度跟不上时间要求的时候,就还是老老实实画低保真吧;

产品经理的另一些职责也可以理解为需要的能力,那么结合第三部分来讲;

面试与入职

亚信的面试很严格。在自我介绍之后,我介绍了自己的作品集,之后面试官针对我的作品,提出各种问题,后来总结归纳,大概包括以下几个方面:

对于iOS、Android设计规范的掌握;

可用性原则,主要参考尼尔森的可用性理论;

对于常见的、大型的、复杂的APP的分析与理解;

实际项目经验的积累;

看过的设计书籍。

以上问题,有些知识是我了解的,有些不太熟悉,实际项目经验方面是一片空白。

每一次面试,都是一次检验,查漏补缺,也指明了学习方向。进入亚信之后,一边了解公司业务,一边学习设计规范的相关内容,是我初期的学习内容。

亚信的主要业务和电信行业有关,服务于通信运营商,做B端的软件开发,我们项目组的工作也和此有关。

  当需求分析会沟通完成后,就要确定需求文档和原型设计,这时开发开始进行开发以及交互设计也在进行,产品要做的就是跟进项目的进展,并且不断地在用户或者老板之间游说,因为会时不时的有新的需求提出来,有的可能天马行空,不切实际,但是有的却是可以实现的,这时还是得及时跟开发和设计及时沟通,并且及时更新需求文档,方式有很多种,可以直接过去说或者及时性邮件或者有一个固定平台,固定时间进行内容更新。(当然这都是我个人想的哈哈哈),后面就是测试同学们了,这里产品应该没什么特别要跟进的,因为都是在挑bug,除非是特别触动到业务逻辑层次上再去干预。

本来以为工作久了,经验多是一种优势,但是在产品经理这一行,好像经验多了,年龄大了,在某些公司的招聘中反而成为了一种劣势,身边朋友也不乏有跟我一样有此种焦虑的。这篇文章我就想帮那些大龄产品经理辩解一下,看看大龄产品经理到底有哪些优势。

3、产品经理需要的能力?

1.清晰的逻辑思维能力

产品经理负担着整个产品的功能设计、结构搭建,清晰的逻辑思维能理顺每个关键节点的内容问题,也能快速看懂竞品的产品逻辑理念和逻辑。同时,清晰的逻辑能力对于培养批判性思维也有很大作用。

这个平时可以用产品结构图,流程图等梳理对产品的认识;

2.善于发现并解决问题

我认为产品经理核心职责职责之一就是发现用户需求并给予解决

第一,谁会使用

第二,什么样的场景下使用

第三,预期的结果是什么

第四,是否有替代的方案

3.保持对生活的好奇心

很多产品在功能上或是设计上一些动人之处都来自于生活,好产品源于生活,并能让生活更舒服。何况世界之大,许多陌生领域能给你意想不到的启迪。

产品经理不止是一个职业,而是一种态度。用产品经理的角度去思考我们的人生,用产品经理的角度去过我们的生活,这也是一种很棒的体验。以前在使用软件的时候就是跟着流程走完,什么都不思考;但是现在在使用别的产品的时候就会不经意的留意一下别人的功能,使用感等,然后赞美或吐槽;会发现真的是处处充满了设计感;

4.良好的沟通表达能力

从虚拟框架、流程结构到最终产品的定型出生,产品经理需要把自己的想法准确无误的告诉开发、设计、运营、市场等团队中所有的成员,而良好的沟通表达能力则是重点。

沟通不顺畅轻则导致需求理解有误差,开发出的功能和预期不符而返工延期,重则产品流产;

对于一个项目中的沟通问题还要额外说一些:

(1)能面对面进行沟通就不要通过QQ和微信等文字进行描述;重要的面对面沟通内容要进行录音,像我们平时的会议、需求讲解也要留下音频;

(2)沟通过程中懂就是懂,不懂就是不懂,没有介于二者之间的状态,凡事你觉得你可能懂了的东西,那肯定是没懂;

产品经理不懂装懂会导致后期无数的大坑,我在讲解一个复盘的时候就因为时间较仓促,自以为理解了整个产品,结果啪啪大脸,好多需求自己逻辑还没有理通怎么给别人讲,结果后期就要更改原型,这样会导致在开发心中信任度直线下降顺带收获一波鄙视,所以最好的状态当然是都捋顺明白,如果没能做到,那遇到自己真没想到过的问题就要实话实说;

开发没听懂硬要认为自己懂了就会导致开发出的功能和预期严重不符,等到发现一般就晚了;每一种情况都是大患;

5、对技术名词的一定理解

另外我觉得产品经理还是需要一定的对技术的理解,不用懂具体技术是怎样实现的,也要大概了解完成这个功能所用到的技术的难易程度,需要的时间,我现在依然很迷茫的是有时候设计一个功能,有几种解决方案,但是自己甚至都不清楚开发这个能不能实现,心里就感觉很虚,这样也影响自己的设计思路;

目前我想到的办法就是:在你设计一个功能不太确定是否能实现的时候,去请教开发人员,然后趁机请教不能实现的原因是什么,是技术的限制还是方案的错误,在这个过程中锻炼自己对技术的感知能力;

4、参考文献

参考一:产品经理与项目经理的区别


PPT

视频链接


感谢大家观看

今天的分享就到这里啦,欢迎大家点赞、转发、留言、拍砖~

技能树.IT修真院

“我们相信人人都可以成为一个工程师,现在开始,找个师兄,带你入门,掌控自己学习的节奏,学习的路上不再迷茫”。

这里是技能树.IT修真院,成千上万的师兄在这里找到了自己的学习路线,学习透明化,成长可见化,师兄1对1免费指导。快来与我一起学习吧~

我的邀请码:14671380,或者你可以直接点击此链接:http://www.jnshu.com/login/1/14671380

第一个项目:RTSS-Q2

入职亚信是三月中旬,当时项目组完成了RTSS项目Q1阶段的设计工作,已经进入开发阶段。我大约用了一个多月礼拜熟悉业务,之后就参与到Q2阶段的设计工作当中。RTSS项目是一个移动端的产品,主要功能是个人电信业务查询与管理,有点像中国移动手机客户端,服务于欧洲客户。这个产品在北京和南京都有合作,杭州主要负责数字资产和缴费相关部分,包括余额、充值、转账、积分、优惠券、账单缴费等功能,这些页面大部分都是我设计和优化的,当然经过了带我设计师的指导和修改。带我的两个设计师,一个是龙哥,一个是贞姐,给了我很多帮助。

  后面就是产品上线等等一些事情,其实还得写好多啊,哈哈,比如内测版本先发布一个,范围(如果版本是从0到1),那么可以让公司的人员进行体验,并且及时了解产品的不足和bug。并且个人觉得还是将这些数据化更合适一些,因为数据大多数的时候更让人信服,这时应该再一次开一次会议,或者说产品部门自行召开,在联合其他部门召开,(这也是自己想的,因为产品是一切发起的源头,也应该最明白产品的功能和核心的业务逻辑),等梳理清楚后,在召开部门与部门之间的会议,进行版本的迭代,最后上线。(因为在上线的事情还不是特别的了解和理解,所以有很多情况考虑不到,应该多思考)

  1. 懂得更多的解决方案

设计流程与需求整理。

在接触实际工作之前,我对于项目流程的认知,都来自于间接知识,比如书籍、博客文章,还有自己的设计练习。来到公司之后,实际的项目流程和我想象有一些差别。我所在的亚信杭研UED部门,没有产品经理,业务需求由外部提供,由交互设计师整理,输出excel表格或是Xmind思维导图,没有产品需求文档。我在做交互设计的时候,会有很多困惑。一方面,刚刚接触通信行业,业务规则还不是很熟悉,另一方面,没有明确的需求文档,对于需求的整理就有困难。龙哥也没有给予明确的指引,只是说先按照给出的需求画原型,给他反馈之后再修改。我刚刚参与工作,缺少对于工作流程的思考和把控,就开始画原型。这样的流程很有问题,不明确的需求,模糊的业务理解,加之自己经验不足,只会造成各种问题的原型,于是反复修改。在之后的评审会议上,后台人员根据原型反馈的问题,很多是业务上的要求,这样造成的修改和返工很浪费时间。

在后续的项目中,我一方面提升自己的设计能力,完善原型,另一方面,在没有需求文档时,首先自己梳理功能需求,操作流程,页面架构,和设计师进行讨论,确认之后,再进入到原型设计阶段,将问题提前解决,提升流程效率。

  上线后就是分析产品的有点与不足,并且培养种子用户,增加用户使用量。另外在上线的版本上,依靠设定的诸如数据埋点获得用户真实数据,或者用户对某个功能模块在评论区的评论等等,来作为下一个版本更新迭代的重要依据,(其实在新产品上线之前,其实产品经理本身就应该结合市场和已确定好的特定用户进行新一轮的产品迭代的工作的开展,另外要考虑潜在用户的用户行为,为产品用户数量的增加埋下伏笔,当然更新迭代后没有促进用户数量的有效增加,可以考虑各方面因素,有选择的去掉某个功能)下一个版本上怎么增加用户基数。(具体操作可以根据各方面反映上来的需求,通过双钻设计进行产品的更新迭代)

富有经验的产品经理在行业内工作多年,做过的、了解的产品也比较多。有些产品即使自己没做过,也看过或听别人说过,对很多产品形态和逻辑规则有所了解,所以他们懂的更多的产品实现方案。

功能架构。

在拿到RTSS项目Q2需求之初,在了解分析原有功能架构的基础上,思考新功能页面的架构安排。首先分开了预付费和后付费的功能,预付费用户包含余额、积分、优惠券、交易记录相关业务,后付费用户包含信用度、积分、优惠券、交易记录相关业务,将原有的一个页面分成两个来做。之后根据功能,分成几个模块,完成页面架构的梳理。在功能架构的基础上,根据要实现的功能,进行流程设计,安排功能操作和信息展示,这样后面做起来就比较顺畅。

  好啦写了这么多,其实并没有很工整的去写,只是随笔记一下,让自己复习复习这两天的学的东西。个人观点,欢迎指正。。。。(小白一个)

当要做一个新产品的时候,只要产品终端相同,面对需求,有经验的产品经理能更快速的想到该用何种产品形态。当产品遇到问题的时候也知道该使用哪种方案去解决。

业务流程梳理。

功能架构完成之后,开始梳理业务流程。余额相关业务,包含充值、转账和余额明细查询,充值和转账更多的是功能操作,余额明细查询更多的是信息展示。充值流程:输入充值号码,选择/输入充值金额,确认充值,支付。充值操作在一个界面上完成,需要注意功能组件的位置安排,还有充值号码、充值金额的报错提醒方式。转账功能类似,输入转账目标账号,金额,确认转账。

有些功能是所有产品标配的,这样的话彼此间有互相借鉴性。即使产品类型不同,但有些功能也是通用的,例如登录、注册,基本各个产品都有。如果你之前做过类似的功能,在做新产品的时候就会有更熟悉的应用,即使有些许不同也能更快的上手。

页面注释。

我之前在做设计练习时,是不写页面注释的。现在参加工作,团队成员要一起合作,完成一个产品,对于原型的准确理解十分重要。刚开始写注释的时候,对于注释的内容并不清楚,只是参考之前的页面,加上自己的理解书写,很不规范。后来经过读书学习,还有设计师的指导,才慢慢走上正轨。

  1. 画原型、写文档效率更高

对于多种情况的考虑。

页面上所有的操作,都会根据条件和情景的不同,做出不同的反馈。按钮的默认状态,各种可能情况,提醒和报错,都需要考虑周全。

分享画原型、写文档的技能一直是产品经理圈内长久存在的话题,但不知道大家有没有这样的感触,工作时间久了以后,你画原型,写文档的效率自然会更高。之所以产生这样的结果,客观因素上讲有三因素,第一是熟能生巧,工作经验久,画过的原型,写过的文档多了,自然就更熟练;第二有些产品可能跟你之前做过的产品有些类似,把自己做过的东西再做一遍肯定会更快了;第三点要说的就是对工具的熟练使用了。

设计评审。

在参加工作之前,是从来没有参加过原型评审会议的。在做完第一版页面时,项目组邀请前端、后台相关人员进行评审。评审内容一部分是我做的,一部分是龙哥做的。评审之前,心中还有些许忐忑,不知道会出现什么问题。评审的过程其实还好,主要围绕后台功能如何实现,原型表现是否切合业务规则逻辑进行。由于加入了优惠券支付,对于之前的业务有较多变更,后台人员对于功能实现方式和业务逻辑进行了长时间的讨论,最后才初定了业务规则。优惠券的功能在之后又进行了好几次讨论,每次都费时费力,我们也很无奈。如何节约会议时间,提升会议效率,是公司需要考虑的问题。

如果跟团队磨合久了,很多事情我们只看中结果对过程反而不那么在意。我们不再拘泥于形式,也不注重文档形式,重要的是把话说清楚,把事说明白即可。不过话说的容易,做起来到不一定。想要做到这一点,也还是有几个注意事项的:第一是重点内容不能遗漏,重点的产品需求说明不能缺失;第二是交付给技术人员的产出物要更具可读性,让别人更轻松的了解需求。

设计规范。

这里的设计规范,包含两部分内容,一部分是iOS/安卓设计规范,一部分是项目设计规范。在实习之前,对于系统的设计规范还了解不多。在做设计之初,有不少功能在其他应用中有所涉及,所以也借鉴了其他应用的页面与组件,结合当前功能的特点,加以修改。后来遇到有差异的功能,在自己设计组件和页面的时候,感到自己能力不足,对于各种移动端的视图和控件,没有应用的得心应手,有时候要去翻设计规范,参考其他app的界面布局。我一边做项目,一边学习设计规范,慢慢做页面的时候就熟悉起来。

在我完成一些页面,给带我的设计师看的时候,他说我做的页面和之前已有的页面风格不统一。我在做页面的时候,很多元素是从之前的界面上复制过来的,可是由于之前的界面元素就存在尺寸、颜色、字体的差异,我做的界面就很难和之前的界面统一。在项目初期,项目的设计规范是不存在的,需要在画界面之初预先规定界面元素的尺寸,在项目一个阶段结束的时候,再整理设计规范。所以我觉得,在项目设计规范方面,部门还有提升的空间。

  1. 对产品业务更熟悉

第二个项目:Omni Channel

Omni Channel(以下简称Omni)的项目和RTSS项目是同时进行的,在我做RTSS项目期间,龙哥和贞姐整理了功能需求列表,在RTSS项目告一段落,评审结束时,我们三个进行了页面分工,开始做Omni项目。

对业务的熟悉程度就完全要依靠时间的积累了,很多产品经理可能连续几年都会做同一类产品,这样的话他们对这类产品的业务就会比别人更熟悉。例如一个做过金融类产品的产品经理,他们对于充值、支付、提现这些方面的业务逻辑就会更了解。有的人可能会觉得这没什么,即使一个人不熟悉,但是经过一番调研后也会明白的。且不说有些信息是很难从调研中获得的,即使可调研也没法保证调研的结果就一定真实。况且调研还需要花费不少时间,这对某些公司来说是不愿接受的。

在混乱中开始。

接到设计需求,我拿到的是一个excel需求列表,x-mind信息架构图,还有现有Axure文件中的user case,写着一些业务流程和页面字段。我当时基本上是蒙圈的,都不清楚一共有几个页面,每个页面放哪些内容,贞姐直接问我几天能完成,说时间非常紧,让我尽快做。我想问一些业务规则,可是她说她也说不清,因为这些业务都是后台的,我们只有后台的开发文档,没有具体的业务规则。这又是没有产品经理,没有需求文档的弊端。我们只能先按自己的理解画原型,拿到评审会议上,让后台人员评审,再完善业务规则。这样的设计流程,费时费力,很多时间都浪费在了确认功能和反复修改原型上,真的希望以后能够改进。

我们从调研中一般能明白正常的流程,假设一个流程从充值到支付完成,如果只是充值成功的话这个逻辑可能没什么。但要是过程中出现什么意外,就难以料到了,而在实际工作中一个好的产品经理与一个差的产品经理的能力差别往往就体现在这方面。再拿APP版本兼容性来说,如果一个产品经理做了多年移动端产品,可能在他脑海中已经形成了一个思维定式,每当做新功能的时候,他会很自然的考虑到旧版本跟新版本的兼容问题。但如果一个产品经理没有这方面的经验,就比较容易忽略这个问题。

再次强调设计流程。

既然现实如此,也只能硬着头皮做了。我先理解拿到的设计需求,对照着拼凑出业务规则,开始画页面。好在有几个业务和移动端是基本相同的,就从那几个业务开始做。现在想来,又犯了设计流程错误。在没有理解清楚业务的情况下画原型,只会在后面反复修改。之前移动端没有出现大的流程和架构问题,是因为移动端相对来说业务简单。这次的Omni项目,需求功能有所增加,时间又紧,缺少了页面架构梳理,导致了时间的浪费。在user case中,字段和规则按功能列出,但是一个功能可能通过多个页面实现,多种信息也可能集成在一个页面展示,所以页面架构的梳理必不可少。时间再紧,流程不可少,这次是个教训。

一个人对业务比较熟悉,他在工作中会尽可能完善的考虑到可能出现的异常情况,提前做好各种逻辑判断以及相应的反馈处理,这样就避免了产品上线后因异常遇到更大的麻烦。

纸面原型

之前听过纸面原型的种种好处,可是一直没有用过,以为纸面原型耽误时间,还要在软件里再画一遍。其实纸面原型真的很好,事半功倍,尤其是在设计初期,快速思考,将功能表现为界面,方便快速反馈和修改。在Omni的设计中,一些新页面,新功能,在设计之初使用了纸面原型,效果很好。我之前没有做过Web端的页面,画完纸面原型,再转到Axure软件中,可以顺利很多。

  1. 对产品模式了解的比较清楚

原型迭代。

Omni的原型经过了非常多次的迭代,每个页面都改过五个版本以上,有几个页面甚至有十个版本。版本迭代多的原因,一方面是用户体验的不断精益,另一方面是业务的不断明确与变更。涉及到业务变更的页面,包括Dashboard,详单查询,交易记录,余额明细,优惠券,支付相关功能;涉及到体验精进的页面,包括信用度详情,积分明细,转账,充值等业务。在做设计的过程中,业务需求不断变更,很多时间都用在跟着需求改页面上了,所以很烦。我觉得这一阶段的设计工作,主要围绕在实现功能上,完成“可用”的目标,适当提升“易用”水平,而“好用”的目标,基本无从谈起。不论设计流程怎样,这段做Web端页面的经历,对于我把握Web端交互设计有很多帮助。

如果你跟一个从业多年的产品经理聊天或许会发现,即使他从未做过你所做的产品,但是只要你跟他聊上几句,他就能明白你说的是什么。跟这样的人交流,沟通过程中会觉得特别省事,你一说他就明白。

沟通与合作的重要性。

在进行到开发阶段时,一件事让我更加重视沟通与合作。转账界面的一个功能设计,是在输入对方号码时,输入框下方弹出列表,展示最近充值的10个号码,方便用户进行选择。在前端同事写页面的时候,还和我确认了一下这个功能,我说是有的,我记得还是后台提供历史转账号码数据。后来页面写完的时候,向后台询问接口,才知道后台是没有这个接口的,历史转账账号数据由浏览器的cookies记录,直接显示在转账输入框里。于是前端同事的代码就浪费掉了,我也觉得很不好意思。在原型评审时,这个功能是通过了的,可是我并不清楚是由前端实现还是后台实现。于是我知道,在做页面的时候,除了要知道页面功能能不能实现,还要了解功能实现方式,是由前端负责还是后台负责,另外,在前端同事做页面的时候,也要及时沟通配合,协调前端和后台。因为部门没有产品经理,所以很多事情要设计师自己跟进。

要做到这一点,背后也是有长时间积累的。原因主要有两个:一是因为对方平时对互联网比较关注,经常了解一些互联网资讯或者看一些相关书籍,对于互联网的一些商业模式,一些玩法都比较清楚;第二跟其工作关系肯定也是分不开的,不仅是自己工作的经验,也时常体验一下其它产品。看到的、使用的多了,没吃过猪肉,也见过猪跑。

与视觉设计师的合作。

由于公司业务的关系,Omni项目的页面有很多表单,还有一些数据图形化的内容,视觉效果要求简洁明快,清晰易懂,页面并不复杂。项目之前已经有了视觉规范,所以视觉同事的视觉稿完成的很快。在视觉稿完成之后,我整体看了一遍,风格没有什么问题,一些小的字段、格式错误,和她反馈之后,也没有进行修改,直接告诉前端同事在代码里修改就好了。后来,由于业务有一些调整,原型做出了相应修改,和视觉沟通之后,也是直接反馈给前端同事修改页面。

  1. 对产品功能考虑的更长远

第三个项目:RTSS&Asset 7.7版本

RTSS&Asset 7.7版本,是在RTSS项目基础上进行优化的一个版本。由于涉及到项目跨团队合作,和外部系统进行整合,一些页面需要进行重新设计,也添加了新的功能需求。需要优化的页面,包括积分、优惠券和账单缴费,新增的功能,包括红包、详单、密码重置。

有时候我们在工作中会经常遇到这样的情况,为了能够尽快交差匆匆忙忙的把产品的功能做好了,做了一个临时方案,虽然很快,但是会留下很多隐患。临时抱佛脚,虽然一时交差了,但是却给后面的长期发展造成了很大的麻烦,有些事情甚至是无法弥补的。一个有经验的产品经理考虑问题的方面会比较多,更大程度上避免犯这种错误。

设计流程的完善。

这次做新功能的时候,依旧没有详细的产品需求文档,于是我自己整理相关内容,补充完善。主要内容包括,已经给出的需求简略描述,产品定义(使用人群、主要功能、产品特色),用户需求(目标用户、使用场景、用户目标),之后整理页面架构,思考任务流程。在整理完产品需求时,和龙哥讨论确认,通过之后再进入到原型绘制的过程。

拿我最近遇到的案例来说,我们公司最近想做一个内容开放平台,目的是把我们的内容分发给不同的流量渠道。因为之前我们的内容只面向一个渠道,有些问题压根不存在,但是后续随着渠道数量的增多,很多问题就要考虑的更全面。当时负责这个事情的产品经理很快就找到了方案,让运营人员在内容上架的时候勾选渠道,已勾选的则意味着上架。当时来看这个方案的确可以满足需求,但是很快就遇到了更大的问题,后续如果内容在不同的平台定价不同、上架时间不同,这样的做法显然就不合适了。所以后来不得已又返工,开发了新的功能。

再谈纸面原型。

这次做界面的时候,纸面原型的方法应用的很多,基本上所有新页面都是先画纸面原型,和龙哥讨论,之后修改,方案通过之后再绘制Axure原型,设计流程顺畅许多,设计效率大大提高。

如果当时负责这个事情的产品经理能够考虑的更长远一些,最开始就采用一种为以后可持续,扩展性更好的方案,那么后续再有新需求基于之前的功能加即可,完全不需要再把之前的推倒,重新再来了。

体验设计。

这个版本的积分功能页面,做了很多在体验方面的迭代。积分相关功能,包括三部分,分别是积分绑定,积分转换,积分明细查询。积分绑定与转换功能,是指将第三方商户和Asset账户绑定,将第三方商户积分转换为Asset积分。整体的功能实现并不复杂,也有现有的竞品可以参考,设计的关键就在于,如何引导用户进行绑定与转换,其中也包含商户的展示,操作流程梳理的问题。我自己最早做的页面,将账户绑定和积分转换割裂开,分别实现功能,造成了用户操作的繁琐。之后的第二个版本,将两个功能在操作流程上做了融合,先绑定,后转换,可是对于新用户的引导并不顺畅,对于老用户,积分转换的快捷操作也并不方便。后来又做了几个版本,用户引导和信息展示始终没有找到平衡的解决方案。最后,龙哥对方案进行了修改,将新用户引导和已绑定商户都展示在首页上,实现了功能平衡。我后来觉得,体验设计的精进,要适当打破现有规则,界面设计要贴合用户使用,而不是一味的符合功能逻辑。

要想对功能考虑的更长远,也是基于产品经理对业务的熟悉和积累的做同类产品的经验。有些是自己踩过的坑,再次遇到肯定要避免历史重演。

与视觉设计师的合作。

RTSS项目是在移动端,页面风格和之前的页面保持一致,是一种深黑色背景的商务风格。我将视觉稿和交互稿进行比对,整体的界面控件形式基本一致,只是在页面元素的细节排布上,综合美观程度、信息展示方式等,做出了细节优化。我对视觉设计师的工作成果感到满意。

  1. 对工作中的不确定性早有预估

其他项目

对业务的熟悉程度和其做产品的能力是对产品经理是否优秀的考量。除此之外,沟通能力和处理事情的能力也很重要,别小瞧这方面的能力,很多时候都关系到事情的成败。

负账单转移页面

这个需求来自匈牙利的项目,安排在Omni项目告一段落的时候。简明解释业务,将一个账户下的负账单转移至另一个账户,并选择抵扣欠费和转移金额。业务不算复杂,只有一个页面和一个弹框,主要任务是完成符合业务逻辑的界面操作。我和后台人员了解需求,沟通之后,现场绘制纸面原型,并立刻反馈,修改通过之后,再绘制Axure原型。纸面原型主要解决界面元素与操作流程的相关问题,包括界面内容、表单排列、按钮位置、操作与反馈,之后的Axure原型,完善界面内容位置安排,考虑美观性。在Axure原型完成之后,反馈修改了两次,修改了一点内容,设计就完成了。这个页面以表单为主,前端可以参考项目的其他页面写代码,视觉同事就不需要做视觉页面了。

做这个页面的时候,我用Axure做交互动效还不熟练,动态面板的条件设置和动作设置是我不熟悉的内容,为了表达方案,通过几个页面的跳转实现。做完这个项目之后,我又学习了Axure的动效内容,提高软件技能。

这个项目的收获,主要就在于业务逻辑的梳理与表现,软件技能的提高上。

我们列举一种工作中的实际情况,一件事情可能别人答应你交付工作成果的时间是周五,如果你严格按照这个时间点来执行的话,最后会发现项目没有完成。有一些不确定因素,一两个人不靠谱,一、两个环节延迟,就会造成多个环节延迟,项目完不成就是必然的结果。

无主缴费页面

这个页面的需求更为简单,一共只有两个页面,第一个是无主缴费的查询页,第二个是信息展示与操作页。主要工作,即是输入框与表单内容的排列,简单操作的切换。依旧沿用之前的设计流程与方法,业务流程梳理-纸面原型-Axure原型。

有经验的产品经理会对项目周期有更准确的评估,把计划制定的更靠谱一些:

自我学习

  • 一是因为经验,之前做过类似的工作,对于技术的开发时间心理大概会有预估;
  • 二是工作时间久了,接触的人多了,看人更准,对于合作同事的做事风格有一定了解。虽然别人跟你说的是一个样子,但自己心里也有一杆秤,对于过程中的不确定性提前做好防范会更靠谱一些。

京东页面临摹

为了学习网页端的界面设计,龙哥安排我临摹京东的一些页面,包括首页和购物流程相关页面。在临摹的同时,注意思考业务流程与界面元素的关系,还有界面细节的处理方式,各种情况、操作的页面变化,如何优化用户体验。

在临摹的过程中,我思考了页面栅格系统在网页设计中的应用,相同元素的复用与统一,设计规范的应用,操作提示与反馈。这些内容对我之后的设计工作很有帮助。

#专栏作家#

读书-破茧成蝶

在实习期间,读完了《破茧成蝶——用户体验设计师的成长之路》,并整理了读书笔记。这本书也是一本讲设计流程与方法的书,和之前看的国外的书相比,更加贴近实战和国内特色。系统讲解了从需求分析、交互设计到设计表达、项目跟进的一系列过程,书中内容讲解很细,对于刚刚参加工作的设计师帮助很大。

云瑞,微信公众号:马虎眼,人人都是产品经理专栏作家。原片刻产品经理,6年产品人,走在内容社交产品路上,死磕产品设计,喜欢玩各种APP,玩桌球,打羽毛球,欢迎与大家交流。

后记

在亚信的三个多月,总结起来,RTSS项目Q2阶段像是入门演练,Omni项目是基础练习,RTSS的7.7版本是用户体验的提高。经过项目的锻炼,我逐渐掌握设计流程,提升设计技能,并不断思考,提升用户体验。

作为设计新人,不断学习,不断实践,总结经验,提高自己,日益精进,有所收获。

俊森

2016.6.30

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Pexels,基于 CC0 协议返回搜狐,查看更多

责任编辑:

本文由公海堵船贵宾会发布于公海堵船贵宾会,转载请注明出处:杭州亚信UED交互设计实习小结,初次了解产品

关键词:

上一篇:B站与人民日报成立媒体融合公益基金,视频营销

下一篇:没有了