An analysis of the interactions on iOS 11
Tags: iOS, UX, Interaction Design, Mobile, Design

Gestures and interactions on iOS11

Let’s start with the lock-screen

The iPhone lock-screen aims to be minimal and as functional as possible. The one downside I have noticed is the way it sets the mental model of users on how it operates.

A good friend of mine, Shankar, delineated everything that was wrong about the iOS10 lock-screen. Since then there have been a few changes, mainly the conglomeration of the lock-screen and notification center which fixes confusion to an extent but most pointers from that article still holds good.

As I mentioned, I’d like to validate my assumptions with as many users as possible. For testing these interactions out, I performed several contextual inquiries with 6 diverse iOS users testing on the iPad — umm, actually 5 users — one was a “I hate everything Apple” person — just for thrills and giggles.

For those interested in the nitty-gritty of the sessions — the results can be found in Google Sheets.

I tried to understand what Apple designers might have had in mind while setting goals for what the lock-screen should achieve — again, these are my assumptions and I have no data from actual designers from Apple.

Goals of the lock-screen

Keeping it minimal to avoid distraction and present only what is important and relevant at a given particular time.

Ability to view current and earlier notifications.

Ability to search without having to unlock — obviously, have to unlock to view the results.

Ability to open the camera quickly.

Ability to access the widgets easily.

Look at the time and date easily.

I divvied up the way to measure this by splitting into three sections – % of users who accomplished the task successfully. % of users who needed a few tries, playing around a bit to learn, and eventually get it right. % of users who just did not get it at all, and hence failed the task.

Completing the task successfully without too much hassle was categorized as task success, whereas when users took more than a couple of minutes to figure an interaction out, I categorized it as a task that required some learning.

With the above mentioned simple goals in mind, I decided to test the interactions on the lock-screen. The tasks I tested on the lock-screen –

Open the camera app from the lock-screen

Task success — 66%

Task failure — 16%

Learning required — 16% Go back to the center lock-screen

Task success — 0%

Task failure — 50%

Learning required — 50% Expectation when swiping right on the lock-screen

Task Success — 83%

Task Failure — 0%

Learning required — 16% Expectation when swiping left on the widget screen

Task success — 100% View notifications

Success — 50%

Failure — 16.6%

Learning — 33% View earlier notifications (just to see if users understood there was a difference between unseen and earlier ones)

Success, Failure, Learning — 33.3% each

Key Takeaways

These are a mix of both, quantitative and qualitative analysis, after talking to the users who helped with the interface validation –

Takeaway 1: Jumping back to the Home Screen from the camera is confusing even for seasoned iOS users.

The fact that none of the users got this right talks about the confusion. Even fairly advanced users of the iPad got this wrong and realized that they get it wrong always.

A question to ask —

How can the lock-screen experience be improved to reduce the error caused when one wants to move from the camera to back to the home screen?

Another perspective —

Is it even necessary for users to jump back to the lock-screen after opening the camera?

This perspective takes the side of the current design pattern, and if we consider that the requirement to jump to the lock-screen from the camera app unnecessary, the existing flow works just fine.

But. there a few quirks with this flow too…

Current Experience

What happens in the current flow is that after a user clicks an image, they have an option to view that image, or return to lock-screen by clicking the Home button. This confused one of the users because pressing the Home button unlocks, which is the most commonly used purpose of the Home button from the lock screen.

Why does pressing the Home button on the camera take users back to the first lock-screen? On the lockscreen when one presses the Home button, the TouchID authenticates and lets users in. Why cannot it take users to the home app drawer page directly instead from the camera app as well after authentication? One rationale I see is that the designers who worked on this might have thought about it as a means to go back.

Another reason I see is probably to handle this situation when the authentication is FaceID. This one is tricky and I see a few trade-offs being made to accomplish an experience with least friction, but how can this be made more intuitive is something to think about.

Takeaway 2: The notification center is still confusing in iOS 11.

The delineation of new notifications vs earlier notifications is a step in the right direction, but again, how can this be made more obvious? Looking at the stats above, even trained users forget patterns that they learnt earlier. There is a significant amount of in-situ learning required to accomplish these tasks, but the learning does not stick as even learned users forget it over time.

The Tips app tries to achieve this to some extent, but seems like it is not efficient enough to help users learn over time from tests performed.

Another point to note is that the pull from top creates a friction by asking users to change direction of swipe to view earlier notifications. Again, this seems like an effort to educate users on how the new patterns work which seems to confuse more than educate.

An interesting challenge to tackle here will be –