2020年第一篇，转换一下写作思路，就写点最近真实项目中复盘的经验吧，考虑不周全的地方和写的不对的地方大家尽管提出来哈，一起研究！2020年Flag先立一下，不得不说的一个事实是，单纯的视觉UI设计师真的已经不能满足现在的市场需求了，事实就是你要懂产品，会运营，会交互，会插画，到你这Part反馈出来的问题还得有深度，代码啥的只要跟技术小哥哥无缝配合好就行，具体看自己的职业规划哈，这也不一定。现在的UI设计师真的是要把自己打造成灭霸级别的全栈设计师才能出去打怪升级，太不容易了~来，一起品一下。
01
—
数字多怎么办
不论大小APP，数据都无处不在，它可能存在列表中、详情页、调研测试页等等~哪哪都有~，不同页面不用层级我们处理的手法也不一样，分类治理~。
尤其是B端类和金融类的产品，数据相对来讲比较多，且数据之间有种种复杂的联系和嵌套关系。我们要做的并不只是把数据按照原形规规矩矩展示出来，我们要做的是 从拿到的原形中挖掘数据之间的联系和产品想表达的想法，并从结合产品本身的利益点出发，去思考、去阐释这个关系，然后输出到画面当中。
我们公司是B端类的业务，基本每个页面都会时不时蹦跶出来一串数字，一串算法，一串电话号码~，这就得跟我们的上游产品确认想法了，目前这块设计图出来跟我们产品的思路还都挺吻合的。还有字段长短的保留问题，Float转字符串，以及一个Int和一个Float的关系，这部分内容有点多到时候单独列出来一篇说吧，有兴趣的小伙伴记得关注下哈~接下来说一说干货。
02
—
这样的原型图你应该怎么设计
当你拿到上游产品如下的设计图，梳理完流程大致一看基本没错，可以进行下去。这时候你照着这样做的话，无疑暴露了一个初级错误，到时候开发出来，用户体验极其不好，这是谁的GUO ？今天就两张原型图牵扯这一系列的设计和交互问题吧！
大家也可以想一下拿到这样的图你会怎么做哈，欢迎留言讨论。
这也是分水岭，如果只捋顺流程和逻辑，只停留在视觉表面层次的话，显然应对B端的业务就会出点纰漏（我也是这么漏过来的）。B端行业错综复杂的业务线真的是令人头秃~，产品给你的原型图不可能面面俱到，如果公司有交互设计师还好。总之你最后交给产品的设计图里，不仅要有设计，还有有交互，还要有逻辑，还要有营销手段和利益点的争取，总之一锅乱炖营养全面，这样你过稿的几率还是蛮大的，起码能说出来几条别人没想到的问题；这在个重视交互的年代，清一水的纯视觉设计已经有些难了，这也不一定，有些C端的业务，就是要炫，我上面阐述的主要仅针对B端来说哈。
下面分析一下问题，这个页面算是比较常见的。产品跟我们看问题的视角是不一样的，我们要为用户着想，交互做的顺畅了、方便了才真正能解决到用户的问题，让用户意识到在线上做操作就是很方便，他们才会慢慢产生黏性。举一个例子吧，我们公司刚开始上架的业务就是把线下的操作流程搬到线上来，线下都是手写填单、盖章，审核速度慢，效率不高等等，但是我们的用户群体已经习惯了这样的操作，突然要改到线上来，其实他们是很抵触的，改变一个人的习惯很难，一群人更难，我们是怎么做的？当然我们的产品也是很给力的，我们设计师能做的就是不断的优化用户体验，让用户感到方便，方便、高效说三遍!接下来说点设计吧！（因为我们公司APP只针对企业页面开放，页面暂时不做公开哈，但是我会给大家描述清楚哒，无图胜有图系列~）
先看第一张原型图，就设计问题来讲：
- 界面的设计其实没有可发挥的余地，只能加一些icon和卡片设计划分一下板块；
- 背景色和模块颜色的区分，tab 栏和 button 的设计，可发挥空间其实很小。
交互问题：
- 这些内容如果都放在一张页面，用户要滑动多少屏才能填完内容？
- 信息是否能用OCR智能识别，帮助用户减少填写操作 ？
- 姓名手机号这些如果不是熟人应该很难记得吧，是否能添加通讯录的功能？
- 发件信息是否能用定位功能？
- 收发信息是否需要储备常用地址？
- 收发信息是用户经常容易颠倒写错的信息，能否区别设计？
- 期望提货时间是否要设置默认时间？
- 发件信息这块是否需要默认展示注册时候本人的信息？
- 最重要的来了，填写完信息，当前页面还在可编辑的页面，滚动信息检查的时候是否会误操作，这样是否增加了用户烦恼和操作难度？（编辑和预览界面一定要区分开）
- 二次编辑的时候，打开页面重新填写某一项，查找信息的时候是否又增加了用户的工作量？
- 物品信息是可以操作增加和删除的，这样不可预测的操作怎么把控？
- 添加货物如果新开一页其实又重复了之前的问题，新开一个界面，如何实现编辑、删除和新增？
- 底部按钮是否需要做成响应式的，当用户填写完所有的内容再高亮？
这些问题可能不是所有的都可以被实现，但是作为设计师，这些潜在的问题我们都要看到，及时止损， 以及反馈给我们的上游。
再来看第二张原型图，
这张图的问题相对比较少，当你们的APP还没有涉及很多板块， 嵌套多个应用的时候，这种嵌套式的应用最好不要使用，况且还得要考虑下你们用户群体的接受度。这个页面还处在三四级，这样的做法会让用户感觉到又跳转到了一个APP的感觉，从一二级操作过来，到这步因为多级Tab突然换了个风格跳跃度还蛮大的。 我们最后的解决方案是：换成tab+标签 展示在顶部。
03
—
解决方案
其实看到这里大家心里应该都有答案了，能看到问题就可以被解决，下面给出我的解决方案。当然我的也不是最优的哈，大家可以当做参考，落地项目牵扯因素太多了，不是设计师一个就能定的，最后解决不下来的问题，只采取了适中的解决办法。
问题答案不放在一起就是为了给大家一个思考的空间哈，说不定你有更好的问题和方案，嘻嘻~。像一些基础的问题，通讯录的添加或者定位什么的，这些你反馈给上游是一定会给增加的，下面看一个比较核心的解决方案，（为了大家有自己的想法，文末再展示我们最后确定的方案哈，大家有更好的方案欢迎补充
）。
第一个问题：长页面精简，编辑预览分开
一个很长的编辑页面，涉及多维度的信息，那么，从编辑到预览，这个操作一定要区分开来的。尤其的信息比较多的页面，还可能会涉及大概率信息会被填写颠倒的可能，比如“收发信息”，就得十分注意。
还有一个比较重要的点需要考虑，二次编辑。用户修改信息是肯定的，所以，再次修改信息时一定要做到明确、快速定位信息。
给大家举个例子，我们本来第一期的想法是当用户进入收货信息的时候，填写完成全部的信息后，响应式按钮高亮，但是按钮文案改成“下一步”，点击之后让用户直接进入收货界面填写。这个方案看似是帮用户节省了时间，不用返回再点击收货再进入填写，但是还是漏洞百出。
问题：1.用户要是二次编辑呢？是否需要再重新全部走一遍流程？一步一步点下一步？系统是否可以直接识别，直接按钮变为“完成”？这其实是给我们技术增加了难度，但是考虑到目前的情况和该页面的重要程度还是舍弃了。
2.加上 上一步、下一步和提示性文案呢？还是被驳回了，用户二次编辑只是想修改一下信息，我们却在这里给用户增加了难度，需要用户再考虑上一步、下一步等等之类的逻辑，相比之下，用户是宁愿多点一下也不愿意思考其中的逻辑。
第二个问题：问题升级，继续设防
到了“东西”这块，进入下一级页面，本想着按照原型图逻辑直接让用户编辑就可，（如图方案一），但是B端就是层层逻辑的嵌套，不妨不行啊~ 如果增加少还行，但是要有二三十条的增加量，还必须保留一条数据，这就……，而且还得可删除可增加，技术在实现的时候怎样的完成度算一条可用的数据？掉头发掉头发~~说一下我们想出来的方案和被PASS掉的方案。
1.第二个给出的方案是这样的，（如图方案二），我们在顶部增加编辑框，相当于编辑添加的信息在上，完成的信息在下，做了很好的区分~，按钮做成响应式的，用户没有填写完成就不给高亮，这样就保证了至少有一条数据，这样子应该没什么问题了吧！
看上去没什么问题了，但是问题来了，往下推敲就发现问题来了，这样的操作是可以用的，但不是最好，还是存在歧义的。这就涉及一个技术的问题，“什么情况下算是一条可用的数据？上面的输入框输入了一半的数据，算一条数据吗？”我们的答案是不算！必须点“完成”才算一条完整的数据，点击完成之后上面的输入框内容清空。“下面已经输入完成的信息如何排序呢？”新增加的在最顶部。“添加货物”的按钮意义何在？和顶部固定的编辑框是否会误导用户？用户的年龄层是否有考虑？到这步还是妥协了，换方案！这样的操作可以用，但是对用户来讲是有一定的学习成本，进入页面用户还是会有点蒙，点击“添加货物”，我们顶多能反馈个吐司提示，页面基本无变化，对不敏感的用户来讲根本看不出来哪里不一样，所以此方案能用但还不是最全面的最好用的！
最后衍生到如下方案，点击“添加货物”直接就Action sheet,再也不用担心编辑一半想退出了怎么办，怎样的数据算一条完整的数据。底部弹窗的操作也给用户很明显的反馈，不想要就取消。
下图是部分拆解的步骤，大家有更好的方案欢迎留言。
上述修改的方案操作也是很常见的，也是平时操作中我们经常使用而且无学习成本的，但是从一张原型图拆解到一系列的层层方案还是得费工夫去研究的，有挑战性的东西无疑也是最锻炼我们设计师的！项目落地要牵扯到很多因素，所以最后方案也不是最完美的，也有待优化，重要的是我们能意识到存在的潜在问题，并且及时止损。
近半年来加入了一些很有意义的交互群和设计群，对自己帮助很大，感恩优秀的同行者~
end
閱讀更多 PMTalk產品經理社區 的文章
