标签：ati 了解 ... 经验 使用 ref 需要 利用 bsp
所谓原型，无非就是一座沟通之桥，是交互设计师与PD、PM、网站开发工程师沟通的最好工具。作为产品面世之前的框架，仅仅利用模块、元素、线框来表达势必会造成沟通效率低下的问题。与其浪费时间去一一询问细节，倒不如直接在原型中进行批注和审阅，一站式的将产品的概念和构想以最简单明了的方式展现给开发者或设计师，同时及时获得逆向反馈，使整个更新迭代流程事半功倍。
那么，最原始的原型批注及审阅方式是什么样的呢？
在Axure中，相较于使用Axure自带的批注功能，更多人习惯于自己动手制作需要的批注控件。我在一篇浏览量近一万的文章中曾见过这样的批注审阅demo，如下图：
这款demo已经属于自制批注控件中比较优秀的了，但笔者认为，这并非我们需要的一站式审阅批注解决方案。理由如下：
1. 控件制作流程繁琐，在Rapid Prototyping的大趋势下，我们没有理由浪费如此多的时间来制作一个批注控件。想象一下吧，当你还在忙着按照网络上的教程制作批注控件的时候，别人的原型可能已经经历好几次迭代了。
2. 审阅者必须安装有Axure软件。这个要求看似不高，但往往你并不了解甲方的习惯。对很多新人来说，即便你的原型做的出色，可能一次下载就让你丧失了被肯定的机会。何况你还得寄希望于甲方能理解你制作的控件的逻辑。
3. 新人难以上手。对刚接触Axure的产品经理来说，能做出一款原型已属不易，很少有人能腾出时间和精力来自制批注控件，而套用别人的控件又有着逻辑错误等隐患。
基于以上3点，我们大概可以归纳出一种合格的审阅批注方式的轮廓：制作简单、对审阅者要求低、对新人门槛低。
一向以上手门槛极低和快速原型设计为名的Mockplus给出了令人眼前一亮的答案。虽然审阅与批注只是其强大团队协作功能的一小块，但你同样可由此一窥Mockplus的简洁与高效：
1.无需控件自制，一键通知审阅，多种批注组件支持。
2.无需软件安装，急速网页审阅，社交软件型沟通机制。
3.无上手门槛，新人友善度Max。
在这样的审阅体系中，审阅者无需费心劳力地一个个地去hover那些小小的批注点，更无需在冗长的标注中苦苦寻找对应的序号。原型→批注→审阅→沟通→批注→迭代，就是这么简单。原型设计，快是第一要务。我们应该思考的是时间。是把时间更多的花在设计上，还是花在因为工具复杂而造成的障碍上？
更多设计类相关干货（文章及经验教程），尽在：UI/UX专业博客
标签：ati 了解 ... 经验 使用 ref 需要 利用 bsp
原文地址：http://www.cnblogs.com/thomas2/p/7238741.html
