前几天，老大分给我一个任务，是一张产品经理给出的功能内容截图。图里面说，我需要对文件列表添加单项内容的开始与暂停，需要对整个列表增加全部开始与全部暂停的功能。于是，我就想，在列表这里增加开始与暂停的功能可以让用户控制哪个文件开始翻译，哪个文件停止翻译，然后全部开始与暂停的功能能够控制所有文件内容，这样更加便捷得达到了对个别文件进行优先翻译的控制。然后在这个翻译的场景中，一次性可以同时翻译3个文件，那么用户当然可以决定哪个文件先开始，哪个文件后开始。所以对应开始/暂停、全部开始/暂停的功能，文件的状态就有了：正在翻译、已暂停、等待翻译、翻译失败。我还去参考了网易云音乐、百度网盘、优酷视频的下载功能，于是顺理成章的产出了方案。对了，老大说要产出多个方案，于是我想了想，实现全部开始/暂停功能除了增加按钮，还有单击右键的方式，或者什么样的按钮出现方式才是最合适的，于是又勉强做了几个方案，顺便写上这些方案行不通的原因。最有意思的是，写的这些原因的基本是“……情况下，这样做就缺少了入口”“这样做，比较奇怪，不建议使用”等让我自己都有些消化不良的原因。
然后约了大家下午进行交互内审。你猜，交互内审是什么结果？驳回。
交互内审时，我说不清楚情况，于是喊来产品经理，在老大为首和产品经理互动后，确认了增加开始/暂停的方式只是为了让用户可以自己决定优先进行哪些文件的翻译，而开始/暂停的方式针对翻译的情况并不是最后的解决方案。产品经理也表示不应该写功能，并连连表示抱歉。于是，最后是我要修改交互稿收尾。
你看这个过程中，我犯了什么错？
第一，拿到任务，惯性思维看功能。第二，看到功能，想当然虚拟并认可需求。第三，死板参考其他同类形式的功能。
我做的比较好的地方是什么？
画了多个自己都不认可的方案，并附上了不可以的理由。😂这妥妥的为了设计而设计，然后拿错误情况当学习材料思考了。
最后老大和产品经理的互动解决了什么问题？
第一，明确了需求：方案背后的根本原因是当需要翻译的文件量大时，要给用户主动权，让他们决定优先翻译哪些文件。第二，明确了产品经理给出的功能方案复杂化了问题的解决办法。
那么怎么做才能避免这种交互稿被打回重做的结局呢？交互稿是针对问题的解决方案详细阐述。问题从哪里来？问题来源于用户需求或者业务需求。需求来源于哪里？需求来源于用户在使用或者企业在确定方向时要达成的目的。如果交互稿做得没有问题，那首先一开始对达成目的、需求的认识方向就要有，而且这个大方向本身要能立得住脚。在这个方案从哪里来的问题上有答案后，再谈怎么做这个方案，再逐一解决遇到的问题。
在上面的故事中，我们接到的需求可能是产品经理自行找到的一种解决问题的方案，或者是模棱两可的需求说明，或者是没说清楚情况的场景，等等。遇到这种不清楚的情况时，多反向推问几个为什么？为什么要做这样的功能？为什么用户会有这样的需要？然后再确认需求与功能的合理化：这个需求什么时候会产生，高频低频还是一般，在真实的世界中是真的存在么？在这个反向推问思路中，可以采用场景思维、问题导向思维、用户目标导向思维等。当这些关于需求、要解决的问题等内容弄清楚之后，开始思考什么的功能或者方式可以解决这个问题，这个过程涉及的面可大可小，需要保证每增加或删除的内容都是有理有据的，还有一些是别人会想到但是站不住脚的功能，虽然不需要在交互稿中表现，但是要做到心中有数。
还有，我产出了那么多我自己都否定的方案，有什么意义呢？如果是要投入到开发阶段的话，这些方案当然没有意义，但是对你自己而言，也许可以检视一下所理解的交互方式有哪些，说不定能锻炼你个人的交互套路熟练程度。尽管会有这么一点点的好处，但其实不建议花功夫做这些，不要为了设计而设计，不应该为了出方案而出方案。
好了，这是工作几个月以来，第二次在需求方面栽跟头。下次再有需求或功能来，先问为什么要做这个功能，解决了用户的什么问题，什么情况下这个问题会出现。针对这个问题、场景，这种解决方案怎么样，其他解决问题的方案还有么？
181205 爽 记
