认识达内从这里开始

我们都知道，在许多的软件设计和网站设计中，除了正常的界面和平面展示以外，还有一种功能就是用来联系用户与电脑的交互设计体现。而这种交互设计的具体表现就是通过许多不同的按钮和控件来完成的。

今天，我们就来了解一下，对于不同的软件来说，如何选择合适的控件。

3. 控件呈现

这里自查的范围主要是与交互体验关系最紧密的控件，但实际上在自查过程中可以同时检查非操作性的普通页面元素(图片、icon、信息列表、分隔元素等)，没有必要分两遍来检查。不过为了叙述方便本节还是简称为控件为主。

3.1 控件是否符合用户认知

控件的选用和设计是否合理、符合用户成型的认知习惯。合理包括形状、文字、用色、尺寸、位置、分组等方面。举极端点的小例子，“拒绝”按钮设计成绿色而“确认”按钮设计成红色、复选项用圆形而单选项用方形、过于口语化的控件文字、位置过于隐蔽、分组不符合用户习惯等等，都是不合理的例子。这点相信熟悉平台规范和业务背景的设计师都不会轻易犯这么明显错误，只是有时改稿很仓促时有可能会随手留下一些类似的小问题，在自查中还是要过一遍以防这些低级错误贻笑大方。

而实际上，控件不符合认知的情况更多来源于设计师有意为之的盲目创新。这里还是建议，在交互习惯已经逐渐沉淀的今天，在产品本身不需要在界面上标新立异的情况下尽量采用通用的组件。

项目案例：设计管理模块中，项目的文件库是一个控件比较密集的界面，二级Tab栏、上传按钮、下载按钮、右滑调出的更新和删除按钮，都能较好地符合用户的认知，功能点具有显而易见性。其中，更新按钮的icon设计原本是用了一个类似于“刷新”的图标，但经过仔细考虑，在工程行业设计文件管理的场景下，文件“更新”的本质应该是重新上传、覆盖原有文件，而不是与字面更为相近的“刷新”，因此最终修改为与上传的含义更为接近的icon，更加符合用户的理解。

3.2 控件样式是否具有一致性

即使是再细心的设计师，先后画的两个button也很难保证完全一致，因此充分通过组件化，在不断的复用中积淀自己的一套常用组件库是非常必要的。导航栏、底Bar、信息Cell(包括Cell的标题或尾注)、图片轮播或泳道等等，都可以通过组件化保证在同一产品中的呈现是完全一致的，后续即使有修改也可以统一修改、统筹优化。这样在后续视觉设计阶段中同样可以大大降低标注的工作量。还是那句话，设计规范形成得越早，后期效率就越高，所以个人更习惯在交互设计阶段就进行组件化的工作，而不是留到视觉设计阶段才进行。

项目案例：消息模块的消息列表中，根据消息的类别不同，标签颜色共设计了蓝、黄、灰、红四种(根据客户的需求，现阶段的版本中实际上只用到了红色和蓝色两种)，红色代表待办类，蓝色代表通知类。消息列表项可以通过组件化，在整个项目的设计中格式保持完全一致，有需要修改时，也可以统一修改和优化。

3.3 控件交互行为是否具有一致性

相同控件的操作反馈也要相同，简单地说，长得一样的控件操作起来也是一样的。交互行为的一致性和样式的一致性是相形而生的。对外要符合整个平台的产品设计规范，对内要与同一产品内”兄弟姐妹“们的行为一致，这样才能更好地降低交互模式的学习成本。

项目案例：整个项目中涉及上传的操作有很多，上传设计文件、上传报价单、上传合同等，对所有涉及上传的操作控件，交互行为也应该统一进行设计，以保证一致性。在交互文档的通用交互说明中，有专门的一张交互稿用于规定全平台中的文件上传、更新、下载操作的交互反馈。

3.4 控件的不可用状态如何呈现

控件常常需要一定的条件触发才变得可用，例如表单页中只有在必要信息全部填写得符合要求的情况下，”提交“按钮才可用。那么，在不可用时，是直接将控件显示为不可用，还是在点击后提供反馈提示用户需要完成哪些条件才可用?两者各有优缺点，前者让行动点的不可用状态外化，让用户直观地理解自己的状态，但假如用户不熟悉当前场景，会难以知道是缺了哪些条件导致不可用;后者在点击后可以通过toast清晰地告知用户需要哪些条件才能触发可用，但这需要增多一步点击操作。因此，两者都是可行的做法，但无论采用哪种做法，都需要在交互说明中写明，前者需要写明可用条件，后者需要写明toast的提示文案。

项目案例：发起工资核算流程中，填报工资构成的界面有两处涉及不可用状态的地方，“下一步”按钮仅当全部金额信息填写后可用，“导入上月数据”按钮仅当该员工存在上个月工资数据时可用，在交互说明中对这两个控件的可用条件以及不可用时的样式(30%透明度淡显)进行了明确的规定。

4. 数据呈现

4.1 空态如何呈现

空态是设计中必须考虑，却又容易疏漏的点。不但数据完全空缺时会产生空态，在所有涉及筛选控件的数据列表中，都有可能因为筛选的结果为空产生空态。

项目案例：在全局交互说明中，有专门的一节“14.4 空状态”用于规定可能涉及空态的页面的空态显示。

4.2 字数有限制时超限如何处理

表单对字数有限制时，超限时是直接自动删除超出部分，还是保留超出部分但通过合理的反馈提示用户删减，或其他更巧妙的反馈手段。无论选用哪种，都需要在交互说明中写明处理方式。

项目案例：项目关闭原因的多行文本输入框字数限制为200字，在交互说明中将其超限的处理方式确定为“自动删除”。

4.3 无法完整显示的数据如何处理

移动端界面的宽度有限，数据量较大、无法在指定行数内完整显示的情况很多，尤其在未对字数进行限制的情况下。那么此时是截断并用”…”提示未显示完全，还是让信息块的高度与内容自适应、多行显示，或者其他方法?一般而言，如果有另一个页面可供用户查看完整的信息时，可以使用前者，从而让页面更规整也更简洁;而对唯一性的显示，或者这已经是信息显示最完整的页面了的话，显然必须全部显示以保证信息的完整性。同样的，无论采用哪种处理方式，都要在交互说明中让视觉设计和开发同学清楚你的想法。

项目案例：供应商名录模块中，供应商列表中会显示供应商名称和供货范围，而供货范围由用户按需要任意填写，可能很短也可能非常长。而由于在详情页中可以(也必须)让用户查看完整的信息，列表页中为了避免视觉上的混乱，可以采用“…”在行末截断。而这些要求需要在交互说明中写明，一种简单的做法是默认在行末用“…”截断，而需要多行显示完整信息时特别指出即可，毕竟后者只占少数。

4.4 数据过期如何提示用户

来自网络的数据过期时如何友好地提示用户?

这点在无论C端还是B端应用中的收藏功能中比较集中，例如C端电商应用中，用户收藏的商品已下架，或者用户正在查看的活动已过期的情况，音乐应用中用户已收藏的音乐下架的情况等等。B端应用也有类似的设备、隐患点、现场图片之类信息的收藏功能，如果用户收藏的信息对象已失效(例如被上传者或管理员删除)，在用户通过收藏页访问时该如何提示?

先举个我们都很熟悉的例子，在用户体验方面的口碑有目共睹的网易云音乐，唯独在歌曲因版权问题下架的处理上，采用了没有任何提示、直接从用户的收藏列表里悄无声息地删除的做法(最近我没有收藏的歌曲出现下架的情况，不太清楚后续版本中有没有改掉这一点，这里的吐槽只针对当时的版本)。这导致用户经常都在歌单里找了半天才发现某首歌消失了。在版权越来越受重视的时代，曲库版权的规范化是用户都能理解的，但对歌曲下架的处理，个人觉得完全有更合适的方式，例如仍然将其保留在用户的收藏列表中，并以一个特殊的样式呈现，双击时弹出toast提示用户”该歌曲已因版权问题下架“。所以，直到现在我也不知道云音乐这样做是出于怎样的考虑。

项目案例：项目现场图库中，用户可以将自己经常查看的照片加入“我的收藏”，而根据客户的需求，项目图库只是方便员工进行现场图片的暂存和分享，并不是一个权限级别非常高的资源库，因此，基本上项目成员都有权限在现场图库中删除认为没有用的照片。而如果A用户收藏的照片被B用户删除时，在列表中将如何显示?点击后又如何处理?这些都是要在交互说明中明确的方案。

4.5 数据按什么规则排序

涉及数据排序的列表，无论有没有可以调整排序方式的控件，都要在交互说明中注明默认的排序方式。这点还是比较容易漏的，画原型时可能只是随意设置了一些虚拟的数据，不会太考虑它们的排序方式，而这恰恰是开发同学最关心的问题之一。

项目案例：设计文件库中的文件列表，按更新时间倒序排列，未上传文件排在最上方，有多个未上传文件时按文件名倒序排列。

4.6 数值是否要按特定的格式的显示

数值的展示和输入，都需要确定的呈现格式，小数可能需要确定的位数，大数值可能需要每隔千位用逗号分隔，这些同样是需要在交互说明中体现的。

项目案例：工资核算流程中，确认工资信息的信息列表中，所有金额都采用两位小数格式显示。

4.7 数据是否存在极值

涉及数值(或日期等)输入和选择的控件，有没有设置极值以帮助用户防错?如果有，在输入值超过极值时如何提示用户?

项目案例：新建任务时，”开始时间“和”计划结束时间“选择器都有相应的极值限制，允许范围以外的日期不可选：”开始时间“只有今天后的日期可选，”计划结束时间“只有开始时间后的日期可选。

达内时代科技集团致力于培养面向电信和金融领域Java、C++、C#/.Net、3G/Android、3G/IOS、PHP、嵌入式、软件测试、UID、网络营销、网络工程、会计、UED、web、Unity3D、大数据、童程童美等17大方向中高端软件人才课程与少儿教育课程。选择太原软件开发培训，不再孤军奋战，轻轻松松做IT高薪白领。太原达内培训带领有明确目标的学子迈向成功之路!想找工作的求职者可以加QQ：3373924515（太原达内就业服务部）咨询了解。