CDC TALK: 它山之石可以攻玉
CDC TALK 是由 CDC 主办的分享会议，CDC TALK 的举办已持续了三年的时间，每年都会邀请来自 CDC 设计、用研、品牌、开发等岗位的 6 位达人，带来 CDC 在互联网跨界实践中的第一手专业分享，为同行提供满满的学习干货。
以下是我在 2019 年 CDC TALK 上的分享《它山之石可以攻玉》：
用设计的思维解决地理的问题
去年的这个时候，我坐上了中介大哥的小电驴，开始奔波在深圳的许多小区，准备用我为数不多的首付买个小房子。虽然买不起大房子，但是我可以选择一个更大的小区，而且小区的绿化率也是我非常关注的一个指标。
在各种看房，横向纵向对比之后我挑选出了几个心仪的目标小区。我准备通过数据来对比一下这几个小区的绿化率情况，但是我在网络上很难找到权威的数据。不过没关系，这个刚好是我可以用我的地理专业知识能够解决的问题。
以前，如果我想知道一个小区的绿化率面积，我们可以尝试进行现场测量。其实，现场测量一件非常麻烦的事情。
首先，你需要遵循国家的《测绘管理规定》拥有测绘资质并进行报备；而且，我还需要先去了解《城市园林绿化评价标准》（GB/T50563-2010），知道绿化率的计算标准是怎样的；另外你可能会遇到很多无法直接进行测量的地方。
如今，学校的专业课程已经有教授 GIS 地理信息系统，通过 GIS 获取到合适的数据源，就可以很方便的对地理相关的数据进行统计计算。
我可以用 ArcGIS 建立坐标系，投影和比例尺，添加一些数据库字段，用来存储 Polygon 图形的面积值，然后用“计算几何”工具来统计绿色植被的面积。也可以通过编写 Python 脚本的方法来做一些更复杂的计算。
没错，这刚好是一个可以体现我专业能力的机会。正当我做完思路规划之后开始认真的收集材料，安装珍藏多年的软件，准备建立模型的时候。
我旁边的的设计师突然问我在干嘛？我准备放下手上事情来给这个设计师同学讲讲，这个事情有多复杂，需要多少专业背景才能做到。
听完我一堆专业词汇的输出之后，他有点意外说，“这有多难”，“你把图片发我”。他熟练的打开 PS ，导入我发给他的卫星图，他告诉我“你看，你这张图里面的小区一共有 198855 个像素。”然后点击魔棒工具，选择了绿色的植被，说“这些绿色的树一共有70745个像素，70745除以198855约等于35.57%，这个就是你们小区的绿化率。”
这位设计师非常快的用设计的思路得到了一个需要有专业背景才能计算出的数值，虽然这种方式精度会有偏差，但是对于我的用途来说这个差值好像并没有那么重要。
反而如果我要做现场测量，根据不同小区的大小，大概需要 3~4 天的时间，用 GIS 做几何计算至少需要 1天的时间，但是！如果用 PS 的魔棒工具却用不到一分钟。
这个时候我才发现，原来有些问题并不一定需要有很丰富的专业背景才能解决，尝试跳出你的专业思维换一个角度来看这个问题，反而会变得更简单。
用开发的思维解决设计的问题
今天在现场的有很多设计师，那你们一定经历过一个设计师逃不掉的“宿命”。什么是设计师逃不掉的“宿命”呢？
你刚开始给需求方做需求，需求方说：“（我们的需求很简单），按你的感觉来做，好看就行！”。你很快地就做好了第一版设计稿，需求方觉得有点小瑕疵，改了一稿，但是他好像还是不太满意。接连又改了 10 次，终于，需求方说：“我还是觉得你的第一稿比较好”。这个时候你已经陷入了崩溃，因为你根本没有保存第一版的设计稿。
当然，这样的事情也不仅仅发生在国内，在今年 2019 年， Pizzahut 把他们最新的 Logo 改回了 1967 年的那个版本。这可能是历史上时间最长的改回第几稿。而且，我看到新 Logo 的颜色跟 1967 年的那个版本有一点点不一样，是不是 1967 年的那个设计稿源文件也没有保存下来呢？
后来你的经验丰富了，也变得机智了。你开始给每次输出的设计稿文件名打上版本号，就像这样。
看起来这个方法还是挺实用的，万一需求方要改回其中的某一个版本你可以很快的改回去。但是，
如果你存档了 50 个甚至更多的版本，在你真的要找回以前的某个版本时，你唯一能做的是把所有的设计稿打开，在不同的窗口一个个的筛选，直到你完全迷失或者意外找到。
看到这样的场景，我在想，既然改稿的「宿命」没办法改变，那我们有没有办法可以让这个事情稍微轻松一些？
在开发上我们有很多可以解决版本管理的经验。比如我们用 GIT 来做代码的版本管理。就像你现在看到的一样，我们可以通过 GIT 可以很清楚的记录下来谁在什么时候修改了哪个文件的哪一行代码的哪怕一个逗号。而且，他可以像时光机一样，随时回到你想要的任何一个历史版本。
看起来这个事情也不难，只要给设计师的设计稿做版本管理就可以了。我开始尝试整理一些跟 GIT 相关的资料，打算给设计师讲一讲 GIT 的概念，这样就可以让设计师也能用上开发人员的这一套版本控制系统了。
我在 Google 上检索，在社交平台上求助网友，希望找一个比通俗易懂的 GIT 教程。Google 和网友们给我推荐了这个评价非常高的教程：《猴子都能懂的 GIT 入门》，我认真的研究了一下这个教程上的入门篇目录，整理了一个脑图。我陷入了困惑，我该怎么跟设计师解释：
什么是数据库，分支，克隆，合并？这可能真的是一份让人觉得不错（头大）的教程，可是猴子哪需要懂这么多的概念啊。当然，我不是在说设计师连猴子都比不上，看不懂。而是这么多复杂的概念对于没有计算机基础的设计师来说真的太难了。
我继续寻找有没有《设计师都能懂的 GIT 入门》呢？是的，果然有更早比我想尝试给设计师讲明白 GIT 概念的人。我找到了两篇文章：
- 《Sketch + Git 创造直观的修改记录》
- 《Git 与 Sketch 的神奇邂逅：Abstract》
他们的内容是这样子的：前者尝试用更简单的方式来告诉你 GIT 的概念，而后者则是建立了一个设计师的 Github 网站，对比起 GitHub 稍微简单一些。但是，不管是前者还是后者，你仍然需要理解分支 、克隆、合并的概念，这仍然是很难的。
这是去年在广州，我花了半天的时间尝试教会两个设计师怎么使用 GIT，我偷偷录了个小视频，可能是习惯了图形界面的设计师对代码和命令行有一种天然的畏惧，我似乎看到了我爸妈第一次使用智能手机的感觉。
总之，如果我们想让一个设计师能理解和使用 GIT 很难，想让所有参与到协作的设计师都能理解和使用 GIT 是“南”上加“南”。因为他的门槛太高了，甚至比需求方的需求还要难。
而且，GIT 也并不是非常适合直接用在设计稿的版本管理上。因为代码是文字内容所以可以比较容易的进行对比。而设计稿是一个独立的二进制文件，没办法直接进行对比。
怎么理解这个问题呢？我打个比方，如果给你两本不同时间出版的《毛泽东思想概论》，那你至少可以一个字一个字的对比他们有什么区别。但是如果给你两块不同时间生产的砖头，你要怎么对比他们的区别呢？
事实上，设计师并不需要理解太复杂的概念，他们的需求就只是希望有个地方能够管理他们不同版本的设计稿，同时能看到各个版本设计稿之间的差异而已。
所以我们尝试丢掉一些复杂的概念，然后把一部分必要的概念解释成设计师能理解的语言。
- pull 的意思是下载更新
- push 的意思是上传修改
- 初始设置 对应 个人设置
- 仓库就是我的文件夹
我们把这几个简单的概念做成了一个 sketch 插件给到我们的设计师体验。他只需要知道，看到设计稿有个小红点，点一下更新，修改完了设计稿点一下上传就可以了。而在这背后真正在工作的其实还是 GIT 的那一套概念。
另外，因为设计稿是一个独立的二进制文件，我们把这些设计稿生成了一张张的图片，让这些图片也变得像文本一样可对比。所以不管以后你是在左边画了一条龙还是右边画了一道彩虹，设计师都可以把这些版本记录下来，做清晰的比较。
在这个基础上，我们可以用开发的思维解决更多的设计问题：
设计稿版本管理把设计稿存在的云端，那么以后只需要一个 URL 别人就可以预览到这个设计稿而不用安装设计软件
更多的项目成员可以在你的设计稿上进行在线批注，在线讨论。
这又是一个令我有意外收获的事情，从开始只是简单的想解决一个管理设计稿的问题，到发现我们其实可以让设计师在不需要懂 GIT 原理的情况下能拥有 GIT 的能力，到最后我们甚至发现了一个解决方案有作为新产品的可能性。
结语
是的，用设计的思路居然能解决地理上绿化率面积的测算问题，用开发的思维还能能解决设计上的版本管理问题。
过去我们常常掉进专业的陷阱，或者停留在一个勉强能用的解决方案，可能错过了不少意外的收获。在以后，如果你碰到了一些难以解决的问题，不妨跳出你的专业思维看看能否用另一个角度来思考呢？
文章同时发布于 腾讯 CDC 博客