交互设计互联网收集器PMskill

原型中,这些应该有的说明

2015-11-25  本文已影响452人  湖边的阿曦

前面有说到《原型应该包含哪些内容》包括:

1. 变更日志;

2. 版本说明;

3. 信息结构;

4. 流程图;

5. 交互说明;

其中“交互说明”部分是最直观和细节的,也是研发会仔细琢磨的部分(也是大部分会跳过前面步骤直接进行画图(&交互)的部分),所有需要我们考虑清楚,表达清楚。因为按钮不止一个状态、文本域是有限制的、用户操作不是完全可控的...

1. 状态

默认状态:主要是默认(初始化)显示的数据、文字、选项等。任何一个页面、表单、按钮、文本域等都会有默认状态,这是需要我们注明的,否则研发人员难以准确单纯的从原型上判断出元素背后的逻辑。

常见状态:页面上一个模块,它可能会有多种状态,比如APP客户端个人中心一般会有未登录状态、已登录状态,这些是需要我们展示清楚的,如果我们少写了状态,研发人员就会纳闷xxx(登录)之后(前)是什么样的呢?

异常状态:非正常情况下的样式、文案、说明等,比如搜索无结果、加载失败、网络(定位)未开启等等。异常状态一般较容易被遗漏,最终导致产品体验较差。毕竟用户不是都在办公室里把所有开关(权限)都打开才使用我们产品的。

2. 限制

范围:数据的取值范围。比如轮播图的个数、滑块的范围&刻度、文本域的长度等等...

极限值:数据的显示限制。比如最多应该显示多少字数,超出时如何显示、每次请求数据的条数,不足时怎么办超出时怎么办等等...

3. 操作

常见操作:正常操作时得到的反馈状态。比如一个按钮经过不同操作会出现不同状态,鼠标进入、按下、点击后。

特殊操作:一些极端情况下的操作,出现概率较小,还是要想好应对措施。比如我们在买保险时会有常用被保险人,选中某个其详细信息会出现在申请表单中,如果在这时候修改了被选中人的信息,修改后的人,算被选中人还是新的被保险人呢?提交表单后是覆盖愿被选中人信息还是新增一个被保险人呢?

面对可能出现复杂的情况,要和研发人员一起探讨解决办法,并把交互说明写清楚。有时候研发人员想到的办法可能更简单实用。

误操作:用户操作错误的情况。这种情况采取的措施一般是提前预防错误、适当提示用户、系统自动纠错。比如库存接近0时,选择数量时就会提醒用户库存5件,如果用户输入超出5,则自动更正为5.

手势操作:使用移动端产品时的操作方式。比如滑动、放大、摇晃等。

4. 反馈

提示:用户操作后,系统反馈给用户的提示。

跳转:点击某个链接/按钮后,页面跳转到的地方。网页也表明是原页面刷新还是新标签页打开,移动端要表明转场方式(默认为全局)。

动画:用户操作后,系统通过动画的方式反馈给用户。动画给人的感觉比较友好,趣味性较强,避免过于夸张。比如Clear用炫酷的手势和动画赢得了用户的青睐。

除静态页面外,还需要考虑各种动态情况;除正常情况外,还需要考虑特殊和错误情况。

上一篇下一篇

猜你喜欢

热点阅读