以前实习做ToC移动产品设计时，我的手机里总是装着一大堆市场上的竞品应用，不愁没有可以参考借鉴的对象，但却也容易陷在对手的思路里亦步亦趋，甚至被对手并不合理的解决方案误导。最后出来的方案，虽然在交互细节上有一些微创新的亮点，但整体上摆脱不了给人「同质化」、甚至「抄都抄不好」的印象。
而现在，不知不觉我已经做了大半年的ToB产品设计（Web端为主，也涉及到少量的桌面客户端与移动端），主要是数据与商家类型的业务。一路遇到的挑战非常多，毫不熟悉的业务背景（第一次看到某Prd时就像看到了天书一样，一大堆看不懂的专业名词），完全陌生的用户群体（无法轻易把自己代入，无法没事就拿手机玩自己设计的APP发现改进点），逻辑复杂的信息架构（虽然我在这方面有些天赋，但毕竟还是个新人，感到头疼、思维混乱不可避免）等，而其中最让我在一开始感到无所适从的挑战，则是「基本找不到竞品参考」。
原因挺合理的，一方面ToB的产品用户群体具备一定特殊性，竞品本身就没有ToC产品那么好找，即使市场上存在性质类似的产品，作为普通用户想访问和使用也不是那么容易；另一方面和「电商」业务相关的部分，以公司的行业地位，也意味着PD提出「做一个行业标杆的产品」的要求并不过分、反而合情合理，去抄别人未必做得多好的设计反而Low了。就这么在「无竞品」的环境下扑棱了一段时间，赖公司各位前辈同事的帮忙和指导，也算顺利上线了大大小小几个项目，本文就总结下我对设计这类产品的一些浅薄感想吧。
回归本源，吃透业务再谈设计
在阿里，无论是平时的工作还是听其他部门的分享，我最大的一个感受是设计师的工作相比「用户体验设计师」更像是「产品设计师」，非常强调「业务思维」与「数据驱动」，而只会从用户感受的视角出发，对业务背景与目标不能深入理解和阐述清楚、不能平衡好商业用户技术冲突的话，无论内审还是外审都很难说服别人接受自己的方案。
而ToB产品的业务背景相比ToC，很多时候要复杂得多，我在之前没有任何了解时看Prd、参加评审的感觉完全是「懵」的，平常也时不时会被产品和运营嘴里冒出来的专业名词搞得一头雾水。这就意味着需要更多的设计前期准备工作，需要花更多耐心硬着头皮去啃PD的文档说明、沟通相关业务背景、梳理产品架构与流程等，一开始可能有些痛苦，但如果因为「枯燥」、「没时间」、「成就感低」之类的理由轻易跳过或蒙混过这些步骤的话，后期可能要花大得多的代价来「填坑」。
以一个问题从发布到解决的流程设计为例，我在第一版方案里我以线性思维的习惯（当时时间也很紧，没有仔细考虑太多），按照发布-受理-（转交）-完结的步骤简单设计了各环节的操作界面，但是上线后就发现了不少问题，陆续有用户反馈爆出各种遗漏、未考虑全面的需求场景，而本源就是前期对流程的考虑太简单、没有理解透相关业务就开始设计界面细节。ToC的产品很多操作流程是单向、线性的，分支、回退的情况也有但不多；而ToB产品的操作流程可能会牵涉到很多不同的用户角色、产品平台，他们的诉求可能是彼此矛盾冲突的，不能从单方面的角度来考虑设计，可能出现的场景与操作类型很多、衍生的路径也会五花八门，不能以简单的线性思维来考虑；想要把流程场景梳理得清晰而全面的话，对PD与设计师有更高的业务理解与逻辑思维能力要求，「信息架构」功底不能差，这也是我觉得理工科技术背景出身做产品/交互设计相比艺术背景出身比较有优势的一个地方。
观察请教，挖掘丰富内部资源
我一直觉得「信息搜集能力」是一个容易被忽视、但非常重要的素质，是一个非常强大的外脑式存在。对于BAT这种大公司来说，内部五花八门的事业部和产品线林立，性质重合相似的大大的有，ToB产品自然也不例外。虽然外部公开的相似ToB产品设计资料可能很少，但对内的话，如果稍微留心搜索寻找一下，是可以通过内网的论坛、云盘、设计交流站点、设计稿预览站点还有不定期举办的内部专业分享等，找到前人对于类似项目的设计文档与经验总结的，给自己的设计思路带来启发，也能少走一些弯路。
没有人是一座孤岛，即使是比较资深的设计师，想要完全独立靠自己想出一个十全十美的解决方案也是比较难的，一个好方案背后往往参考了很多人的建议、经历了很多次挑战和PK。一个人闷头思考出来的方案，总会有各种各样考虑不全的地方，而当ToB产品找真实用户访谈验证比较麻烦的情况下，就更依赖于主动多次在出方案过程中去找所做产品线类似的设计同事、对用户习惯与各种背景限制更了解的PD和运营验证排除想法（条件允许最好做一些可交互的动态Demo，一定程度上替代可用性测试），让设计变得更加合理。
善于联想，拆分借鉴打散重组
没有整体产品性质相似的竞品，并不意味着我们「完全没有可参考的对象」。当把一个复杂的ToB网站解剖成一个个页面、功能、组件后，我们可以轻易地发现：这些小的模块很多在我们熟悉的ToC产品里都能找到影子，具体到交互设计模式很多都是通用的，应用的前置场景合适的话完全可以借鉴过来。
拿我之前设计的一个给商家用的客户评价管理系统插件（刚上线不久）为例，里面有一个「待解释评价」列表，在真实场景中列表内容非常多，对于解释完评价后的交互，起初和运营、前端产生了一些争议。设计方案上，我们希望列表使用翻页组件，解释后的评价从列表中消失，同时下一页的评价自动顶上来，翻页组件的页码也会随着总评价减少自动刷新；起初被担心「技术上不好实现」，我们知道通常来说应对这类理由最有效的做法之一就是拿出已实现的案例，但如果从「商家评价管理」这个角度去找竞品显然会比较困难，所以我提炼了「大量内容列表」、「处理后消失」的特征关键词，然后很快就联想到了邮件列表（标记为已读/删除邮件）和商品订单（删除订单），找来163邮箱与我的淘宝页面一看，交互形式和我们设计方案里提出的很类似，再拿去给运营和前端一看，最终顺利通过了设计方案。
专业执着，没有最优只有更优
在做并非行业第一（甚至第三第四都不算）的ToC产品时，有个「行业标杆」的老大在前参考借鉴未必是好事，它会框住我们的产品设计思维，也可能成为别人阻止你创新的武器。有人会提出「做成某某那样就行了」，有人会反驳「你看某某就是这么做的，不会有错的」，而作为设计师的我们很多时候也无力辩驳只能默默接受，觉得「某某就是这么做的，某某和某某都是这么做的，那么这就是最优的了，没有更好的解决方案了罢」。
而有些ToB产品并没有这样的限制，从积极的方面来说，更利于我们突破惯性思维的框架，做出创新性的解决方案，也让我们更自主地去思考如何不断地打磨优化，而不是因担心改变造成流失等在别人的阴影里亦步亦趋。在ToB的世界里，设计不会像某些ToC App一样，照着MD/HIG再找几个竞品，也能模仿出个像模像样的东西；而会更关注事物的本质，对「专业执着」提出更高的挑战，某种意义上，ToB产品设计更接近我入行前对「交互设计」的想像，虽然可能很多时间都是枯燥、无聊、复杂的，但对理性思维的我来说，却能在解决问题的那一刹那带来更强烈的快乐和成就感。
