comment 0

交互设计流程小结

回忆下过去三个月做DC的流程:

首先,明确了使用场景,即用户在什么场景下使用DC。这里的DC只是一个统称,是指设备协同,它不再是一个应用。然后,抛开了之前的架构,不再在原有程序基础上进行改动添加功能。而是根据具体的使用场景进行分析,来确定最后的页面。

整个DC根据功能根据使用场景被拆成一个个小的应用:自动备份、远程浏览、播放到、远程控制。每个小应用进行单独的分析设计。不同设备上不再通过限定的形式强调软件的一致性,而是根据设备特点进行设计,再从其他方面考虑一致性:比如界面风格、设置页面的位置、信息架构的相似性、语言的一致性等方面来突出一致性。
我觉得这就是最重要的:根据使用场景、根据设备特点进行界面设计。

在phone、pad端的设计上,尽量使信息扁平化。通过使用滚动选项卡、全景视图、信息分类、多栏布局、隐藏、清晰的导航等的方式使应用更扁平。phone多使用隐藏、pad多使用分栏,二者使用了全景视图的方式。

整个流程:

1,确定使用场景,多次进行开会讨论(重构需征求多方意见);

2,拆分功能,分析不同应用的特点进行信息架构,出典型场景demo;

3,针对每个功能进行竞品分析。有详细的产品整体分析,以及简单的功能有无分析;

4,1、2进行迭代,3与1、2同步进行,确定最终场景及demo;

5,绘制流程图、确定典型use case(一般包括首次使用、正常使用、异常情况,也可以加入亮点操作);

6,开会讨论,与多方人员(技术、需求等)确定关键页面(根据功能模块进行讨论);

7,UI进行关键页面输出。如有遇到难以确定的问题,进行讨论或与PM、技术讨论;

8,GUI输出页面;

9,技术进行开发;

10,6、7、8、9进行迭代,有问题需及时沟通,小问题立即当面对,立即解决,大问题开会与多人一起解决,直到完成所有关键页面,出alpha版本程序,开始对内发布,根据反馈进行调整。

11,UI根据多方意见补充其他页面,完善UI spec,出1.0版本

12,技术出beta版程序,开始对外发布,根据反馈调整修改。

13,之后开始漫长的维护与解bug过程,A/B类bug解完后,发布正式版。

14,解bug,解C/D类bug,完善体验。同时,开始推广运营。

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注