不能商业化自己的设计师不是好的产品经理

254天前发布

原创文章 / 多领域 / 观点
锦_Jin 原创,如需商业用途或转载请与锦_Jin联系,谢谢配合。

设计师跨行做产品经理的个人经历及经验汇总,文章主要介绍个人发展经历及经验,希望能抛砖引玉~

个人经历


2012年之前,产品经理职业从业人员并不像现在那么多,交互设计师更少,这时期个人工作方式主要领导口述任务需求,直接传达给设计师,由设计师出UI设计稿,直接评审设计稿。不管是业务需求、产品逻辑、技术实现等问题都通过设计稿进行沟通。如果对业务理解不充分或经验不足的情况下,设计稿可能会经历n多次修改才能定稿的问题。


13年,在乔布斯的影响下,“用户体验”这个词是每个互联网从业人员的口头禅,于是交互和用户体验设计进入了视野。要追求好的产品体验,并得到各部门认同的产品设计过程不容易,还要通过设计稿表达,显然效率会很慢。于是在一个新项目中,向上级提出在设计前通过原型表现产品的业务需求、功能设计、交互逻辑及内容编排等,确定后再做页面设计的工作方式。


之后便开始进入交互设计中,刚开始是用Balsamiq Mockups这款原型工具做产品原型,这款工具在表达产品的概念设计是挺好用的。后来需要表现产品更深层的逻辑关系,开始使用Axure作为原型设计工具。通过边做边学地摸索中前行,不断完善交互设计能力,慢慢喜爱上交互设计。然后通过交互设计,涉足深入学习做产品,如产品规划,理解用户需求、功能设计、产品迭代、推进项目及团队之间沟通协作等问题。做产品并不简单也不容易,虽然兼做产品工作5年,但还没信心说自己是优秀的产品经理,只有信心说对于功能型产品经理而言,有够足能力做出符合需求和交互体验好的产品。



对于技术的经历


刚入行互联网时,没经验,做设计会天马行空的去想,完了之后会兴高采烈地拿着设计好的稿去评审,结果可能会是以下情况。


技术:“这实现不了。”


我内心读白是“wc,这么辛苦才完成,实现不了那我不是白做了?不行,要反抗一下。”


我:“为什么实现不了?”


技术:“因为......”


???对技术所描述的原因产生一堆问号,内心读白是“wc,说得这么专业不知道从哪点反抗啊,看来他真的不行。嗯~~~还能再反抗。”


我:“老板~技术说这设计不能实现,你觉得这设计好看吗?”


老板:“这设计看起来挺好的~但是的确不好实现,因为......”


我内心读白是“wc,老板也懂技术,又说了一堆我不懂的东西,再反抗下去就显得像个sb,不行~我不能暴露!”

于是灰溜溜地屁颠屁颠地拿回去修改。


我:“改好了,你觉得这样可以实现吗?”


技术:“实现不了,因为......”


???行~我再改!


“实现不了。”技术都有点不忍心的说到,“你可以看些案例或者有想法先和我沟通一下。”


那时候内心读白是“唉,难受啊!马飞~我是不是不合适做这行呢?”


后来还是坚持了下来,并学习了前端技术的知识,也发现如果不了解技术,是可以通过沟通和积累经验来解决。现在做出来的东西几乎都可以实现,沟通起来像德芙一样丝滑,如下情况。


技术:“这种背景渐变实现不了。”


我:“试试用background:linear-gradient属性和多渐变堆叠,色值我给你~”


技术:“wc,用这种特殊字体做标题怎么实现啊,就算引用这种字体用户电脑没装这种字体也显示不出来啊。

我:“将这种字体和网页一起打包上传,不用装字体就可以显示,字体包删减没用到的字体就不会因为字体包太大影响加载速度。”


技术:“这种点击旋转切换的交互效果不会做...”


我:“我给个案例你看应该就会做了。”


技术:“为什么我写了字体渐变,效果没出来,是不是没有这种效果的?”


我:“我看看你代码...没看到你写渐变颜色啊,是不是写错位置了?”


技术:“......”


每次在做设计的时候,我都会想清楚大概用什么方法实现,这样能保证能够实现,而且对技术的提问也能接得上。当你不了解技术时,平时可以多看多收集一些好的案例,说不定那天会用上。还有在做一些没把握能实现的东西时,还是需要先和技术沟通,再怎么了解其实都没技术那么了解,毕竟不是像他们把头扎进去做那么熟练。想了解前端技术可以去看一下我之前的两篇文章“100%极致实现”和“避免与前端撕X”。


技术懂得越多,对产品设计肯定是有帮助的,就像我非常了解设计一样,如果我来接手一个产品的工作,在设计阶段真的无比顺畅舒服。但是做产品是不是一定要懂技术呢?这个问题我觉得不一定,有帮助是肯定的。如果一点都不懂技术,一方面要从工作对接中积累经验,一方面要靠搞关系的能力。如果总是以个人想象,不管技术的感受,关系又搞不好,那真的凉了。


像之前比较火的一件事,一个产品经理需要程序员跟据用户手机壳颜色自动变App主题颜色,很多人都嘲笑这产品经理,很同情这程序员的难,包括我也是,现在想起都忍不住笑出声来。但是仔细去想,这需求真的不能实现吗?于是我抛开是否是真伪需求、实用价值等等问题,只从实现方法和技术实现方式去想,我想到一种可能行的方法。


从需求上看,App主题跟据手机壳自动变颜色,如果只依靠技术码字是不可能实现的,因为手机壳在背面和侧边,虽然手机可以换主题,但是手机没眼睛,想换都换不了啊。如果那一天能将变色龙的基因植入手机,让手机像变色龙一样跟据环境变,那肯定是一件很酷的事情,但是现在做不到。这样只能从需求上妥协一点,去掉“自动”,只要变颜色就行了,那就未必不能实现了。如用户可以将手机壳拍张照片,上传到App,App通过照片取得1到3种照片中的颜色,然后用户选择要变更的1种颜色,app变更用户选的主题色值代码,这可能是一种容易实现的方式。虽然对于用户来说体验不是很好,没“自动”变那么酷,但是起码可以大概满足产品经理的需求,也调和到技术可以接受的地步,这也不至于互相干架。


对于产品来说,上有老板下有技术,左右为男,夹在中间也不好受。老板说这个需求必需实现,技术说实现不了,产品肯定是优先思考老板提的这需求怎么实现,如果真实现不了,看能不能在需求上妥协,毕竟实现是要依靠技术的。互相抬杠只会影响项目推进和影响工作氛围,对于需要互相合作的关系肯定是有害无利的,长期积怨说不定那一天就干起架来了。搞好关系,技术还是会容忍很奇葩的需求,就算你不懂技术,可能还会摸着你大腿和你协商或解释其中存在的问题。就算再懂也没技术懂,所以不懂技术也没关系,只要能好好沟通还是能挽救。


可能有人会问,“不懂技术你怎么评估需求实现难度和时间进度呢?”那不是有技术在吗,他不会评估难度和时间给产品吗?难道产品码字比技术还牛逼?如果不信任技术为什么要招技术,产品上就行了。以我做设计的角度再说说这问题,设计更主观,只要有眼晴都能对设计说上两句主观的看法,如叫我做个App标志。


产品:“帮忙做个App标志,给你一个上午的时间可以吧,很简单的就像一个小图标,以你的能力一小时都不用啦,给你一个上午的时间有点侮辱你了,做得好看点哈~”


我一般人比较佛系,听到这种情况内心都会笑出声,不过还是能忍住。


我:“eng......只要求好看的话是挺简单的!”


半小时后......


我:“我做好了!”


产品:“wc,怎么这么像苹果的标志,只是把苹果的缺口换成人脸,你打发叫花子呢?”


我:“你不是要求好看吗?苹果的标志世界闻名又好看,我还提前这么多完成,工作效率这么高,怎么就打发你了~”

当然这是我意淫的,关系不是很恶劣的话,都不会出现以上情况。如果产品给我评估紧迫的时间,我会和他好好解释做标志并不是这么简单的,在不能抄袭的基础上,需要考虑标志传达的思想、要想创意、做概念草图、规范设计和怎么搭配等,还可能做出来不一定符合你的要求等不可控因素,一个上午能做好是很难的。如果产品给我评估一年的时间,那当然很高兴能给我这么长时间做。说回正经的,就算我做了这么久设计,让我评估一个准确的时间进度,我也不一定能评估得出来,只能给个大概的范围2天到1个月以上。2天是我估计最快的时间,灵感很快就来了,加上同时符合要求,不需要修改,这种情况就很快完成。如果怎么做都不满意,做1个月以上的情况是有可能的,因为做决策的人不会去深究原因,就算理解原因,看着不喜欢就可以跟据主观想法去否定,“怎么看,总感觉怪怪的。”如果不想出现1个月以上才完成这种情况,想越快完成越好,这就需要互相多沟通,尽可能让设计理解各方的想法,共同朝着一个方向做,这样才能高效完成各方都满意的标志设计。之前我做一个标志,老板没给我评估时间,完成大概花了两个星期,期间我下班睡觉吃饭都在想方案,出了10多稿,开始老板只给了标志需要传达的理念,做出来总觉得不是想要的,我就尝试引导他参与其中,慢慢沟通多了,也给我提拱了他的一些概念方案,就越清楚他想要什么,很快就定了方案。后来老板也开始信任我了,只要我有足够的理由说明为什么这么做就会尊重我的设计,这让我工作更有动力,都是尽最大努力去做好事情,有一段时间比996还狠都感觉值了。


所以并不是不给我评估时间我就会偷懒不做事,只要沟通协调好,都互相信任,让专业的人做专业的事这很重要。技术也一样,产品想要评估难度和时间进度让技术评估,如果时间不允许,在需求上或技术上妥协一些,有时间再仔细完善也是可行的。现在就算我能写页面我也不敢说我熟悉技术,因为没有把头扎进去做,只有设计我才真的熟悉。当然不熟悉可能会被技术忽悠,这也需要依靠个人的职业素养,如果存心想忽悠就算懂也未必能看得出来。尽量多积累协作经验,有空就搞上关系,保持谦虚的态度,几乎不会被忽悠,毕竟有时候可以强人锁男也未必能得到好的结果。

问题解惑


为什么会跨行做产品?

感兴趣:喜欢思考产品的交互逻辑,热衷追求好的用户体验。虽然有时候会被技术吊锤,但是会感觉越锤越勇,这就是真爱吧。

危机感:在找工作时,发现想找到满意的设计工作越来越难,于是尝试找产品相关的工作,感觉可走的路更宽了。

掌控产品设计:在15年时,经历了一次最难忘的设计经历,在一个新项目中,项目经理在没有产品经理的情况下,需要我直接出视觉稿,因为需要给老板评审,让老板看原型会不好看。经历讨论问题-确定结论-出稿-推倒结论-老板评审-再推倒等不段反复的过程,终于得到项目经理认同,到了开发阶段,在开发过程中,项目经理再次推倒走回反复修改的过程,最后直接坐在我旁边,指点让我调元素排版和颜色等事情,那时真的被磨到很没耐心,还好我脾气好,其他人估计就要翻桌子了。可以看出,如果能够有能力掌控产品的设计,就不会出现产品和设计之间的理解差异问题,于是更坚定的向产品渗透。PS:做产品不只是服务于设计,设计只是产品对接的一部分。

最终目的:想做一款属于自己的产品,并且符合用户需求和有发展潜力的产品。


为什么有时间兼顾产品的工作?

经历过的公司,设计工作有时候并不饱和,如果不是两个项目以上或多需求交错设计时,会由于项目上线或没新需求原因,设计工作会停滞,要么自己寻找设计问题修改要么提升设计能力要么摸鱼,有机会我会选择主动申请去协作产品的事情。但职位是设计师时,就需要优先处理设计问题再去做产品的事情,因为设计是本职工作。我能跨越去做产品都是由于没有产品经理或产品经理工作繁忙,而且设计已经停滞的情况下,才会主动申请帮忙做产品的工作。在不影响设计质量的前提下,研究怎么提升设计的工作效率,也有更多时间涉足产品。


跨行做产品会使设计能力下降吗?

不会。只要不完全脱离设计,不会对设计有影响。要保持做有创意的设计,紧跟设计趋势,在工作中实践,自然设计能力会不断提升。


这样做有市场吗?

有。这是差异化问题,举个简单例子,如果我想做一款微信一样的社交工具,没有任何差异化,你觉得有一丝丝机会与微信竞争吗?工作我觉得也是这样,如果没有差异化,谁都可能被取代,更何况做设计的人不少。在分工明确的公司,可能不会需要同时兼顾产品和设计的,但没有产品或交互思维,如果产品出错,设计也会跟着出错,所以就算产品不是我做的,我会在做设计时,思考产品问题,这避免不少反复修改的问题,这也是其中的价值。在商业竞争市场里,企业都是不断保持自己实力,同时拓展更多业务进行扩张,永远只想着自己的三分两亩地,某天就会被别人所吞并。现在做设计的人越来越多,阿里用AI在设计行业也插了一脚,细思极恐(狗头保命),不努力真的慢慢就没市场了。


这样做优缺点是什么?

优点(1):从产品到设计很连贯,在熟悉业务和需求的情况下做设计几乎不会出错或修改,也不会出现互相扯皮的问题;

优点(2):当公司需要时可以临时受命,更灵活调配人力资源,对公司来说难道不香吗?在其他产品经理工作繁忙时,可以协助他们,难道还不香吗?

优点(3):对于个人,觉得能力越大,发展空间越宽广,也能避免过于空闲被裁的风险这是真实存在的机会和风险。

缺点(1):同时兼顾产品和设计,时间周期会变长,在复杂和周期比较短的情况下这种方式不可取;

缺点(2):掩盖设计能力,会被误会。


以上是个人经历和观点,不一定合适所有人,可能有向顶尖的设计方向走,也有向游戏行业方向走的,也有向前端方向走的。不管怎么样,差异化很重要,跟据自身情况,保持独立思考,找到自己想走的路很重要。



产品经验


以下是我个人做产品时,输出需求文档及产品原型的文档框架整理汇总,想形成个人的产品模版,及展示产品的能力,如有缺漏希望指正。

MRD(市场需求文档)

逻辑:通过竞品(不一定有竞品)及其发展过程、现状、数据、趋势、存在问题等描述市场及分析其中可发展机遇(市场说明);再收集目标用户的特征,结合用户场景说明用户需求,并分析总结用户目标及使用动机(用户说明);根据以上的信息,准确描述要做的产品需求及核心目标,并整合业务模式及功能,设计产品示意图。通过以上路线,能让被传达者理解想做什么,要怎么做这一个过程。


文档结构

封面(标志或名称、创建时间、公司名)

市场说明

  -市场现状(找竞品、定位、用户、数据、业务模式、运营策略、盈利模式、产品特点)

  -趋势(研究发展过程、方向及趋势)

  -市场现状分析(通过数据、功能、用户需求等对比分析,发现其中问题)

  -结论(在竞品中总结还能做什么)


用户说明

  -目标用户特征(属性)

  -目标用户需求(需求特点,如需要产品及属性、优质服务等)

  -用户场景(用户需求假设性案例)

  -用户场景分板(跟据用户场景,梳理其中涉及的平台流程及平台特点)

  -用户动机(总结用户目标及影响使用的因素,如匹配度、质量、优势特色等)


产品说明

  -产品概要(产品简介、需求概述等)

  -核心目标(做这产品的目的)

  -业务模式(产品业务结构及流程)

  -运营模式(运营方法、发展路线)

  -产品示意图(主要的设计图)

  -其他事项(需其他部门提拱的帮助及资源)


PRD(产品需求文档)

文档结构

封面:(标志或产品名称、创建时间、公司名)


目录


产品综述

  -版本信息(版本号、内容、时间、编辑人、审批人)

  -项目参与人(需求发起人、审批人、产品负责人、设计负责人、开发负责人、测试负责人)

  -产品概述(简介、定位、目标)

  -参考资料(MRD、原型)

  -术语(术语及说明)

  -时间规划(什么时段什么人需完成什么任务)


产品业务需求及功能

  -业务流程(用户、客户端、后台、中台、第三方平台等交互方式)


  -产品功能结构图


  -产品信息结构图


  -功能列表(客户端、功能名称、描述、优先级)


  -ER图(辅助数据库设计)


  -功能流程(使用某个功能的整体流程)


  -用例图(以角色出发使用功能及反馈结果的过程,需分清角色,如内容作者、普通查看者或特殊VIP)


全局说明

  -权限获取(微信个人信息权限或设备权根)

  -产品权限(登录、未登录、未注册的权限、不同设备互斥)

  -刷新(刷新数量、手动或自动刷新、刷新失败或无数据)

  -加载(内容位置预加载、打开时加载、加载数量、加载失败或无数据、滚动预加载)

  -缓存(缓存对象、数量、缓存客户端或服务端、自动或手动清理缓存)

  -消息推送(推送对象、通知推送或消息推送、用户点击推送正常或失败跳转位置)

  -删除(彻底删除或表面删除)

  -异常(无网络、超时、慢、网络4g和wifi切换)

  -基础弹窗提示或toast提示

  -手势说明


产品页面交互

  -嵌入原型设计文件(页面多时不建议放原型页面,因为篇幅过长,让相关人直接查看原型文件即可)


非功能需求

  -数据收集(埋点需求及维度)

  -接品需求

  -运行及兼容平台

  -其他部门支持


产品原型

  -更新记录(更新时间、版本、内容、模块、负责人)

  -功能结构图、信息结构图、功能列表、功能流程、用例图(没有PRD时,可以再此增加)

  -全局说明(没有PRD时,可以再此增加)  

  -页面原型设计

1、规划页面显示内容、层级、排列关系等;

2、从上至下把页面中的内容进行说明、如展示方式、显示规则、状态、交互逻辑、手势、动效、UI设计要求等;

3、附带字段表,说明字段的数据来源、说明和限制等;


注意事项:

1、没设计基础的不建议使用多种颜色设计原型,直接用黑白灰制作原型,需要重点突出显示的内容可搭配红色使用,这样不会影响UI设计发挥;


2、建议一个功能流程用一张原型页面从开始到结束串连成一条流程线,有助于查看者更直观查看每个页之间的关联,逻辑更清晰且不会遗漏页面,如以下购物车功能,到完成支付的流程向下串成一张流程线,与此条线有关联的页面在右侧展示;


3、不要用文字描述交互逻辑,因为文字较难理解或造成理解错误,尽量使用流程图,能更直观且更易理解其交互逻辑;


4、原型文档最好使用线上共享的方式向其他项目成员共享,不用每次更新都把文档发送一次。我一般使用蓝湖,需求文档、产品原型和UI设计图都可以一起共享,只要刷新就可以查看更新内容,很方便。


以上是本人汇总的产品经验,如有可改善的建议,欢迎评论指教!最后附带一份本人1个月内完成的产品原型链接:https://lanhuapp.com/url/4yzwF

55
- 位站酷推荐设计师推荐 -

声明:站酷(ZCOOL)内网友所发表的所有内容及言论仅代表其本人,并不反映任何站酷(ZCOOL)之意见及观点。

    文章信息

    • 文章标签

    没有新消息