任何复杂的软件开发项目，无论前期多么努力地识别风险，开发实施过程中还是难免会出现未知风险。那交互设计师如何应对开发过程中反馈回来的需求或交互相关的突发风险呢？下面将结合最近项目中遇到的一个实例来回答上述问题。《项目管理知识体系指南》（PMBOK指南）中将风险分为已知已知风险、已知未知风险、未知风险。已知已知风险，是已经识别并分析过的风险，不仅知道风险类别，还知道其发生概率和后果，通过根据其风险敞口计入项目直接成本。
已知未知风险，属于已经识别出的风险，但不清楚其发生概率和后果，通常由应急储备来应对。未知风险，又称未知未知风险，是从未遇到过、完全未知的风险，因此也称作突发风险，只有在实际发生后才能识别、分析的风险。未知风险通常无法预防，只能通过提高项目的韧性来减轻发生的后果。我们公司是乙方，在某个银行项目进行到中后期，甲方通过项目经理提出一个新需求见图1，其中有一句话描述为“3.保证金存款：查询时间点客户在我行开立的所有未销户的保证金存款账户信息，包含主账户和子账户的所有信息，包括账号、开户时间、开户金额、余额、存款产品、利率、冻结编号等； 同时支持发生额查询”，在联系不上甲方的情况下，交互设计师如何根据这么一句话描述开展工作呢？只能凭借自己和团队的经验和能力了。输出方案初稿后，和UCD内部同事讨论修改了两轮，和项目内部同事及行方业务老师评审修改了两轮，最后跟行方确认无问题后交接给UI和开发的原型如图2。此后大约一两周的时间，风平浪静，岁月静好~有项目管理经验的人，可能要质疑，项目进行到中后期，为什么还允许需求扩散。我推断：当时的情况是，前期约定的大部分功能都已开发完毕，人力不紧张，加之项目经理读了这几句话需求，判断为就是个简单的报表统计和展示功能，所以决策接纳此需求。 岁月静好一两周后，忽然平地一声惊雷起，万顷风雨加于身。现场开发同事抛来一个问题“主账号能查询么？测试说主账号有钱，但是子账户里面没有钱”，然后我第一反应是，啥？主账号有钱是咋回事？主账号右边的金额数不是下挂在它下面的子账户的余额相加得出的吗？之前评审那么多轮“主账号右边的金额数是下挂在它下面的子账户的余额相加得出的”这个点没人提出质疑啊！他是不是问如果主账号下没有子账户的场景该怎么展示？这个问题之前已经考虑了呀，图2中，第一个大卡片就是只有一个账号的样式，第二个大卡片是主账号下挂有多个子账户的样式。因此，我就回复这位开发同事：要是主账号有钱，子账户没有钱，是不是说的主账号下没有子账户的场景？这样的话，是不是只显示上面的主账户就可以了？还啪给他截了一张图，大红框框把第一个大卡片圈起来，让他直观看到我说的意思。' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
图3.接收问题
结果，刚开始沟通，开发情绪就上来了，给我一顿怼。我立马意识到，我可能并没有get到真实问题。图4.冲突预警
别慌，稳住。使用目标五问法一问一答反复沟通试探，一定能挖掘出问题本源。图2的方案，是根据需求及以往经验做出的界面，如果一个账号下挂有子账户，就用卡片嵌套卡片的形式表达出包含关系，且主账号后面的数字是下面几个子账户余额的总和。但实际上，数据接口拉上来后，测试发现，主账号后面的数字，不是总和，第三方系统返回的数据显示这个地方就是主账号它自己的余额。也就是说，从实际数据来看，要把主账号看成跟子账号一样的存在，同样也要显示它自己的余额，提供余额查询和发生额查询的入口。好，出问题不可怕，只要找到了真实问题所在，就知道接下来应该朝哪个方向继续讨论了。丰田汽车公司前副社长大野耐一曾举了一个例子来找出停机的真正原因经过连续五次不停地发问，才找到问题的真正原因和解决的方法，在润滑泵上加装滤网。如果员工没有以这种追根究底的精神来发掘问题，他们很可能只是换根保险丝草草了事，真正的问题还是没有解决。如果问题传达人或沟通对象刚好是该问题的关键干系人，比如说是负责这块的需求或开发，那他传达任务之前或当下一定已经有了自己的想法。可以先问一下他认为可行的方案，再结合自己的设想往下沟通，才能更快达成一致。如果对方暂时也没有什么想法，交互设计师可以按下面的第三步继续往下推进。如果当前的问题传达人和沟通对象不是关键干系人，那要通过项目经理跟负责这块的需求或开发同事联络上，再往下沟通。前面找到的真实问题是，测试发现，目前的界面上没有展示主账号自己的余额，也没有放置余额查询和发生额查询的入口。综合各方信息，需要在脑海里快速勾勒解决方案，然后截图并快速标注，描绘自己的设想，发给沟通对象继续对齐。
图5.方案草图
本次沟通过程中，开发看到上面的图形化方案，立即提出两个重要问题：1.主次账号这种情况下，没有总余额这个概念了；2.他要把主账号的余额查询按钮和发生额查询按钮放下面。问题1是客观事实，接纳，修改。问题2按钮位置的问题是他的个人想法，需要继续沟通，了解他想要这么做的原因，并跟自己的期望作比对：两个方案做AB测试的话，前者数据是否会很难看？当然，项目进行到这个节骨眼，一般不会允许耗费太多时间在这些细枝末节了，所以上面所有的思考过程，都是在脑海中快速运转的，需要快速调用专业和经验来做出最佳决策的。问题2的处理中，我预判结论大概率是要按照开发少改动的方案来，所以我就会接着想，如果按钮放下面，能做点什么让体验不至于更糟？最后跟开发沟通，如果主账号的余额查询和发生额查询的按钮放下面，按钮文案最好加上一个定语，即“主账户余额查询”“主账户发生额查询”，右上角的余额也改为“主账号余额”，这样即使信息拆散，用户通过完整文案也能判断此处信息的归属。试想，如果用语言描述，能这么快速暴露问题吗？沟通过程中，快速描绘自己的设想，哪怕只是截图标注，都会起到事半功倍的效果。图6.推翻重建方案沟通过程
通过和开发持续沟通，了解到，按钮放上面的话他需要重新写组件，前端框架改动大，可能会带来更多风险。此时，交互设计师就面临一个矛盾问题，基于技术可行性考虑要放下面，但从体验角度上，本来属于主账号的按钮放在子账户卡片的下方，违背了相关信息紧密排列的信息设计原则。是继续要求开发把按钮放上面？开发同事背井离乡在项目现场待了大半年了，压力已快到极限，再给他施压可能会爆发较大冲突，影响未来其他项目的合作。还是同意按钮放下面？体验不好，不美观。当不知道该怎么办的时候，就是向上汇报的时候。汇报给项目经理，如果他赞成重写组件，那就万事大吉了，如果他赞成少改动，万一以后出现行方提出不美观体验不好的问题，他能清楚历史，也好应对。汇报给本部门领导，跟他说一下目前的困境，让领导帮忙决策和推动。需要说明的一点是，如果我们是乙方，这种问题最好不要由交互设计师直接汇报给甲方，而是由项目经理去汇报，因为一旦我们跟行方达成一致意见，回到团队内部技术上无法实现，我们将陷于很尴尬的境地。通过下面的聊天记录可以看到，项目经理并不会就这个问题再去跟行方汇报，而是按照我们内部达成的一致结论来实施。就目前实例中的问题，这样处理确实不会再衍生更多问题了，但如果换做其他问题，不跟行方达成一致，很可能是解决一个问题，又埋下了更多问题的种子。图7.向上汇报过程
经常前面的沟通，最终方案确定下来后，就可以着手修改交互设计原型里的相关界面。比如说上面讨论的是保证金存款账户的界面问题，但活期存款账户存在共性问题，那我们就要把所有相关页面全部调整过来，以便存档后用。修改完毕后，在变更记录里写明变更点，便于问题溯源。最后把修改好的原型连同变更记录一起发布出去，告知项目组成员，以便相关联模块协同。把方案交接出去后，交互设计师可能又要经历一段时间的岁月静好~待开发完成后，还要进行开发效果核验，如果有较突出的体验问题，反馈给项目经理和开发修改，直至交付。如果项目有UE/UI核验清单的话，也可以把这个零散问题的核验结果记录在里面。最后，每处理完一个问题，最好都要快速复盘一下，以史为鉴。像上面一个小的功能模块开发后期暴露出的未知问题：主账户余额是所有子账户余额的总和，所有参与者都对此深信不疑，直到测试阶段，发现返回的数据不是总和，才了解到原来主账户的余额是独立计算的，并不存在余额总和这样的概念。为什么会发生这种情况？一是需求分析和交互设计阶段没有保持空杯心态，太过于依赖经验；二是评审时细节评审不到位，看到一个数字，都默认是总和，没有分析它的数据来源（上面这个案例数据是第三方系统提供的，我们到开发后期才拿到真实数据，这也是导致问题没早早暴露的原因）；三是交互设计师对当前项目的业务需求的理解不透彻。了解了出现未知风险的原因，以后工作中有意识规避造成风险的思想和行为，就能尽早识别出风险，尽早离开墨菲世界到达理想王国。以上案例，就是一个简单问题的处理过程。看似简单，但把处理过程和思考过程拿着放大镜放大，会发现每走一步都需要带着系统思维去思考很多东西。做设计的过程中，总有人说，你想复杂了，问题没这么复杂。其实用系统思维来看待问题的话，任何问题都是一个更大整体的一部分，要想获得解决方案可能需要理解整个系统。打造好解决系统问题能力的冰山模型，愿每个交互设计师面对未知都能从容以对。
