如何处理UCD在软件开发中令人纠结的那些事

不知从哪天起,软件的交互设计不和UCD搭点边似乎是羞于启齿的事。那么为什么要UCD?vonbros设计组在实践UCD过程中有哪些遭遇,又是如果处理的呢?

UCD(User Centered Design),以用户为中心的设计,是指软件交互设计时,尊重用户使用习惯,把用户体验放在首位。

或许大家都碰到过这样的事,匆匆忙忙关机下班的时候,系统提示你有30个更新,请不要关电源,但我们急着回家,不关电源老板要考核的。又或者,点了个链接,浏览器一直在转圈圈,这时候想关闭浏览器,可怎么点鼠标也没反应,就是关不掉。这些软件的实现就是非常的不UCD!

从上面的例子可以看出些端倪,交互设计要做到UCD,一方面要设计合理,系统更新可以在下班前的时段做,比如在午休时间就比较合理,另一方面,软件代码质量要可靠,浏览器要稳定,少转圈圈,或者想关闭浏览器就保证能马上关闭。

由此可见,要真的做到UCD,至少需要交互设计师和程序员通力合作,但艺术流的设计师和技术流的程序员实在是有距离的两个频道,怎么合作呢?

首先,换桌子。vonbros 的产品经理搬走了原先的格子间,换上了一张加长的大桌子,同个项目的程序员和设计师坐在同张大桌子,可以直接面对面交流。事实证明,这大大提升了程序员和设计师的沟通效率和效果,程序员更快速到位的理解产品交互设计稿的意图,设计师也领会到有些看似简单的交互流程,需要花费较长的代码时间,从ci(持续集成)的角度出发,分步分阶段来迭代设计,更符合产品开发的大局需求。

接着,设计师直接介入产品每周的迭代测试。自己最懂自己,所以设计师进入测试,直接检查产品是否实现了设计意图,有问题马上和程序员讨论(因为就坐在身边),而每周小颗粒的检查可以避免产品开发离设计意图跑得过远。同时,设计师更接近普通用户,而非技术流的工程师,所以设计师是再好不过的前期小颗粒阶段体验用户,从设计到检查的闭环介入,在vonbros,这个时间段甚至可以小到半天,这是无法通过普通用户测试来实现的。

然后,可遇不可求的,需要一个设计和技术都贯通的产品经理。设计师和程序员难免产生分歧,这时候,设计师的UCD优先还是产品代码的简洁高效和及时交付优先?产品经理需要站在全局的角度,评估这些分歧最终对产品价值的影响。UCD 肯定是要的,代码质量和项目进度也必须把握,有时候是权衡,这个容易,哪个重要就哪个,有时候不是权衡两者的事,这个需要产品经理深刻的分析设计和代码实现。分析一番后发现,设计其实不够好,也不是用户真正需要的,代码实现可以改进到更高效简洁的逻辑流程,那么重新要求设计和代码任务吧,这样的一个产品经理能高效的推动开发的进行,尽量找一个吧。

最后,多找机会提高团队的整体审美水平吧,vonbros 经常组织团队学习讨论设计课程、参观设计展,注意是大家一起参加,包括程序员!

发表评论

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