当我们讨论交互稿，我们在讨论什么

先给大家看一个场景，不知道是否很熟悉：某产品正在开交互评审会，策划小菲菲和交互媛媛正在组织开发、测试同学参与下一期需求的交互稿评审，媛媛同学对照着交互稿开始逐条讲解，我们下期需要做的功能，交互上有哪些新增/改动。然而进展却不像预想的那么顺利，产品团队内部似乎并没有对交互和部分需求达成一致，开始激烈争论某个需求是否有必要做，某功能的交互逻辑是否应该这样，某个页面的排版是否合理。甚至连开发同学也加入争论，这个功能不合理，那个功能也不合逻辑。原计划一个小时的交互评审会，两个小时过去后，依然有大半需求没有确定下来，大家都有些焦虑，那么问题出在哪里呢。

 

分析原因，不难看出，问题根源在于，我们评审的这份交互稿，并非一份“靠谱的”交互稿，它存在很多的不确定因素，很多的疑问和争议，这样的情况下，我们就很容易陷入无尽的争论，如果勉强开工，等待我们的也很可能是漫漫返工路。

 

1.     在形成交互稿前，需求目标是要完全确定的（例如要完成什么功能，以怎样的方式实现它）。

 

一般来说产品团队都有一定的分工，或者按功能模块或者按端，无论按照怎样的分工，在需求定稿前，产品团队内部都需要对需求进行充分的沟通和讨论，确保在形成交互稿前，需求目标是非常明确的，包括我们需要实现怎样的功能，以怎样的方式来完成，此外还要尽可能多的考虑异常和极限情况。产品团队引到了整个项目的方向，如果不够明确，会导致团队走很多弯路，浪费很多精力。

 

2.     交互稿的主人，是整个产品团队。

  

交互稿的主人，并不是策划同学一个人，而是整个产品团队。在把需求目标转化成交互稿的过程中，需要产品和策划同学充分沟通，以确保交互稿是正确表达需求目标和实现方式的，从而更进一步细化需求。

 

3.     开发同学的早期参与，也很重要。

 

在需求和交互的早期，与开发同学的沟通其实是很重要的，因为一些功能的实现实际上很大程度上一来了技术，开发同学的尽早参与可以帮助产品团队更容易的找到更好的实现方式，尤其是在年轻团队，开发同学的参与可以避免很多后期的问题。

 

4.     所以当我们讨论交互稿时，我们在讨论什么？

 

实际上，当我们进行交互评审的时候，我们讨论的是明确的需求，以及比较确定实现方式。大家的注意力集中在我们需要实现什么功能，如何实现它，至于“它是否合理，是否有必要做”这些问题，应该是会前就已经基本解决的。

网易云新用户大礼包：https://www.163yun.com/gift

本文来自网易实践者社区，经作者戴薇授权发布。