When I joined the one-person design team at 1aim GmbH in 2018, we had time/budget limits to conduct user researches to define personas. However, stakeholders had the target groups defined and created assumption personas. In addition to that, the sales team already received a lot of product feedback and complaints from the customers. The plan was to conduct usability testings based on this information. In that way, I could determine the reasons for complaints and pain points to find design solutions. Refining assumption personas during the research process was also on our long-term plan.

The defined target groups are co-working spaces, offices, co-living spaces, hotels, and hospitals.
The assumption personas are managers, HR officer, employee, contractor, and visitor.
I improved the personas among the continuing research process; the latest version can be found here:  LightCommand(desktop).

We prioritized the user needs by considering business goals with the key team members and stakeholders.

Most of the customers need instruction to open a door with a LightPass.

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 attract 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.

I conducted a guerilla usability testing to gather user insights and identify the usability problems in the legacy app.

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.

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.

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.

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.

Some of the customers find door installation process confusing. They have to repeat some parts of the installation process if any technical error occurs.

The user's goal was to install a door smoothly and operationalize the product; the business goal was 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 customer inputs. In addition to that, a new product was added, which requires a Bluetooth connection during the installation. The challenge was to logically merge all of the steps that provide a natural user experience and incorporate technical-time limitations.

I followed the User Story Mapping methodology to clarify user activities and stories with other team members. Using this methodology was to share understanding with all team members and catch technical feasibilities while advising the design solutions. In that way, we eliminated many possible solutions since we had some technical and time limitations. At the end of the session, it was clear which path the user can take.

I improved the user flow that provides intuitive interaction by considering the technical barriers. I designed the installation wizard by conduction a Heuristic Evaluation of the legacy app. So, I improved:
‍Visibility and system status by adding a step by step wizard.
‍User control and freedom by adding freedom to jump between each step or leave the wizard by knowing that they'll lose the data.
‍Consistency and standards by designing the same patterns through the app. I used the same interaction patterns, such as the "Pass Sharing" wizard.
‍Recognition rather than memory, learning and anticipation by adding visuals while teaching users, guided user so they can use the system at all times without remembering previous screens.
‍Flexibility and efficiency of use by implementing that the user can leave the wizard and continue whenever they want. The expert users can save their addresses and select from the list in the future instead of typing every time.
‍Help users recognize, diagnose, and recover from errors by adding an info button containing necessary information tailored for each step if the user needs it. A checklist is also provided if the product doesn't pass the test step. So, the user can diagnose the errors and fix them.

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.

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).

By restructuring the information architecture, I made the management features more discoverable. "Install Door" feature is placed under "Manage Doors" with a CTA button where all of the doors were listed.

The "Door Details" were also became accessible through "Manage Doors" which is a common pattern to reach any detail through lists.

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.
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.

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.

After the L700 or Wallreaders are installed upon any door, the doors stay locked. Every time somebody wants to enter a place, they must use a pass(digital key) to open the door. On the other hand, other products on the market, such as the RFID cards, which many companies use at their offices, provide a feature to leave the door unlocked whenever the user wants. For example, when a guest or employee holds the RFID card longer on the electrical sensor, the door stays unlocked. So, employees or guests don't have to use the pass every time they want to enter the kitchen, common areas, or waiting rooms. 
‍
The Sales team got feedback from customers, and I observed during one of my site visit that co-working spaces need to leave some doors open during the day. For example, one of our customers put a holder upon the doorway. So, the door is left ajar, and the receptionist doesn't have to open the door when a guest or postman arrives. They found a solution by themselves, but providing a lasting solution is vital for them!

The user's goal was to leave some of the entrances (main entrance, kitchen, etc.) ajar at any time they wish; the business goal was to fulfill the customer needs.

As I mentioned in the Pain Points section, our target group(many companies) is already using RFID cards. So, it's nice to mimic that interaction (holding the RFID card few seconds above the sensor). We had to figure out how to do it and include interdisciplinary teams to figure out technical barriers not to lose time.
‍
On the other hand, we already had an 'Open Door' CTA on each pass that triggers to unlock the door only for a few seconds. We must be sure that it's clear for the user 'Open Door in Office Mode' leaves the door unlocked during the defined period. It's risky if they don't understand the difference and leave the door open unintentionally. The devices' communication is also only from the phone to the sensor; we couldn't provide feedback to the user if the door left unlocked.

We started to map the feature called "Office Mode" with the whole team to understand the big picture. In the meantime, the group already started to ask questions. I began to write them down.
Why are we adding this feature right now?
What is the goal of this feature?
How could we not fail, there are many technical and time limitations?

We also determined some technical barriers with the feedback from the development teams (noted as Dev Teams) and expected interaction from the customer's perspective while we were mapping. Everyone also started to write down the obstacles to the sticky notes. So, we could turn them into solutions in the "how might we?" step. Let's call the customer, "John".
‍
Can John enable the office mode feature on some of the doors and just open it? So, he doesn't have to select "open in office mode" every time he opens the kitchen.
‍
Why can't John activate office mode with Bluetooth(BLE) connection? So, we could give feedback on the phone.
Dev teams: No, because the system should display a different LightPass to define that the door should stay unlocked. The user should trigger it through the phone. Maybe we can find another solution, but we need Bluetooth(BLE) connection for two-way communication. That is quite unrealistic because it's too much effort for a user to turn the BLE on every time they want to open a door. Keeping BLE on all the time has disadvantages like consuming battery.
‍
What if John tapped in "Open in Office Mode" accidentally? It's risky to leave a door unlocked unintentionally. So, feedback is crucial!‍
If we want to provide feedback through the phone that the door will stay unlocked during the defined period, the phone's Bluetooth connection should be ON. That is again quite unrealistic because it's too much effort for a user to turn the BLE on every time they want to open a door.
We must provide "Lock the Door" for this kind of cases.
‍
What kind of feedback can we provide to the user without a BLE connection?‍
We can provide different sound feedback than the usual door opening.
‍
How would John expect to edit/display the defined Office Time of each door?
We assume that John expects to define the Office Time through Door Settings.
Dev team: It's not possible to define it without BLE connection. Two-way communication is needed. He should connect the BLE of his/her phone to display and edit each door's defined Office Time.

The interaction might be complicated for novice users due to technical barriers. How might we teach it?
‍There must be visual instructions that are discoverable or guided tours at the beginning of the installation.
We focused on the HMW situations below, while the whole team was looking for inspiration and sketching. 
‍
‍How might we make the LightPass interaction similar to RFID cards?
How might we minimize the number of taps while opening a door?
How might we toggle Office Mode over BLE?
How might we prevent accidental usage?

Since we already got tons of requests for this feature, I witnessed the pain point on one of my site visits (I explained at the beginning of this section). We already picked the target: implement a feature that lets users leave some doors unlocked for a defined period: Office Mode.

We voted the most useful "How might we?" notes and focused on these areas while looking for solutions and sketching. The two topics got the maximum votes below:
‍
‍How might we make the LightPass interaction similar to RFID cards?
How might we prevent accidental usage?
‍
It was impressive that some developers got inspired by car features or competitors. After the final decision, I draw the storyboard. So, we shared understanding among the whole team members.
‍
I was ready to develop the prototype and test it with our target group!

I created the wireframes with pen & paper before jumping into InVision. I also got final confirmation from developers. Since we had most of the UI designs, I retouched the missing ones. I built the prototype in InVision.

I tested the prototype with participants of different age and gender groups at one of our customers' offices in Berlin. The number of participants was five.