Remote Authorization

Company: Western Digital

Product: ArmorLock

Role: Lead UX/UI Designer, Research, User Testing

The G-DRIVE ArmorLock SSD and app deliver next-generation security and new-generation simplicity combined with powerful, pro-grade performance to help protect users most critical content. Encryption is only the beginning.

The target market is the MNE (Movie and Entertainment) business. Entertainment studios across the world need a secure solution for storing huge amounts of high-quality footage, audio, and more. In conjunction with its associated software, the ArmorLock SSD enables users to securely store content on a drive and then control access it.

ArmorLock doesn't use cloud infrastructure to facilitate access requests. Managers must be within Bluetooth range of a drive to edit its list of authorized users.

Users that want access to a drive must first install ArmorLock on the Android, iOS, or MacOS device they want to use. After they've set up the app, they send their User ID to the manager. The manager adds their User ID to a list authorized users, and then sends them the drive.

1. Manager(location A) syncs drive with ArmorLock app.
2. Users(location B) install ArmorLock App and send User ID
3. Manager receives User IDs and adds Users to the drives Authorized User list
4. Drive is then shipped to location

In theory, the system works great. Managers have complete control over who accesses their drives, and users have an easy way to lock and unlock the drive when it's in their possession. However, there are scenarios where ArmorLock runs into issues. For example, what if the drive has already been delivered to a location with three users authorized, but a fourth user is suddenly added to the team and now requires access? If none of the first three were granted manager privileges, they'd have to send the drive back to add the new user. This will definitely result in delay and frustration.

The obvious fix for these issues would be to enable remote requests. However, we didn't have any plans for adding cloud support to the app. So, the question became:

How do we allow remote authorization of a user without cloud support?

We needed to make a new feature in the app to enable remote authorization. I didn't know what it should look like or how it should function, so I began to research.

To develop a remote access request feature, we needed to understand what our users wanted from it. We started by interviewing some of our MNE users to see what they thought. We wanted to learn what these users needed in order to feel confident that using a remote request feature wouldn't introduce security concerns.

We found that users who managed drives wanted this feature to do some interesting things, such as:

1. Allow a requesting user to add a comment to the manager.
2. Present the geolocation of the requesting user.
3. Enable the manager to take more actions on the request:
   1. Approve as Manager
   2. Approve as User
   3. Deny
   4. Remote Erase

Now that we knew what our users wanted, we met with our engineers to brainstorm. We needed a way to send critical, secure information back and forth between users and managers remotely.

We tried a few ideas, such as QR codes, and ultimately we settled on using email. This is similar to how users send their User IDs to managers when requesting access normally. The engineers developed a way for ArmorLock to create request and response files and automatically compose an email with them attached. This method facilitates sending all the information our MNE users said they wanted to see.

At this point, the Journey Map consisted of three primary journeys:

1. User Request Access.
2. Manager Approves Request.
3. User Accepts Access

We built our prototypes and tested them among or target demographic using Usertesting.com. With our internal design system we were able to prototype rapidly once we had the initial journey map solved.

User testing is where we learned just how the advances in technology have formed a user expectation around automation within applications. The users responded well to the flows up until the user needed to email the generated file themselves. When asked if they had sent the file 90% of users responded “yes” even though they had not sent it. When further asked why they felt they had sent the file they responded “because technology does it for you”. Only 10% of users actually went through the process of sending the email with the attachment file.

Thanks to modern advancements in file sharing and cloud support, users don't expect to have to send requests manually. However, cloud support was off the table, so automation was impossible. Ultimately, we found a solution that worked by creating a list of steps that we presented to the user at just the right time. This led to a huge increase in the number of requests sent successfully in testing.

• iOS Prototypes
• macOS Prototypes

Now that we had the data to understand our users needs, it was time to design. I used Figma to develop the following flows, and worked cross-functionally with others to develop the following flows:

In Summary, we developed a remote access request feature within the limitations we were presented with. We carefully researched our users' needs and then crafted a curated experience to satisfy them. If cloud support is ever on the table for ArmorLock, this will no doubt be deprecated, but in the interim it works beautifully.