UI转行​做产品

最近有被朋友问到UI设计师怎么转岗产品经理的问题。其实交互设计师、UI设计师平时都会和需求打交道，虽然可能更多的是去理解产品经理给出来的需求，但长期的耳濡目染，自然对需求的管理、产品经理的工作方式以及产品研发流程有一定的了解，所以就算转岗，在某些方面也有一定的优势的。

不过角色的转变也意味着工作职能的转变，比如

工作思维要从执行需求转变为分析和设计需求

毕竟指出别人设计出来的功能缺陷很容易，找问题当喷子每个人都会。当真正需要自己上手去设计功能时候，能否把当初找问题的方式方法都用上，然后去寻求解决问题的方法，这就是学问了。产品经理就是要解决问题的，而不是制造问题。

做事方式要从任务制转变为负责制

对产品经理来说不是说需求输出了就结束了，而是要持续的跟进UI设计、开发进度、测试反馈、运营上线，上线以后还要不断的跟踪用户反馈、数据反馈，以便不断的优化完善，这是一个长期的过程，产品经理要负责到底。

doyoudo项目是去年10月份帮朋友的团队做的一次网站项目，包含前端和管理后台。UI设计资源由甲方来提供。工作内容就是甲方和开发团队之间的桥梁，将甲方的需求梳理分类整理并细化，然后将产品需求文档PRD输出给开发团队，并跟进开发的进度，解决开发过程中遇到的问题，以及应对甲方临时增加或修改的补充需求，协调双方情绪，保证项目有条不紊的进行。

项目从立项到上线历时3个月，在此将本项目中的一点点经验心得分享给大家。

doyoudo是一家在线教育网站，创始人是从36氪出来创业的大佬。网站的主打内容是设计类软件视频教学，通过售卖优质的付费课程来盈利。主要针对的用户是想有一技之长的设计小白、热爱设计并想学习更多技能的业内从业者。

用户画像

需求收集分析

需求的收集、整理、排优先级是产品设计的第一步，也是最重要的一步。需求收集的完整程度，决定着开发过程中的工作总量和工作变量。需求收集的完成度高，则很容易估算工作量和工期，反之，则会出现很多不可控的变量，直接导致工期延期。

需求一般要以目标用户为中心来收集获取，所以需求分为直接需求和间接需求两种。

直接需求：直接与目标用户交流或者分析目标用户行为获得的需求。间接需求：从其他人那得知的有关目标用户的需求。由于本次项目为迭代重构，甲方拥有足够的用户行为数据，不需要再去额外做用户研究的工作，只需要从甲方处了解目标用户的特性即可，也就是间接需求。

之后就是需求分析。需求分析是一个过程，从描述需求、理解需求、分析商业价值、转化为功能需求、初评实现难度、计算性价比，到最后根据性价比和所允许的客观因素（如时间等），选择最合适的功能进行开发。

经过沟通、分析、整理后，最终整理成一个树状图，如下图，基本上理清了本期的需求以及相对应的功能点（完整的需求图太大，右键新标签中打开可看大图）。

doyoudo前端需求

细化功能点

梳理好需求树状图之后，开发就可以估算大致的工期，并且进入搭建架构的阶段了。而这段时间，产品的真正工作才刚刚开始——开始根据树状图中的需求逐个细化功能点，理清功能逻辑和交互逻辑，并输出到需求文档prd中。本次项目里我用了腾讯文档来进行录入需求，其实并不是很好用，只是腾讯文档可以远程多人协作编辑，对于这种多人异地协作的工作来说来方便。

（做前端原型图时因为职业习惯喜欢往里面填图，很耗费时间，后来就直接画线框了）

后端即指内容管理系统（Content Manage System），简称cms。通俗来说就是把一个网站的骨架（指网站的功能结构布局），皮（是指UI设计）和肉（即网站中的内容、图片、音频、视频等内容）分离出来，可以将各个页面连接到一起（交互路径可理解为经络），可以控制页面内容的显示。所有网站的前端内容都是通过api接口从对应的cms中获取的。

通过这个系统，管理员可以更方便的管理、发布和维护网站里的内容。打个比方，站酷要发布一个新的比赛活动，那么它就需要运营人员在站酷的管理后台新建一个活动页面，并上传活动banner以及活动相关信息，然后发布，就可以显示在站酷的前端页面中。再比如说有人在评论区发表了敏感的言论，管理员发现后，会在管理后台的评论管理页面查找这个敏感评论，进行删除屏蔽等操作，或直接给评论人禁言封号。这些操作都是通过管理后台来实现的。

管理后台的原型图直接用sketch做的图，因为相对于axure等原型工作，我更倾向于直接sketch来做。虽然sketch对于表格的绘制不是很方便。

通常来讲，大多数管理后台并没有站酷大神做的那么洋气，没有大片的留白，也没有过多的修饰元素。管理后台的第一要务是要能用，其次是易用，最后才是好看。

能用是指需求文档中的基础功能要有，比如最基本的增删改查四要素；

易用是指交互体验方面，管理员使用某个功能过程中是否流畅，对于各种异常状态和非常规操作是否有清晰的交代和明显的提示，能否顺利的引导用户达到他的目标期望等。交互体验并非仅指动效，因为有动效的作品容易被加火苗，所以很多新人设计师对交互有误解，认为交互就是酷炫的动效，其实动效只是交互外在体现的一部分，而且是很小的一部分。

好看的优先级最低。虽然我也是UI设计师，11年刚入行的时候这个行业其实才刚刚起步，所以有段时间一厢情愿的以为UI设计师把东西做好看就行了，易用性是产品的事情，动效开发不能还原是你开发水平不行，合不合理我才不在乎，我就是要洋气要高端要炫酷，产品说不行？呵，你审美太差。开发说不行？呵，你能力不够。这种所有人都要以美观为中心的观念是错误的，本末倒置的。

拿管理后台来说，大多数还是用的第三方开源的组件搭建，比如ant design、element-ui、iview、muse-ui等，这些UI组件库具有模块化、高扩展性、组件齐全、接口一致、适合多种应用场景等特性，很受开发喜欢。设计师要做的，就是配合产品经理来给这些组件定义主题色以及优化下交互体验即可，不需要重新设计一套组件。

实例分析

做产品需求和做ui设计在某些方面是很相似的，比如都是一个反复求证的过程。在这个过程中不断的剥丝抽茧，反复验证，才能找到最合适的解决方案。给大家举一下doyoudo项目中的实际案例。

实例1 课程列表排序

在新建课程中需要给添加的课程排序，对应的前端页面就是播放列表。有时候添加视频的顺序并不是实际想展示给用户的的播放顺序，咋办呢？这就需要有一个排序功能。最开始的方案是直接如右上图所示，通过一个箭头控件操作课程上下移动即可排序。

咋看上去好像没什么问题，问题解决了。但仔细想一下使用场景，就会发现很多问题，比如这个列表里有20节课，我想把最后最底部的课程放在第一位，那就需要连续点击19次上移才可以，这简直是惨无人道的操作啊。所以最后换了一种思路，用权重来给课程排序，只需要给课程标上一个数字，这个数字代表该课程的权重，数字越小权重越高，位置就越靠前，这样就可以轻松的进行排序了。

实例2 热门评论排序

评论列表中的评论都是以一定的规则进行排序展示的，比如时间、被回复、浏览、转发、点赞等。通常网站对于评论的排序选项有按时间排序和按热度排序（被置顶的除外）。按时间排序容易理解，那么按照热度排序这个热度应该怎么来定义呢？最简单粗暴的方法就是按照回复数和点赞数，回复数和点赞数越高就越靠前。但是这样粗暴的排序存在一个问题，就是随着时间的发展，我们不可能还让这些历史的评论一直呈现比较高的“温度”，我们需要将其冷却下来，这样才能让一些新的评论获取更好的排名。我们知道通过悬赏、赞成、转发、评论等方式可以增加评论热度，但是我们需要找到一定的方法去降低热度，但是一些跟增加热度有关的相反的，比如不感兴趣、举报等，虽然能降低热度，但是很难做到根据时间来降低热度，不然排名的时候很难将新文章有个合理的排名。

这里需要引用一个公式，叫做牛顿冷却定律。是指物体所损失的热的速率与物体和其周围环境间的温度差是成比例的。当物体表面与周围存在温度差时，单位时间从单位面积散失的热量与温度差成正比，比例系数称为热传递系数。即是说，热度其实是会随着时间推移衰减的。曾经热度最高的评论，会随着时间的推移热度可能会变的很低。而曾经的老帖重新被人回复顶起恢复热度，叫做挖坟（贴吧黑话）。

最后的热度结果是以点赞数、浏览数、一级回复数、二级回复数和时间等维度来计算的，公式如下

Math.ceil((likeCount * 256 + viewCount * 8 + 256 * firstReplyCount + 64 * secondReplyCount+100)* Math.pow(Math.E, -0.005 * hour) + likeCount * 16 + firstReplyCount * 64 + secondReplyCount * 16)

（参考文章http://www.ruanyifeng.com/blog/2012/03/ranking_algorithm_newton_s_law_of_cooling.html）

我们最常听到的一句话就是，人人都是产品经理。我们身边也有很多从各个行业专业转行做产品经理的人。其中设计师转产品的人更多一些。因为与产品经理相关的核心竞争力中，设计师有更多一点的优势，比如对用户需求的理解能力，对用户使用产品习惯的理解力，审美能力以及对细节的把控能力。

其中审美能力和对细节的把控力是设计师的天然优势，而前两种则需要在日常的项目中潜移默化的练习。比如在拿到一个功能需求后要问“什么人，在什么场景，遇到什么问题才会使用这个功能？”然后模拟出用户的行为和使用场景，针对不同使用场景来做对应的设计方案。再比如，关注用户体验，对一个功能需求要反复的验证“用户用的爽不爽，学习成本高不高”，然后有目的性的优化交互路径和降低学习成本。

沟通很重要，沟通很重要，沟通很重要

我们虽然经常调侃产品经理，认为产品经理就是自恋狂，入门门槛低，项目中经常会出现程序员或设计师怒怼产品经理的情况。实际上产品经理才是产品团队的灵魂人物。一个产品的产生，是各部门协作的结果，而产品经理（大公司可能是项目经理）则是协调各部门的主力人物，几近指挥官的存在。

不是每个团队里的产品经理都是经验丰富的大牛，所以这就更对团队协作有要求。如果设计师在团队中自认为自己能力高于产品经理，那么完全可以协助产品经理完善产品需求和用户体验；如果设计师认为自己能力不如产品经理，那就虚心学习；毕竟大家在一起的目的是做事，而不是搞山头搞对立。另外对一款产品来说能用是基础，好用是关键，好看的优先级不可能优于前面两个，举个最明显的例子，用户真的认为带弥散阴影的button比纯色的button好吗？这也是为什么dribbble里很多酷炫的设计稿难以落地的原因。良好的沟通可以减少不同部门之间的摩擦，甚至能将摩擦变成正向的动力，来促进产品往优秀的方向发展。学会好好说话，好好沟通，很重要。