浅议手机客户端设计
 

2009-06-10 作者: 盆地 来源:penddy.com

 

(一) 客户端安装

一、前言

从2004年Nokia N-Gage QD刚发行入手N-Gage QD入手开始,到现在为止使用了N-Gage QD、E60、N73、E71四部手机,平均下来每部手机的使用时间只在一年多一些,盆地也算是有些败家了。

近一两年随着公司业务的开展和工作方向的变化,盆地也从一个纯粹的使用者逐步过渡到了设计者的角色,在这个过程中陆陆续续的也有一些感悟,整理以作积累和留念。

注:由于个人使用经验集中于symbian系统的手机客户端,文章描述将基于symbian系统

二、手机客户端安装

1.手机客户端的安装包尽可能的要小

要安装手机客户端至少需要安装程序先在手机上,目前手机客户端软件放入手机一般有几个途径:

a. 通过各种方式下载到电脑,通过蓝牙、红外、数据线、读卡器等方式拷贝到手机; 这里额外提一句,广东移动有一款名为手机快车的软件,支持在没有上述方式的情况下直接通过网络发送到手机,前提需要其手机安装客户端,这一部分流量目前是免费,走的是cmnet、cmwap之外的专用apn: gdmob.gd。

b.通过短信方式下发下载地址,用户访问链接直接在手机上下载

c.提供wap网址,用户访问wap网站后选择合适版本下载

较小的安装包,可以加快下载、安装速度,并在采用手机进行下载时有效减少用户的流量费,在当前中国手机流量费并不便宜的今日,这点优化还是有一定价值的。

2.安装过程可以适度提示

symbian系统在软件安装时是可以弹出提示文字的,在这里可以将一些客户端最主要的用途、特别注意事项、最吸引用户的要点等用文字展示出来,便于用户在使用前会有一些印象。

这个提示有两点要注意:第一不能过多,一般有一次就够了,因为这些提示都是需要用户确认的,屡次打断用户的安装可能会导致用户中断安装;第二对于追求装机量的客户端,可能没有更合适,多了一步操作还是会降低用户装机的成功率。

3.如果条件允许则进行正式签名

s60第三版开始引入了签名机制,一方面一定程度上增加了安全机制,另外一方面,其实也是一种盈利手段。每次正式签名需要200美元,而如果不是正式签名则会提示安全信息。这一步提示带有警示性,也会进一步降低用户的安装比例。

4.根据实际情况设置安装后自启动

symbian系统是可以做到安装后自启动的,比如google map、手机大头等都是采用安装后自启动的方式。这些方式的好处是安装后首次不需要用户寻找到安装位置而直接进入,避免因为用户寻找产品未果而造成的客户流失。

但安装后自启动的方式在部分用户来说会有流氓行径的感觉,特别是安装后自动联网并占用用户流量等情况。如果相信自己产品的吸引力能够足够抵消这些反感带来的负面影响,则安装后自启动不失为一种较好的选择。

(二)客户端启动

一、前言

客户端启动没有太多的元素,基本上是三种场景的组合:

1. 启动界面 2. 提示信息 3. 主界面

下面根据自己的一些知识谈一些个人的看法,盆地平时忙于具体的事物而较少做总结,随着时间的推移,有些曾经的经验教训可能也就逐步遗忘,付诸于文字是有效保留这些收获的手段。

二、启动界面

在一些较为简单或启动较快的手机客户端中,可能会省略掉启动界面,但作为用户使用手机客户端已经被培养形成习惯的第一个界面,一般还是会使用启动界面的。

注: 即使处于启动界面,也应该给用户提供退出的选择,即所谓的逃生出口,避免因为启动出现异常导致用户一直停留在此界面无法处理。

在symbian系统上,一般情况下会采用设置在启动时右软键为退出按钮的方法,但为了美观一般退出或取消的文字提示不会显示在启动界面中。

1. 使用场景

启动界面一般会在如下几类情况下使用:

a.信息获取和数据交互 启动过程中进行登录、认证、网络数据获取、大量本地信息读取等需要较多时间,为避免用户被动等待,提供对用户有一定价值的启动界面,以降低用户对时间流逝和等待的在意程度。

b.介绍和帮助 启动过程中向用户显示值得用户注意的信息,比如显示symbian认证信息提升用户信任感、显示手机客户端关键功能在用户使用前形成初始印象、显示帮助信息等。

显示symbian认证信息的好处是对于了解的用户会增加信任感和认同感,不过由于相当多用户并不了解什么是s60、什么是认证以及认证有什么好处,所以盆地个人还是认为在非必要时可以不显示此信息,避免造成在启动时即让用户有一个疑惑。

当用户在使用产品时连续几次遇到未知时,用户会产生明显的挫折感,一般情况下继续探索和使用的兴趣将会大幅降低。

注:如果盆地所获取的信息无误,启动时显示下图代表经过symbian认证,相对来说具备可信性,并且一般情况下会提示此程序将会使用用户哪些资源,比如提示使用电话功能、短信功能等信息。

c.营销和推广 由于启动界面是大部分手机客户端中用户使用时必经的阶段,在此界面中加入的营销和推广信息理论上会获得相当高的曝光率和到达率;当然,由于这里是启动界面,所以适合做一些纯展示而非互动类的营销和推广信息,如果是互动类,则适合在其他场合而非启动界面中进行。

d.节日、特殊日期提醒 此种使用方法在手机qq中较为常见;这种方法属于用户体验的细节,实现上需要动态获取数据,由于启动是常见手机客户端使用的第一个界面,所以一般需要提前下载,或下载后下次启动使用;

如果采用此种方法,可以考虑学习手机qq制作带有品牌特色的节日、特殊节日的启动界面,以加强品牌潜在影响力和强化品牌效应。

e.版权和品牌强调 有相当一部分手机客户端会在启动时专门提供界面强调版权和品牌,以起到宣传和影响用户潜意识的目的。

2. 常见元素

a.Logo 基本上是必不可少的元素,便于向用户强调品牌和加深用户对logo的熟悉程度,同时如果有多项产品,用户看到logo即知道是什么公司或什么人的出品。

b.进度条 凡是涉及较多信息获取的启动界面基本上都会出现进度条,进度条是一种用户所熟知的并可以降低用户等待时焦虑程度的非常有效的方案。

进度条的选择应该以用户所熟知的一些进度条为基准,避免出现自由发挥的不像进度条但用来表达进度条含义的情况。

进度条的选择,盆地个人有如下建议:

1.难以估计进度或无法估计进度的loading条,可以采用循环进度条的形式进行,但滚动速度应加快,较快的滚动速度会使用户一定程度上形成错觉,认为产品启动很快或产品很快。

下面是一个简单示例(photoshop水平有限,不要求美观,只要求说明清楚),可以考虑采用此种方式或其他循环性质的进度条,滚动速度建议较快。

2.可以估计进度的loading条,包括可以精确估计的进度条(此种情况比较困难),建议采用先快后面的展示形式。

比如前百分之六十或七十是以较快速度完成的情况,用户会形成一种错觉认为启动进度较快同时因为进度很快超过一半以上,因为用户已经花了一些代价且离成功不远,从而更愿意等待。

c.版本信息、平台信息、厂家信息等

d.帮助信息、营销信息、推广信息、认证信息、介绍信息等

e.节日信息、版权信息、公司信息、品牌等

三、提示信息

提示信息一样属于手机客户端启动的可选步骤,一般情况下会在如下场景中出现:

1.登录、注册、获取信息等其他情况出现异常时

在启动过程中,如果由于某些原因未能成功进入主界面,则应该弹出相应的提示信息,这些提示信息应该绝对清晰的告知用户异常,并相对清晰的告知用户可能原因和提供解决建议。

2.有新版本时的提示

有不少手机客户端会在启动时检测新版本,并设定在有新版本时提示用户。版本检测和提示是否都放在启动时进行可根据实际情况调整。

需要注意一般情况下升级会有强制性升级(即不升级无法继续使用)和非强制性升级(不升级可以使用,但可能有功能缺失或其他缺陷)两种。

3.权限确认

此种情况较常见于kjava手机客户端,由于受虚拟机和系统限制,在使用某些功能例如网络访问能力等时会弹出提示询问是否允许。

这里关于kjava的权限确认有一个值得注意的细节,由于在登录时可能仅用到网络访问权限,但在使用中又会用到其他权限:比如读取用户资料等,此时就会有两种做法:

第一种是在用到时提示用户确认,第二种是在启动时即使当时没有用到也提前提示用户确认,避免后续用户需要多处确认。

这里较好的处理方法是根据是否可以在一次确认中完成多种权限的确认,如果可以则在启动时一次确认,如果不行则后续使用到具体权限时确认。

原则是尽可能降低用户确认的次数,从而避免对用户操作的打断。

四、主界面

在手机客户端启动这个环节谈到主界面,是因为有一些手机客户端会越过启动界面、提示信息直接进入主界面。

一种是进入主界面后所有功能立刻可用,比如上面提到的一些纯本地程序且需信息较少或速度较快,这种属于正常行为。

另外一种是先越过启动界面、提示信息进入界面后先让用户看到主界面的外观,同时显式或隐式的进行登录、注册、认证、数据获取等操作。如果记忆没有出错的话,手机大头应该是一个相对比较典型的例子。

这种方案会让用户感觉启动很快,但如果进入主界面后在能使用前需要等待较久时间则会带来较差的用户体验。盆地个人认为比较适合进入后是向导式的手机客户端,这种情况下即可立刻显示用户可控制的界面,又可以多步向导过程中给类似登录、注册、认证等留出隐式处理时间。

如何采用,还需要根据实际情况来;盆地个人认为是否采用需要慎重;适度的优化有利于改善体验,但过度的优化可能会带来复杂度的大幅增加,当对用户体验的改善非必须且相对于成本远不合算的时候,则此类优化属于优先级较低或可摒弃的优化。

注: 本篇内容相对来说文字较多,且属于个人的看法而非对每个人都适用的结论,如果你耐心看到这里,说明本文还有一些可取之处,不妨谈谈自己的看法以作交流。

(三)CS模式和BS模式

一、前言

关于CS(Client-Server)模式和BS(Browser-Server)模式的水很深,盆地自己也认为对此了解不够透彻,但作为手机客户端设计,如果不对CS、BS做一定程度的了解,是很容易出现一些方向性的错误、走一些弯路抑或在实现性价比上付出过多代价。

本文偏向于基础知识,产品人员很多情况下不仅仅要了解表现、交互,还需要一定程度上了解可实现性、实现代价、实现形式、实现限制等。

二、CS模式产品

CS(Client-Server)模式:顾名思义为客户端-服务器的意思,对比的话类似我们pc上面除浏览器外和服务器有交互的软件,例如qq、杀毒软件等等都是CS模式;如果和服务器没有交互,则可以认为是一个纯客户端。客户端和服务器交互的方式可以通过自定义协议、公共协议(ftp、http)等各种方式进行。

在手机上面的客户端例如Gmail客户端、搜狗输入法、来电通都属于CS模式的产品.

CS模式最大的好处就是可以相对灵活实现各种预期的功能和特效,所受的限制为系统提供的底层功能或开发工具的限制。

CS模式最大的缺点就是大部分功能新增、界面调整、逻辑变更需要更新客户端来实现。当然,通过良好的设计可以一定程度上实现不更新客户端来实现新功能、逻辑变更等,但相对来说在不升级客户端的情况下对架构设计要求较高。

三、BS模式产品

BS(Browser-Server)模式:顾名思义为浏览器-服务器的意思,对比的话类似我们PC上面浏览器使用的产品即为BS模式产品,例如google doc、各类网站等。

浏览器就盆地看来可以认为是Client的一种,只不过实现了和Browser有关的协议(http等)和标记集(wml、html等)。

在手机上纯粹的BS产品可以认为是我们常见的手机访问的网站。在手机客户端中常用的浏览器(UCweb、opera mini、opera mobile、qq浏览器等)属于这些产品的承载体。

为了增加功能,一般会自行开发浏览器,例如ucweb、qq浏览器中除浏览功能外,还默认内置了网站导航、历史浏览记录、各类频道等,即属于浏览器非协议实现和表现外的新增功能。

BS模式产品最大的好处就是可以灵活实现逻辑变更、内容动态变更、界面布局调整等。

BS模式产品的不足是受限于实现的浏览器标记集和浏览器能力,许多特殊效果无法通过浏览器实现。虽然可以一定程度上通过自定义开发来实现功能新增,但此种方法却丧失了BS的灵活性,而偏向于CS模式的客户端。

目前绝大部分的手机客户端浏览器基本上停留在支持html、wml的阶段,受限于手机性能和pc表现差异等方面,基本上不支持或仅少量支持css和JavaScript。

四、CS模式和BS模式结合产品

综合考虑灵活性、实现效果等,不少手机客户端产品会选择CS模式和BS模式结合的产品,至于其中CS和BS所占的比重则更多根据所需要实现的功能、表现形式等来决定。

例如手机QQ中,涉及到IM部分均为CS模式(这一块难以通过BS模式支持的协议来表现),而其他的频道例如资讯、音乐、书城、股票等则通过BS方式来表现。 手机msn也和手机qq类似,在IM功能实现上采用CS,而资讯类采用BS方式。手机QQ音乐中除音乐门户是BS模式外,其他都是CS模式实现。

五、一些注意要点

受限于BS模式的承载协议和支持标签集(目前和PC上的实现还有较大差距),如果不支持或难以支持的方式则主要考虑CS模式实现,而在可以实现的情况下是否实现也需要根据实际情况来。

1. 如果希望有较绚丽的效果,基本上可以不用考虑BS。

2. BS模式的产品中,左右软键选项菜单的内容基本是固定的,除了部分情况下会变化外,大部分情况下都表现的一致,这类似于浏览器中菜单的内容基本上不会根据浏览网站不同而变化是一致的。

3. 想实现通过选项菜单来控制主界面中元素的功能(例如通过选项菜单选中主界面中某个元素), 最好考虑CS模式。

4. 无法在承载协议上支持的例如音乐播放、视频播放等,则要采用CS模式。

5.希望动态加载数据,CS模式和BS模式都可以支持

6.如果希望动态排版变化,则最好采用BS模式

7.如果要在BS模式调用非标准本地能力,则需要自定义标记集

六、适配

如果采用CS模式,则基本上不同分辨率、不同系统的客户端基本都需要进行适配,即提供不同安装包,每次变更适配工作量巨大。同时不同分辨率的适配基本上都需要相应的UI配合设计和切图等。

如果采用BS模式,则在标准的浏览器标记集支持范围内,则只需要更改服务器以及根据ua不同展示不同页面。如果为自开发浏览器核心,则由于系统、平台、开发语言等不同,进行不同的适配,但由于业务逻辑和功能基本上在服务器实现,适配工作也大大减少。浏览器本身可以开发自适应的功能,在界面不包含绚丽效果的情况下,很多情况可以实现自适应。

根据业界某历史相对较旧的客户端开发公司介绍,其公司采用的为BS加自定义标记的模式,BS模式中如果需要调用不支持能力的时候,则通过自定义标记集支持,针对同一个标记集在不同平台中根据实际情况做不同解析,通过此种方式降低后台适配工作的工作量,以及保障客户端支持的功能。

七、小结

本文较为零散,很难起到循序渐进了解的效果,受限于盆地个人了解深度和表达能力的限制,估计本文对有一定手机客户端设计经验的人可能会有帮助,如果实际经验没有涉及到相关方面的话,此文帮助程度恐有限。

(四)客户端导航设计

一、前言

之前关于手机客户端导航曾经罗列一些常见的到导航设计,见下面两篇,当时本来想写第三篇的,由于手头事情耽搁下来了,现在继续此话题继续扯一下。

1. 浅议手机客户端软件导航设计(1) 2. 浅议手机客户端软件导航设计(2)

二、导航如何选择

就盆地个人的看法,可以从如下几个方面去考虑导航的选择:

1.遵从用户习惯

遵从用户习惯是指导航的操作、排列、切换等形式尽量和用户的常用软件、操作形式保持一致。比如上下键在界面上体现的就应该是控制上下焦点的移动,在播放器中一般中键就是暂停和播放的等等。

之前文章中给出的UCWEB(6.3beta)的频道切换时采用右软键来切换(后来的版本已经改为迎合用户习惯的标签形式),这一点是和用户的习惯相违背的。

Nokia的维信,虽然说理念非常不错,但在操作上更多是让人感觉新奇,用户友好性和在手机的操作便利性上不敢恭维,还好可以在电脑上配合进行一部分操作。

2.提示明显,操作响应及时

提示明显指用户可以根据固有习惯或提示知道如何操作;操作响应及时指两个方面,一方面指操作要有响应,另外一方面响应需要及时和明显。

比如魔橙的左右软键提示被隐藏,用户不试验就不知道可以操作左右软键,下方的方块其实是代表一个个频道,这个甚至会让用户猜测不出来。为了界面的"美观"牺牲了用户的体验,盆地个人认为是得不偿失的。

3.参考平台常见界面

在Symbian平台中最常见的是三类:列表、九宫格、标签三种导航方式,采用这几种方式或类似的方式设计的导航用户的学习成本会比较低。

在windows mobile平台常见的有九宫格、频道在下方的标签等形式。

这几种单独采用或者组合采用是最常见的导航形式,而有些产品的标新立异大幅增加了用户的学习成本,导致使用难度增加。

比如手机msn采用的两级导航,其中第二级导航是需要"#"激活二级导航,然后左右键选择后中键确认才能进入相应到相应频道,使用非常不便。

盆地在项目中也曾经参考过手机msn进行过导航设计,虽然对二级导航做了一点优化设计,调整为"#"直接切换二级导航的形式,但即使这样,使用起来还是非常不便。

而维信的导航如果脱离了PC端的排版和整理,在用户使用上则可用性就更差,盆地个人也认为是一个不成功的导航设计。

类似之前文章中提到的飞信3.0、MIMO等更多参考了windows Mobile平台的一些界面。

4.同产品和营销配套

导航的选择也应该和产品的类型、功能以及采用的营销策略等相配合,比如产品是一个非常纯粹的功能类似搜狗输入法、来电通、列车时刻表等,则没有必要设定九宫格、标签等比较复杂的导航方式,列表是一个很合适的选择,用户也非常熟悉和容易接受。

如果产品功能很清晰分为几块,且这几块用户都比较清楚,则可以采用九宫格方式。不过九宫格方式由于一开始进去就看到一个个块,适合功能性产品。

标签的方式更适合内容类的,可以一进去就可以看到具体的内容,不像九宫格进去只能看到一个个的宫格,从而只能对功能而非内容有直接的了解。

如果是一个需要引导使用的产品,则初次使用可以采用引导式,引导用户一步步完成。

如果是有营销需要,界面中还需要配套营销信息,包括在导航中如何排版和哪一步出现等。

5.别太急进

在手机设计和手机客户端设计发展这么多年的时间,除了这里提到的一些导航方式外,还是有很多没有提到的导航方式。

不少做设计的朋友们可能更希望在设计时达到惊艳、颠覆传统等目标,不过要知道,虽然我们可能是天才,但是别人也不是蠢材,这么多年的沉淀还是有道理的。

初期最好别太急进,也别太贪新奇,先参考现有的东西踏实做一个第一版出来,后续在小众范围内去进行新的版本的测试,根据反馈来做调整,这种方法是一种比较稳妥的选择,毕竟实践是检验真理的最佳方法。

三、小结

这里提到的一些方法、经验相信不少人早就知道;作为设计者和规划者,追求更好、更有效、更优秀的导航设计是属于产品完善和才智发挥的,不过别忘了,我们的目标是为了使用,而不是为了让别人惊叹。

尽量从好用、方便、简单的角度出发,实用的是最好的,好看的、新奇的不一定是好的。

(五)非触摸屏页面和元素操作设计

一、前言

想了好久没有想到合适的标题,目前这个标题第一眼看到恐怕很难理解是什么意思。简单解释一下,本篇文章介绍的是针对非触摸屏的手机(即键盘操作的手机)中,同一屏幕中针对页面有多个操作、或针对页面中元素有多个操作时设计的处理方法和一些思考。

虽然触摸屏和非触摸屏的手机这么多年一直在并行发展,但以nokia为首的symbian平台却是最近才在触摸屏上投入的更多精力,且目前市场上symbian平台还是键盘操作的手机为主。

这点和dos下无鼠标的情况有些类似,和目前绝大多数基于鼠标操作的web设计也有不同,本文谨从盆地自身的理解对此情况下的页面操作和元素操作设计进行一些介绍。

二、页面操作设计

页面操作设计在本文的意思是指在页面中不是针对某个元素而是针对页面或者某些功能的操作。先看下下面的三个操作示例图

这三个操作示例,不知道读者您认为哪一个较好?盆地从自己理解谈一下看法:

页面操作示例1:

优点: 把常用的操作放在最上方,把使用度不高或需要到页面下方才使用的功能放在下方,相对来说设计较为合理。

缺点:下方的操作必须键盘多次移动到最下方才能使用,操作步骤过多。

页面操作示例2:

优点:把操作放在最上方,可以方便使用各种操作。

缺点:查看具体内容时,如果左右键被定义(比如定义为为上方的标签页切换),则每次查看具体内容焦点均需要经过操作,需要无谓操作。

页面操作示例3:

优点:通过选项菜单的方式进行操作,页面比较整洁,操作比较清晰

缺点:由于选项菜单需要通过左软键或其他方式激活,用户可能第一时间会优先界面寻找而不是在选项才打中寻找,即选项菜单的内容容易被用户忽略。

就盆地个人的选择,在这些操作取舍中,建议如下:

1.保留选项菜单中必要的操作,为用户保留此入口,供希望使用选项菜单或其他地方遇到挫折的用户可以在此处获取解决方案。

2.如果左右键已被定义,最好选用示例1结合示例3的形式,避免无谓操作

3.如果左右键可以被定义为页面的左右焦点移动,最好选用示例2结合示例3的形式,避免无谓操作

这里提到的仅为建议,具体哪些应该保留在页面、哪些保留在菜单,页面中放置在上方还是下方需要根据具体的操作和是否必须等综合判断和设计。

三、元素操作设计

元素操作在这里是指针对页面中某个元素有多种操作,比如针对音乐可能有播放、下载、设为铃声、设为彩铃、收藏、评分等多种操作,我们也先看下面的4个示例。

 
 

这四个操作示例,不知道读者您认为哪一个较好?盆地从自己理解谈一下看法:

元素操作示例-1:

优点:直观

缺点:操作过于繁琐,对每一个歌曲的操作都需要多次键盘移动,从而失去可用性

元素操作示例-2:

优点: 通过选项菜单的方式进行操作,页面比较整洁,操作比较清晰

缺点:由于选项菜单需要通过左软键或其他方式激活,用户可能第一时间会优先界面寻找而不是在选项才打中寻找,即选项菜单的内容容易被用户忽略。

元素操作示例-3:

优点:和元素操作示例-1的操作对比有了大幅改进,中键默认弹出菜单用户门槛较低

缺点:中键没有默认操作,用户必须在菜单中选择

元素操作示例-4:

优点: 提供详情页面,在详情页面中操作,用户门槛较低

缺点: 不够直观,用户必须进入下一级菜单才能进行操作,对用户的引导不足,也比较繁琐。

就盆地个人的选择,在这些操作取舍中,建议根据实际情况优先考虑采用示例3或示例4的方式,综合用户门槛和使用习惯,会更加适合一些。

其中如果有对多个元素进行多选、全选等操作,则示例2、示例3会更适合一些。

四、小结

客户端设计这个话题太大,这些所谓的设计经验最主要的用途是用来做参考;在具体的产品设计中,经验的使用可以少走弯路,也可以加快进度,但更重要的是经验和实际的结合。

没有永恒的经验,只有永恒的人性。

(六)设计流程和设计分工

一、前言

就盆地个人的理解,从手机客户端设计流程来说,和互联网产品、软件产品的设计流程并没有太大的区别,盆地个人所经历的手机客户端偏向于项目,因此这里的描述也会有所偏向,同时不同公司、一个公司的不同时期、不同市场环境、不同人员配置等都会引起设计流程的一些差异,但万变不离其宗,基本的流向和关键点是不会有太大区别的。

至于分工,由于手机客户端的设计尚处于方兴未艾的阶段,虽然逐步被人们重视,但其分工合理性、技术支持度、平台统一性、从业人员数量和质量等都处于逐步发展的阶段,和互联网产品和软件产品的设计还是有一些不同的。

二、设计流程

下面谨根据盆地的了解粗略谈一下设计流程,此流程保证可行性,但不保证完全准确和正确,具体如何参考取决于读者。

1.需求提出

一个产品至少需要有第一个推动者或推动力,要么是领导的一个想法、要么是现有产品的派生或者是一份合同等。

2.需求收集

在这个阶段中主要采用各种需求收集的方法从客户、用户收集需求,如果是偏项目性,则更多从客户。需求收集虽然是一个产品设计流程的初始阶段就出现的,但基本会贯穿整个产品的生命周期,根据不同阶段和不同来源有些情况会由客服、售前、售后、销售等作为直接需求收集员。

3.需求整理

在这个阶段中根据不同公司的风格采用不同的方法和工具进行需求的整理,例如盆地所经历的产品基本上是通过如下几个输出物来进行整理,如果想要了解更标准的需求整理流程,可以参见《用户体验的要素》这本书:

功能列表: 基本上采用excel的形式进行整理,分作一级、二级功能(某些时候可能会进一步细化)来列出产品所需要具备的功能。

产品线框图(低保真):客户或者用户的需求很多时候受限于表达工具和技能,更多是通过口头、邮件、文字等方式表达,而一副画胜过千言万语,一张线框图可以大部分的表达在配色、美观之外的用户的意图。产品人员通过熟练工具制作线框图相对来说所需时间较短,可以作为需求确认和需求沟通的有效工具。

如果采用类似Axure RP之类包含交互设计的产品线框图,也可以作为和后续开发、测试沟通的有效输出物。

产品需求规格说明书:针对产品按照功能性、非功能性进行分类,随后对相关需求进行详细描述。iamsujie的产品设计中给出了一个具体的描述。

这份文档一般是一份重量级的文档,一般在时间要求较为紧张的项目中,此文档基本上都会在后期才能完成,很多时候前期是通过其他文档来完成沟通的。

这里顺便提一下盆地个人的看法,对于不是很大的公司来说,如果追求每个环节尽善尽美、每个岗位配置齐全,基本上产品就变成了无底洞,变成了属于不可完成的任务。

产品设计过程中大部分输出物的目标除了存档外,最主要的目标是沟通清楚,非大型公司的产品由于人员规模较小,异地沟通、跨产品线沟通、多方资源协调的情况不会太多,这种情况下更应该注意以有效的推进产品为目标,而不应该一味的追求流程的标准型和文档的完善性。

而大型公司很多由于分工较细、存在较多跨部门沟通、异地沟通、多资源协调、跨产品线沟通等,如果没有相对明确的输出物,在上述方面是较难推动产品的,所以一般会在输出物的规范性上要求更高一些,但其目的也是为了有效的推进产品。

有一个情况是明确存在的,即一个环节从思想到文字(语言),再从文字(语言)还原为思想,都会有不同程度的失真(受限于人类的沟通方式),其中文字的失真是高于语言的,所以沟通环节越多,沟通成本越高,沟通失真的可能性就越高。

每个公司需要根据自己的公司规模、人员配置、产品特性等去寻找适合自己公司的流程。

产品效果图(高保真): 根据产品人员配合线框图等和UI人员的沟通后,UI人员形成的效果图。此输出物是进行进一步需求确认和需求沟通的有效工具,同时也是便于和后续开发、测试等沟通的有效输出物。

不过,如果产品需求变化过于频繁,很可能出现产品效果图跟不上产品需求变化的情况,在盆地所经历的某些产品中,会在产品效果图未跟上时仍然采用产品线框图作为沟通的工具。

4.需求讲解

通过需求整理阶段的输出物向开发、测试、UI等进行讲解,使产品相关人员对产品的需求有一个清晰的理解。在需求材料明确、完善的情况下需要如此,毕竟从文字到思想要丢失太多,在需求材料不明确、不完善的情况下更要进行讲解和沟通。

5.产品开发

UI/开发配合进行产品开发,UI提供配色、效果等设计和切图(前端代码编写这一步在客户端开发中很多情况下是不存在的),开发人员根据相关需求文档进行产品的开发,测试人员编写测试案例。其中针对不明确的地方随时保持和产品人员的沟通。

6.产品测试

如果采用敏捷开发或某些开发模式,则5和6会在产品开发过程中循环出现,产生不同的迭代版本,产品的需求会放置在不同的迭代中予以实现。

7.产品上线

8.产品完善、更新

三、设计分工

这里谨针对盆地经历和了解的互联网产品和手机客户端产品设计分工予以简单描述,受限于经验,以及产品类型、行业、公司、规模等存在差异,同样的请读者谨慎参考。

1. 产品人员

  • 需求收集
  • 需求整理
  • 功能设计
  • 用户体验设计
  • 交互设计
  • 需求沟通和反馈
  • 需求文档编写
    产品上线
  • 产品完善
  • 营销配合
  • ……

2.UI人员

  • 用户界面设计
  • 切图,包含多规格适配图
  • 图标
  • 配色值
  • 设计规范

目前web设计中常见的产品前端开发(html、CSS、JS、交互效果),在手机客户端设计中由于目前技术上对css、js的支持基本属于忽略不计的阶段,所以此工作内容基本上并未正式作为UI人员的必备技能,而大部分由开发人员完成。

四、小结

在实际的产品设计中,即有一个人包办产品从设计、开发、测试、上线、营销的所有角色的流程和分工形态,也有每一个环节的每一个阶段都配备有相应人员或团队的流程和分工形态;

这里盆地套用句老话,最适合你的流程和分工是才最好的流程和分工。其他人的经验是用来参考的,大部分情况下是不适合直接套用的。如果实在不知道什么是最好的,在理论上分析具备可行性后,实践是检验的最佳方法。

(七)谈谈快捷键

一、前言

快捷键基本是PC软件中必备的一项功能,在Web设计中随着Google系(Gmail、Google Reader等)软件对快捷键的推行,也逐步开始兴起。

在手机客户端设计中,受限于手机本身操作途径有限、屏幕有限、交互方式有限等,且整体性质更加类似于PC软件,因此快捷键也是由来已久,本文盆地权且从自己的理解谈一下手机客户端设计中的快捷键设计。

二、快捷键的设计思考

1.快捷键的定位

从盆地个人的角度出发,快捷键应该定位为辅助操作功能,即快捷键可以进行的操作应该同时提供其他形式的操作路径。

快捷键是需要用户记忆的。每个手机客户端软件都可能有自己的设计,而在手机客户端上暂时并没有类似PC上的通用快捷键,例如Alt + 字母选中相应菜单,Ctrl+S保存等等,用户也没有形成固有的快捷键记忆。

用户在打开你的软件使用时,可能还没有从其他软件使用的惯性中回神过来,此时可能会造成连续的操作错误,如果用户遭遇到连续操作错误且没有其他解决方案,会对用户造成严重的挫败感。

其他操作路径为用户提供了另外一种解决道路,而且这种操作路径应该是用户熟悉的、惯用的操作。

举两个例子:

UCWEB: UCWeb中切换窗口快捷键为3,但是如果用户不记得,可以移动焦点到最上方,然后左右切换,第二个出路是用户惯性操作和学习成本最低或者可以认为没有学习成本的操作。

手机QQ: 手机QQ中默认查看消息是5,但是同时消息发送人的头像会闪烁,用户可以焦点移动到闪烁头像上,中键既可查看消息,这也是基本不存在学习成本和惯性的操作。

这里还有一个反例:

手机msn的#键切换菜单焦点的功能,如果盆地没有记错的话,是没有其他替代方案的。这时候#键就不能叫快捷键,而应该叫功能键。

2.快捷键的使用场景

快捷键,顾名思义是快捷的使用按键,即用在其他途径操作比较繁琐时的快捷替代方式。因此,如果快捷键的操作繁琐程度甚至超出了其他途径的繁琐程度,那么盆地个人认为这个快捷键是一个失败的快捷键。而如果正常操作本身就不复杂且符合用户习惯,也没有必要一定要设置快捷键,需要根据实际场景来确定是否设定快捷键。

另外,盆地认为并不是所有繁琐操作都需要设置快捷键;一来用户记忆力有限,二来非全键盘的话按键更加有限,三来不常用的操作,即使略为繁琐也不会较大影响用户体验。

即快捷键应用在常用的繁琐操作上。

还以手机QQ为例,查看系统消息、好友消息,如果不用快捷键,需要焦点移动到闪烁头像,然后中键打开查看。由于查看消息基本是手机QQ最常用的操作,所以此处的快捷键让用户基本感受不到操作的繁琐,是典型的快捷键使用正面案例。

还有一点虽然是常识,还是提一下,即快捷键适用于有键盘的手机,且快捷键需要根据是否有键盘、是全键盘、普通键盘、特殊键盘等予以考虑。

3.快捷键的选择

现在大部分的手机都是五维导航键或四维导航键,用户最常使用的按键也是导航键,所以盆地个人认为,最常用的操作应该绑定在五维导航键上。

君不见大部分的音乐播放器的最常用操作都是通过五维导航键来进行的,比如Nokia自带的音乐播放器、Last.FM的手机客户端Mobbler(参见《S60上的Last.FM客户端Mobbler》,最新版本有所更新)、酷狗音乐播放器、天天动听音乐播放器等。

在UCWeb中左右键分配给了最常用的翻页操作。

导航键如果使用恰当,可以使用户最快的熟悉产品的常用操作,从而形成良好的第一印象。

至于其他键或组合键作为快捷键,使用效率会差很多,毕竟用户的使用习惯并未形成。

针对非导航键之外的快捷键,最好在选项菜单、使用场景中或者页面相应的滚动帮助区域提供帮助,以协助用户熟悉快捷键的使用。

比如在Symbian软件常见的在选项菜单中有快捷键的菜单后标明快捷键,QQ音乐、手机msn在固定位置长期提示用户快捷键,手机qq来消息时提示的按5键等。

4.快捷键的其他注意事项

a. 尽量保持软件内快捷键的一致,避免在同一客户端不同界面的快捷键含义不同,这会对用户造成困扰。

b. 快捷键应尽量符合用户习惯或有一定含义,比如音量调节保持和界面图示一致,如果界面上为上下音量图示,则最好用上下键调节音量,或2、5(2、8)调节音量。如果全键盘,则可以以快捷键代表含义的首字母作为快捷键的选择,这点和PC上的快捷键有类似之处。

c. 快捷键提示直接放置在界面可能影响美观,需综合用户体验、操作、实现考虑,比如qq音乐当前版本已经把下面截图版本的界面数字提示去掉了,可能更多考虑了美观。

d. 在使用时提示不失为一个好的办法,不过针对不可预知或无触发的操作,此方法不具可行性,使用范围有限。

e. 上、下的状态栏是一个良好的帮助信息(包括快捷键)提示位置,需要尽量利用起来。启动界面也是一个良好的帮助场景。

f. 还是老话,没有一成不变的设计,只有不变的人性。如果前人走过的路和前人总结的经验和要做的产品一致,不妨参考一下,可能会起到少走弯路的作用。如果走别人没有走过的路,那么就要从原则出发,考虑最适合自己的设计。

三、小结

本来盆地又想通篇文字的完成本文,虽然有PhoneScreen的配合可以适当减轻截图工作量,但毕竟截取使用界面还是比较麻烦的,还好找到了一些之前截的图,因此适当放上几张,减轻一下枯燥感。这也是常说的可用性和友好性是需要代价的实证。

很多时候设计人员和开发人员会在用户体验改善上有争执,作为产品人员,需要综合考虑性价比。如果为了非明显的、致命性的用户体验改善而花费致命性的开发时间,那也是会得不偿失的。妥协,有些时候并不是可耻的。

(八)机型覆盖的一些知识

一、前言

转眼间这个系列已经写到第八篇了,一些盆地想总结的内容也总结七七八八了,后续此系列的更新速度可能会放缓,盆地自认是手机客户端行业中的一个新兵,这个系列也是盆地在结束上一份工作后进行的总结,今后的路怎么走,盆地还在思考中。

关于手机客户端,盆地也表明一下自己的态度,盆地个人认为手机客户端行业如果作为某个公司的非主营业务,在有其他收入支撑的情况下,还是有发展前景的。而如果作为主营业务的话,鉴于目前手机客户端行业中有盈利和有商务模式者寥寥无几,个人还是非常不看好这个行业近几年的发展的。

也许有人马上又会开始谈Apple的AppStore,并指出国内有某某或某某公司挣钱了,但是,相信大家也看到AppStore后来的进入者收入越来越少,产品均价越来越低,免费软件越来越多,又在逐步走上互联网服务的道路,这一点恐怕不容乐观。

而中国移动即将推出的MobileMarket被自称为梦网的二次创业,但盆地个人还是不太看好,不排除如飞信一样在投入大量的资金下被硬推了起来,也有人在这个环节中获益,但是纯靠资金推动的东西很难成长为一个真正受用户欢迎的产品,看看盆地在《飞信的用户是这么来的?》中的遭遇也许会更能理解飞信的用户数。

在3G普及已久和正版意识较强的国外,也只有Apple带来了一股创新的空气和业界的轰动,为什么呢?因为太缺乏收入模式了,所以AppStore长唱不衰,但是很多东西照搬是不行的。

跑题了,开始进入本篇的正文环节……

二、手机操作系统有哪些

目前常见的有如下一些手机操作系统:

a. Symbiain操作系统

其中包括了Symbian UIQ、S40、S60 2nd、S60 3nd 、s60 5nd、S80 、S90,其中S40是Nokia专用的非智能机的系统,由于Nokia的覆盖率过高,所以也经常会被列出来。UIQ系统现在已经停止开发了,而S80、S90也只用在之前的少数机型上面,比如之前高端的9系列,7710等手机上,现在也很久不见踪迹。

目前市面上主要常见的或者说开发手机客户端主要覆盖的S60系统,包括第二版和第三版,这些版本还会有FP1、FP2等,其中FP是Feature Pack的意思。

采用了Symbian系统的手机目前比较常见的是Nokia、三星、西门子、SonyErrison(UIQ的系统)等。

b.Windows Mobile操作系统

如果我没有没有理解错误的话,Windows Mobile的前身是划分较为凌乱的PocketPC、SmartPhone等系列,现在统一成为Windows Mobile。

这个系列也有不同的版本,不过和windows一样,基本上是向下兼容的,不像Nokia的操作系统,不同版本之间有较大差别。

c.Windows CE操作系统

国内的酷派、魅族的M8 等都是采用的Windows CE的系统,Windows CE的系统相对来说有更大的定制性,但是目前市场覆盖面较小。

d.Iphone OS操作系统

近几年很火的Iphone的操作系统是Apple根据在PC操作系统Mac OS X的经验针对Iphone开发的,目前独此一家,别无分号。

其核心采用的是Linux系统。

e.BlackBerry 操作系统

黑莓使用的操作系统,在国内相关机型似乎只由中国移动引入了一款,其他都是水货,水货性价比很高。

f.Palm操作系统

一度非常受欢迎的Plam系统,现在越来越没落了,不过随着去年宣布推出的Plam Pre,似乎最近也开始火起来了,不过采用的是另外一款操作系统,即Plam Web OS

g.Palm Web OS操作系统

随Plam Pre发售搭载的系统,之前引发了人们的无数遐想,现在根据初步评测似乎比较让人失望。

h.Linux 系统

其实有不少操作系统采用了Linux的系统,比如Motorola的e6、e680等型号,以及Nokia的n770、n800、n810等。酷派也有手机采用了Linux的系统。

i.Android系统

google主导的手机操作系统,其实也是基于Linux。

j.MTK系统

这个系统其实应该叫平台,其开发的产品需要在前期置入手机而不是后期安装的。

k.展讯的手机系统

同上,其实也是个平台,属于手机解决方案

i.kjava

这个应该算是一个环境,很多系统除了本身提供开发环境外,也提供java的环境,可以开发应用。很多非智能机也提供了java环境从此可以安装软件。

……………

三、分辨率

针对不同的手机,又有不同的分辨率,比如盆地相对比较熟悉的Symbian系统的分辨率就有如下一些类型。

176 x 208、176 x 220、240 x 320、320 x 240、352 x 416 、360 x 640等

即一旦要做覆盖,不仅仅要考虑手机操作系统的不同,还要考虑分辨率的不同。

更多的分辨率,还请自行查找相关的机型信息。

四、常见覆盖的操作系统和分辨率

一般来说,常见的客户端会覆盖Symbiain、Windows Mobile、Kjava,而近几年随着Iphone的火爆,还会考虑Iphone的覆盖。

其他的一些有些由于系统的不开放性,有些由于用于群较小,一般就被排除在外了。

关于分辨率,windows mobile的大部分为240×320的,一些新的机型开始采用VGA的分辨率,即640×480的分辨率。

针对symbian的系统,第三版大部分为240 x 320和320 x 240的分辨率,第二版则主要为176 x 208的分辨率,第三版也有少数几个分辨率为352 x 416的分辨率(176 x 208的2倍),比如盆地之前用过的e70,以及n80、e71等几款机器。而360×640的s60第五版目前是5800 mx和n95的分辨率。

至于kjava则根据覆盖来处理,一般覆盖会包括Nokia s40系列和Sony Errision系列,这两个系列受众较广。

五、kjava的限制

做手机客户端如果有kjava覆盖的话,需要适当了解kjava系统的限制。

kjava比较适合来做游戏类的产品,而针对其他需要联网、调用本地资源、文件管理等操作一般都需要权限确认甚至无法操作。

很多情况下,你会发现做kjava会很郁闷,有很多东西需要产品人员根据实际实现限制去妥协。

六、签名和认证

关于签名和认证的细节,盆地所知不多,所以不做细节描述,仅作简单介绍。

就盆地个人看法,签名和认证主要为了或的更多的权限或减少提示,目前主要是symbian和kjava需要签名和认证,不然会无法安装或过多提示,而windows mobile虽然也有签名机制,但似乎不签名问题也不大。

目前大部分的认证机构都在国外,但国内一般都有代理机构。且一般签名和认证时会有相应机构对产品进行一些测试,保障可用性、无害性等,当然,这些一般也是要收费的。

如果需要了解更多关于签名和认证的内容,请向专业人士咨询,或在互联网上寻找更多介绍。

六、结语

这一篇盆地给出了一些很基础的知识,这些描述基于盆地个人理解,其中不排除存在一些错误,如有发现还请指出。

任何一件事情如果有太多的细节、太多内容要考虑,很容易会变成一个庞大的工程,相信有不少做手机客户端的从业人员对机型覆盖这个事情非常头疼。

Iphone在成功的某一方面来说,也和其没有历史包袱,机型单一,操作系统单一有一定关系,这些很多情况下是无法复制的,其他厂商也很难摆脱历史的因素轻装上阵。

关于机型覆盖的事情,恐怕至少在相当长的一段时间内是手机客户端从业人员无法回避的一个问题,既然无法回避,还是应该多加了解和熟悉,这些对于产品的设计和能力的提升都是有用的。

版权声明:转载时请以超链接形式标明文章原始出处和作者信息

本文链接:http://www.penddy.com/the-design-of-mobile-client-sentiment-a-client-setup.html


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织