当前位置: 首页 > 科技观察

移动端交互输出文档应该怎么写?来看看专家分析吧!

时间:2023-03-18 01:29:04 科技观察

一套完整且比较优秀的移动端交互文档,我觉得可以包括以下几个部分:业务背景、产品目标、用户群体和用户目标业务规则定义用户流程图设计原则交互流程注解当然可以还增加了产品概览和更新日志等,产品概览是对产品版本号和产品相关人员的简要说明。更新日志主要表示每次更新后更新了哪些内容、更新者和更新日期,如下图所示。作为交互设计师的业务背景、产品目标、用户人口统计数据和用户目标。我们收到需求后,首先要弄清楚产生需求的业务背景是什么。二是根据业务背景了解产品的目标是什么。最后搞清楚产品的用户群是谁,用户目标是什么。交互设计师从产品经理或其他需求发起人那里了解需求产生的业务背景,理解为什么需要这个需求。理解清楚之后,追溯需求最原始的本质。在我们实际工作的大多数情况下,产品经理并没有把业务背景写清楚在需求文档中。这时候我们的交互设计师就可以把交互文档中的业务背景输出出来,清晰的展示出来。1.业务背景是什么?商业背景通常是我们做这个功能的原因。通过做这个功能,对业务有什么帮助。通过业务背景,推导出业务需求,得到相应的产品目标。2.产品目标是什么?产品目标就是产品能达到什么样的结果,能为产品获得什么样的收益。因此,在交互文档的设计中,需要着重体现产品目标。通过明确产品目标,可以明确的引导我们做出交互的解决方案。3.用户群有哪些?用户群体主要是通过我们现有产品的用户画像得到的,我们可以计算出什么样的人使用这个需求。通过明确用户群体,我们在设计过程中可以做到这一点,可以清楚的知道这个需求是针对谁的。4.用户的目标是什么?用户希望通过使用该功能达到什么样的利益或目的。下面我将通过一个虚构的案例来说明如何输出移动交互文档。5.案例:新浏览器猜谜活动。本次活动的需求是通过浏览器的金币竞猜活动,让用户与产品产生新的互动,增加新老用户的日常活跃度,增加活跃度。基于这样的需求,我们的交互设计师应该如何设计并输出一个交互文档呢?根据以上:在设计之前,我们需要考虑业务背景、产品目标、用户群体和用户目标。经过分析,可以得到该需求的业务背景、产品目标、用户人群和用户目的如下:活动),从而形成一个完整的良性闭环。产品目标:通过事件分享增加浏览器下载量;通过用户赚取金币的方式增加用户使用某个浏览器的时间;通过活动引导用户分享,从而获得更多的产品活动曝光。用户群体:使用过某款浏览器,喜欢赚钱的用户;没有使用过浏览器但喜欢赚钱的用户。用户目标:轻松便捷地完成答题,并希望获得奖品。业务规则关于产品的业务规则,可能需要与产品经理、业务方、运营进行沟通和讨论。这涉及到整个产品业务的规则。在实际工作中,我们在交互的时候会遇到两种情况:情况1,产品经理会跟业务或者运营沟通,然后输出一个业务规则。这时候我们可以在交互的时候仔细阅读和梳理业务规则。如果我们觉得不合理,可以和产品经理一起讨论和沟通,修改业务规则,使之更合理,并输出到交互文档中。情况2.产品经理只是对业务规则有一个想法。这时候就需要我们交互设计师的帮助,来沟通和提炼他们的业务规则,输出到交互文档中。新浏览器竞猜需求涉及的业务规则包括:活动时间规则、金币生成规则、金币消耗规则、资金池消耗规则、活动发布规则、提现规则。对于这些,如果产品经理没有明确的表述,或者表述的不够好,不够详细。然后我们就可以互动梳理和制定。在制定规则的过程中,我们的设计师需要了解活动开始前、活动过程中、活动结束后的所有活动流程,并将整个活动流程贯穿始终。并给出合理的规则定义。如果规则制定不当,上线后,整个活动就会因为规则漏洞而崩溃。下图展示了我定义的所有规则:UserFlowchart用户流程就是我们的设计者需要梳理用户在使用过程中各种场景的流程。通过用户流程图,我们可以避免遗漏场景,避免遗漏交互方案。对于任何功能或活动,第一个问题是入口设置在哪里?所以我们需要设计活动入口的逻辑。Activity的用户主进程是用户正常执行该Activity时的进程。与主进程不同的是金币不足时的异常进程。如果用户赢了竞猜,对应的问题就是提现。由于浏览器还没有钱包,所以设计了绑定微信提现。为了曝光度,活动需要重点设计分享功能和入口。当用户中奖时,需要提醒正在使用该产品的用户中奖。当Activity过期时,需要设计对应的过期Activity接口。经过以上简单的分析和深入的用户流程图总结,可以得到以下7张用户交互流程图:问答活动的入口设计在哪里?金币哪里够?-竞猜活动的主要流程是金币不足时的提现流程。活动分享流程及所有入口活动已过期已中奖时的场景设计原则这里的设计原则不是一些常见的交互或视觉设计原则,而是设计本次活动的交互方案需要遵循的原则.这里的设计原则与业务密切相关。在做这个活动设计之前,有必要明确一下这个活动的设计过程应该遵循哪些原则。这样,我们在设计整个活动的各个场景时,就可以明确的让交互过程和页面布局遵循既定的原则。这更像是一个全球视角。本次活动的产品目标是通过活动获得产品曝光和下载量。需要满足的原则是引导用户快速找到活动入口,并提供活动介绍以吸引用户参与并顺利参与。本次活动的用户目标是简单方便地完成猜谜活动,并希望中奖。在设计过程中,应该简单易懂,用户没有认知和操作成本。为了让用户有机会中奖,也为了让用户感到公平,需要及时向用户反馈中奖用户。由于该事件只是暂时的,因此需要减少对绝大多数非目标用户的干扰或冒犯。基于以上分析,总结后制定如下设计原则:引导用户快速找到活动入口,顺利参与提供活动的简短描述,吸引用户参与问答活动页面,简洁明了容易明白。为确保公平公正,对绝大多数用户产生打扰或反感,及时向用户反馈中奖人数以上的设计原则,为后续交互过程确定思路和设计指导。交互流程标注根据上述用户流程图,可以得到7个用户操作流程,即7个交互流程标注。目前我认为最好的展示交互流程标注的方式是按照一个主流程,以站点地图/画板的形式展示。当一个主流程中有多个分支操作流程时,可以将它们分别显示在站点地图/画板中。同时,用标题来区分和描述分支过程的操作名称。如下图所示:当涉及到异常场景并可以全局复用时,只需要全局的组件描述即可,不需要为每个进程展示其异常场景组件或页面。全局组件是指整个产品共有的组件,比如全局断开、运行成功、运行失败、加载、空数据接口、404等。全局断开:一般在首页使用提示。当用户在其他界面点击操作时,也会出现toast反馈提示用户。也有一些APP在用户进入时出现对话框提示用户网络异常。与对话框相比,使用提示对用户的干扰较小。操作成功:一般操作成功会根据具体的使用场景给出相应的提示。操作失败:由于异常情况导致操作失败。这时候就需要统一提示。通常使用Toast,一些对话框用于强烈提示用户。加载:涉及全局加载和局部加载。全局加载应该在设计中统一解释。比如点击上一个界面进入下一个界面,需要说明一下使用的全局加载。如果是一些小场景的加载,需要特别说明。例如上拉加载、下拉加载、局部小区域加载等。空数据类型分为三种:初始状态的定义:初始状态,没有任何内容,需要用户进行某种操作生成内容界面的操作。清空状态的定义:通过删除或其他用户操作清空当前页面内容,产生空界面。这时候就需要有明确的提示,告知用户如何处理。错误状态的定义:由于网络、服务器或其他结果查找失败等原因,无法加载内容,导致界面为空。这时候就需要有明确的提示,告知用户如何处理。用户操作反馈的无结果界面也可以用这个思路来设计。下图是H5问答新活动部分的交互流程标注示意图:在列出流程的过程中,尽量走到一行的末尾,避免行与行之间的交叉。乱,体验特别差,逻辑容易出问题。同时在每个接口下方写上相应的标签说明。结束语以上就是如何在移动端输出交互式文档。仅供参考。您可以根据贵公司的实际情况进行合理增删改,使文档更适合贵公司/项目组。