B工作流经常出现在终端产品的设计中，有流程复杂，有的流程简单。


无论是简单还是复杂，它的概念都是一样的。


工作流的概念定义非常复杂，更多的是从技术层面。


一般来说，文档、信息和任务是根据一系列流程规则在不同的执行者之间传递和执行的。


接下来，我将介绍一个相对简单的财务报销工作流程中的交互设计。


在进行交互设计之前，我想谈谈许多新手设计师会踩到的一个坑：在设计之前，我对需求没有充分的了解。


需求沟通是交互设计师非常重要的能力（不要认为交互设计师是绘制原型图，当我做项目时，我也最讨厌项目经理让原型图不清楚）。


谁需要沟通？当然，最好与客户沟通。


当然，我们经常与项目经理或产品经理沟通。


我们必须有能力通过这种现象看到本质。


如果需求沟通的话题太大，这里就不赘述了。


如果你有时间，你可以单独谈谈如何沟通需求。


我将从以下三个方面阐述如何在工作流中进行交互设计： 确定和梳理需求。


正如前面提到的，任何设计都必须基于明确的需求； 流程梳理和信息架构输出。


流程设计是交互设计中非常重要的组成部分一个好的过程可以让用户更容易地完成任务。


这也是我这次分享的重要组成部分； 原型输出。


简要介绍原型设计中应注意的问题。


1、确定和梳理需求 在需求沟通阶段，一些客户（用户）相对专业，可以清楚地解释他们需要的功能，但大多数客户（用户）只能粗略地谈论他们需要什么。


至于具体细节，他不清楚。


此时，我们需要根据需要组织自己，通过与客户（用户）的沟通，尽可能了解用户的使用场景，首先设计一套方案，然后与客户（用户）反复沟通，直到确定最终需求。


如果条件允许，试着做一个简单的用户研究，因为它将了解更多的用户使用场景，然后挖掘用户的潜在需求。


通过沟通，我们了解并最终确定了客户的需求。


客户最初提出的需求是这样的: 通过沟通，我们进一步挖掘了一些潜在的需求，现在的需求是这样的: 一开始，客户的需求是申请人发起报销申请，然后经部门经理、副总经理、总经理和财务部批准。


如果在批准中发现问题，可以拒绝。


如果批准，财务支付，整个过程将形成闭环。


在了解了需求后，我们结合自己的分析提出了几个问题： 如何处理审批中被驳回的申请； 如果申请人在提交申请后发现问题，可以修改； 部门经理、副总经理、财务总经理是否也需要报销申请。


与客户沟通后，最终需求为：申请人发起申请，经部门经理、副总经理、总经理、财务审批，经批准后进行财务支付。


被拒绝的申请，申请人可以在修改后再次提交。


如果申请人在提交申请后发现问题，可以在修改和提交前撤回。


部门经理、副总经理、财务总经理有审批和发起申请的权限，毕竟，他们也需要报销。


经过沟通和梳理，需求基本确定。


当然，这只是一个大框架，有很多细节没有考虑。


这是我们在设计过程时需要做的 二、梳理信息架构和流程设计 经过之前的需求沟通和梳理，我们对需要设计的财务报销系统有了一个一般的框架。


接下来，我们需要从互动的角度来考虑和设计过程。


为了让你直观地理解需求，我画了一个简单的过程，现在我们需要在此基础上进行细化。


这个阶段更重要，因为这个阶段的设计基本上决定了我们的系统的可用性和易用性，这与用户体验有关，所以在这个阶段需要很多时间来思考和抛光。


首先，从需求出发，梳理出一个大概的过程。


前面谈需求的时候已经梳理好了，这里贴出来: 这里有两个流程图，不是说有两个流程，流程是一样的，只是不同的角色，然后再说。


让我们先看看我们梳理的过程。


功能点相对清晰，似乎没有问题，所以我们需要更深入地思考，从用户体验的角度思考。


此时，我们将带来一些使用场景。


我们举两个通用场景: 若操作中出现异常情况(网络异常、服务器异常)； 用户因个人行为被迫中断操作(试图挖掘用户的新需求点)。


在当前的过程中，我们没有考虑到第一个异常情况。


在这里，我们必须考虑异常情况。


事实上，有很多异常情况。


在这里，我们只考虑几种常见情况：网络异常；服务器异常。


(1)网络异常 在提交申请的过程中，如何处理网络异常。


输入大量表单内容并上传一堆附件后，网络在提交时出现异常。


如果不设计这个环节，用户辛苦输入半天的内容就没了，回头再输入是一件很崩溃的事情。


此时，我们需要一些策略来缓存用户输入的内容。


即使用户遇到网络异常后返回，内容仍然存在，这种体验也非常好。


有些学生可能会认为这是一个技术问题，应该考虑发展，这是一个很大的错误。


除了少数有经验的开发人员会考虑这个问题外，大多数开发人员不会考虑，或者他们只会根据需求清单开发，你可能不会问他。


这些地方是反映系统易用性的重要细节。


它也反映了产品经理或互动设计师的设计能力。


(2)服务器异常 服务器异常与网络异常基本相似。


最大的区别是网络异常可能不在我们的控制范围内，但服务器异常是我们不可推卸的责任。


因此，在这个时候，除了解决用户内容缓存的问题外，我们还需要安抚用户的情绪，提出一个好的解决方案，比如告诉用户尝试刷新页面，或者判断用户操作是否导致问题并给予提示和指导，而不是直接丢失给用户404页。


第二，用户因个人行为被迫中断操作 这实际上是从用户的使用场景中挖掘用户潜在的需求点。


例如，用户正在输入报销内容，突然有重要电话，或临时重要任务需要处理，此时用户输入了很多内容，他不想放弃输入的内容，现在该怎么办？ 如果不设计这个环节，会影响系统的可用性吗？当然不是，我们的核心流程没有问题。


会影响用户的情绪吗？ 也许，为什么是可能的，因为有些用户可能不在乎或者没有这种意识。


如果我们在这里设计一个草稿箱，能解决用户的痛点吗？这对改善用户体验很有帮助。


这些潜在的用户需求点，只有通过带入用户场景，从用户易用性的角度考虑，才能寻求突破。


再来说说角色 角色是工作流中最基本的环节，不同的角色有不同的权限，过程也会有所不同。


上述报销系统主要分为员工、领导（部门经理、副总经理、总经理）和财务三个角色。


员工只有发起报销申请的权限，领导有请报销和审批报销单。


在这里，部门经理、主管副总经理和总经理被划分为一个角色，因为他们的权限是一致的，但他们在流程节点之间有关系，财务权限相对特殊，他没有审批权。


但要行使审计权，就是要检查报销信息和发票信息是否正确、真实，但在权限上要特别注意与领导角色一致。


不同的权限角色在过程设计上也会有所不同，因此在设计过程中必须明确角色权限的问题。


在此之前，我们为员工和领导角色设计了不同的过程，财务角色的过程与领导角色的过程是一致的。


该报销系统的设计是最基本的工作流形式，权限相对清晰。


在实际工作中，由于不同的需求和应用场景，它往往非常复杂。


在设计中，需要明确告知角色权限控制的规则。


通过进一步的考虑和分析，流程设计基本完成(不一定全面，任何设计都要结合实际需求和业务场景)。


下一步是梳理信息架构。


通过流程和角色设计，输出信息架构相对简单。


这里需要注意的是，信息架构需要考虑得更详细，哪些角色对应哪些页面，页面需要列出哪些功能点 三、原型产出 原型也是一个非常重要的环节，因为它是连接上下游和可视化呈现系统设计的重要载体，也是设计、开发和测试的重要基础。


因此，原型的设计不能粗心大意。


它必须涵盖一切，反映以往设计过程和角色权限的规则，注意细节和过程的完整性。


事实上，当我们在前面梳理信息架构时，页面的设计在我们的脑海中已经有了一个原型，原型的绘制只是一个时间问题。


当然，在绘制原型的过程中发现一些信息架构设计问题并不排除，可能需要同步整理和修改。


就我个人而言，我习惯于在绘制原型之前简单地画一个草稿，这有利于梳理我的想法，修改问题的成本相对较低。


以上是我对工作流中交互设计的一些理解。


这只意味着个人观点不是行业标准。


我希望它能帮助你。


欢迎您提出问题并一起交流！ 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。


本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。


如有侵权行为，请联系网站管理员删除，。