以一个B端项目为例，聊聊若何应对复杂需求下的UX设想

需求文档200多页、时间紧、变动频繁，专业常识点还超多！若是是你接到如许的一个复杂需求，你会若何展开工做？做者以现实工做中的那个详细项目为例，与我们一同切磋若何应对复杂需求下的UX设想。欢送阅读~

上周给团队做了一个1*分钟的小分享，以我们之前一个详细的B端项目为例，切磋若何应对复杂需求下的UX设想。

因为此次的分享主题是由team内的小伙伴指定的，所以在分享的起头，我就问了一个问题：你们觉得那个项目复杂在哪里？

以前听人大一个传授说，任何问题，都需要有一个定义域。后来听舒祺教师讲课的时候，也听到一句话，叫做：defined before detented。

01 处理问题之前，先定义它

当你拿到一个你认为复杂的需求时，先确认对你而言，复杂的是什么很重要。以我分享的阿谁项目为实例，它的复杂性在于：

我拿到手的需求是一份200多页的手艺要求文档，是由甲方组织撰写的国标文件，固然现实描写功用的只要10页摆布，但为了理解每个功用的详细细节，必需要翻看后面更偏手艺的描述，好比接口构造、传输协议等等。而其时项目里也没有产物司理的岗位帮忙去梳理需求。那一条也是我其时分享时现场询问小伙伴为什么觉得那个项目复杂时，所得到最多的谜底。

时间严重，需求变动频繁。中间一个版本又在那200多页文档里添加了详细的后台微办事及接口定义文档，和最后我们本身后台微办事框架和接口定义有许多纷歧致的处所。

B端项目自己的营业门槛和相关的专业常识点形成的壁垒。

02 那些复杂性，给UX设想带来了什么困难？

有时候，我们很容易将现象和问题混淆起来，复杂和简单只是事物的属性，是那个世界的一部门，它并没有好坏之分（详见《征服复杂，B端设想思虑》）。

好比“200多页的手艺要求文档，没有专门的产物岗位去梳理需求”只是一个现象，并非问题自己，需要定义的是你面对的问题，而不是将现象和问题混为一谈，因为统一个现象，可能对其别人形成的问题（也可能其实不成为问题），和对你形成的问题是完全纷歧样的。

在那个项目中，前面三点形成的问题次要有：

（一）兼顾大构造的同时，又要留意小的细节。

（二）同期间其他工做的干扰后端接口文档改动时本身的预判不敷

（三）对营业的领会水平不敷可能形成设想后的界面交互其实不那么满足用户体验要求

（一）兼顾大构造的同时，又要留意小的细节。

我们晓得，交互设想是要下沉到细节逻辑的，它流转的不行是表层的界面跳转，也关系到界面下的底层信息交互的逻辑运转。

我之前写过一篇文章，切磋B端界面设想的复杂性从何而来（详见《B端设想思虑：以界面为触点的信息流转》）时也有聊到。

同时，B端系统需要交互的信息常常有良多（功用点多），也就意味着它需要许多许多相互相联系关系的界面来承载它们。

不外，面临项目其时的情景和目的，切磋按钮的摆放挨次和表单字段能否冗余已经没有任何意义，起首要确保的是主构造、支流程和关键界面的准确性。

好在那个项目之前，我已经做过一些不异营业范畴的类似项目，所以在确认主构造和支流程上，我根本没有浪费什么时间。

那块的准确性和可扩展性，也包管了我在第二个现象：小需求变动频繁的情况下，其实不认为它有困扰到我，成为要专门处理的一个问题的原因。

在细节设想上面则更多的是包管它的无错性而不是体验性，好比遵照已有的平台设想经历，套用常规组件，在评审之前容忍许多细节处于非更优设想的风险，然后依靠研发评审及开发和测试过程的反应来不竭调整。

（二）同期间其他工做的干扰后端接口文档改动时本身的预判不敷

单纯的时间和工做使命抵触问题我认为仍是比力好处理的，其时我同期间还有一些办理工做，所以我一方面从本身动身，尽量集中大块时间来做那个项目标设想，而且提早将设想分批输出评审的时间方案表同步了研发。别的一方面，我也小模块地引入了其他两位设想小伙伴的帮手，加快了部门进度。

在那种情况下给出方案并严酷施行我认为仍是很重要的，那是一种确定感的赐与，不只能便利其他相关工做的摆设，也能让你在工做的过程中不会被打搅和诘问。

第二个问题也是研发同事帮手一路处理的，他们从接口文档反推出可能新增或改动的界面功用给到我，我再连系他们的反应去看满满手艺语言的接口文档，思虑新增或改动的交互，确实快了很多。

当然，输出也是分批分模块和对应的前后端小伙伴确认的。

（三）对营业的领会水平不敷可能形成设想后的界面交互用户体验欠安

固然那个问题我列上去了，但在做项目标时候并非我的次要问题，第一个原因是之前项目铺垫的营业常识已经让我可以确保次要逻辑和流程的准确性，第二个原因是项目其时的目的并非现实投入利用，而是要去通过该系统所对标行业的一个资格测验。

那也再次申明了定义问题的重要性。

0* 回忆那个项目

关于若何应对复杂需求的UX设想我认为有三个关键点值得一提：

1. 优先包管主构造、主逻辑和关键帧

次要构造，指产物功用若何组织，它需要通过火类和条理性来表现。

次要逻辑，指用户的思绪若何流转在几个次要功用上面的，它需要通过界面的用户流和逻辑流来表现。

关键帧，主构造和主逻辑的详细表现，是此中关键触点的具化界面。

2. 确定你面对的问题，而不是将现象和问题混为一谈。

那也是我们上面不断在廓清的，每一个现象要定义它给你形成的详细问题上，defined before detented。

*. 最末，处理问题的素质，仍是你以往经历和才能的积累。

在做那个项目标过程中，若是我没有之前的营业积累，我也没法子在面对B端项目自己的营业门槛壁垒时，认为它所形成的问题不是那么次要，不会影响我的主逻辑和支流程。也没有法子在确保大构造放弃小细节时仍然可以包管细节的出错概率在所有人能够容忍的范畴内。更没法子在面临第三个问题时悄悄放下，认为它影响不了大局。

另一方面，若是我的经历和才能更好一些，在应对那些问题时就会更为轻松，也不会发作前面提到预判不敷形成的措手不及。

总结一下

复杂所形成的问题是什么？defined before detented。

以一个B端项目为例：我的三个问题（两端兼顾、其他工做和预判不敷、用户体验欠安）和次要的处理办法。

三个关键，关于若何应对复杂需求下的UX设想。

做者：林影落，10年+体验设想师，专注AR及立异范畴设想；微信公家号：林间有影落

本文由 @林影落 原创发布于人人都是产物司理，未经答应，制止转载

题图来自 Unsplash，基于 CC0 协议。