天际汽车IOV UED项目复盘
项目涉及到的相关人员有上千人，一个复杂的软硬件一体化UED项目，两年多从0到1，可以说是将敏捷开发做到了极致。
FIRST, SHOW IT
这个项目总涉及人数上千人，是一个复杂的软硬件一体化UED实践。
这里对UED部分进行一个概要性的总复盘，记录并分享一些经验和探索性的敏捷开发工作流。
------------------------------------------
软件定义
基础操作系统的选择上毫无意外的是Android Auto，接下来的软件的定义就开始了真正极致的敏捷开发。 在系统基础上对功能和软件展开定义时，所有的功能规范和产品文档几乎都是半成品下线，由交互团队和产品团队共同完善，User Centered Design 从产品定义之初便开始与广大工程师进行博弈。毕竟钢铁理工直男是不大容易掰弯的。虽然过程艰难，但整个项目让UED部门迅速成长。 产品定义和交互定义的同步展开极大提高了前期沟通效率（没有过深度结合复杂硬件开发经验的人可能不理解我说的是什么意思）。硬件工程师、产品经理和交互设计师的沟通开始信息同步成本很低。
v0.1版本的交互框架定义：
------------------------------------------
v0.2版本的交互迭代：
框架定义完毕之后开始v0.2版本的交互定义，首先进行的是快速车控和空调模块的深入设计。这里采用的是交互定义与快速原型并行进行，交互定义有想法之后利用快速原型工具短时间内制作可验证高保真原型。 在完成两个交互方案后，用高保真原型进行内部用户对比测试，高效完成设计-调研-反馈回路。
解构重组: 之前的版本将各个功能进行了大模块到小功能的拆解，将小功能模块拆出，并平铺到了launcher的快捷操作区域。 但是，在实际的用户测试过程中，一些关联度较高的功能模块由于拆解的问题，联动效果被减弱且会产生使用效率严重降低的现象。 由于处于“高压”使用环境，过度拆解用户的操作上不但没有方便，反而造成了使用、记忆和理解负担（例如空调模块） 于是我们从新对部分功能进行了重新拆解和整合：
主观权重调研：
经过第一次的用户反馈，暴露出了“普通软件”和“车载软件”之间一些设计逻辑的不同。 两个方案产生了一些共性问题： 首先，是焦点定位问题，普通应用软件的使用场景对安全性并无过高要求，使用场景中用户处于无压环境，因此在功能的焦点定位上比较从容，车机软件完全不同，在没有达到L4级别的自动驾驶之前，用户使用场景仍处于“高压”环境下，因此定位的效率是高频车控模块的一个关键要素。
对比与改进：
v0.2版本的设计思路：
1.一致性的操作模式，弹出——操作——关闭结束
2.最短执行路径，即将更小的功能模块平铺
3.最高频与次高频功能的分层的跳转，在快速控制面板，让用户可以进行更复杂的操作
然而:
a.一致性的操作模式造成了很多冗余的操作步骤，这在移动设备上完全没有问题，但是在车载系统中无疑是极大的提高了操作成本。
b.最短执行路径的目的虽然达到了，但是相对过于密集的功能平铺给用户的功能键定位造成了一定的负担，同时过于隐晦的“双层dock”设计也使得功能调用不够直接。
c.分层的跳转设计跳转之后页面的操作逻辑变化较大，在“高压”使用环境下用户的使用负担会急剧上升，直接导致用户放弃使用。
d.功能icon的排序没有进行权重划分
------------------------------------------
v0.5版本的交互迭代：
根据调研记录和简单数据分析，我们决定V0.5版本在launcher上进行较大幅度的重构和调整：
a.将关联度很高的空调模块的组建进行了整合，并提供统一入口。
b.最短执行路径的思路沿用下来，但是进行了功能的权重划分，将主观权重较高的功能置于默认位置，其余区域放入更多功能菜单。
c.摒弃了“双dock”的设计思路，将更多功能进行整合，变成了一个集中的快捷操作菜单。这样一来虽然用户定位成本没变的情况下，界面的统一性降低了用户的使用负担。
d.据规划新增了语音助手和多屏互动系统。
e.最初交互定义规划时就采用了严格的布局定义，包括控件大小、位置、样式都严格规定，为UI的并行迭代做了准备，因此从v0.5版本开始交互和UI并行迭代。
在参加完上海车展之后我们通过搜集到的反馈即调研数据又展开了V0.9版本的迭代。 经过“抛头露面”和进行再一次的内部测试之后，我们搜集到新的反馈：
a.用户对于执行效率还是有抱怨，虽然0.5版本进行了一系列的改进后，使得部分功能为一键执行，但是另一些功能仍然要展开设置面板，而且两类功能键并没有非常清晰的能让用户区分。
b.空调模块过于强调视觉，造成使用干扰。跳转逻辑过多，操作成本较高。
c.多屏联动系统是0.5版本新增模块，也是全行业的新面孔。我们应该是第一个系统化实现的可落地并且有实际使用场景的多屏互动系统。用户的实际反馈是很有意思，但因为隐私策略的加入操作有些繁琐。
根据得到的数据和反馈，重新构思之后V0.9版本进行了更纯粹的改造。 所有默认功能键操作均变为单击执行，更多功能2次触达一键执行。将更多应用的跳转变为扩张功能面板展开，用户不再需要适应跳转，且关闭操作可以盲操。 经过讨论，决定在封闭熟人空间的使用场景中去掉多屏联动的隐私限制策略，让用户获得更便捷的使用体验，操作上极大地进行了精简。功能上也做了减法，原则是既然用户不习惯，那就减掉它。只保留最自然的功能使用体验。
------------------------------------------
v0.9版本的交互迭代：
SOP版本在之前用户体验的基础上，着手对视觉、性能、可靠性进行迭代和平衡，并思考后续运营入口问题。
在v0.5版本基础上对日间/夜间UI进行完善： 在v0.5版本基础上，为了日夜场景下得到最好的视觉体验和行车安全，完善了日间/夜间两个UI版本。实现跟随照明场景自动切换和语音免唤醒快速切换。
动画与性能： 在0.5版本基础上，SOP版本对动画和特效进行了进一步的细节迭代，帧率、性能、渲染引擎优化都被UED从设计源头加以考虑。 通过对动画效果与响应时间的配合调整，在保证视觉效果的前提下增强系统流畅感，对细节的推敲以10ms为单位进行调试。
对预留运营入口的规划： 我的账户、地图、语音助手是三个预留的运营入口，UED从着手设计开始就对车联网入口的场景和意义进行了比较多的思考，宽度和纵深度都进行了探索。
自动驾驶技术未能有效突破情况下的一些规划中的场景和应用：
车机轻游戏，低操作强度的积分类游戏，通过HUD、AR互动，积分排行+换购商城。
车载语音助手虚拟形象的个性化商城。
长途陌生人语音聊天，车队语音聊天。
被动式、主动式语音购物。
沿途地图合作商优惠推荐。
路书、旅行攻略。
------------------------------------------
后记：
后记： 辅助驾驶与自动驾驶的发展将对用户体验设计产生深远影响，机器学习在UED领域将会提供更加量化的客观可参照指标。
车联网运营时代，车场景的还原和验证是未来的一个主要方向：
1.由强调控制到泛娱乐为主的设计思路转变（受到自动驾驶发展最直接的影响）。
2.车场景下，有限精力、非沉浸的主动、被动式消费引导（非完全自动驾驶）。
3.车场景下，算法化的基于“个性”的千人千面推荐系统（效率型、种草型、性价比型、知识付费型等）。
4.车场景下多传感器数据采集情况下，数据组合式挖掘。大量的传感器是车场景特有的数据采集环境，封闭空间下采集到的大量复合行为数据，通过组合可以得出其他场景难以得到的数据结论。
------------------------------------------
项目为团队协作成果，这里感谢团队小伙伴和我敬爱的帆老师两年来对我的帮助，从你们身上我学到了非常多东西，OCEANUS很棒！
全文完
