关于Axure,你需要知道的5个误区

专为互联网人打造的365天成长计划,500门视频课程随便看,构建你的产品、运营知识体系。查看详情

在产品工作中常常使用的Axure,有哪些需要避开的误区呢?

之前在知乎上、身边遇到过类似的问题“如何高效利用Axure”、“Axure有哪些鲜为人知的技巧”,类似初学者讨教Axure使用心得的问题。凑巧进行了一些整理,顺便交出我的组件库,那么就分享给大家吧。

这不是一篇如何学习Axure工具技法的文章,因为Axure确实简单好学,但是它能够让你避开那么可以避开坑,少走一些弯路。

  • 误会1:把整个交互设计的过程都放在了Axure工具上。
  • 误会2:尽可能追求完整、高保真的原型,而忽略交互细节说明。
  • 误会3:注重提高Axure工具技能的效率。
  • 误会4:注重原型的视觉层次

误会1:把整个交互设计的过程都放在了Axure工具上。

为什么说它是个误区呢?

因为在打开Axure之前,那些交互设计的过程远远比最终的那个方案来得重要。

这个误会,就好比交互设计只是绘制线框图。

当我们过了学习Axure工具技能的阶段,就需要明白他只是个简单的工具,他不能带来优秀的交互方案(会word,不一定能成为作家)。

所以:需求业务的理解、推敲;需求的拆解;功能列表的整理;大流程的分析、斟酌;多种设计方案的对比、平衡等等,这些是我们重点花时间的地方。而且这个过程不是线性的,需要反反复复。最终做到“脑中成图”,思路很明晰之后,打开Axure把方案呈现出来,那是水到渠成的。

这样不仅能让你顾全大局,对整个产品更好的把控而不是过早的陷入的细节中。避免忽略主次,来来回回出现多次返工而没抓住重点,影响整理思路的顺畅。

误会2:尽可能追求完整、高保真的原型,而忽略交互细节说明。

1.是否真的要制作高保真复杂的交互动效?

确定几个问题之后再动手…始终明白它并不是交互设计的重点。花一两小时在动效上,倒不如多斟酌流程和更多的解决方案。尤其是没经过斟酌的方案,反复修改,无用的成本投入太大。实在时间充裕,不如利用交互设计自查表(可以自行了解),把交互细节说明交代清楚。

  • 问题1:是需要给客户直接演示的方案吗?
  • 问题2:这个动效是否不能通过其他方式来表达?例如,文字说明,口头介绍,或者实际的例子。
  • 问题3:这是斟酌后最终确定的方案吗?

2.过程中交付不完整的方案,更有利。

先确定核心场景、重要的流程页面,慢慢提交方案,避免一次提交完整的方案。同样是有主有次的道理。

误会3:不注重提高Axure工具技能的效率。

几点建议:

  1. 积累、更新自己的组件库
  2. 创建空白模板,设置好参数项,以及都会用到的页面(文档说明、版本记录等等框架)
  3. 利用母版,不多解释
  4. 大项目中,需要创建项目部件,达到复用的作用,确保统一性以及效率。

误会4:不注重原型的视觉层次

“在原型阶段,不要过早的引入色彩”、“配色不要超过3种”…最终依旧没有美感,不耐看!甚至没法看。

怎么办~~

这个时候需要寻找几种中性色、一种主题色、一种功能色配合白色来使用。(找一个好的案例,把颜色提取出来。)

找到一个好案例

提取色

大量中性色使用在导航框架、背景底色、描边、或次级操作等等,它的使用有利于关键内容的衬托和功能的引导。

主题色主要体现在关键行动点及操作状态、重要信息高亮等场景。拉开视觉层次,更聚焦到任务本身,便于理解。通过主题色来引导视觉流。

通过主题色,体现主次

不需要体现主次的地方就不要通过主次来引导用户

功能色,这类色彩起到传递功能信息、代表某种状态等作用。主要应用于消息通知、反馈提醒、表单校验这类场景中的成功、出错、失败、提醒、链接等状态。

如果对您有任何帮助,那是极好的。

 

本文由 @UX笔记本 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自PEXELS,基于CC0协议

打赏也是一种认可
7人打赏
评论
有话不说憋着难受!
  1. 现在国产Mockplus做原型也是非常给力的,拖曳鼠标即可完成交互,最近更新的格子(类似Axure中继器),页面流程图,脑图(类似Xmind),模板例子等,非常给力!

    回复
    1. 都是工具哈,做交互工具不是重点

      回复
  2. ;-) 初学者,给小编点赞

    回复
    1. 棒棒的

      回复
  3. ;-)

    回复
  4. 关于高保证原型,有2点看法:
    1.高保证原型还是有必要的,原型文档做的尽量精细,对于前端设计界面,后端梳理逻辑更有帮助,有助于提升开发效率。有时候把业务逻辑表现成流程图真的不如一个现成的模板来的好,流程图过于复杂有时候真不如原型上点2下更好理解
    2.不执著于高保证原型我觉得得有个前提:就是在工期有限,需要快速开发的情况下不要执着于高保证,或者说项目并不是很打,业务逻辑很清晰的情况下不要执着与高保证原型
    3.我想大公司不管项目大小,都会要求高保证原型吧(这点不是很了解,但是我所在的公司是这样要求的,其他公司有带求证)。所以我觉得多做高保证原型对产品经理的能力也有一定的提升

    以上是我对于高保证原型的一些看法,还是很感谢楼主分享,学习了,谢谢哈

    回复
    1. ;-) ;-) 互相切磋学习

      回复
  5. 初学者。了解了很多 赞

    回复
    1. 对你有帮助,那是极好的 ;-)

      回复
    2. 有用那就是极好的

      回复
  6. ;-)

    回复
  7. 沙发

    回复