交互从产出需求到输出方案，内部专家评审过完以后去给开发和产品经理们讲解，除去逻辑和流程上的失误，还会遇到很多参与会议人员关注你交互稿表象的问题。这到底是为什么？是你专业能力不过关吗？其实不是。
我们都知道每个人会有不同的喜好，那些在你看来非常完美的细节也许在另外一个人眼里并不那么重要，甚至多余。
所以我们得回过头来想想评审的本质是什么，大家挤出工作时间来听你评审其实并不是对你的界面元素这个怎么摆，放在什么位置有多么好奇或则是在意，只要不出现明显的实现难题，对于开发来说其实并不是最重要的，重要的是他想知道自己接下来可能要花费很多工时里写出来的代码有什么意义，换句话来说就是我接下来要做的这个产品或者是改版解决了什么新的问题和对旧问题的改善，只有这样你才能获得产品和开发的信任，觉得你是专业的，听你的不会是浪费时间和单纯的为了修改而修改。
所以我们开评审之前，就要想好一个理性的，有逻辑的说法。
例如我们是怎么发现这个问题的，这个问题在哪些方面困扰着我们的用户，妨碍着我们的目标，我们需要解决这个问题，然后展示你是如何解决的。
这样的话，我相信大家的思路都会跟着你的解决方案走，这个时候大家提出来的问题可能会更加致命，或者是总监提出更高层次的问题，但是，开评审，要学会引导大家专注于问题本身，而不是一直在说这个功能按钮在这里，点击以后到了哪里，异常流程了会怎么样，这些都应该是写在你的交互文档里面，评审过方案是大家以不同的视角验证你是否解决了某个问题，为什么要这样解决，同时让大家知道接下来这段时间里面要干嘛，而不是大家都基于自己是用户的情景下去找你方案的缺陷以及和竞品的不同点。
所以总结下来，引导大家专注问题本身，场景化、目的化的介绍你的方案。
当大家提出：“为什么不那样做？为什么不像竞品那样做？我觉得这样会好点啊”的时候，把他们拉回到要解决的问题上面，如果现有方案解决不了，那错了就是错了，改！如果你的方案能够解决现有问题，纠结的只是和竞品不同或者是一个按钮的位置，请主动终止这样的讨论。
这是我对解决评审无休止讨论的一个思路，希望能够对读者有所帮助。
网友评论