设计师、产品经理，两个完全不同的角色，但有着一样的目的：利用自己的专业不断的改进产品，让用户更好的接受产品从而达到商业利益上的成功。
第10期我从正面的角度讲述了产品经理的优势以及设计师应该从他们身上学到什么。但事实上并非每个产品经理都是优秀的或者说是难合作的（设计师也一样），他们往往会因为各种原因而抛弃设计师的创意、想法。是的，这让每位设计师都很不爽，就目前的观察来看大致有这么几种情况：
产品经理一言堂
很多环境中产品经理是离商业最近的人，他们要背商业指标，而通常情况下设计师并不背。于是大家更多的把设计师当做“资源方”，认为设计师更多关心的是设计，而且这些设计只是拍拍脑袋想出来的。
如果设计方案正好和产品经理想象的一样，恭喜你，产品经理会当着所有人好好的把你夸一通；如果不一样，不好意思，他们会通过自己的优势（PinDesign #10期有提到）来证明你的错误。作为一个在大多数团队拥有产品话语权的人，你的设计方案很可能就会被毙或者被改得支离破碎。
产品经理干预设计、甚至直接设计
设计师相对于产品经理来说算是一个较新的岗位，很多创业型公司一开始是并没有设计师的。产品功能和页面设计都是由产品经理一个人完成，所以你会看到一批全能型产品经理。随着业务的扩大，公司也希望找到更为专业的设计师来帮助完善产品。
原本完整的产品“控制权”被重新分配，而产品经理由于工作惯性依旧会保持对产品设计的关注。在工作中他们有时会“忍不住”直接画出交互稿，设计师要么在其基础上做“刷油漆”的工作；要么新的设计方案会被他们各种挑战。
人人都是用户，产品经理也不例外
之前有本书叫做「人人都是产品经理」，在互联网公司中它一定可以换成「人人都是用户」。
绝大部分设计师所设计的产品都是大众消费类产品，所以团队中的每个人都可以代表用户，而这个权利在产品经理这里可能会被放大。这几乎是每个设计师都会遇到的问题。
如果你的设计方案没有满足产品经理的预期，那么他一定会戴上用户的“帽子”并通过产品经理的“特权”企图将你的设计方案扼杀在摇篮中。
产品经理设计的老板
在我看来这也许是设计师最悲哀的一件事情了。除了前面会遇到的问题，设计师还将面临一个更大的问题 - 学习与成长。
有很多公司喜欢招聘从 BAT 出来的设计师，觉得他们非常的专业，这其实与他们所处的团队有很大的关系。BAT 这类大型互联网公司的设计团队少则几十人，多则几百人。在如此庞大的专业团队中设计师有机会学习到更多的专业知识，也有机会参与更为全局、系统的设计工作中。这自然也有机会让设计师获得更大的提升。而在绝大部分隶属于产品团队的设计师他们的成长是非常有限的，很多时候甚至只是一个画图的工具。
现实很残酷，设计师不好当。其实即使在 BAT 设计团队也并非所有设计师能够在与产品经理的合作中获得认可。但想要改变现状也并非完全没有办法，一套好的工作流程、方法尤为重要。
简单画了张图，列举了一个项目完整的基础设计流程：
Design Flow
设计前期准备：
01. 需求分析：
上期的周刊中我们也提到，这是设计师的起点。通过对商业需求的分析，我们需要将其转化成设计需求并建立两者间的联系。确保设计方案是朝着解决商业需求进行的。
同步对象：产品经理、设计团队
02. 竞品分析：
我现在将竞品分析分解成了商业竞品和设计竞品两种。商业竞品帮助设计师搞清同类产品的产品背景和设计师思路，设计竞品帮助设计师将每种功能设计的方式烂熟于心，除了辅助设计还能在于产品经理的 PK 中提供支撑。PinDesign 之前有一期专门介绍过竞品分析，这里就不再展开。
同步对象：全员（代指产品经理、开发工程师、运营人员、设计师等最小项目单位）
03. 用户研究：
这是一个非常容易被忽略的环节。忽略的原因其实不是不知道，而是大家觉得没有时间进行完整的用户研究。
用户研究在很多大的设计团队都有专人负责，用户研究员会负责访谈课题、用户招募以及最后结论的分析。可惜除了大的设计团队，很少公司会专门配备这样一个角色来帮助完善产品。但这不代表我们不需要或者不能做用户研究。
前面我们提到过，互联网时代人人都是用户，所以你身边的朋友、同事都可以作为你的研究对象。制定一些核心的访谈话题对他们进行一些调研，你一定能得到不少的信息辅助设计，让你的设计更具有说服力。产品经理再以己代全的时候你可以拿出研究报告来告诉他你为什么会这样考虑。
同步对象：全员
开始设计：
00. 设计规范：
现在越来越多的团队开始建立属于自己的设计规范，这是基于系统平台（Web、App）、业务、用户习惯建立的一套设计标准。有了这个才能让我们的设计有根可循，让设计更具有全局性和系统性。这个话题找机会单独写一篇，今天先不展开。
同步对象：全员
01. 交互设计：
基于前面的分析和研究，我们可以根据需求开始交互设计的工作了。其中有两个重要的点上期也有讲到过，UserFlow 和 SiteMap。确保在现有的商业需求和设计需求下完整的完成整个项目的设计。
同步对象：设计团队
02. 用户测试：
在完成交互稿设计后，一定要进行一轮用户测试。有资源的可以邀请用户测试，没有资源也可以邀请同事进行测试。测试的目的一方面是是帮助自己找出设计方案中潜在的问题，同时也可以通过测试验证设计方案的可行性。当遇到产品经理以自己为用户对方案提出质疑的时候，你的测试报告和用研报告就可以牌上用场了。
同步对象：设计团队
03. 交互评审：
通过用户测试并对交互进行迭代后就要进行交互评审了。这是非常重要的一个环节，建议邀请所有项目成员（如果Boss 参加更好）参加。在评审会上你可以基于前期分析研究的结论阐述自己的设计方案，并将用户测试反馈同步给大家。让更多的项目相关方了解你的工作过程和设计思路。如果与产品经理在方案上出现较大分歧，其他角色也有机会参与到讨论中，给予合理的建议。这对避免产品经理一言堂有很大的帮助。
交互评审的另一个关键作用就是让技术方也尽早参与方案讨论，避免由于技术限制导致设计方案的反复修改。
同步对象：全员
04. 视觉设计：
在确认交互设计方案并确认可行性后，视觉设计师可以介入进行设计。有了前面的共识，视觉部分的工作会相对简单很多。不会再由于过多的交互方案改动导致视觉设计师时间的浪费。
同步对象：设计团队。
05. 视觉评审：
如果可以在这个环节之前还可以再进行一次用户测试，通过视觉对信息层次的处理和行动的引导用户对于信息的理解将有一个新的认识。可以在开始之前准备好可能会被产品经理挑战的问题进行着重的询问。在评审的时候针对性的进行阐述。
同步对象：全员
设计后期：
01. 数据跟踪：
在进入开发后，设计师需要进行对项目中核心功能、争议点进行数据打点，确保项目上线后能够能够通过数据进行项目结果分析。
项目上线后提取相关数据进行分析，看看此次的设计是否达到了商业期望或设计期望。同时将可以需要关注和改进的点形成报告同步给大家。
同步对象：全员
02. 用户反馈：
项目上线后（真实环境）可以再次邀请用户进行用户测试。可以着重就当初设计方案的争议点进行访谈，看看用户在真实使用中的感受如何。
如果这是一款 app，强烈建议要对当前版本在 AppStore 和 GooglePlay 的用户打分和评价进行整理分析。如果有必要，你还可以借助 http://appbot.co** 之类的工具帮助完成分析的工作。
同步对象：设计团队
03. 项目总结：
等待用户测试和数据反馈趋于稳定，我们需要花点时间进行项目结果分析。将整体结果和存在的问题进行归纳总结，在与大家沟通之前我们还需要针对现有的情况制定改进的方案。在总结分析的同时将自己下一步的改进策略同步给大家。
同步对象：全员
这是一个项目设计过程中一个完整的基础设计流程。当然按照这套流程完成的项目并不代表就一定能得到好的结果（还有很多复杂的因素会影响结），但设计的策略和方向不会有太大的问题。最重要的是让项目所有相关人员了解你在使用科学的方法进行合理的设计。
网友评论