简单的说，自己不干，而是提供一个平台，让别人去干的产品。比如淘宝就是一个平台，它自己不卖东西，而是让买家和卖家在这里交易，它提供帮助、服务和监管的作用。很多人可能觉得淘宝、天猫的设计逻辑并不复杂，但其实你看到的只是产品的一小部分，即面向买家C（Customer）的部分。面向卖家B（Business）的部分则要复杂的多，当然还有面向开发者D（Developer）的（比如淘宝开放平台）。CBD都生长在淘宝平台上，都是平台的一部分。当然除此之外，还有其他角色，比如模特啊、摄影师啊、服务商啊等等，太多了，这里就不一一叙述了。所以平台其实是一个复杂的生态系统，这也是平台的魅力所在。
不管做什么类型的产品，都需要考虑业务、技术、用户这三方面。而平台型产品在这三方面的难度都加大了。
我总结了下面这个表格，通过它可以更清晰的了解平台型产品与其它类型产品的区别：
1、总的来说业务、技术上都相对复杂，我们目前正在做的更是一个史无前例的产品，业务、功能、设计都没有太多可以参考的对象，大家都是在摸索中前进。以往的经验、产品设计流程可能都没法直接复用。
3、我们目前在做的平台型产品，业务和功能是最重要的。对于设计师来说，最大的挑战莫过于理解这么复杂的业务，然后才是设计的问题。
在设计这个产品的时候，我们首先向PD了解了一些产品的基本信息（比如产品背景、过往的用户调研内容、用户痛点、产品功能、业务场景、业务逻辑图等等）。由于内容比较复杂、信息量大，设计师和产品经理的思维方式又不太一样（产品经理更多的是考虑功能、业务模块以及它们之间的关系；设计师更多的是考虑用户角色、任务、使用场景、信息结构等），因此理解起来比较困难。那么首先需要梳理内容，把业务转化为设计师容易理解的内容。于是，我尝试根据自己的理解梳理出产品不同角色、任务、可能的页面等（不考虑细节、分支流程等，只考虑最基本的用户角色和用户任务）。为了能正确的表达业务，同时又符合用户的使用逻辑，可能要反复多次，并跟PD不断讨论（上图是PD梳理的业务流程图，下图是我画的角色任务草图）。（由于涉及到未上线的项目，图片内容已做马赛克处理，希望不影响对方法的理解）
根据这个图，就可以大致得出产品的信息结构、导航，然后我们在此基础上补充细节，形成界面草图（草图过于潦草，这里就不展示了。顺带说一句，草图出来后视觉设计师马上YY了一个风格稿，这样我们就可以大致按照这个风格来设计原型，美观很多，满足了汇报或宣讲的需要），这也是和PD一起讨论、完善的过程。有了界面草图，我们就可以使用Axure来绘制界面风格，然后PD接过去在里面填上和业务有关的表格、文案等内容，交互设计师再根据经验来补充界面元素，完善交互细节。在完善界面的过程中，我们不断发现PD之前没想到的功能、业务问题（主要是和界面有关的部分），然后推动PD去解决问题。有些东西暂时定不下来，那就先假设，日后再去求证，总比什么都不做要强。之所以采用这样的合作方式，是因为PD更有业务sense，而设计师更有界面sense，充当了业务转化为界面的翻译。
后来这部分产品（其实这只是产品中的一个子模块，但这种方法也可以复用到这类产品的整体设计中）设计顺利的按时完成了。我把整个设计流程总结下来，大概是这个样子：
我们的分工大概是这样（这是一个我心目中理想的流程，实际上前面两步主要是PD和运营在做，我们希望日后可以按照这个流程和PD共同奋战在一线）：
后面我还会讲一个使用这个流程完成的具体案例，证明这个流程是可以复用的。
1、平台是为了成就他人，客户永远是第一位
前期的用户调研非常重要，比如PD们经常出去调研，积累了很多宝贵的资料。我们也跟着PD一起出去调研过，但是对方说的很多东西我们都听不懂，所以了解业务非常的重要。
2、先抛砖、后引玉
很多时候困难摆在眼前，不知道从何入手，那不如先随便抛出一个靶子，然后通过这个靶子再去找修改方向，总比停滞不前要强。
3、没有正确的设计流程，只有合适的设计流程
经历过这么多项目，发现每个项目的设计流程都不太一样。因为每个项目的产品类型、项目资源、项目环境、人力情况等都不一样。所以设计师要根据项目情况，考虑最合适的流程。当然也要注意沉淀好用的方法，尽量让其可以多的复用。
5、和不同产品类型的PD协作有门道：平台型，贴着走；垂直型：并肩走；网站型，推着走
对于前面说的平台型、垂直型、网站型这三种类型的产品，UED和PD的合作方式是不同的：比如对于平台型产品来说，业务复杂且不易短期内掌握，所以PD更多的是推着UED走，UED也需要主动贴着PD，尽量好的给予设计上的协助；对于垂直型产品来说，PD从专业角度给意见，UED从设计体验角度给意见，双方不分伯仲都很重要，所以要并肩走；而对于网站型产品来说，产品同质化严重，入门门槛低，用户体验则非常的重要，所以UED要推着PD走。我们现在正在做的产品既是平台型，也包含垂直型，但以平台型为主。