如何优雅设计二维码 – (上)

设计思考 +

上篇 – 二维码基础知识

在2017年的今天，二维码的应用已经融入到生活的方方面面，其中二维码作为主要载体的移动支付，已经得到了极为广泛的应用，一二三四线城市的大街小巷所有几乎线下商家都可以使用扫码来进行支付，由此可见二维码所承载的移动支付渗透率有多么的惊人。

在我们已经如此普及的使用到了二维码的情况下，我们对二维码基本知识的了解到底有多少呢，借此机会希望一起就二维码的来龙去脉一起进行下完整的梳理。

先抛观点，借助于我们熟知的互联网超链接的概念，我对二维码的诠释为：“二维码是连接互联网世界和现实世界的超链！”，它的本质是一种连接方法！

二维码是连接互联网世界和现实世界的超链！

二维码产生的背景

二维码又称二维条形码，顾名思义就是两个维度的码，这里的维度就是指方向，具体点就是水平和垂直方向可以存储信息的码；对应于二维那是不是应该有一维码呢？答案是确定的。

二维码的“爸爸”就是我们熟知的一维码，又名叫条形码，条形码的身世就不在这里深究，且说条形码的出现可以说是一炮而红发展非常迅速，条形码带着各种先天的光环得到了工业时代所有人的关注，它极大地提高了工业流程中的数据采集和信息处理速度，大大地提升了工作效率，为世界四化做出了极大的贡献！至此“但是”终归还是要出现，由于受一维码存储信息量的限制，一维码只能做到对物品的标记做不到对物品的描述，它的使用不得不依赖特定的数据库来翻译那些标记才能有意义，没有这些数据库的时候就会歇菜，所以它的应用范围也受到了大大限制，在很多新兴场景下显得特别无力！再补一刀就是条形码实数不太识字，在用到汉字的场合就变的无比的尴尬！所以一维码的进化版出现是历史的必然，幸运的是历史刚好选择了二维码！二维条码正是为了解一维条码无法解决的问题而产生的。因为它具有高密度、高纠错性等特点，所以可以用它表示数据文件、图像更加靠谱；同时二维条码是大容量、高可靠性信息实现存储、携带并自动识读的最理想的方法！

继续阅读如何优雅设计二维码 – (上) →

老板送宝的春节体验反馈

设计思考 ++

背景信息：

  • 产品：糯米一元抢宝
  • 平台：Android，HTML5
  • 版本：糯米7.1.0；老板送宝：1.0

糯米一元抢宝新玩法【老板送宝】春节前正式上线并迎来春节假期，休假的“老板们”在亲友群中尝试发几期【老板送宝】，完整真实体验了产品存在的种种体验问题和亲友们使用的反馈建（TU）议（CAO），做了逐一记录如下。

因为是春节期间，按照往年传统微信红包才是大家联络感情喜闻乐见方式，在亲友群里【老板送宝】信息的出现难免会被拿来和微信红包对比一番；简单总结下，如果微信红包是“雨露均沾，即发即抢”，那老板送宝就是“独宠一人；坐等开奖”。

微信红包是随机平分总额，参与者多少都会领到小至一分钱大到几十几百现金！“抢红包竞争性+随机派发的不确定性”机制下，虽然每人得到金额有多有少，但参与者积极性被充分的调动起来。【老板送宝】本质是一个人买完商品再通过一个抽奖平台发放出去，目前中奖者只能是一个人，相对维系红包来说老板送宝这样的机制在调动大家参与的积极性上稍逊一筹，且必须领完奖品才能开奖，这也为一些尴尬情景产生买下了伏笔，后文会有说明。

在整个【老板送宝】参与过程中有三个主要角色分别为“老板”，“参与者”，“中奖者”，后面将从三个角色视角来阐述下不同角色分别遇到的使用困惑。

老板的困惑

备选合适商品少：春节期间全部品类一共约50件左右，作为备选还是较少，若没有适时的商品可供选择，无法有效激发老板们送宝的热情；

电子商品更受欢迎：因为春节期间物流停运，并且物流涉及到后续太过复杂，所以电子类商品成为首选，但是电子商品可供选择不多，且定价“太高”；

商品单价过“高”：相对于不同用户群体的认知水平，价格高低是相对的，老板送宝商品价格起点普遍偏高，鲜有低于50元的商品，阻碍了老板们的连续多次送宝的积极性，没有引爆病毒式传播的基础；

内容口令分离：分享到微信好友群，口令复制需要单独再次黏贴，如果忘记手动复制，可能涉及到 APP 间的切换，操作变的复杂繁琐；

需要解释规则：复制的口令内容只有口令本身，直接黏贴后可能是“1234”或“abcde”没有显著意义的字段，口令单独发送后一般都不理解后面发送的这段内容的含义，此时需要发起人需要不停去解释，例如“这是口令…；需要输入口令…；记得复制口令…；等等口干心累”；

不受控的开奖时间：大家对老板送宝这样的新玩法的认知和积极性普遍不敏感，假如新手发起人发起份数过多，导致可能会出现不能很快领完的尴尬！此时老板就很希望可以自己控制开奖时间！但规则默认是三天自动开奖，就会好尴尬。

中奖人是谁：参与记录采用这种1******6极端的加密方式，导致开奖后作为发起人都不能很快的确定获奖者的名称！全靠猜。

不能糯米余额购买：中奖者中了糯米卡，回馈大家也想发起老板送宝，但不支持糯米卡余额支付，导致糯米卡金额无用积累。

支付手段单一：目前只能用百度钱包，相对小众的百度钱包绝大多数用户需要重新绑卡，支付成本无限增加，间接导致新用户发起送宝难度很大。

继续阅读老板送宝的春节体验反馈 →

7条避免 Axure 慢死的注意事项和解决方法

设计思考 ++

Axure 作为产品经理交互设计师主要的吃饭工具，平日打交道多了，使用过程中必然会遇到工具偶尔“罢工装死”的情况，一旦不幸遇到了这些情况如何解决呢？下面是结合我们团队和自己使用过程中总结归纳的一些避免 Axure 软件运行缓慢和假死的一些经验教训，希望对遇到类似问题的同学有对帮助和启事。

1. Axure 单个页面内不要有太多的 Group，尤其是嵌套的 Group，有次设计师在 Axure 7 中的一个页面打开和操作都巨慢无比，打开文件要花5分钟，操作就假死三分钟，经过排查发现就是因为一个模块中适用的 Group 太多了，而且是嵌套 Group过多导致，耐着性子 Ungroup 后操作慢的问题得以解决。

2.  Axure 中高清大图不要太多，大图太吃内存，尤其单个页面不要太多，如果真的需要放很多高清大图，建议一，分散在不同页面，建议二：对图片进行预先压缩，让图片大小减小。因为太多大图会导致最后生成时候内存报错。

3. Axure Repeat 功能是提升效率利器，但是单个页面内太多且复杂的使用 Repeat 功能，也会让页面变的很慢，容易出错。

4.  既然是软件就会有 Bug，不同版本的 Axure 本身会有 Bug，对于一些元素的应用，会导致无故报错，有次遇到一个用最新的钢笔勾画的图形，在版本迭代后再次打开就会报错，而且没有指出报错内容，找了好久才定位到的错误，删掉那个钢笔图像元素就一切回复正常了。

5. 我之前用的自己生成的图标字体 ，在配置中添加 Font 链接，但是由于链接地址更新，Axure 文件配置没及时更新，文件打开加载好久，后来才发现是 WebFont 链接错误，Axure 一直在取地址没反应，也会导致变慢或假死。

6. 如果发现太慢，就关闭 Axure，再重新打开，因为时间长了它的缓存机制存在问题，退出重启往往能解决一些偶尔出现的报错和锁死，此条方法其他软件遇到问题同样适用哈。

7. 多用 Master，减少不必要的重复，降低维护成本，也能让页面快点。

如果以上问题都不足以解决你遇到的问题，那就建议你去 Axure 官方论坛中搜索下关键词，前人踩过的坑就在那里，不妨多学学；或者可以直接去发帖子提问，也许很多 Axure 大拿会帮你解决。

如有你还有其他典型方法的遗漏也欢迎补充交流。

Axure 功能进阶高手篇

设计思考 +

本次挑选的功能点，是区别 Axure 高手和菜鸟能力的分水岭，师傅领进门，修行靠个人，有识之士请务必努力逐条修炼。（本次涉及功能点请参照 Axure 7 以上版本）

一、Widget 类：

Dynamic Panel ；
动态面板是定义了 Axure 最核心的模型；可以这么说，脱离了动态面板的 Axure 就不能称之为 Axure，几乎任何原型的各个环节都会看到动态面板的身影，动态面板的使用让 Axure 制作原型增加了无数可能性；
深刻的掌握动态面板在原型制作中的规则，将对你的设计带来质的飞跃。

Masters；
Masters 就是孙悟空吹口气变出来的小悟空，它可以让你的模块元素复用变得异常容易，尤其是在夸页面的模块引用场景下尤为突出；不过需要考验你对整个交互结构的清晰认识，Masters可以帮你节省大量时间并降低维护成本，但是有时候也会因草率行为掉进Masters的各种坑里。

Repeater ;
Repeater 存在的意义在于某些需要大量重复且有一定规律的设计场景下，Repeater 会帮你大大提高效率，并且降低维护成本；Repeater 本身属性的灵活性，也可以让我们更加灵活的适用于不同的场景；拿下 Repeater 会让你在大型项目中事半功倍。

继续阅读Axure 功能进阶高手篇 →

Axure原型在iOS上的演示

分享学习 + 设计思考 +

由于接手的移动项目逐渐增多，在初期的设计探索阶段交互设计原型如何在移动设备上能够很好的还原，成了我现在比较多的研究课题，也看到了很多关于在iOS设备上实现原型效果的文章，但感觉总是缺了那么一点内容；因为我的一些方法在具体项目中已经得到验证，也已经在团队内部做过关于iOS设备上原型展示的内部分享，综上所述，还是决定把之前总结的一点心得记录下来，贴出来与大家分享探讨。

本文的内容主要聚焦：如何让利用Axure（6.5）制作生成出来的移动APP原型在手机上流程的还原。

最基本的原理：在局域网WIFI下，利用Web Server把Axure原型文件共享，利用iOS设备的浏览器访问Server的html文件，从而实现在iOS设备上演示原型的目的。

Axure_prototype_on_iphone

主要内容分为以下几大块，分别展开说说：

继续阅读Axure原型在iOS上的演示 →

对新版Axure的10点期待

分享学习 + 设计思考 ++

目前主力使用的是Axure 6.5 版本，包括MAC和PC两个平台的同一个版本，6.5在之前的基础上增加了很多非常有用的好功能，具体功能在这里咱就不多做说明，网上可以找到各种的溢美之词。

说明一点今天的“吐槽”只适用于我的工作流程，是我长期使用Axure过程中发现的一些问题和功能短板，在这里做个小小的总结，算是向Axure致敬的同时，希望在不久的将来的某一天，还会用到Axure的时候，那会儿的新版本中能够看到以下问题可以得到改进或解决。

———我是分割线———

1. 希望Axure可以自带常用移动端设备预览模拟器；
可以是一个独立的插件，或者应用程序，类似与xCode写APP一样最后的结果可以在一个iOS 模拟器上被模拟出设备来，而不用再把移动设备的外壳画在原型里面了，这样对移动原型设计的体验来说是非常重要的；关于不同机型外壳的话，系统可以提供几款常用的例如iPhone，iPad等，用户也可以自定义所需要的分辨率及其机型外壳；
参考：Xcode的移动设备模拟器；

xcode

2. 对CSS3特效的支持，更丰富的图形库；
Axure的输入物为Web页面，目前主流的浏览器对Html5和CSS3的支持成都已经很完善， 其中CSS3的诸多新特性如果可以在Axure原型上很棒的还原，那么Axure原型视觉效果将会上一个台阶；

class-header-css3

继续阅读对新版Axure的10点期待 →

小议时间轴的“w”与“l”加载机制

设计思考 ++

人们经常把浏览微博的行为冠以一个专用名词即“刷微博”，这里理解所谓的“刷”就是需要你在内容时间轴中频繁的刷新加载出新微博内容的这一过程；最近在微博中看到了有朋友抱怨说在使用新浪微博客户端过程中总是得一会正向一会逆向来回反复划动时间线，而且很容易遗漏或忽略一些重要的内容，很是烦恼；借此问题就引出下面要涉及到的时间轴刷新的交互机制问题。

这里讨论的有两种机制，分别是“w”与“l”加载机制；

“w”刷新机制：
由于某些原因（真的不太清楚），我们在Web端浏览器机制中，通常页面刷新之后会跳回到页面顶部并显示最新内容（如W-2）。用户自上而下浏览内容，浏览内容的顺序是由新到旧（或由“最新”到“较新”更为恰当？），如图示一，在Web版微博中，当浏览到内容B底部之后（如W-3），用户要重新划过很大块内容B区域才可以回到顶部（如W-4，这里特指是划动返回顶部的情况，点击刷新按钮的情况另说）然后点击加载更多新的内容C（如W-5）；不断的浏览就会不停的重置这个过程；

继续阅读小议时间轴的“w”与“l”加载机制 →