认识达内从这里开始

随着移动市场的发展，许多的同类型app充斥在各大应用商店之中，区别也是大同小异，基本内核可以算是差不多的，但是，为什么还是有热门与冷门的区别的。一般来说，这些都与软件设计题材以及文案的展现有一定的关系的，当然了，后期的数据反馈也是必须的。

今天，我们就来了解一下软件设计的文案展示方法。

文案呈现

5.1 句式是否一致

相似场景中，页面标题和页面标题之间的句式结构要保持一致，文案与文案之间的句式结构也要保持一致，总之，相应位置的文字句式要始终一致。

项目案例：所有流程的成功提示页中，页面标题都是“动词+对象”(标题为动词、动词短语也是iOS设计规范建议的方式)，而主提示语都是“宾语+动词+成功”的句式。避免有时因为“好像这样读起来更顺一点”就写成了“宾语+成功+动词”(如：采购流程成功关闭)或者其他句式，哪种句式更好是语文问题，这里不做探讨，我们要做的只是保持一致。

5.2 用词是否一致、准确

操作、称谓、反馈中的用词同样要保持一致，并且应当在准确、不引起歧义的基础上尽可能简练。

项目案例：涉及表单提交的操作都用“提交”而不是混用”确定“、”确认“，涉及新建的操作都称为“新建”而不是混用“创建”、“添加”，涉及对当前用户的称谓都用“您”而不是混用“你”，涉及成功提示的反馈都用”成功“而不是混用”完成“、“结束”，诸如此类的细节往往是反映一个设计师是否足够专业和细心的重要指标之一。

5.3 文案是否有温度感

文案需要让用户感觉到产品的温度，对C端应用而言很好理解。而即使是B端应用，在必要的场景下，文案内容也应当在不影响表达的准确性和效率的前提下，避免冰冷的机械感，应结合场景和用户角色融入恰当的情感。

项目案例：在一个项目各专业验收完成，项目经理执行“完成项目”操作时，附言提供了具有温度感的默认文案，相比冷冰冰的“本项目已全部完成”，即使收到通知的员工知道这是系统提供的默认文案，也多少会心头一暖吧。

6. 输入与选择

6.1 是否为用户提供了默认值

是否为选择控件提供了默认项?输入框内容为空时如何显示?输入框获得焦点时，默认文字是消失(即仅作为提示文字或占位符)还是保留(即作为可编辑的默认文案)?

项目案例：这一点其实在前面一些例子里已经提到过了，像5.3节案例中提到的默认文案。这里还是用4.7节里讲过的“新建任务”页面的例子吧，因为确实比较典型。项目经理在项目中新建一个阶段任务时，需要选择专业、阶段、开始时间、计划结束时间，并填写任务描述，如果不提供默认值的话，创建多个专业的多个任务对项目经理是一件非常繁重的工作。因此，设计中为每项都考虑了默认值。

其中，有一部分是用户可能可以直接使用的，例如“阶段”的默认值为当前最新进度的下一阶段，“任务描述”的默认值是“阶段+(专业)”的字段组合，“开始时间“的默认值为今天。

有一部分是便于用户的选择，例如“计划结束时间”的默认值等于“开始时间”，虽然用户肯定要重新选择一次，但基于“开始时间”点去选择一段时间(比如半个月)后的日期，至少比基于一个“1900年1月1日”之类的点去选择要方便很多。

而还有一部分是无从预计默认值的，这不代表可以随便用一个选项作为默认值，而必须提供一个“未选择”选项，例如“专业”，如果很随意地默认“工艺”为默认值的话，用户很容易稍一疏忽就提交了一个专业隶属错误的任务，而默认项为“未选择”，则可以让“提交”按钮在这一情况下不可用，从而起到防错的作用。

6.2 输入过程是否提供提示和判断

是否在输入过程中为用户提供提示?是否执行输入判断，是在输入过程中执行、失焦后执行还是提交后执行?经判断输入不符要求时如何提示?

项目案例：“忘记密码”流程中要求用户输入自己用于登录的手机号，这里对手机号格式的判断就是一个典型“提交后执行”的处理。无论采用哪种方式，都要在交互说明中写清楚。

6.3 是否存在不必要的输入

是否存在以下不必要、甚至会引起逻辑错误的输入(这里的输入包括键盘输入和选择等多种输入形式)：

(1)如果某个数据是对应整个流程全局的，那么在这个流程内部，显然这个数据不需要再重复输入，每多一次输入就多一次错误的可能。

项目案例：按照客户公司的设计文件编号规定，完整编号的格式是”项目号(6位数字/字母)-专业缩写(2个字母)-文件类型缩写(2个字母)-流水号(4位数字)“。在新建或编辑设计文件目录时，需要输入文件编号，此时如果要求用户输入完整的编号，不但增加了大量的重复输入操作，还容易填错。考虑到这点，输入时锁定了项目号和专业缩写两个字段，用户只要根据自己要上传的文件具体是什么，填写文件类型缩写和流水号即可。这样不但避免了重复输入，也确保了至少不会出现项目号和专业错漏的现象。

(2)A和B两个数据成对存在时，显然也不应该允许同时允许输入A和B。这个比较容易理解，比如商品单价和总价、项目名称和项目号、部门和部门负责人之间都是成对的关系，允许同时输入两者不但不必要也不合理。但要注意的是，设计师不要按照自己的生活经验想当然地判断这种逻辑联系，例如上面的商品单价和总价，在某种情况下并没有直接的逻辑关联，下面要举的也是一个这样的反例(正面的例子很容易理解，就不赘述了)。

项目案例：初版方案中，因为请购阶段已经指定了设备数量，那么自然地会想到单价和总价应该是关联的一对数据，在输入单价后，总价应该是自动输出的只读数据，不应当允许重复输入总价。但在自查中，结合自己在设计院工作的经验，我忽然意识到这里有问题，设备采购中的单价和总价确切地说是“设备单价”和“合同总价”，两者之间的关系并不是乘一个数量那么简单，而应该是”合同总价=设备单价×数量+其他费用“，其他费用可能包括配件价格、税费等五花八门的类目。而设备的单价和整个合同的总价对客户来说都是重要的信息，因此在此两个数据都应该是允许输入的。因此，自查后，将总价由一个只读的cell改成了一个数值输入框。

6.4 是否指定了键盘类型和键盘引起的页面滚动

当需要通过键盘进入输入时，需要在交互稿中标注调出键盘的布局类型。否则，开发同学如果将所有未标注的键盘都写成了默认键盘，会让用户不得不手动切换键盘类型、大大影响用户的输入体验。以iOS键盘为例，常用的主要是以下11种：

默认键盘(UIKeyboardTypeDefault)：用于文本输入

密码键盘(UIKeyboardTypeASCIICapable)：用于密码输入

URL键盘(UIKeyboardTypeURL)：用于网址输入

邮箱键盘(UIKeyboardTypeEmailAddress)：用于Email输入

数字键盘(UIKeyboardTypeNumberPad)：只有数字的数字键盘

数字符号键盘(UIKeyboardTypeNumbersAndPunctuation)：数字符号键盘，用于数字符号(主键盘)和字母(次键盘)同时输入的情况

电话键盘(UIKeyboardTypePhonePad)：用于电话拨号的数字键盘(比数字键盘在左下角多了”+*#”键)

文本数字键盘(UIKeyboardTypeNamePhonePad)：用于文本(主键盘)和数字(次键盘)同时输入的情况

小数键盘(UIKeyboardTypeDecimalPad)：比数字键盘多一个“.”，用于需要输入小数的情况

推特键盘(UIKeyboardTypeTwitter)：用于发布推文，右下角是一个“#”号，便于插入标签

搜索键盘(UIKeyboardTypeWebSearch)：用于网页搜索

此外，如果键盘调出后会引起屏幕滚动(为保证部分重要控件或信息可见)，也要在交互说明中注明。

项目案例：登录页的手机号码和密码输入框，分别调出的应该是默认键盘和密码键盘，同时，输入框获得焦点、调出键盘后，页面相应地向上滚动相应的高度，以保证输入框、登录按钮、“忘记密码”链接可见。这些都需要在交互说明中向开发同学注明。

第三部分 过程与特殊情形

7. 交互过程与反馈

7.1 是否周全地考虑了所有操作成功的反馈

操作成功后如何跳转?如何提示用户?通过toast还是设置专门的成功提示页?

项目案例：本项目中按照情景不同，两种反馈方式都有采用。

(1)对流程较短、重要性级别较低、信息量较小的操作，不设置专门的成功提示页，直接在页面顶部弹出非模态的toast进行反馈。交互文档中，在通用交互说明的章节指定了toast(成功型)的显示方式，而在正文部分，需要对操作成功进行反馈时，只要写明反馈文案即可。

(2)反过来，对流程较长、重要性级别较高、信息量较大的操作，则设置了专门的成功提示页，并在全部的成功提示页设置返回开始页的按钮，方便用户快速退出流程并进行其他操作。

7.2 是否周全地考虑了所有操作失败的反馈

因网络环境差、无网、后台故障等原因导致操作失败时如何提示用户?跳转至专门的失败提示页，还是阻断跳转、停留在当前页面并通过toast提示?

项目案例：本项目中对异常流程全部采用非模态的toast进行反馈，和操作成功的反馈一样，交互文档中在通用交互说明的章节指定了toast(失败型)的显示方式，而在正文部分，需要对操作成功进行反馈时，只要写明反馈文案即可。

7.3 操作过程中是否允许取消

表单提交过程中是否允许取消?文件上传、下载过程中是否允许取消操作?

项目案例：项目中对表单提交过程不允许取消，而在文件上传、更新(重上传)、下载过程中，则在进度提示控件中提供了取消按钮，允许用户中断正在进行的操作过程。允许取消时，应该在交互稿中体现出取消后的反馈或者跳转。

7.4 是否设计了必要且合理的动效

是否有必要添加动效?载入时间是否适合添加这样的动效效果?如果长时间等待后操作失败，如何提示用户?

项目案例：这篇文章主要讲交互自查，就不方便放动效的具体案例了，因为具体做起来会涉及比较多和开发的沟通。对本项目这样一个B端的管理类应用而言，常规的动效库足矣，除了信息列表的下拉刷新、页面的载入等待、文件上传下载的等待等场景外，基本上不需要额外的动效设计。这种情况下，实际工作中，对动效的考量和开发团队的组件积淀是有很大关系的。在这类项目的交互设计的自查阶段，我们更多地需要做的是考虑需要动效的场景(无论你起初是不是这样想，最后会发现，需要动效的地方通常都比你想象得少)，以及动效的必要性和合理性。

8. 特殊情形

8.1 角色权限与状态不同造成会造成哪些差异

对允许未登录状态使用部分功能的C端应用而言，需要考虑的主要是游客状态转登录状态、登录状态转游客状态时，体验路径中的差异。对B端应用而言，需要分析的则主要是根据用户在流程中的角色不同、根据用户在公司内的部门和职务不同、根据用户在同一流程中的权限不同，会在任务流程、界面呈现(例如：部分控件和入口的显示与否)文案等方面产生哪些区别。

项目案例：在2.5.2节的例子中我们讲过，采购流程、报账流程、工资核算流程中，在任意一步，流程的发起人如果发现自己提请的信息有误，都可以通过全局性存在的”关闭“按钮撤销其发起的流程，而“关闭”按钮显然就是只对流程发起人显示的。

另一个例子是关于文案的差异，根据流程所属模块不同、用户在流程中所承担的角色不同，流程各步骤发送的待办事项或者通知的文案也有非常多种可能性。这时用例表就是交互文档中一个非常直观清晰的表达方式，例如本项目消息模块的通知类就有23种不同的用例。

8.2 是否提供特殊模式

是否提供无图模式、夜间模式、编辑模式，如果有的情况下，如何呈现?

项目案例：本项目没有提供无图模式和夜间模式，但在项目的人员架构选择、以及供应商名录的管理等功能中，都有浏览模式与编辑模式之分。两种模式间控件方面的差异可能会比较大，最好是通过单独的页面绘制呈现出来。

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