产品历程
跟着一款产品从0到1，为了做好一款产品，跑了1000公里。
这个历程要从16年的夏天说起，5月份正式加入团队开始做App，团队是刚组建的。又通过2个月的完善，产品团队达到20人左右，开始是PM-UE-UI-RD，后来测试和用研也陆续加入。
产品的规划和方向已经确定：全程服务马拉松和越野赛事；专业的个性化马拉松训练计划；丰富的跑步、马拉松赛事资讯；保存完整的比赛和训练记录的个人主页；精确的GPS运动轨迹记录。
在一年的时间里不断的去增加和完善这些功能，还有一些新的功能不断加入。采用敏捷开发模式，基本上2～3周一个版本的节奏。经历了从高速迭代到平稳发展的整个历程，不光是产品，整个团队也一起磨合成长，有一些感悟分享一下，这也可能是大多数初创团队共同存在的问题和经历。
那就以UI的视角，产品迭代的历程为线索来回顾一下吧：
刚开始产品有三个板块：训练/比赛/个人中心，已经在开发测试阶段，UI界面是外包做的，和市场上的App差距还是很大的。训练模块暂时只支持手动打卡，比赛页面是网页嵌入的，个人页面只有我的比赛和训练动态。
V1.0
在对公司业务和产品还不是很了解的情况下，第一个切入的项目是跑步界面，相对来说比较独立，不到一周的时间，对市场上的轨迹App做了调研，有nike+、咕咚、悦跑圈、Runkeeper等等，由于轨迹的开发在技术上是有挑战的，对界面的设计也有一定的限制，能够快速开发原型并稳定运行为目的，界面风格简约为主，能让用户沉浸在跑步中。
跑步界面
其它板块也在完善中，沿用之前定好的排期，主要是训练板块，想通过专业的马拉松训练来吸引用户使用App，而不是报完名就走了。还开发了跑力计算等比较方便实用的小工具。在做UI的同时，刚好公司在做品牌升级，还需要同时兼顾VI的设计和输出。差不多在7月的时候才全心投入到App的设计中，开始做改版。
V1.5的改版对主要页面进行了设计，包括icon/插画的风格，按钮/标签形状的统一，组件的间距和样式，整体的色彩、字号等等，并建立了设计视觉规范。在ios10之前，尝试了新的设计趋势，在必要的地方采用卡片式设计、弱化线条/色块的分割，边角更圆润，tab bar上的线描icon用成色块样式的等等。用留白来减轻页面给用户的负担，最简单自然的表达方式减少页面的元素以及杂乱的色彩，让用户可以快速聚焦到内容本身。没有特意的追求趋势和流行，形式还是由功能决定。更符合产品的行业属性，充分考虑用户群体和核心用户场景，提升产品的品质感和专业性才是最终目的。
引导页
V1.5
V1.6-V2.0App在下半年不断完善，个人主页/照片展示/自定义训练计划/社区活动及社交功能/打卡贴纸分享/iWatch控制轨迹/比赛报名支付...。在V1.8的时候针对安卓用户还做了一次MD的改版。不过这次针对安卓的改版有点囿于规范，很多地方没有结合品牌特性，在更灵活的MD2.0中可以看到我们踩过的一些坑。
V1.6-2.0
MD安卓改版
iwatch跑步界面
从V1.5后产品的管理开始采用新的工具（JIRA），半年多磨合下来，团队上下游配合的默契度已经非常高了，不能用眼神确认过来形容，至少在沟通的过程中很快能达成共识。从刚开始的开会一开就是半天，各种会议，到后来会议频率和时间都减少很多。
产品流程总结：
1.需求&设计
细化需求，不在一个版本做很多事情。
将大功能拆分为小的迭代周期，持续优化。
在需求确定初期，就引入各方同事，交互、开发、测试等角色共同确定需求的估时和优先级。
产品经理和交互设计师将最终确定的素材提供给开发同事。
产品经理和交互设计师充分考虑边缘情况。
交互设计对功能的优先级需要进行判断，设计时有取舍。
交互和UI设计同事即时反馈，最终需要确定设计稿是否对应。
UI设计师可在需求确认时就开始调研工作，尽早和产品交互同事沟通。
2. 开发&测试
开发同事对新技术的采用进行简要的介绍，协助产品和设计同事的工作。
开发同事更细致的看交互设计做评估。
分拆功能开发减少团队依赖的问题。
iOS和Android的功能同一套代码实现，但视觉效果分开实现。
测试中发现问题直接找负责该功能的同事。
开发人员保证代码输出质量，完成基本测试。
3. 团队合作流程
任何团队成员发现当前开发版本有遗漏的功能和bug当天汇报。
在开发过程中发现估时不准，尽快提出，供团队参考。
暂定时间节点如下：当前开发周期进行到一半时，不再修改交互和UI，按照定稿确定开发最终实现的功能。
注意事项：
1.需求文档写清楚需求背景和目的（数据指标等）。
2.评审之前，需要至少提前一小时把设计稿发给大家。
3.交互和UI评审会直接提出问题，会前相关人员必须认真审阅设计稿。
4.每周一、周三发布正式的测试版本，发布时开发人员须说明更新内容。
5.对于正式的测试版本，UI/UE的同事须提供测试报告给测试负责人。
6.产品同事对正式测试版本进行埋点检查，将检查结果提供给开发负责人。
7.测试完毕后测试人员须将bug提交在jira上（标记label是哪个测试版本的bug），在confluence的各版本日志中记录每个测试版本的bug数及相关情况，并与产品人员共同确认bug是否需要在当前开发版本中修复。
8.按照版本评估测试和UI/UE调试的时间，版本估时时考虑到这部分耗时。
9.演示前参与本版本开发的同事都必须测试过演示版本，并认可已达到演示标准。如没有达到标准，推迟演示。
10.演示或上线时间有延迟时，明确延迟的原因，责任到人。
在经过半年多的高速迭代后，有了一些数据的沉淀，开始重新思考产品的定位，当时大家对产品都提出了一些自己的看法。
尽量跳出自我，站在用户的角度，针对App的主要功能、框架结构、用户体验做了详细的分析和总结，主要分析了这几个板块：成绩照片/比赛/训练/媒体资讯/社交。
细节就不多说了，diss了成绩照片和训练，成绩照片在搜索、排列、上传、查找上存在很多体验的问题。训练除了基本的轨迹记录，在训练计划中也存在着很多体验的问题。甚至怀疑它存在的价值，半马以下用户是不会用我们的训练和轨迹的，有nike+，悦跑圈刷个10公里装逼就可以了。对于初级跑者参加半马和全马会用，公里数和配速有参考价值。训练有就可以了毕竟它是个工具，其他产品做得也足够优秀。不指望它能吸引多少小白用户来跑步记录，能提供给初中级跑者训练完赛就可以了。除非做得又专业又有差异化，目前成本比较高。
比较认同的是比赛和媒体资讯，比赛页面有评论和日记可以参考和互动，这是价值沉淀，相比其他平台只有报名会好很多，比赛比较全，赛事有参考价值，把功能补全应该还是很有优势的。媒体资讯的文章很专业&深度，用户原创这些都是内容产出，这也是价值沉淀。社交的话也是需要做很多规划的，这里存在一定的战略层的问题，怎么提高用户活跃度，需要运营资源的大力支持。
收集大家的反馈以及数据的分析后，17年2月份V2.1App开始改版，产品从战略层到框架层都做出了改变。首页从原来的训练改版为资讯，弱化训练模块，完善比赛/报名相关页面的流程和用户体验，在个人页面更好的服务好跑者的整个参赛流程。
v2.1改版
之后的版本基本上就比较平稳了，陆续加入众测模块、优化搜索功能、建立用户等级体系等等，不断的完善设计规范，用iconfont来管理图标库，创建组件库，开始考虑产品的情感化设计，将品牌基因渗透到更多的页面中。在赛事页面的改版中，从立项开始就全程参与，还参与了用户调研，感受不同级别用户在参赛中的不同体验和需求。团队在产品推进中的配合和共识又上了一个台阶。
空白页
设计规范
产品初始阶段可能存在的问题：
1.被限制在产品中，一直在填坑，用户到底喜不喜欢这个功能，需不需要这个功能，发现需求而不是创造需求。
2.每一阶段有点草率，一直在追赶时间，感觉还不够透彻，花半年做了10个功能，5个功能用户不会用、不好用，不如做5个想用又好用的，别人有的我们不一定也要有，别人没有的我们可以把它做好做精。
3.风格和规范是基础，定制化和创新探索是要必须去尝试的，虽然比较和模仿是必经之路，最终目的是还是超越竞品。
4.光有骨架和经络是不够的，还要有血有肉皮肤白嫩滑弹，运营设计质量要上来。
最后做一些总结：
跳出自我和界面来做UI设计，试图站在用户的角度和使用场景去思考，反思需求和交互的问题，尽力用视觉来解决，不能解决的一定要及时沟通达成共识。反思需求和交互的问题是设计过程的一部分，与开发跟进细节，很好的还原设计也是设计过程的一部分。
UI就像经络和骨架，骨架即布局，经络即用户达到目的的视觉流程，怎么让这个流程更清晰、布局更合理，这是基础。然后再去考虑更深层次的问题，交互体验、情感共鸣等等。
设计要符合原则，又不能只符合原则，不管原则、方法、流程都是没有统一标准的，要学会变通。
数据是设计师的工具，它是被设计师使用的，而不是反过来把设计师变成奴隶。
设计被用户接受，产品推向市场前没有人能做判断，只能说一个设计顺应潮流或者风格很有自己的特色，但我们不知道用户会不会喜欢，只有推向市场之后，才会有一些反馈，一些声音，一些数据，慢慢得知人们对设计的评价。
存在是为了不存在，视觉（UI）设计所做的一切，只为了更好的服务于流程（UX）。
