iOS - Settings
“Double-Face”
( Face ID & Passcode Functionality Extension)
Role
Solo Ux Designer project
Scope
1 Week
Tools
Figma
Introduction & Extension Overview
The idea came from my first experience with an iOS device. During the first year of using the iPhone SE, I had the opportunity to explore the various features of the software settings. I was particularly interested in the 'Touch ID / Face ID & Passcode' functionality. Using face or fingerprint recognition, it is possible to unlock the phone, make transactions, download apps and permanently delete images from the gallery. The Passcode has a priority level, in fact, any functionality in the general settings can be accessed with it (*).
The mobile device is a personal object, yet we find ourselves having to share it at times with family members, friends, colleagues, etc. (however, trusted people). There are already indicators of this latter dynamic within the iOS software. One could register a face or fingerprint of a person to whom one would leave the device in order to give him or her constant access, as there is no apparent limit of registrations that binds the owner to register only his or her own aspects, and preferring this method of unlocking over the handing over of the code, which has higher priority, as mentioned earlier (*). In fact, the newly registered face will have access to payments and all other functionalities.
From these considerations, the idea 'Double-Face' [ French] was born. An extension that would allow new face IDs to be added and limit the functionality of payments and access to apps if necessary.
Problem Statement & Verification Survey
The iOS software allows unlimited Face/ Touch ID registration. Therefore, if you intend to give access to your device to a trusted person, you can register a new ID. The problem may arise, however, when the latter will be carrying out transactions and accessing apps/sites that are not approved by the owner, as there is currently no possibility of diversifying the authorisations.
After noticing the problem, I already had in my head what the graphic idea could look like, but I thought I would like to carry out a short quantitative survey (about 15 people interviewed) to check the quality of my idea, whether it could be a need shared by others and the probable use they would make of it. I also asked for a willingness to be contacted if I decided to carry out a user test of a prototype in the future.
The graph below shows the percentage of people in the survey carried out, who would not have ruled out the possibility of using the proposed extension. It also allowed me to understand the target group of people for whom I would design the extension.
The survey had positive results for the development of the extension I had in mind. I continued towards the design process.
Would you use this functionality in your phone?
Identification User Personas
Andrea Rossi - The father
Age: 45 y.o.
Description:
Andrea is a father who often finds himself giving his devices to his son. In the car to allow him to select his favourite playlist, at home to allow him to play video games and many other everyday contexts.
Needs:
He wants to share his device but limits access to certain apps (e.g. those where he does not always log out) and payments.
Anna Ferrari - The entrepreneur
Age: 56 y.o.
Description:
Anna is an entrepreneur. In her business, she found herself wanting to communicate with her employees via mobile devices provided by the company.
Needs:
She does not want her employees to download unauthorised apps on the company device and to carry out transactions on behalf of the company.
Johanna Hall - The wife
Age: 29 y.o.
Description:
Johanna is Abraham's wife, she finds herself sharing her phone with her husband for every day events.
Needs:
She needs to limit her husband's access to social networks and other apps.
Abraham Hall - The husband
Age: 28 y.o.
Description:
Abraham is Johanna's husband; like her, he finds himself sharing his mobile device with his wife every day.
Needs:
Johanna uses her spouse's phone to make many online purchases for shoes and clothes. Abraham would like to restrict his wife's access for online payments.
Design Process
For the design of the Face/ Touch ID extension, I started with the study and understanding of the functionality of the software settings, followed by a survey to ascertain the level of interest in the implementation I wanted to design and the identification of the user personas. I started with the design of the wireframe, and the development of the prototype that I would use for the final User Test.
Information Architecture
Sketches
Solution
Usability Testing
In this phase, I contacted the people who participated in the initial survey and who had given their availability to be contacted at a later stage. They were asked to perform four tasks divided into two phases:
Step 1 (the person performing the test is the owner of the phone).
Set Face ID 1 as main and restrict access to the Facebook app.
Recuperare Face ID 1 con visiera
Step 2 (the same person performs the second phase of the test as a secondary Face ID).
Try to access Facebook from the app, once the phone is unlocked.
Buy a pair of shoes on Amazon, opening Safari.
Feedbacks
Those who tested the prototype liked this possible feature extension, 90% of people would have liked to have it in their phone. About 15 percent of people would have preferred, having concluded the settings for activating the main Face ID, a confirmation notice via a pop-up.
After getting this feedback, I evaluated what could be implemented and what would be appreciated but not in line with the brand identity; this led me to the final version of the product.
Prototype
The prototype was divided into two parts. In the first part Face ID 1 sets its ID as “principal,” its actions with the device end the moment the screen dims. After a few seconds the Face ID 2 experience will begin, so it will try to log in to Facebook and then buy a pair of shoes on Amazon on behalf of Face ID 1, from the page opened on Safari.
Conclusions
This idea came about a little bit at a time during the time I was comparing the Android device with one from the iOS. What I noticed, in iOS was a greater demand for confirmation of one's ID regarding various actions once one's device was unlocked. The ideation process started from this last consideration, I wondered why it was so necessary to request the identifier a second time even for actions that do not include online transactions, almost as if consideration had already been given to the fact that the device could be shared among trusted people but with limited actions. So I have tried to work along these lines. In the future, I would like to study different alternatives and create more models of the same functionality, perhaps comparing opinions from a team of other designers.