从实际案例出发,说说交互文案设计的几个原则新.pdfVIP

从实际案例出发 ，说说交互文案设计的几个原则 想必大家都见过下图所示的著 的“交互文案”反例吧 ？ 如果文案写成这样 ，无论设计师在文案出现方式、时机等方面再怎么优化 ，这也不可能成为一个合 格的设计。因为“看起来重复、读起来绕口、理解起来更是云里雾里”的文案很难让用户获得良好的 阅读体验和使用体验。 可见 ，文案本身是交互设计不可忽视的一部分。而不像许多交互设计部分受产品需求、技术现状等 的限制 ，交互文案是在交互设计师的可控范围内的 ，只要你愿意 ，你总是可以写出“趋近完美”的交 互文案。 理解需求 交互设计师写文案 ，好比是翻译家将英语 （功能语言 ）翻译成中文 （用户语言 ）。比如产品经理可 能会这么描述一个需求 ：It rains cat s and dogs。要翻译这句话 ，首先要透过cat s and dogs这个俗 语 （产品经理的描述习惯 ）去理解这句话的含义 ，即需要交互设计师理解需求。 以上图为例 ，产品经理一开始在PRD中将这个分页标题定为“兴趣” ；然而由需求本身可知 ，这个分 页包含的是推荐的优质版块 ，并不是由用户选择自己“感兴趣”的版块构成的 ，所以谈不上“兴趣” ，经 过交互设计后 ，该分页标题最终定为“频道”。 下面的设计 ，却是理解需求后的“直译”。 产品经理要求在编辑直播间推荐页提供“该推荐是否显示到大厅”的设置 ，优化前完全按照需求的表 述来进行设计 ，不能说有错 ，但不够明确。 深入了解需求 ，我们发现 ，这里的设置其实是对当前推荐类型的选择 （选择否时 ，推荐为一般推荐 ，不显示至大厅 ）。优化后 ，直接将选择“是”和“否”的结果明确写出。 理解了需求 ，才能知道要“写什么”以及“写成什么意思” ，才能把“It rains cat s and dogs.”翻译成“天上 下了很大的雨。”而不是“天上下起了猫猫狗狗。” 基本原则 用语确切 文案作为被阅读的对象 ，需要被用户理解。 我在使用网上银行找回用户 的时候 ，收到这么一个提示 ： 主提示句明显是一个病句 ，就算进行修正我也无法理解 ，无奈只能大胆猜测我的银行卡是不是没有 开通网银。文案撰写时如果没有准确使用词汇、语法来表述其含义 ，用户就无法理解 ，甚至容易产 生歧义让用户误解。 不过 ，仅仅“用语”准确还不够。 我曾经设计了这样的分享文案“给大家安利[用户昵称]的直播……”。“安利”一词在网络用语发展过 程中 ，逐步演变为比“推荐”更具情感化的表述。使用“安利”一词在达意上自然没有问题 ，而且更显 诙谐。不料 ，我却发现有不少用户反馈“是不是写错字了 ？”“安利什么意思啊 ？”这时 ，再拿“安利”对 一些用户进行随机调研时 ，我才发现原来太多知道“土豪”的用户都不知道“安利”。这说明用语还要 恰当。 这就要求设计师根据用户特征和习惯来撰写文案 ，做到“用语确切” ，文案才能被用户准确理解。 全局一致 由于汉语博大精深 ，同一含义的确切表述可能有许多种。为了符合用户的心理预期 ，同一产品的同 一功能、含义的表述必须一致。 下图设计中 ，“校验码”“验证码”甚至“动态码”等表述都可以用在这里。然而同一功能、同一页面上却 用了两种表述 ，就会让用户迷惑“到底是验证码还是动态码” ？ 同一产品中 ，同一流程或同类功能 ，如果短语结构、句式等可以一致 ，那么也应该遵循一致性原则 。 一个流程中的三步文案分别使用了动 、 动、动 形三种短语结构 ，感觉有些杂乱 ，不如统一 使用“动 ”或“动 、动形”的结构来的舒服。 此外 ，同类或相似功能的文案叙述视角也应该一致。 同类功能描述差异性的文案 ，却分别从产品和用户的两个角度去描述 ，也给人以混乱的感觉。 这需要设计师从实际需求出发 ，多维度地去考虑一致性 ，以给用户安全感和舒适感。 情感关怀 满足用语确切、全局一致的文案 ，达到了文案的基本要求。这样就够了吗 ？ 在“网银文案”一例中 ，假设我们将文案按我猜测的意思优化为“请使用已开通网银的账户进行操作” ， 那么某些有且仅有一张未开通网银的银行卡的用户如何使用另一张并不存在的卡呢 ？某些就想对该 账户进行操作的用户又该怎么办呢 ？文案应该以当前操作为出发点去描述问题 ，才能帮用户解惑。 因此 ，本案例中优化为“本账户暂未开通网银 ，请前往柜台开通”更明确合理。 当我点击下图设计中的“确定”时 ，弹出了“领取失败”的文案 ，阅读后能够理解当前“失败”的状态 ，然 而失败原因是什么呢 ？我还能怎么做呢 ？这些都无法从交互文案中获知 ，因此用户会产生迷茫。文 案应该描述失败原因 ，比如“今日兑换结束 ，明天再来试试”