空间数据协作工具，帮助用户完成从数据收集、整理到空间数据可视化和分析的全部流程工作。
PLATFORM
Web, Responsive
CONTRIBUTOR
Designer: Weibin
Contributor: Donglei
MY CONTRIBUTION
Prototyping
Research
UI / UX Design
Product Management
* MapTable 公测版已经发布，在网站中获取更多信息：http://maptable.com
项目背景
为什么要做 MapTable？
我们过去一直聚焦在开发空间数据相关产品，在空间数据领域已经有了多次产品上的尝试，我也参与了从地图喵、小区罗盘、城市地图、投研数智云、到粤港澳大湾区产业空间价值地图等空间数据相关产品的开发。几款产品覆盖了空间数据从收集、协作、可视化到数据分析的各个流程，并在地产、产业园区等领域进行了尝试。
但几款也不同程度上存在问题。产品在商业化的探索并不算成功，好几款产品还是为了满足少量客户的定制化需求，产品本身不够「标准化」，功能和字段都根据客户业务定位，耗费大量资源开发完成后，也很难作为「标准化」产品直接卖给其他客户，一次研发投入只产生一次收入，对公司的商业目标是很不利的。
在产品上我们一直希望寻求突破，希望在空间数据领域能打造出一款足够「标准化」、可直接面向客户售卖的 SaaS 产品。
产品目标
产品要解决什么问题？
我们在过去的产品开发中，一直在与客户保持交流，收集客户的反馈，并结合我们自己总结的经验，总结出我们当时面临的问题：
- 之前的几款产品都是针对单一场景提供解决方案的，例如地图喵侧重于空间数据采集和可视化，城市地图侧重于数据协作、可视化和分析。没有一款产品可以完整覆盖整个数据处理流程；
- 以往数据分析工作更多依赖于咨询服务，对数据的处理依赖于其他工具。而且很多分析模型无法应用到产品中，只能通过咨询报告的方式输出；
- 客户分布在地产、规划院、教育机构、零售等不同领域，不同行业的客户需求差异很大，很难标准化。即使是同行业的不同公司对数据上也有不同的需求，每次遇到新客户都需要定制一些字段。所以导致很多客户项目中定制化开发仍占很大比重；
- 客户以传统行业居多，客户之前的工作中积累了很多数据，大量数据积累在团队成员本地的 Excel 中，成员间通过传输文件的方式来协作，效率不高且容易出错；
- 由于客户历史数据量很大，在以往的客户项目中，帮客户处理旧数据的导入和兼容工作会花费很长时间，这部分工作量往往超出预期。
总结起来就是现有的产品无法完美解决客户的问题，具体有以下几点：
行业数据需求差异大
不同客户的数据需求差异大，无法标准化，需要提供定制字段
缺少有效的协作方式
无法多人协作，使用 Excel / 奥维地图线下传输，效率低且易出错
旧数据迁移成本高
客户历史数据繁多，分散在不同的本地工具中，迁移成本高
产品化程度低
部分工作仍依赖于人工处理，例如增加定制字段、导入旧数据以及部分数据分析工作
产品方向
选择产品切入点
与团队分享调研结论后，团队明确了结合表格和地图两种形式的产品方向，并决定从「空间数据」这一垂直领域切入，一方面可以在产品早期避开成熟产品的竞争，另外也可以专注于现有的客户群体，在几个领域中深入到一定程度后再横向扩展。
有了初步想法后，我开始了客户和产品调研工作，对之前从客户收集来的反馈整理出来。然后组织团队共同进行了一次 Lean Canvas 讨论。我先在 Google Docs 中新建了一个 Lean Canvas 模板，然后组织一次会议，由团队共同讨论填写。
这样的目的是，一方面分析我们的竞争优势，另外一方面是与团队明确要做的产品，将产品的想法具象话后同步给团队成员，让大家对要开发的产品达成共识。对产品竞争优势、目标客户、关键指标都有初步了解。
设计难点
原型设计阶段首先遇到的问题是：如何定义表格和地图的功能边界？
我们的产品规划中，表格和地图都是重要的产品形态，但表格和地图在空间数据处理流程中扮演的角色还需要进一步明确：
- 表格：承担数据收集、团队协作和少量数据分析功能；
- 地图：承担数据收集、地图可视化和数据分析功能。
接下来需要处理的问题是：表格和地图如何结合？
表格和地图两种形态能满足客户在不同场景下的需求，但形态差异大，如果不能用合适的方式联系起来，就只是一个产品中相互独立的两个模块，对用户的价值就大大降低了。
- 坐标字段
我们观察以往开发的地图产品，发现「坐标」是空间数据产品的「标配」，因此我们决定将「坐标」作为一种字段类型增加到表格中，用户可以在表格中录入坐标，地图会根据表格的坐标在地图上进行渲染。
- 明确表格和地图的组织方式
- 数据表：组成项目数据的最小单元，一张数据表中包含若干行列单元格；
- 地图图层：组成地图模块的最小单元，一个地图图层中可选择一张数据表作为数据源，并设置填充方式；
- 项目：一个项目中包含「数据」和「地图」两个模块，数据中可以包含多张数据表，地图中包含多个地图图层；
- 团队：由多人参与的组织，团队下可创建多个项目，并对团队成员进行管理；
- 个人桌面：存放用户创建的个人项目，与团队对应，可以理解为一种特殊类型的团队。
根据以往产品从客户获得的反馈，客户通常都是以「项目」来管理任务和进行人员安排的。所以我们也将「项目」概念引入产品中，另外考虑到协作通常在一个公司或部门之间完成，在项目之上增加了「团队」概念，至此整体的信息组织方式基本梳理清楚。
在设计探索的同时，列出产品的功能模块清单，和联合创始人共同确定功能优先级，定义 MVP 和内测、公测版本的开发计划。
设计难点
从设计探索中我们选择了一种方案作为 MVP 版本的框架，在其基础上将核心页面逐步完善。
- 页面基础结构
选择的方案是项目中数据表和地图作为两个独立页面，通过页面中的「全景地图」和「查看数据表」作为访问入口。
- 确定数据字段
通过前期对国内外表格工具的调研，对数据表部分的功能和字段类型已经了解清楚，但作为 MVP 版本，引入太多字段会增加额外的开发成本，另外考虑到地图场景的结合，最终决定在 MVP 版本中增加以下字段：
- 文本 / 长文本
- 坐标
- 数值
- 单选 / 多选
- 日期
- 相册
- 附件
- 定义基础组件
- 详情侧栏（Side Panel）
- 信息窗口（Info Window）
在表格页面和地图页面以外，还需要考虑增加信息展示形态，满足展示不同重要程度的信息展示。我们选择了将「详情侧栏」和「信息窗口」加入到产品中。
POI 数据展示在数据表中是一行内容，展示在地图中是一个点、线或者多边形，POI 数据本身存储大量的数据字段，但在数据表和地图中默认无法展示更多信息。因此我们增加了详情侧栏，展示 POI 包含的完整信息，并且将详情侧栏设置为表格和地图中通用的组件，增加两个页面的一致性，也减少不必要的开发成本。
地图页面中展示 POI 的空间落位，除落位的点或多边形，和对应 POI 的名称标签外，并没有更多信息，侧栏详情中又展示完整的信息，对于只想预览重要数据的场景，打开详情侧栏的操作成本较高，而且同时只能开启一个详情侧栏，无法打开多个 POI 的信息进行对比。所以在地图上增加了信息窗口（Info Window）。地图页面支持同时开启最多 6 个信息窗口，并且支持配置信息窗口中展示的字段（字段来源与对应数据表的字段）。
MVP 版本确定了产品的信息架构和交互方式，完成了数据表和地图的基础功能，在 MVP 版本可以实现在表格和地图中对数据的增删改查，并实现表格中数据和地图数据的对应关系。
通知
通知在产品中总是相对复杂的功能，复杂不在于产品设计上，而在于前期对通知类型的整理、通知文案的撰写和后期对每一种通知类型的测试上。
这次的通知整理也采用了以下流程：
- 列出系统中所有用户操作；
- 对操作进行优先级排序；
- 为不同优先级的操作选择对应的通知类型（系统通知、短信等）；
- 为每一个会触发通知的操作撰写说明文案
整理时使用 MapTable 创建了通知表格，一方面可以快速与团队协作；另外也可以深入体验产品的功能和交互（eat dog food）。
通知表格包含如下字段：
- 通知类型
- 功能模块
- 触发方
- 接收方
- 通知文案
- 通知方式：系统通知、短信
- 说明：点击通知跳转到的页面或其他注意事项
- 测试结果：通知上线后补充测试结果
整理好通知类型后，通知的设计相对简单一些，我们采用了通知浮窗 + 通知页面的形式。
- 通知浮窗点击导航栏中的通知图标展开，用于快速查看最近的通知。浮窗中展示最近的 5 条通知，并可直接在浮窗中进行查看和标记已读操作，点击通知会跳转到对应页面。在浮窗下方提供「查看全部通知」入口，点击可进入通知页查看全部通知；
- 通知页面展示全部通知，并区分已读、未读状态，支持「最新通知在前」和「未读通知在前」两种排序方式。
实时协作
产品的定位是「空间数据协作工具」，实时协作是核心的功能之一。我们的实时协作比其他表格产品要更复杂，因为在地图视图中也需要体现实时协作。
我们对实时协作状态展示的处理有以下几部分：
- 导航栏：展示同时访问项目的团队成员
项目导航栏中展示当前正在访问该项目的全部成员，并为按先后顺序为每个成员分配一个颜色，用于和表格或地图中用户正在操作的元素对应。
为保证协作成员区域在导航中不占用太多空间，限制了最多展示 5 个协作成员的头像，超出 5 个协作成员收起到列表中。
- 数据表：展示其他用户正在编辑的表格
- 协作成员选中的单元格边框高亮，单元格右上角展示协作成员用户名；
- 单元格高亮颜色与导航栏协作成员头像右下角的颜色一致；
- 多名协作成员可同时选择同一个单元格，单元格颜色以最后选择的成员所属颜色为准，单元格右上角展示多名成员的头像。
协作状态展示在数据表中起到的作用是展示状态和预防冲突；数据表部分其他表格产品都有比较成熟的解决方案，我们也采用类似的方式处理：
- 地图：展示其他用户正在编辑的 POI
地图部分最开始考虑类似 Figma 协作时展示多人鼠标的方案，但评估下来，我们产品对协作实时性要求没那么高，而且实时渲染用户鼠标会增加传输的数据量，对其他用户会造成干扰。
最后决定采用和表格一样的处理方案：高亮用户正在操作的 POI，防止操作冲突。
注：地图协作状态展示为公测版增加的功能，为方便介绍功能放入此部分。
权限
权限是整个产品中最复杂的部分，需要处理多个层级继承关系。前期组织类型区分个人桌面 / 团队、项目中包含数据 / 地图的设定，每一部分都需要重新考虑对应权限。
产品从信息层级上分为：
- 个人桌面 → 项目 → 数据表 / 地图
- 团队 → 项目 → 数据表 / 地图
权限类型分为：
- 不可见
- 只读
- 编辑
- 管理员
项目、数据表 / 地图除了完整继承上一层级的用户权限，还需要考虑到用户在团队内会进一步明确分工，例如团队中几名成员负责一个项目，其他成员不需要参与；或者一个项目中每名成员负责维护一张数据表，成员之间也需要做权限隔离。因此我们在项目、数据表 / 地图上（二级、三级）的权限增加了两种选项：
- 继承上一级权限
- 指定成员可见
为了简化需求，指定成员可见只支持上一级的内部成员，不支持邀请团队外部成员。例如在项目中只能从团队中的成员选择几名设置为「指定成员可见」；在数据表中只能从项目的成员中选择几名设置为「指定成员可见」。
所以权限的整理就是以上三部分的排列组合，为了整理得更清晰和与开发同事协作，我在 Google Sheets 中建了一个表格，按照功能模块将每一个页面的操作在不同权限下的行为全部整理出来：
整理好不同权限类型下的操作后，开始权限部分的设计，有两种用户类型需要考虑；
- 管理员：邀请成员、管理成员、修改成员权限、移除成员等；
- 普通用户（包括只读、编辑用户）：查看协作成员列表、自己退出协作。
地图样式设置
数据录入后，在地图视图下进行可视化展示也是空间数据分析的重要步骤。在地图样式处理上，从之前的几款产品中积累了一些经验，对 GIS 工具的可视化功能也有基本了解。MapTable 的图层样式设置就是将之前积累的经验转化为具体的功能。
地图图层最初的设想是与数据表一一对应，一张数据表默认拥有表格和地图两种视图。团队讨论下来，这种方案的优点是清晰直观，用户容易理解数据表和两种视图的关系；但缺点也很明显，每次只能看到一张数据表的图层，不利于查看全局的 POI 数据，有时分析是需要基于全局的数据才能得出结论的，这个方案下地图可视化和分析这一部分功能大大被弱化了。而且也不利于扩展，如果后面增加视图也比较困难。
所以我们决定采用更灵活的图层方案，借鉴设计工具里的图层概念，用户在地图页中可根据需求创建任意数量的图层，每个地图图层只是单独设置展示 / 隐藏状态，地图中展示的是多个图层叠加展示的效果，每个图层支持单独的图层样式设置，用户可以高度灵活地完成可视化和分析需求。
我们在图层设置中提供了以下设置项：
- 数据来源：选择一张数据表作为数据来源，选择后可在地图中展示；
- POI 坐标：选择对应数据表中的坐标字段，默认选择第一个；
- POI 标签：展示到地图 POI 中的文字标签；
- 标签样式：POI 标签的展示样式和展示位置；
- 填充颜色：POI 的填充颜色、填充方式等（POI 包括点、线、面、多点、多线、多面等类型）
- 描边：POI 图形填充边缘的样式，包含描边颜色和粗细；
- 填充半径：POI 图形半径的大小，以及依据的字段。
内测版测试：Eat dog food
内测版功能完成后，留出 2 个迭代来让大家体验产品和修复问题。体验产品不仅是测试产品功能，还需要引导大家去找到产品的使用场景，便于在公测版中为不同的场景制作模板，场景引导对一款通用型的工具至关重要，不论是 Notion、Airtable 都很注重这一点。
- 量城通讯录项目
想到的第一个场景和我们团队有关，因为团队部分成员是远程工作，大家分布在不同城市，原来的通讯录在 Google Sheets 中维护，但位置只能通过城市名称标注，在 MapTable 中则可以在地图视图中展示空间位置，清楚了解同事所在的位置。另外在 MapTable 数据表中补充了一些字段，鼓励大家分享自己的兴趣爱好、动态等。
- 同学录
第二个场景与通讯录项目类似，是在 Twitter 上看到的一个场景，毕业季同学找工作，分散在不同城市，同学之间互相了解对方的动态和联系方式，对我们的产品也是十分合适的场景。基于「班级地图」这个场景，做了一个同学录项目。
- 深圳二手房
前两个项目比较简单，数据量也很小，不能充分测试表格和地图的性能上，决定找一个数据量大的场景。从之前做过的城市地图项目中找到了深圳市二手房数据，于是导入 MapTable 中，着重测试了表格性能和地图可视化效果。
项目列表页优化
项目列表页使用 MVP 版本开始的设计，布局比较简单，只展示名称、数据表、创建时间和地图、数据表入口。随着内测版本协作功能的加入，原列表页呈现信息不足的问题暴露了出来：
- 项目列表中无法看到共同协作的成员信息；
- 数据表涉及用户权限，每个用户能访问的数据表数据不同，在列表中展示的「数字」可能不够准确；
- 缺少创建人信息，有时名称相近的项目不容易区分；
- 地图和表格入口分开，给用户感觉两个功能是割裂的，而且入口只有两个按钮，整张卡片并不可以点击，操作上略有不便。
在公测版中尝试重新设计项目列表页，第一个方案从 Figma 的项目卡片中获得灵感，为项目卡片增加地图封面，在卡片下方展示项目名称、最近更新成员和日期、数据表和协作者数量，并在左侧菜单中增加「使用帮助」模块，用户在使用产品时随时可获得帮助。
设计图看上去效果还可以，但到具体产品策略层面遇到了问题，主要是封面如何生成一直没有找到合适的解决方案：
- 封面图自动生成还是手动上传？
- 自动生成使用何种规则？展示一个图层还是多个图层？中心点、zoom level 如何确定？
- 何时更新封面？数据有修改时？图层设置有修改时？
- 封面图层是否涉及权限？（如果用户只对部分图层可见，是否能在封面中看到其他图层的数据）
- 用户未创建图层怎么办？
虽然以上问题都能一步一步找到解决方案，但考虑到实施这些解决方案的开发成本可能远超项目列表本身的前端调整，我们只能放弃该方案，继续寻找其他的思路。
使用地图封面的方案行不通，却给了我们带来为卡片增加个性化样式的思路，不使用封面图同样也可以做到个性化，为不同项目增加区分度：每张项目卡片可设置卡片背景颜色、项目图标。
但设计出来也并不太满意，过多的卡片颜色使得整个页面显得杂乱，单张卡片中的元素也比较多，接下来想在此基础上做一些减法。
如何做减法的同时能保留一些个性化样式，还不会使整个页面变得杂乱，增加项目之间的区分度。所以在下一次优化方案中尝试了：
- 只保留项目图标设置，去掉卡片颜色；
- 增加协作成员头像展示，增加视觉元素的丰富性；
- 去掉容易造成用户误解的数据表数量
- 缩小单张卡片宽度
- 增加 hover 卡片最后的空白位置提示用户「新建项目」的引导；
- 保留左侧菜单中「使用帮助」模块。
单元格样式
单元格样式需求来自内测版的客户反馈，客户公司之前的团队协作方式主要依赖于线下传输 Excel 文件，并在 Excel 标注出需要重点关注或跟进的项目，在 MapTable 中如果提供了样式标注的功能，就可以将需要成员关注的重点内容标出来，提升协作的效率。
单元格样式中初期只支持部分文本类的字段类型，例如文本、坐标、数字、日期、公式等；多选、多选、附件、表格等其他类型字段暂时不支持。在交互上我们采取了以下策略：
- 单元格「样式」按钮在默认未选中单元格的情况下不展示在操作栏中，在用户选中单元格后展示「样式」按钮（提示用户样式是针对单元格生效的）；
- 选中支持的字段类型单元格：样式按钮处于激活状态，可点击；
- 选中不支持的字段类型单元格：样式按钮处于 disabled 状态，不可点击，hover 时展示提示「该字段类型不支持样式设置」；
- 选中多个单元格中既有支持样式的字段，也有不支持样式的字段时：样式按钮处于激活状态，可设置样式，设置后只对支持样式的字段类型单元格生效（例如同时选了文本、数字、单选、附件 4 个字段，此时可以看到样式按钮并设置样式，设置样式后只对文本、数字 2 个字段生效）。
图表
在内测版中，我们收到参与测试客户的反馈，客户平常使用的空间数据录入场景中，经常会为一个 POI 数据录入复杂的结构化数据，例如某一楼盘多种户型数据、或者历年的房价数据，如果使用原有的「文本」或「数值」字段，则需要添加多个字段，而且无法清晰表达数据间的对应关系。因此我们决定在 MapTable 中增加「表格字段」，允许用户在一行数据中插入结构化的子级数据。
内测版中客户提到的另外一个反馈是，数据详情中都是字段的展示，缺少图表等可视化的展示形式，对于复杂数据的展示不够友好，希望这些复杂的数据也可以有可视化的图表形式。这个反馈我们在内测版并没有想好具体的解决方案，在公测版中团队讨论出可能有两种解决方案：为表格字段增加图表展示功能；增加图表应用（Apps）。应用模块的开发已经在公测版的规划中，所以首先我们可以表格字段增加图表展示功能，之后图表的设置部分在之后的「应用」模块也可以复用。
移动端适配
移动端的适配工作从内测版陆续开始，当时只适配了注册、登录相关流程，表格和地图等产品核心页面并未适配，考虑到公测后会被用户使用，但用户的访问设备并不一定是 Web 端，移动端的适配工作也很重要，因此公测版中把移动端适配的工作提上了日程。
移动端适配开始前，先将所有页面划分了优先级，将用户可能会经常看到的页面优先适配，其他用户不经常访问的页面则放到后面优化。重点的适配页面有：
- 登录、注册
登录、注册流程首先做了适配，因为在项目协作中邀请新用户是通过短信的方式邀请，被邀请的用户很可能会直接点击短信中的链接进入到产品中，首先就会引导用户完成注册流程，所以对注册、登录、填写邀请码的几个页面先做了适配，并补充了产品 Logo。
- 项目列表
Web 端项目列表在公测版优化后，移动端适配也使用了新的设计。同时在移动端重新组织了菜单，Web 端导航栏中信息较多，在移动端也做了优化，将次要信息收起到菜单中，方便用户在手机上操作。
- 表格
表格视图部分的菜单操作项很多，在移动端展示的效果也进行了简化，为保证横向展示空间，操作栏中默认不展示操作图标，在用户点击展开菜单后才展示操作名称。展开的菜单中也保留了完整功能。
- 地图、POI 详情
地图视图下的操作栏采用和表格一样的处理方式， Web 端侧栏展开的详情在移动端做成了全屏覆盖的形态。图层样式设置采用下方菜单的形式，用户可以边调整样式边在地图上预览修改后的效果。
Retro / Things I learned
创造从小的东西开始
当思考一个很大项目的时候，你肯定会做很多假设，也就意味着你有很多错误的可能性。从越小的点出发，正确的可能性就会越高。在最初的产品定位上我们就避免将自己当成另外一个表格产品，表格只是目前阶段实现我们用户需求的一套合适的解决方案，我们将自己定位「空间数据协作工具」，而不是一款 Airtable 的新产品。只有我们在细分领域做得足够好之后，再考虑扩展更多场景才有意义。
市场才是检验产品需求真伪的最佳标准
MapTable 是基于我们之前几款产品中对客户需求的理解诞生的产品，但开发过程中缺少与真实客户的互动，只有在内测版功能完成后才与有部分客户参与进来，导致很多功能上与客户实际需求和使用方式有差异。如果客户能从一开始就参与进来，我们对需求和市场的理解能更上一层楼，也会少走一些弯路。
Fail fast and learn fast
整个产品的开发周期太长，迟迟没有推向市场，因此也没办法获得更多有价值的客户反馈。MVP 版本和内测版本其实已经具备了基础功能，但我们一直「追求完美」想推出一个更好的版本，但「更好」的版本应该来自于客户的反馈，而不是我们的假设。
SaaS 产品的价值
SaaS 的本质是续费，客户续费的前提是产品本身为用户解决问题，带来新的价值，因此只有保证客户成功，客户才愿意续费。客户成功与用户体验类似，并不只是产品设计的工作，整个公司的不同部门都需要对齐「客户成功」这一目标。
通用型产品 SaaS 产品的难题
通用 SaaS 产品和垂直领域 SaaS 哪一个更有前途争论已久，做 MapTable 过程中对两个方向的理解又加深了。我们做的是一个通用的产品，能满足不同行业不同场景下的使用需求，但也带来不够「专业」的问题，客户本能地会希望有一个为自己「定制化」的解决方案，特别是一些传统行业的客户，这部分面对通用型产品接受起来就会有一些门槛。所以通用型的产品一定要做好对客户场景的引导，不仅需要体现在产品的功能设计上，还包括运营、销售策略等。Airtable 和 Notion 在产品中都很注重对用户的引导，在产品上提供了很多场景模板，并经常发布实际用户的使用方法，这都是在降低用户对通用型产品的接受门槛。只有客户决定产品和自己的使用场景足够接近，客户才会迈出尝试的一步。
