早在2017年，数栈当时没有这么多子模块，只有【离线开发+实时开发】2个部分，所以在导航设计上不存在问题，仅仅按照数据开发的通用设计逻辑即可。在2018年，增加了数据质量、数据API等几个模块，涵盖多个模块，整体的导航规划就变得很重要，搞得好的话，增加新的模块，可以继承现有的设计，搞不好，后续的改动就会比较大，甚至可能推翻重来，所以导航的重要性就在这里。
既然包含了多个模块，有几个问题是需要重点考虑的：
1、向后兼容性问题，未来增加新的模块，对现有的导航方式必须改动很小，最好是不要改代码，而是改数据库或者配置的方式。
2、共性模块的抽取，每个模块大概有哪些功能，哪些模块是共性或十分类似的，应该抽取为统一的页面进行管理。
3、共性部分在聚合在一起的同时，也要有良好的产品体验，不能因为解耦造成体验很差。
4、结合商业模式也要考虑解耦性，未来产品的售卖模式是单独售卖，例如数据API可以不依赖其他模块单独输出。
对于数栈产品经理来说，这是一个之前从来没遇到过的问题，那要怎么解决呢？这里提供一种思路：
自己没遇到过的问题，考虑一下别人有没有遇到过，如果有的话，那就去学习，如果没有，说明这个问题本身可能有问题
——简单地说，就是“抄”
整理了上述问题之后，首先不是思考如何画原型，而是去找哪里“抄”这个设计。
如何去找“抄”的地方呢？当时主要考虑了以下3个因素：
1、友商的产品要比我们多，最好能多很多，而且必须集成在1个导航体系内。
2、友商不能只有SaaS服务，因为SaaS服务可以做很高程度的耦合，但我们还要考虑各种产品独立部署的场景，要可拆分、可解耦。
3、最好是2B类产品，2C类产品这种场景的好像也不太多。
按上面的思路，能确定几类友商范围：
1、公有云：公有云一般有上百个产品，遇到的问题比我们更是复杂，既然参考了更复杂的案例，产品数量少就是小case，例如阿里云、亚马逊aws、微软azure及Google。
2、国内的企业服务厂商，华为、亚信，遇到的问题与我们是类似的，一般是输出有限的几个模块，面向专门的一家客户服务，也可以参考，例如：华为，国外的这方面友商不太了解。
注意，本文的截图是2018年，与当前的产品形态可能有差异
1、阿里云
登录后直接进入门户，平铺各种产品的入口链接，便于直接分流，分流可以说是此页面的唯一目的
顶部导航可根据需求定制，将常用产品「挂」上去
进入某个产品后，通过面包屑的形式提供多层导航
2、GoogleCloud
首页以dashboard的形式铺开，便于用户观察核心指标，但只能依靠左侧的导航来寻找产品
3、华为
华为某产品截图，利用顶部导航拆分各个模块，同时借鉴了Google Dashboard的形式，将关键指标体现在首页。
参考了以上几个产品之后，数栈在设计上要注意以下几个问题：
1、可能最多有7—8个产品，但不会有公有云那么多。
2、数据质量、数据API、智能标签、数据地图等模块，会逐步演变的比较复杂，应充分利用顶部菜单，如果后续需要扩展功能，可以设计左侧菜单，便于扩展。
3、首页无需强分流，数栈几个产品的相关度很高，首页可以借鉴Google的dashboard模式。
4、导航上，充分利用顶部导航，为页面下面留出空间。
5、公有云大部分产品不使用顶部导航，猜测可能是因为二级菜单过多，无法统一（阿里云的dataworks使用顶部导航，也是由于其功能可以划分，且只用左侧导航会出现导航过多、无法与数据开发集成等问题；AWS的Cloud9也是使用了顶部导航）。
6、用户独立部署一个产品或多个产品时，导航的体验一致（包括从一个产品升级为多个产品）
7、部署单一组件和多组件的区别就在于顶部上多了一个“xx产品”的icon，其他导航菜单不动，这样比较简洁，且体验一致
设计方案1
以上内容就是数栈导航的一些设计过程和思路，最终选择了第二种设计方案。当然，这种方案也有一些问题，例如首页没有体现Dashboard等，有些问题已经有了解决思路，会在未来版本中逐步迭代优化掉。
绝密文档公开！首次揭秘数栈导航设计思路 
766
0
