不能商业化自己的设计师不是好的产品经理
设计师跨行做产品经理的个人经历及经验汇总，文章主要介绍个人发展经历及经验，希望能抛砖引玉~
个人经历
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
