上周回家没赶上火车，废了一张票不说，在火车站白等仨小时，巨不爽。其实也是掐着点赶的车，主要是那天的火车尽然没晚点，让我惊掉了下巴。没办法，只能在候车室找了个安静的角落，默默地翻看那本《信息简史》。一边看书，一边安慰自己正好可以静下心来读书。这尼玛怎么能骗得鸟我自己啊，读书再少，这也安慰不过去啊！摔(╯’ - ‘)╯︵ ┻━┻

独自一人在角落合上书，怨念刚才发生的一切。总感觉有些地方不对，只要任何一个环节做的更高效，我就不会赶不上这班火车。如：上了一路绕远的公交车；下公交车打的也没在第一时间打到车；取票时也绕了远路……如果这一切都事先能安排恰当，这班车怎么都不可能落下。

哈尔滨毅腾，中超最北的俱乐部。

今年是毅腾的中超处子赛季，

现积分5分，排名倒数第一，赛季初八连败创中超历史。

刚刚结束的足协杯，点球输给了中乙球队丽江嘉云昊。

战绩如此差，即视的战五渣！

那又如何？也拦不住我这个申花球迷喜欢她啊。

从去年开始陆陆续续买了五个智能秤，分别是Withings ws-50、PICOOC Latin智能健康体脂仪、咕咚网络智能体重秤、mecare智能体重计、乐心A2 dulife智能电子秤。这五个秤都有体验超过一个月的时间，每个秤都不尽完美，有很多槽点。当然写这篇文章的目的不是吐槽，更不是横向的测评，而是想从一个用户角度思考下对于智能秤的需求。

简单说下产品

这五个智能秤大致可以分为两类，一类是Withings、PICOOC；另一类是mecare和dulife。至于咕咚智能秤，我只能呵呵。。。

Withing与PICOOC提供的数据最为全面，PICOOC提供了体重、BMI、脂肪率等所谓的8项指标，同时针对这些数据提供了一些改良建议方案。而Withing就更为全面，除了PICOOC所提供的指标外，还提供心率、空气质量检测等数值的测量。二者均有十分完善的手机端APP。

最后是咕咚的智能秤，这货真是个奇葩！原谅我暂时打开启吐槽模式！这货尽然要安装PC客户端，并且称重后需要用usb线连接计算机将数据传输过去！更关键的是，我家三台PC，就没一台能连上！如此反人类的交互、如此傻逼的产品，简直让人无语！咕咚手环发布会上还好意思说把玩意开源共享给开发者，我真特么代表开发者谢谢你们啊！

昨天的巢湖马拉松成绩是339，比去年的上马慢了近十分钟。这段时间的训练不算系统，加上现在三十多度的天气，成绩基本满意，当然本来就没抱太大希望(¬д¬。) 。只是这次全马暴露了好多问题，后半程幸亏坚持下来，才未至于跑崩。

体验地图是了解用户对我们的产品看法的重要工具，体验地图可以可视化的呈现用户使用行为流程（在产品或服务之内），他们的需求、想法、期望及对这个特别目标所有的体验行为。

除了体验地图外，有一些目的相似的做法但名称名称：顾客旅程、使用者旅程、蓝图及服务生态，尽管这些有一些细微的差别，但我还是将这些归纳在多维地图的大类别中

之前随体验团队对产品拟上线的概念功能做了一些原型测试，随着原型测试的进展，对原型测试有了一些新的看法与感悟。

首先，原型测试的方法多应用于稍大一些的公司团队，并且产品也较为成熟。若不是大公司，很难有精力来做产品原型阶段的测试，最多也只是可用性的简单测试；另若不是成熟的产品，功能需求的快速迭代上线才是头等大事，原型测试得出的优选方案倒是其次。

原型测试要有明确且唯一的目的性，尤其是“唯一”经常被忽视。大家总认为一次测试若可做多个任务可以提高效率，所以经常在主干测试方案成型后，在其中插入其他目的的测试分支方案。看似不会影响主干测试任务，但在实际的测试过程中，有多个目标的测试方案，往往会干扰到主要的测试目的，反而造成效率的低下与测试结果的误差。

同时原型测试一定要围绕唯一的测试目标去制作测试原型，将与测试目标无关的干扰因素降到最低。尽量让测试用户在使用原型测试时，将注意力集中在我们的目标之上，而不被其他的因素干扰到。比如：某次测试的目的是界面结构的合理性，但是在测试中发现影响用户操作行为的原因更多是被原型中的图片所吸引。

原型测试方案成型后，一定要在大范围测试前，找几个人试行一遍测试流程。试行的目的是找出方案实施上的问题，与测试方案的研究问题无关。这样可以及时修改测试方案，降低测试成本，避免正式测试过程中的临时修改。

选择测试人群时要注意甄选符合条件的人，这样可以减少测试误差。宁可少测，也不要为了凑人数而产生垃圾数据，影响测试结论。当然原型测试中各方面的误差难以避免，不必过于苛求完美。

最后，原型测试的结论只是给产品经理做决策的参考。和数据分析一样，原型测试只是决断的参考，而不是最后的结论。

原型测试只是一种方法，一个工具。工具与方法是去运用的，而不是去依赖的。

要说移动互联网出现频率最高的词，快速迭代肯定是其中之一。之前对迭代的理解仅仅是快，甚至为了速度可以忽视一些细节问题。

而现在对移动互联网的移动互联网产品快速迭代的理解已不再单单是“快”，更重要的是验证需求与设计，通过上线后的验证去调整自身的产品路线。所以，这就要求产品经理在需求提出时，就对此需求的整体样貌与实现目的有完整的知悉与透彻的理解。并且有计划地一步步推动这个功能上线，进而可以给开发提出不同困难程度的实现方案，便于快速迭代去验证此需求的。尽管不能要求开发一开始就把所有细节都完善到理想模型，但是需要有清晰的发展路径，在上线验证中，一步一步的去推动功能的实现。至于细节，快速迭代不是不追求细节，而是在迭代阶段，细节根本不是最主要的阶段目标，故就追求细节也就无从谈起。

所以快速迭代的目的并不是单纯为了追求产品功能上线的速度，更重要的是为了功能上线后的验证反馈效果是否符合产品经理的事先预期。

这是新的开始。

从年前租阿里云的服务器，到购买域名再到注册备案，直到上个月才将网站落实。

之前有一个写了八年的老博客，期间断断续续的更新，那里埋满了我的秘密。但每次在最低潮最无助的日子，他总在我身边。我将所有的苦闷与迷茫向他倾诉，他也很尽责地为我保守秘密。我和他就像老友，快乐时不会记起，难过时却是唯一的陪伴。

这是我的新博客，更是一个新的开始。这里不会是倾吐的树洞，她会是我的恋人，与我共同经历、一齐成长，分享生活中所经历的点点滴滴。我给她取名Antahkarana，梵语翻译过来非常美——“彩虹桥”，是沟通大脑与灵魂的桥梁。

期望在这里，我可以安静的反思自己，以期许遇见更好的自己。