你是否也遇到过这种困境？屏幕上堆满了设计好的界面，但你其实并不清楚这些元素与系统里其他部分到底有什么关联。每次从需求评审会上离开，手里攥着的指示模模糊糊，甚至跟上一次聊的内容对不上号。你心里明白，只要团队对“用户到底需要什么”这件事多一层共识，大家就能少走很多弯路。可现实是，研究经费和时间都不太允许。
直接开口向团队要更多接触用户的机会，这种感觉往往让人犹豫。许多人心里会浮现出《雾都孤儿》里奥利弗小心翼翼端着碗请求“先生，我还想要一点”的画面。
问题就在于怎么开口。等待领导和产品经理主动重视用户研究，常常要碰运气。这里的诀窍恰恰在于换一种方式提出请求。你需要让利益相关者自己揭开那些高风险的假设和被遮盖的复杂性。当他们自己意识到，在几个关键问题上大家的看法根本不一致，或者某些隐藏的依赖关系从来没人认真梳理过时，他们就会变得和你一样迫切地想要寻找答案。也就是说，你要让他们觉得“这件事非做不可”是他们自己的想法。
实现这种转变不需要长篇大论的提案，也不需要搬出几十页行业报告。有一种协作办法能把团队里潜藏的认识偏差和知识缺口摊在桌面上，让大家共同面对。办法的核心只需要团队一起回答两个简单的问题：
第一，“我们所面对的对象到底有哪些？”
第二，“这些对象之间，究竟是一种什么样的关系？”
这两个问题对应一套名为ORCA的方法论里最初的两个步骤。ORCA是“对象、关系、行为召唤以及属性”这四个英文词的缩写。它描述了一种用于打造坚实对象导向型用户体验的流程。在具体实践中，ORCA是一套反复迭代的方法，专门用来把用户研究里的发现，逐步转化成一个优雅的结构性基础。这个结构本身并不等于界面设计，但它决定了界面上的信息该怎么组织，交互逻辑该怎么流淌。对于用户体验设计师来说，这套方法论能让协作更顺畅、效率更高，也更容易找到工作的策略意义。
整个ORCA流程包含四轮迭代，细分下来总共多达十五个步骤。每一轮都会让团队对“对象”“关系”“行为召唤”“属性”这四样东西的理解更深一层。但这里有一个很要命的前提：这个过程极度依赖原料的质量。糟糕的信息输入，只会导出糟糕的结构性结论。
要想让ORCA流程在最后一轮产出一个经得起测试的原型，整个过程里喂养它的用户研究必须是扎实的。话又说回来，如果你手头正好缺研究资源，那么流程开头的这两个步骤反而能派上另一种用场。它们可以帮助你去“兜售”对研究本身的必要。
可以把ORCA流程想象成一道横在研究工作和界面设计之间的关卡。如果你已经握着充分的研究结论，那就可以顺着这道门顺畅地进入具体设计层面，就像乘着虎鲸优雅地滑入水面。但假如你两手空空，强行推开门往里走，这个流程本身就会把你挡回来，弹回研究阶段去。它不会让你糊弄过关，而是交还给你一张清单，上面列满了各种具体的、悬而未决的问题，等着你去向用户求证。
很多项目之所以后期陷入混乱，并不是因为大家知道得太少，而是因为大家在很多假设上太笃定，偏偏这些笃定经不起推敲。马克·吐温那句老话说得直白：让我们惹上麻烦的，往往不是我们不知道的事，而是那些我们深信不疑、但事实压根不是那样的判断。
在ORCA的头两步，也就是对象发现和关系发现这两个环节，团队认知里的黑暗角落会被强光完全照亮。平时大家随口一提的概念，被要求明确写下命名时，才发现有的人管它叫“订单”，有的人心里默认的是“工单”。平时被地毯盖住的那种固有复杂性，也会在梳理对象关系时被一把掀开。
在小组协作时，这种认识差距会非常直观地暴露出来。随着团队在白板上标出两三个核心对象，尝试画出它们之间的连线，并且争论“这个对象能触发那个对象的哪些变化”时，问题自己就跳出来了。有人会发现自己一直默认存在的某个关联步骤，在另一个人眼中根本就不成立。而有些在讨论里被频繁绕开的模糊地带，也会因为要强行为它命名、为它摆位置而变得无法回避。
这恰恰就是团队动力的转折点。一开始只是你一个人在建议“咱们最好去问问用户”，现在变成了整个房间里的人都在举手提问：“等等，用户真的会这么理解这个流程吗？”以及“我们得去找几个用户聊聊，确认一下这里。”这时候，推动用户研究不再是一个设计师的请求，而是团队为了继续往下走，必须采取的集体行动。
这个过程不制造焦虑，但会制造清晰。它不给压力，但会给方向。它没有强迫谁认错，而是用一种结构化的方式告诉大家：你看，这里有一堆问题，答案都不在咱们这个房间里，而在真正的使用场景那边。而这两个简单的问题，就是打开那扇门的第一把钥匙。
热门跟贴