Digital Access Management

Product Design
Product overview
Mobile App
Door Handle(mounted on the door)
Electronic Device (mounted on the wall)
The product lets people open any door, with any phone in a highly secure way through a digital key: LightPass. People can share a digital key with their employees, friends, or guests through the app, instead of delivering a key by hand. They can also define time restrictions for each person and manage their access.
My contributions
Aug 2018 — Jun 2020
As an only UX designer, I was in a vital role in achieving business goals while keeping the focus on the user. I brought the Human-centered design approach, facilitated Design Sprints, applied Design Thinking methodologies, supported UI designers to build up a design system. During the process, I collaborated with different development teams like backend, embedded, React Native, and frontend developers.

Let's start!

The target group
We clarified the target group in collaboration with the Sales team and stakeholders. Place (workspace) types in the app are based on the target group. They're defined below:
Co-working space
Co-living space

Goal #1

Make the door opening feature intuitive and quick

The illustration designed by attoma Berlin.
User & business goals
The user goal was to open a door quickly and intuitively; the business goal was to increase customer satisfaction, enhance the usability of the main feature of the app and gain more customers with the "easy open" function.
Open any door, with any phone, is the main feature of the app. It should be accomplished by any user quickly and intuitively. However, with the technology we use, the user has to find the right digital key (called pass in the app), tap on the "Open" button, use the LightPass in front of the device to open any door. If the user has ten digital keys (passes), he/she has to scroll and search to find the right pass, which takes a lot of time.

Research: Guerilla Usability Testing & Interview

I follow Don Norman’s human-centered design process. There are four different activities in the process.
  • Observation
  • Idea Generation
  • Prototyping
  • Testing
Testing the legacy app
Guerilla Usability Testing
I conducted a guerilla usability testing to gather user insights and identify the usability problems in the legacy app.
1. The product installed to the door, lets you open any door with any phone in a highly secure way. Assume that you have an account and use the app. Can you try to figure out how would you open this door via the app?
Key findings
  • Most of the participants spent quite much time to scroll down and find the right pass.
  • Some of the participants hesitated that they could open a door through the home page. It was not clear enough.
  • Most of the participants tried to use the LightPass in the wrong way; they didn't know how to use it. 
  • One of the participants found the LightPass very bright and expected a warning.
  • Most of the participants didn't know what to do after using the pass. There was no feedback or a close button. The user has to tap on the pass to close it or the back button on Android.
To do's
  • Find a better way to display passes that let users quickly find the right pass.
  • Make sure that the user understands that each pass is a digital key for a door.
  • Add visual instructions that explain how to use the LightPass.
  • Add a dialog that warns the user about the bright lights.
  • Due to one-way communication between the device and phone, we can no give success or error feedback in the app after a LightPass usage. We also can not close the LightPass after it's used because the app doesn't know if the pass is used successfully or not. Hence, I added a highlighted "close" button on Active LightPass. So, the user can close it after using it.

First ideas and iterations

Legacy app
Task Analysis
  • Scroll and display the passes
  • Find the pass which belongs to the door that you want to open
  • Tap on the "Open" button on the pass
  • Use LightPass in front of the device
  • Open door
First sketch
Task Analysis
  • Display the pass
  • Tap on the "Open" button on the pass
  • Use LightPass in front of the device
  • Open door
First ideas
Sketches, wireframes
During idea exchange meetings with development teams, some of the team members suggested using Bluetooth or GPS technology. In that way, the app could figure out which LightPass to use for every door. So, as you can see the first early sketches above, the app shows only one pass, and the user doesn't have to look for the right pass. That was the best solution in terms of user experience: no pass hunting, no thinking, and no scrolling!

However, it was a time-consuming improvement; the development teams had many other priorities, and we didn't have enough sources. It was sad to postpone this idea to implement in the future.

The version in the middle was clear to have one big pass with a horizontal scroll. However, it was vital for us that finding the right pass shouldn't take much time. So, I kept looking for a better solution.

In the end, it was good to consider other possibilities and know the limitations. So, at least, I learned that I have to keep the "Step 2" above on the Legacy App. My next focus was to find an intuitive way for pass selection as you see on the latest iterations.

Final solution (before/after)

Task analysis
  • Scroll and display the passes
  • Find the pass which belongs to the door that you want to open
  • Tap on the "Open" button on the pass
  • Use LightPass in front of the device
  • Open door
Task analysis
  • I displayed as many passes as possible at a glance (less scroll)
  • I highlighted door type icons instead of text (Door Name) that helped the participants a quick scan with the eye.
  • Tap on the "Open" button on the pass
  • Use LightPass in front of the device
  • Open door
Final User Interface and Icons are designed by attoma Berlin.
Final solution
Wireframes, final UI
When I think about how we use the physical keys, we first put it in a place where we can easily find it. Secondly, we usually put a kind of label on it to distinguish from the other keys, or the shape of each key is already different, and we don't need any label. So, we quickly and easily get in when we arrive at the door. I came up with the idea which provides users as much as passes at first sight, and the passes should be customizable as the physical keys. So, they can display and distinguish each pass quickly.
Usability Testing (Target Group)
"It's clear that every card represents a different door."

Visual Instructions

The photos are taken by FSB Marketing Team.
Add a step by step guide
Sketches, Final UI
I had a shocking finding from the first user testing, as I mentioned in the key findings; most of the participants tried to use the LightPass in the wrong way! Instead of displaying the flashing lights in front of the device, they held the camera in front of the device like they're scanning a QR code. It was a crucial finding for us because door opening (the main feature of the app!) had to be the most natural interaction. 
So, I added visual instructions that explain how to use the LightPass on the homepage.
Final User Interface and illustrations are designed by attoma Berlin.
Next steps
The next steps are to implement GPS technology to the app for filtering the passes based on the user's location, add guided tour for the users who download the app for the first time, gather customer feedback by performing analysis and tracking tools to the app and improve the user experience.

Goal #2

Ensure that users easily meet their needs in the application

Photo by NordWood Themes on Unsplash.
User & Business Goals
The user's goal was to intuitively navigate throughout the app, including finding the features they need; the business goal was to reduce customer frustration moreover adding the value of the user-friendliness of the products in sales and marketing.
According to customer feedback stakeholders received, users have difficulties in discovering:
- If they can share a pass (digital key) with someone else
- From which page to install a new door
- If they can log out from other logged-in devices 

As I explain below, I validated the feedback in the first round of guerilla usability testing.

Guerilla Usability Testing (continuing)

Testing the legacy app
Guerilla Usability Testing
In the first round guerilla usability testing, I gave other three tasks to the users to observe their interaction in the app:
2. Your company uses the product, and they've just purchased a new one for another lunchroom. You'll assist the technician during the installation. Could you figure out how you would start the installation process in the app?

3. You logged in to the app on your friend's phone last week. You noticed that you've forgotten to log out. How would you find out what devices you are logged in?

4. You use the product in your home, and your friend Carolyn is visiting you. You won't be at home when she arrives. So, you want to share a pass (digital key) with her. How would you do that through the app?
Key findings
  • Most of the participants had difficulties in discovering how to install a new door.
  • Most of the participants couldn't discover to log out from other logged-in devices.
  • Most of the participants drove round and round to complete the tasks. The app had poor navigation and information architecture.
  • None of the participants (seven) were able to discover to share a pass (digital key) with Carolyn.
Share/create a pass
"Identifying the fact that the owner's pass allowed me to generate other passes to somebody else is difficult." 

Design & content audit

Determine the problems
Nielsen's Heuristics
I determined the problems with content and UX audit. The outcomes were like below:
  • Consistent error/success feedbacks 
  • Clean color scheme 
  • Consistent language
  • Poor navigation and information architecture
  • Inconsistent interaction patterns 
  • Hidden features
  • Unfamiliar terms
  • Poor design system 

Improve the content relation and information architecture (IA)

Icons designed by attoma Berlin.
One user account can have multiple buildings; each door belongs to one building. The user can have multiple accounts and switch between their home and office accounts. The user can not have multiple accounts with the same email address. For example, one employee can not create multiple accounts with his/her work email to access the other branches of the company.
Icons designed by attoma Berlin.
The information architecture had a direct effect on users and software architecture. So, I improved the information architecture in collaboration with the software development teams. We changed the structure from account-based to workspace-based. So unlike the previous structure, we provide the user can have multiple accounts with the same email address in a different workspace (Place). For example, an employee can create multiple accounts to access the other branches of his/her company with the same work email. In that way, the employee can log in to the Berlin and Munich offices with the same email but different accounts; the passes are automatically filtered based on the logged-in Place, the user can have different roles (member, manager, etc.) in each Place.
  • The relation between door and pass was confusing; a door has a name, but a pass also can have a different name. For example, a door can be named as "Hawaii Conference Room" in the app and physically at the door entrance, on the other hand, an HR Manager can give a different name to the pass while sharing with an employee. He/she can name it "Conference Room" or "Temporary Interview Access" while sharing with a candidate. However, the employee or candidate can not know which conference room he/she can access since it named differently. This decision was made to provide users flexibility. So, they can give different pass names for the same door, but in fact, it generates chaos and risks that the user can't find the right door.
  • The door address is displayed on each pass, but if the user wants to update it, he/she should go the address book and figure out which address belongs to which door/pass.
  • Neither a door nor a pass has the floor information, which is crucial for user to find the door.
  • While the user creates a pass, he/she must give either owner, admin, issuer, user-level permission to the recipient, or select the pass type as temporary. Regarding the usability testing findings, this information group confused most of the participants. First, they're two different categories under one choice: recipient permission type and pass type. Secondly, the terms are unfamiliar to most of the participants.
  • As I mentioned the problem on the legacy app, being able to give different pass names to the same door confuses the user and makes it challenging to find the right door. So, I removed the pass names. While the installer sets up the door, he/she selects a door type and enters a door name. The system uses the door type icon and name while creating a pass. In this way, each door has a consistent pass matching with the door. For example, if a door named "Hawaii Conference Room" during the installation in the app and physically at the door entrance, the system designates the pass name as "Hawaii Conference Room".
    In addition to this, I provided a description field for the temporary passes. So, an HR Manager can describe the meeting "Temporary Interview Access"  and the recipient still gets the door name and description together.
  • I removed the door address and added the floor information on each pass. The user can display the address under the pass and door detail page and edit it under the door detail page if he/she's a manager level member.
  • I changed the permission settings into can share-can't share since we defined user levels(owner, manager, member) of the Place. I separated the pass type at the beginning of the pass creation wizard as normal-web and included more information about the options.
Collect data
Open Card Sorting Study
I conducted an open card sorting study. So, the users were free to assign whatever names they want to the groups they've created with the cards in the stack. In that way, I could also discover if they call any feature differently. I could conduct it with five participants because of time limitations. The number of participants should be around fifteen/twenty, according to Nielsen Norman group. That's why I just used the input as a base (to be validated later) for guiding me.

I paid attention not to use terms on the cards that bias participants. For example, I haven't used the name "pass". Instead of saying "create a pass"; I said "giving access to someone for opening a door." You can find below the cards categorized by the participants during the card sorting research:
New information architecture
Site map
I created the new sitemap for the app and desktop app based on my findings.

Final Result

Validation & impact

Guerilla User Testing
After implementing the solutions to the prototype, I conducted user testing for validation.
Discoverable pass creation
Lostness Score
While observing the participants’ performance, I’ve also assessed if they feel lost on their path to success by using a “lostness score”. The lostness score measure is the user's ability to find a specific information.

The metric itself is pretty simple as it ranges from zero to one. A high score of lostness means users are having trouble finding what they want. A low score means the opposite, that they are able to find what they want with relative ease. Anything under 0.4 indicates that there are not lost and anything over indicates that they’re lost.
Legacy App
  • Most of the participants drove round and round to complete the tasks on the first guerilla user testing. The app had poor navigation and information architecture.
  • I decreased the average lostness score from 1.17 to 0.9 for the pass creation task, even the prototype was not fully functional and had some adverse effects on the participants.
  • The new information architecture, less technical descriptions, and consistent patterns helped participants to discover the features and increased user satisfaction.
Next steps
The next steps are to gather customer feedback by implementing analysis and tracking tools to the app, follow app store reviews, and interview with the customers for validating the design and improving the user experience.

Goal #4

Make door installation intuitive

Photo by Theme Photos on Unsplash
User & Business Goals
The user's goal was to install a door smoothly and operationalize the product; the business goal was to have more self-sufficient customers to relax the technical support and costs.
The door installation process has to be done through the mobile app, has many steps, requires some basic technical knowledge, and includes many inputs from the customer. In addition to that, a new product of ours was ready for the market, which requires the Bluetooth connection during the installation. The challenge was to merge all of the steps in a logical way that provides a natural user experience and incorporates technical-time limitations.
Clarify the user activities
User Story Mapping
I followed the User Story Mapping methodology to clarify user activities and tasks(stories) with other team members. The reason for using this methodology was to share understanding with all team members, catch technical barriers while advising the design solutions. In that way, we eliminated many possible solutions due to technical or time limitations. At the end of the session, it was clear which path the user (and me) can take.
Define the user flow
  • I improved the user flow that provides intuitive interaction by considering the technical barriers:
  • The user had to scan a QR code which he/she gets from the product package that connects the product/device with the system. Since the app could gather some of the information about the device after code scanning, I moved this step at the beginning of the process. In this way, the user didn't have to add extra information that we could gather by QR scan.
  • The user had to connect his/her phone to Bluetooth to be able to install a door. In that way, the phone could communicate to the device mounted on the wall/door. So, I guided the user by adding the Bluetooth connection steps based on different product types(installed on the wall/door).
  • I moved the test step at the beginning of the installation process, after technical configuration settings. In that way, if the door doesn't work at the test step, the user can not proceed unless it is successful.  If the test step is successful, the user can continue the installation process with typing door information like name, floor, address, etc. Thus, I prevented the loss of data that the user would have entered before the test step when the door did not pass the test step. This change also reduced customer frustration.
  • With the feedback I gathered from the participants during the user testings, I added a screen that warns the user about the bright flashing lights while he/she is testing the door.

Install a Door, Final UIs

UIs are designed in collaboration with attoma Berlin.