程序员说系统体验

    这篇在脑子翻滚了一整天了,上午开始构思到现在才能动笔。

    在现在的团队又启动了系统的体验升级工作,催来催去的不见成效,所以上周没忍住,自己又冒出来,把如何做体验从头分析了一遍。想想还是要里面的要点写下来吧,积累起来便于后续使用。

    首先我们来解决两个问题,第一个体验升级工作不是什么;第二个体验升级工作是什么;

    首先,体验升级绝不是一群人坐在电脑面前,看着一个软件界面,然后大家说这个不好看或者这个挺好看,是不是挪一下这个按钮。这是拍脑袋,是很难拍出好的体验的。

    然后,体验升级是什么呢,是来解决三个问题的,第一个是“认知障碍”;第二个是“操作动线”;第三个是“价值引导”;

    因为我是做后端系统研发为主的,所以我只分析前两个,最后一个不分析了。

    在开始分析上面内容之前,我们先来说说,体验的好与坏的界定。一个软件系统的界面设计一定是分好与坏,但是大家往往只能给出很感性的评判,比如不好看、用起来很别扭等等,这些评价是很难映射到具体的设计中的,所以体验提升就变成了一件非常难的事,猜别人是怎么感知你的软件的命中率一定会非常低。

    所以,我把一个系统操作环节分成了3个阶段来分析,那就是“事前”、“事中”、“事后”。

    事前事后,是大家特别容易忽视的地方,一般想要提升一个环节,我们大都完全针对这个环节的过程去分析和优化;这是不对的,这意味你把它视为一个点,完全孤立的点,但是我们都知道,没有什么是独立存在的。每一个环节一定有前置工作和后置工作,甚至有协同工作,把他们都连起来才是一个完整的动作,所以抛开前后左右只分析当事环节是个低效、低质的动作。

    事前主要是指前置动作和前置任务,举几个例子比如:想看微信的消息首先你要解锁手机、写文章之前首先要构思、操作收货首先你要知道收货这个功能菜单在哪里、想上架货物你要把货拉倒货架边上......等等很多吧(为了适应性高点,所以例子用的都不是软件系统的),以上的内容很明显就涉及到认知障碍,所有前置动作都涉及一个问题“我怎么知道!!”我们习以为常的动作并不都是合情合理,所以一个人要做某个动作首先一定是他怎么知道去哪做,然后紧接着要问怎么做。再举个例子,我们都知道iphone的指纹识别在home按钮上,但是三星的指纹识别在手机背面的摄像头边上,Sony的指纹识别在侧面的电源按钮上,是不是涉及“我怎么知道!”问题了,打破常识是非常重要的动作,常识是一种约定俗成的协议,但是你确定你的协议和对方的是互通的吗?豆腐脑到底是放糖还是放卤呢?

    事中是大家研究的最多的,不多说了

    事后主要是指后置动作或者收尾动作,我们肯定都会跟踪任务的进展,“跟踪”是一个后置动作。比如吃完饭总是要刷碗的吧,刷碗确实不是吃饭的一部分,但是很强烈的影响了一批人的决策,想到在家做饭要刷碗就干脆出去吃饭吧或者点外卖。

    所以事前-事中-事后,串起来才是一个完整的动作链,优化动作要全盘考虑,不能只是考虑事中。   

    认知障碍

    上面已经对认知障碍做了一些分析,大家是不是清楚什么是认知障碍了,认知障碍就是设计者认为用户知道但是用户可能不知道或者不能清楚的知道的部分,更多是大家在于成长、教育、工作经历的不同所以在认知上生成了不同的认知树,但是又认为互相是一致的,又涉及设计者缺乏同理心,做不到换位思考,所以默认认为自己想到的东西就所有人都知情了。还是不清楚的就自己延伸一下,琢磨吧,不赘述了,想深入的兄弟可以看一下批判性思维。

    软件中如何解决认知障碍呢,这里我们不分事前-事中-事后(区分的话要写太多了)的说有几种办法

    第一种将文档和软件融为一体,可以在每个控件边上添加尽量多的解释,但是这样界面看起来确实比较繁杂,但是繁杂的界面也是比完全不知道如何使用要强。

  也可以制作很贴近的帮助系统,我们都知道在微软的软件中按F1你一定可以得到帮助,如果做过.Net开发的一定很怀念MSDN是多么强大,所以也可以用优秀的帮助系统来解决。

    第二种使用图形化系统,前几年流行过用各种直观的符号来制作软件,既避免了软件上有厄长的说明又可以启到很好的引导效果,而且看起来软件很高大上、超级简洁,但是“直观的符号”这个东西本来就带有认知障碍。

    不列更多了,大家搜一搜应该都能搜到。

    总而言之,不管用哪种方法或者各种方法混合使用,要解决最关键的问题就是要让软件如何“自描述”,善用上下文、不要吝啬做衔接、做一些文档、引入一些直观的符号系统,站在用户的角度多思考一定可以解决认知障碍。

    应用软件设计中特别普遍且严重的问题就是开发者对使用场景的上下文和衔接忽视的特别严重,因为往往这一个功能是由一个或者多个开发者开发,上一个相关功能是由另一个或多个开发者开发的,开发团队的分工天然就是以一个一个的点在开展。做应用系统的产品由往往关注点又在业务上,所以没有人来串联上下文。衔接这个问题是最逗的,基于上面的开发模式软件系统天生在衔接上就有短板,然后往往产品或者开发者还特别倾向于设想我提供了一个超级自由的场景,所以往往是本来相互关联的环节反而散列在系统中,没有任何衔接动作。这种软件真交付了,用户就精彩了。其实这是同理心和设计缺乏模式的体现,大部分应用系统的产品经理都是说业务头头是道,说系统设计完全不通,这样是做不出好的软件来的。

    操作动线

    解决了认知障碍后需要解决的下一个问题是操作动线,动线是从家装行业借的一个词,本意是为了规划家具和活动的分隔,让家里的人有合理的移动方式。我们借用过来放在软件系统里,用来规划操作人员在界面上的处理路径。合理的处理路径可以降低认知障碍提升处理效率。

    下面是我们某个系统早期设计的动线

 

    大家可以看到明确的操作路径,但是这个在落地后还是有很多不舒服的地方,主要体现在动线过于单一,没有回馈动线等问题上。设计动线意味着我们对用户的操作是有预期的,这个非常重要。有预期就意味着我们在脑中正式的模拟过用户的操作流程,并由此对用户和系统都作出了相应的调整。这样系统和用户在操作上有基准可作为沟通的基础。

    以上我想就是系统体验升级的内容吧,原定还要写插件化和配置化所带来的问题,仔细思量上面的内容都是关于界面优化话,所以我们把插件化和配置化后续单独写一篇。希望上面我写清楚了

posted on 2018-12-14 16:08  水一  阅读(581)  评论(0编辑  收藏  举报

导航