在2015年，智能手表还是个非常新的品类，项目组成员都没有过开发智能手表的经历。设计和开发的过程中，大家都在不断的学习和探讨，组内没有绝对的权威，也就给了大家更充足的个人发展空间。这让原本就不满足视觉设计的我，能在这段时间里更多的参与产品设计、交互设计。对我而言，在Ticwear这段时间是我的专业能力和对产品的理解提升最快的一段时间。
出于对产品的兴趣，我会经常反思现有产品存在的问题，思考并寻求新的解决方案，方案比较成熟的时候，我会主动找产品经理沟通。我始终相信，产品经理会乐于跟这样的设计师合作，因为这样的合作伙伴是一直在思考产品设计的，不是被动的接收需求，而是能保持跟他们站在一样的视角和高度去设计产品。
我会经常用在线工具记录自己的这些思考和理解，记录产品迭代思路。长期保持这样的习惯，会让自己的头脑始终保持高度的敏感的状态，也同时会积累形成一个很丰富的产品设计的知识库。这样无论对个人，还是对团队，都有很大帮助。
我觉得做好设计，这些画图之外的事情更重要。
在 Ticwear 项目期间，对我来说最大的收获，是在设计工作中重新理解了设计规范。
在之前的工作中，由于“规范”这个词的误导，我总会认为，设计规范就是定好了不许改的东西。在 Ticwear 项目期间，我设计思路上的第一个转变是：规范就是设计本身。进一步说，是“团队设计”。它不是那个不能变的东西，而是那个整个团队需要一起遵循的东西，需要团队一起去维护，它不是束缚大家的枷锁，而是共同创造美好设计的基础。这部分工作很难一气呵成，更多的是跟周围的同事紧密的合作。例如在设计中用到的字号、颜色、间距、小控件等这些很容易规范化的东西，大家需都需要建立意识，在自己用到的时候要记得跟大家讨论和同步。逐步形成统一的设计规范库，并用在线的工具记录。
我的第二个转变是：规范不能只在设计师端维护。规范如果只维护在设计师端，最后只能变成设计师们自嗨的工具，不会为产品带来价值。在实际开发中，也会跟工程师之间发生很多不必要的沟通。解决办法是：必须把设计规范在工程师端落地，形成代码库，例如：规范里的一个交互控件，在工程师端应该是由负责开发控件的工程师开发成可以调用的通用控件，而不是每次都要重新开发。这样不仅实际产出会更标准化、效率更高，所有相关的同事也都会对设计规范有共同的认识。
基于上面的理解，跟我的同事们一起，共同创建了 Ticdesign 设计规范和代码库，您可以点此 点此 进入Ticdesign网站做进一步了解。
产品设计过程中，会时常碰到用一个很临时的快速方案处理用户反馈事件的现象，往往这样的处理办法不会解决根本问题。创业团队，很想快速对用户的反馈做出响应，很怕错过些什么，就会经常用这种方式处理问题，我给这种现象取了个名字——“快餐式设计”，这样的问题多了，会积累很多根深蒂固却又谁都不敢碰，不愿意去碰的问题，会把最本质的问题藏的越来越深。在 Ticwear 的开过程中，多次遇到这样的问题，有一些在我和一些同事的坚持下得到了解决，有的则石沉大海。
下面是一个例子。
有段时间，用户反馈：他们的手表屏幕经常被误触发点亮。有产品经理准备用这样的解决方案：在设置项里，增加一个触摸亮屏的开关，开，触摸亮屏，关，完全不响应触摸事件。看起来非常聪明的设计，只要告诉这个用户，我们给你加了这个开关，这个用户就会很开心。实际上是这样吗？这种办法解决了根本问题吗？并没有。
先说加开关这个方案，这只会解决“发生了误触发现象，且通过反馈渠道向我们反馈过问题，并且得到我们回复”的用户的问题。大量的用户，是不会向我们反馈这种问题的，这些用户怎么会知道系统设置项里增加了这个开关呢？就算无意中发现了这个开关，他怎么会知道这个开关会解决误触发的问题呢？要为这个功能发送集体通知推送吗？要把他写进更新日志中吗？开关开着，就不会误触发了吗？触摸亮屏这个体验本身有问题吗？
所以这种加开关的快餐式设计方案完全不解决根本问题。
而实际上不难理解，误触发一定是系统对于屏幕触摸的响应处理的不够好。我们经过分析和测试后发现，当时屏幕在熄灭的状态，对长按和划动都会做出响应，在进一步了解，我们发现屏幕其实对所有的touch down事件都会做出响应，而用户反馈的问题，很多也是由一些能产生划动和长按的肢体动作造的。所以问题的本质是屏幕对touch的响应机制上的设计遗漏，之前并没有对此做出严谨的定义。应该用类似如下的方案去解决这个问题：首先应该调整为，屏幕熄灭状态，取消长按和滑动的响应，在开发和测试后看实际的效果再做下一步调整。
如果用了开关方案，这个问题将会被永久遗忘，团队也就失去了做出卓越产品的机会。我认为，无论怎样都一定要坚持去找到问题的根源，不要只看表面，如果能修一座桥，就不要准备一根竹竿，这是做出好设计的基础。
很多时候，我们是打开工具软件就开始做设计的。虽然团队内部会有一定的讨论，但也通常都是直奔主题，快速进入细节。用这样的方式做设计，产品会在很长一段时间里都缺乏个性，没有灵魂，有时候甚至会不知道为什么要设计成这样。设计原则的存在，就会解决这个问题。
例如，如果智能手表产品的设计原则中，有一点是：尽可能让用户一瞥即知，那信息展示为主的界面就会围绕这一原则去设计，对布局，字号，信息密度都会有要求。而如果没有这一原则的存在，可能就会出现字号较小，信息密度过大的设计。或者，如果设计原则中有一点是：让用户尽量少用另一只手，那在有可能增加存在复杂交互的功能时候，就会认真去思考是不是真的要做这样一个功能了。
当然，设计原则一定不是在产品设计开始之前就能想清楚、弄明白的，需要一定的经验积累，需要团队每位成员对产品的理解能不断的保持同步。但无论怎样，设计原则是必须存在的，否则产品将失去灵魂。
有时候，团队里会有一些比较好的想法，但由于种种原因没有被采纳。当其他的竞争对手先把你这些想法做出来的时候，没有人是真心的想说“哎，你看，我不是都说过了…” 因为大家都宁愿不要说这种话，那时更多的是内心的无限遗憾。这让我不得不去思考这其中的原因，到底哪里出了问题？
对于这个问题的思考，让我想到了最近听到的一段历史，一战后的1919年，在决定人类命运的巴黎和会期间，是有一些人预言了二十年之后的第二次世界大战的发生的，也在会上表达了自己的态度。可为什么最终悲剧还是发生了？把问题放大到如此之大的历史的角度，夸张了。但我试着找到其中清晰的道理：1. 二十年之后的二战是个悲剧；2. 悲剧有机会避免。3. 应该从历史中学会如何避免悲剧的发生。
我觉得最主要的原因，是这些好想法的提出者，没有把好的想法做深入和完整阐述、设计、甚至是demo。如果真的觉得这是个好设计，一定要做的完整的设计，不要只是说说，要更正式和完整的去阐述观点。最重要的是，一定要为这个设计找到让人难以拒绝的理由，如果找不到这样一个理由，也就证明这个想法是有问题的。当然，这期间还要注意沟通的技巧。就像当年的那些“预言家”，如果觉得未来真的那么可怕，他们应该找到更合适的方式尽全力阻止悲剧发生。
另一个重要的原因，我认为是在决策者本身的综合能力。专业能力，学习能力，沟通能力，领导能力，判断能力所有这些能力共同决定了产品最终的发展方向，过程真的很复杂，但结果会体现一切。
我很想知道像苹果这样的公司是如何决策的。数据？满意度？专家评审？个人决定？民主决定？我没有答案。我看到的经历过的过程，并非是很多利益的绝佳权衡的结果，也并非是力排众议力挽狂澜的大气，更多的是混乱。我会继续去寻找答案。