Designing Intuitive Microinteractions （设计本能型的细节交互）
“等等，你刚刚做了什么？”
这就是 STD 传播的方式. 在上面的事件中, 我通过滑动通知图标解锁了自己的iphone.
在IOS6中，你可以通过滑动通知的Icon来解锁iphone，并进入相应的应用。
按住通知Icon，然后向右滑动。手机可以直接进入到给出通知的APP中。
我边上的人可能从来没看到过有人用这样的方式来解锁Iphone。他可能很早就拥有了Iphone，但是并不知道Iphone有这样的功能。
当然，他又怎么会知道呢？这里并没有视觉上的暗示来告诉你通知是可以滑动的。如果你只是在一开始拥有手机时被告知这个功能，你现在也可能已经不再记得了，除非你不断使用它。
STD: Socially-Transmitted Detail （靠社交来传播的细节）
我发现能通过上述方式解锁手机是因为我看到其他人这么使用过。他们就站在我的身边，然后滑动了icon，这让我叫出声来：“等等，你刚刚做了什么？”
我们给这个现象取了一个名字：Socially-Transmitted Details 。
STD是用户从其他用户身上学到的交互方式。在界面上没有教育或者线索来告诉你这个交互的存在。
一个比较传统的STD就是通过拖放来完成一些操作。例如：把一个文件拖动到应用上来打开它。把照片拖动到照片编辑软件的ICON上来打开照片的操作可能你无法靠自己来发现。你不得不被告知。
Calling the Magic Escalator of Acquired Knowledge（获得知识的神奇扶梯）
从定义上来说，被STD隐藏起来的特性不是直觉的。因为用户不知道他们的存在，他们不能使用他们。
大多数这样的特性埋葬在微交互中，就如同滑动通知来解锁的特性。Dan Saffer（一本关于小交互的书的作者）说过他们是围绕在一个用例周围的行为——他们有一个主要的任务。比如滑动解锁的主要任务就是解锁手机，并把用户带入到给出通知的app中。（也就是STD都需要对应一个明确的任务）
为了让微交互提供帮助，他们需要对于用户显得是直觉性的。我们如何知道我们是否设计了直觉性的东西？那就是Magic Escalator of Acquired Knowledge因素所存在的地方。
不久之前，我们发明了Magic Escalator去帮之解释直觉性设计如何起到作用。在我们设计一些微交互时，我们最关心的点在于用户当前拥有的知识和他们需要获得的目标知识。
当前拥有的知识是我们在接触设计时已经拥有的知识。它包含过去对于相似设计的经验或者他们从现实世界中获得的知识。（比如翻书或者操作汽车仪表盘）
目标知识是用户完成任务所必须要有的知识。而那些设计需要用户知道而用户还不知道的东西就是目标知识和当前知识的差别的了。
The Magic Escalator of Acquired Knowledge helps explain what we need to make our microinteractions intuitive （懒得翻译...）为了让我们的微交互对于用户来说是直觉性的，我们需要利用他们的当前知识。直觉性设计时让当前知识和目标知识合二为一的设计。因此，我们需要基于用户已经拥有的知识去设计。不幸的是，当我们设计了一个STD的时候，我们已经离开了直觉性设计。
Thinking Intuitively
If you use Luke Wroblewski’s Polar app, you’ll probably want to check to see if any new polls have been added by your friends. Like many phone apps, he’s included the pull-to-refresh interaction.
Polar tries to reinforce the user’s current knowledge by offering a little hint that tells them to “Pull down to refresh...” Pulling down further rewards the user with a cute graphic (which changes each time) and changes the instructions to “Release to refresh...”. This interaction, which only lasts a second or so, makes it clear what to do, making it feel intuitive.
In Polar, pulling the page down starts the refresh operation
After the user has pulled enough to see the graphic, releasing starts the refreshPolar still has the problem that users need to know to pull in the first place. If they’ve used many other apps, that will be their current knowledge. Many users might do it subconsciously. We call that finger memory since your fingers seem to do it on their own.
However, new users to the phone may not know about this yet and nobody has told them. They won’t get the benefits of the refresh microinteraction.
A Longcut for Every Shortcut (Mostly)
One solution is to think of the STD as a shortcut to the functionality. That means there must also be a complimentary longcut to get the same functions. We can drag a file onto the app’s icon to open it, but we can also open the app and use the File > Open commands to accomplish the same objective. Sliding the notification icon over to unlock the iPhone is the shortcut, while using the standard unlock slider and opening the application is the longcut.
Another approach is to bypass the shortcut altogether. United Airline’s iPhone app used to have a pull-to-refresh microinteraction for updating flight status and reservation data. In a recent design update, they changed that to use a refresh icon that’s always visible at the top of the screen.
United Airline’s iPhone app replaced their pull-to-refresh microinteraction with a buttonSensible FeedbackWhat does the microinteraction do? If we want it to be intuitive, it needs to do what the user expects. Those expectations also come from the user’s current knowledge.
In many phone apps, the pull-to-refresh microinteraction bounces back into place immediately. If the refreshed data updates right away, the user is happy. That’s what they expected.
But what happens if nothing changes? Does that mean the operation didn’t work? (Maybe the user thinks they haven’t pulled it down far enough?) Or is the server just slow in responding?
Some designs use an animated busy indicator (such as a spinner) to indicate the app is still retrieving data. Some don’t snap back until the server has responded, floating open to indicate data is on its way. In some cases, a text message appears to say “Checking for updates...” or something similar.
Well-designed microinteractions provide the user with sensible feedback. It feeds into their existing expectations, even if it presents it in a way they’ve never seen before. This is the basis of a mental model: cause and effect. The user’s action produced the expected outcome.
Clear Microcopy
Embedded in most microinteraction designs are words. Take an online banking app, for example. At some point, a user may need to cancel an automatic payment. Because this is a serious operation, the system needs to verify with the user that the automatic payment is about to disappear forever. That verification is another type of microinteraction – one that needs to be intuitive.
A poorly designed verification microinteraction might ask the question using the standard OK and CANCEL buttons. But what does CANCEL mean when we’re verifying a cancellation? Does CANCEL eliminate the automatic payment or does it cancel the cancellation?
What does CANCEL do in this case?A better designed verification microinteraction could use clearer language to help the user understand their options. Buttons with improved microcopy might use full sentences like “Yes, go ahead and cancel the payment.”
Improved microcopy could help the user make the right choiceDesigning Intuitive MicrointeractionsAt the core of any interactive experience are dozens of microinteractions – the little details that make that design work. Using our understanding of building intuitive designs, we can focus our efforts on making the right choices to help our users know what to do, how to do it, and what to expect.
评论