杭州亚信UED交互设计实习小结

2019-10-29 21:14栏目:互联网平台

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

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

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

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

图片 1

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

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

面试与入职

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

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

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

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

实际项目经验的积累;

看过的设计书籍。

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

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

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

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

第一个项目:RTSS-Q2

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

  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端交互设计有很多帮助。

版权声明:本文由www.98455.com发布于互联网平台,转载请注明出处:杭州亚信UED交互设计实习小结