认识达内从这里开始

相信各位设计师在工作中都会遇到这样的问题，自己的原型产品与销售提出的需求不一致，同时开发程序员又将自己的原型产品进行了修改，导致更加偏离了原本的设计初衷，在这样的情况下我们应该怎么办呢?

今天，我们就一起来聊聊关于设计师和产品之间的问题，以及对应的解决方法都有哪些，下面就开始今天的主要内容吧。

在产品和设计工作中，很多时候你无法确定：是该追求实现一个需要花很长时间才能完成的完美产品，还是该首先快速推出产品，再快速迭代?

设计师的担忧是双重的：

发现一个问题后，如果限定要在3个月内就推出相应的产品或功能来解决这个问题，这种时间上的限定会限制可以尝试的想法类型，这可能最终导致我们实际上不是在提供最佳的长期解决方案;

如果我们走捷径、快速开发出产品，可能导致无法开发出质量足够高的产品，从而无法满足市场需求(可能是因为产品比较粗糙、功能也比较少，无法给用户留下良好的第一印象，更无法说服用户喜欢和使用这款产品)。

与此同时，面对这种情况，产品经理的担忧是：为了开发一款“完美的产品”，可能需要花费整整一年甚至更长时间;到那时，如果我们的解决方案并不是正确的解决方案，这就等于我们浪费了整整一年时间才发现我们的产品方向是错误的。

这时，你需要弄清楚三个问题：

对于究竟想要解决什么问题，你们是否达成了共识?如果还没有，首先要达成共识，然后再去讨论解决方案。

你们能否在最重要的事情上达成一致——是追求一个需要花一年甚至更长时间才能实现的“完美”解决方案，还是在3个月内就快速推出一款还算合格的产品，再进行快速迭代?如果选择的是前者，那么你应该提出，首先需要花2-3周的时间来探索各种可能的解决方案，从而能对解决方案有更清晰的认识。在一些情况下，比如当有明确的截止日期时，这时，快速做事可能比花太多时间追求完美要好一些。如果你必须快速推出一款产品或功能，那么就清晰地区分开两条工作流：一条工作流主要负责让我们将3个月内需要完成的工作完成的最好。另一条工作流则主要负责探索我们在一年内能完成的最佳工作。通过将这些问题作为两个独立的问题和工作流进行讨论，你就可以弄清楚如何为做一些长期探索留出一定的时间。

假如你有一个清晰的长期设计/产品愿景，那么问自己：我们通过做哪些小的改变就能解决这个问题?如果你的直觉与产品经理不一致，看看你是否可以通过一些研究或数据让团队有更多用来判断的讯息。

如果发生下面这些问题，你就应该采取行动了

当事情进展不顺利时，你就应该采取行动了。不过需要注意的是：这里的“采取行动”并不是说去怀疑团队其他成员的的动机，或是怀疑其他人的能力。毕竟，团队中每一个人的最终目标都是一致的：为用户开发出好产品。为实现这个目标，我们每个人都有责任找到需要改进的地方，并知道接下来该做什么。

(一)涉及到产品感觉方面的问题

你或者团队中的其他人不能清楚地表达出你要为用户解决的是什么问题，我们是如何知道这是一个重要的问题的，如果成功了结果会怎样。

团队的路线图并没有实际地解决已经确认过的最大问题。例如，你团队中50%的人力都用在解决问题A上，而实际上，B问题是比A问题重要得多。

你不明白为什么产品经理让你设计一样东西。是因为你认为这个设计任务不重要?亦或是这个想法不靠谱?还是因为目前还不清楚我们将如何处理这个实验结果?

就最终产品的高质量标准是什么，你的团队并没有达成共识，导致推出一些你或公司其他人觉得质量非常差的产品。

(二)涉及到执行中的问题

团队花很多时间探讨新的创意想法，但是却不对这些想法进行合理的优先级安排，或是无法将想法转化成具体的计划让大家去执行。

团队不为未来几周或几个月设定明确的里程碑或目标期望，这就导致对于何时需要完成哪些工作这个问题没有明确的方向或紧迫感。

团队有设定目标的习惯，例如何时完成设计工作、何时完成测试等，但经常出现无法按时达成目标的情况。例如设定的目标是在4周内全面发布产品，最后因为各种意外和延迟，用了3个多月才最终完成这个目标。

你的团队不寻找捷径去快速学习和验证假设。这类错误包括：

不思考是否有验证假设的捷径，例如通过研究验证，快速打造一个产品原型，在大规模投入生产之前对它进行测试。

在不理解核心人物问题和假设是否合理的情况下，就在两个平台上同时打造一个产品或验证一个假设。

试图将10个想法合成一个超大的想法，而不是将想法分解成一个个独立的模块，从而快速对每一个想法进行验证。

打造一个另一个团队在过去曾经尝试过的东西，但却不清楚你这次尝试和之前那次尝试的不同之处在哪里。

在你最终回过头来回顾这个项目的时候，你对“为什么这个项目花了这么长时间?”这个问题产生了疑惑。当你有这种疑惑的时候，就说明你的团队的执行力出问题了。

在一个项目介绍后，(不管这个项目是否成功)，团队都没能很好地从中吸取经验和教训，如果让他们再做一遍这个项目，他们也不知道该在哪些方面进行改进。

(三)涉及团队/领导力/驱动力方面的问题

产品经理说话或做事的方式让你感到自己不受重视，或是仅仅将设计视为一种资源;而不是将设计视为同样投身于开发一款伟大产品的合作伙伴。

这样的例子包括：

让你做一些设计改变，或是设计一些看起来很漂亮的东西但却不告诉你为什么要这么设计。

让你设计一个产品经理脑海中想象的东西，而不让你对解决方案进行权衡。

不让你参加围绕团队目标、策略或项目路线图的讨论。

在会议和产品评审中，产品经理代替你去展示你的设计工作成果，而不是鼓励你亲自去给大家做展示。

你的产品经理表现得就像自己是一个“小CEO”一样，好像他们可以命令每个人去做任何事情，而不是让团队聚在一起讨论重要的话题、充分发挥团队中每个成员的优势，从而营造一个共享与协作的工作环境。

你发现自己总是有开不完的会，导致能真正用于设计工作的时间少之又少。这时，不妨问自己这样一个问题：“产品经理是否有办法让我将更多时间投入到真正的设计工作中?”、“我需要参加的会议能否在时间安排上进行优化、从而少占用一点我的时间?”

你感觉自己经常被排除在团队讨论之外，而这些讨论其实是能为你提供一些有助你更好完成工作的重要信息的。例如，产品经理不与你分享一些相关的数据、反馈或研究，或者不邀请你参加一些有关你工作内容的工作评审会等。

产品经理对你或团队中其他成员说或做一些让人感觉是粗鲁或幼稚的事情。Facebook一般是不会容忍这种混蛋的存在的，公司对产品经理在成熟度和良好沟通能力方面的要求要比其他大部分部门都要高。

当你针对团队如何才能更好地工作或更好地协作提出自己的问题或建议时，你明显感觉到这是不受欢迎的做法。产品经理会防御性地回应你的问题、或轻视你的建议、甚至不听你的任何意见。

如果在和产品经理合作的过程中遇到上面这些问题，该如何应对呢?

建议你做下面这三件事：

直接向产品经理反馈。这是最推荐的应对措施，因为这种方式体现了直接和诚实的价值观。即使这么做可能会让你与产品经理有一段艰难的谈话，但是我发现这是与产品经理之间建立信任、长久关系的最有效方式。

将你的想法与你的领导沟通。你的领导可以为你做这几件事：倾听、给你分享一些有助于你了解你看到的东西是否正常的额外信息或视角，并为你接下来该怎么做提供建议，例如告诉你如何与产品经理沟通，或是由你的领导代替你与产品经理沟通。

在某些情况下，可以向产品经理的领导反馈问题。在这么做之前，请务必先和你自己的领导进行沟通。虽然这么做在某些情况下可能是合适的，但是我们还是不希望营造一种背着别人打报告的公司文化，因为这种方式不仅效率低下，还会让大家对同事是否真诚得对待自己心存警惕。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!