<p>鸿影：管理设计的复杂性一直是个令我头疼的难题，「简约至上」这句口号说着轻松，可是实际执行起来却常常发现无从下手。这段时间也重新翻出了几篇和设计复杂产品相关的文章阅读，从中受到了一些启发，再结合个人工作中的一些反思，写成此文。</p>    <p>先举一个撕逼失败的场景（设计对象为B端内容型产品）：</p>    <p>产品经理：我们要设计一个XX模块，需要放的内容有XX、XX、XX……</p>    <p>设计师：（大致设计了个效果后）这么多内容也太复杂了吧！真的都是用户需要的吗？能不能再精简一点，你看这个字段是不是可以少几行，这个功能是不是可以考虑不要……</p>    <p>产品经理：不行，这个内容对用户很重要，这个内容也是，这个功能是我们业务上非常希望做的，一个都不能少，而且我觉得现在放的内容还少了，这里能不能再加一行……</p>    <p>设计师：但我觉得这些地方根本就不会有人在意啊！</p>    <p>产品经理：那是你作为设计师的看法，你又不能代表用户。</p>    <p>设计师：……可我还是觉得这个地方意义不大，上线了也不会有人用的。你能证明它的意义吗？要不要做个用户测试？</p>    <p>产品经理：这个我没办法给你预测，我们现在没有点击和浏览数据，证明不了这点，做用户测试太耗时了，先上线看看效果再说吧。</p>    <p>设计师：……</p>    <p>问题出在哪里呢？其实在这次争论中，双方都没有举出可以支撑自己观点的实在论据。因为既没有数据，又没有用户反馈，于是就变成了站在各自立场上凭直觉判断的主观争论，而本身离业务相对更远、也没有需求直接决策权的设计师，更容易在这样的争论中陷入被动境地，不情不愿地产出自己并不喜欢的业务结果方案。</p>    <h3><strong>设计的论据</strong></h3>    <p>「在拿到切实证据证明人们需要你的产品之前，不要急着围绕价值主张设计用户体验。」——《决胜UX：互联网产品用户体验策略》</p>    <p>大家应该有类似的感受，相比产品功能缺失、开发 BUG、老板的吐槽，日常体验问题的推动要困难得多，而其中一个重要原因就是价值与效果难以得到量化和验证。</p>    <p>之前我一直对产品上线后的数据反馈不太上心，一般都是直接用业务方整理的，对数据埋点也没怎么主动盯过。结果就是想到要去验证产品的上线效果后，才发现几个业务指标根本没法证明体验设计的好坏，想去要一些 UV 转化率、满意度等和体验比较强相关的指标时，却又发现因为埋点问题完全拿不到数据。缺少了数据反馈这个重要的论据，也让我们验证和推进想法的过程变得更加困难重重。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/dd4a9a93501db9e6c70fc5b68d1ad1f5.png"></p>    <p>另一个重要的直接论据是用户反馈，但是对于 B 端产品来说，获取用户反馈可不是像一些 C 端产品那样，问几个身边的同事、或者截图往微信/QQ 群里一发那么容易的事情，邀约、访谈的过程都要更耗时耗力，当遇到快节奏的需求时，并不是很现实。这件事情需要做，但需要在平时、项目前期就积极展开和沉淀下来，而不是临上线了才想起这茬。</p>    <p>再就是一些专业方法的运用，比如用户画像、体验链路梳理等，但这些需要和业务方达成一致，并且细节逻辑充分、可以有效执行应用到具体业务场景，否则就成了形式化的空中楼阁。对于部分业务场景，也可以靠类比 C 端的相似内容来建立同理心，比如 B 端的任务工作台和 C 端的 To Do List 应用，B 端的内容聚合列表和 C 端的资讯应用等。</p>    <h3><strong>间接的减法</strong></h3>    <p>对于 B 端产品，减法需要建立在对业务和用户充分了解的基础上，而当我们进一步了解业务后，就会发现直接的减法很难落地，砍掉任何一个内容和功能都可能对部分用户或业务诉求造成影响。</p>    <p>但是减法并不只有删除，看过《简约至上》的朋友也知道还有组织、隐藏和转移三大法则。在直接的减法失灵时，不妨从更间接的角度去寻找突破。比如说对内容进行更合理的组织归类展示，降低用户浏览的认知负荷；又比如采用「渐进式策略」，循序渐进分优先级展示信息。</p>    <p>另外需要指出的一点是，对于 B 端场景来说，某些 C 端产品所追求的信息架构扁平化并不太适用，一味想降低用户找到内容的操作路径成本，有可能导致的一个后果是大量信息被默认平铺出来，反而让用户在浏览的时候变得无所适从。操作的高效与浏览的清晰，是需要找到一个合适的平衡点的。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/b8395ce62e958a096815dc263f8e295f.png"></p>    <h3><strong>惊喜的触点</strong></h3>    <p>因为 B 端产品的一些特殊性，比如业务逻辑复杂，用户拉新与留存压力低（企业内部强制性使用），往往更难像 C 端产品那样变着花儿给用户带来惊喜，而是优先去满足更多的业务诉求。</p>    <p>但这不意味着设计师就可以放弃对于体验创新这一本职工作的追求，坦白来说，我也一度深陷在业务逻辑里，沉迷于研究和梳理信息架构，觉得逻辑足够清晰合理，就是一个好的 B 端产品了。</p>    <p>但事实上，也有不少 B 端产品在致力于给用户带来一些惊喜的触点，就在上周，我的各种钉钉工作群都被那个新出的「点赞」功能刷屏了，这也让我进一步思考：是否可以再进一步洞察目标用户在产品各个交互触点的情感诉求，在我们的产品里也为他们带来一些不一样的惊喜？于是又开始重新审视现在手里的项目，萌发出了一些之前并没有考虑到的 ideas，不过怎么推进落地就是另一门学问了，啊哈……</p>    <h3><strong>坚持的态度</strong></h3>    <p>于我个人而言，感觉做复杂 B 端产品体验设计，最困难的不在于设计的背景梳理、逻辑推导与方案产出，而是如何在和业务方的沟通中坚定自己的态度。在遇到强势的业务方时，我容易变得态度摇摆、有时急于结束争论也会想「那就先这样好了」，光有方法论和 ideas 是不够的，怎样以良好的 Storytelling 技巧和自信的气场让业务方理解和接受我们的想法也是非常重要的事情。这点是我的弱项，所以也没啥好分享的，如果大家有什么好的建议，欢迎给我留言~</p>    <p> </p>    <p> </p>    <p> </p>    <p>来自：http://www.uisdc.com/complicated-product-design-practice</p>    <p> </p>