LightAccess Pro

My Role: Product Designer (UI, UX and Service Design)
About the Product
The LightAccess Pro(mobile app) lets our customers open any door with any phone in a highly secure way through a digital key: LightPass. It works together with L700 or Wallreader(electrical device) mounted on the wall/door.

So, guests or employees can access any entry with a smartphone for a restricted time.

Any co-living or co-working spaces manager can share a digital key (called pass) 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.
Overview
Product: Mobile app , L700 Door Handle, and Wallreader
Company: 1aim GmbH, FSB GmbH (Franz Schneider Brakel)
DAC (Digital Access Control) GmbH acquired 1aim GmbH in May 2019. DAC GmbH was the daughter company of FSB GmbH (Franz Schneider Brakel).
Date: Aug 2018 — Jun 2020
Duration: 2 years in parallel with LightCommand
My contributions
Aug 2018 — Jun 2020
As an only UX designer, I played a vital role in achieving business goals while keeping eye on the user's goals. I brought the Human-centered design approach, facilitated Design Sprints, applied Design Thinking methodologies, supported UI designers to build up a design system. I collaborated with different development teams like back-end, embedded, mobile, and front-end developers during the design process.

Let's start!

down by Brandy Bora, Search User Created by Ben Davis, Search Created by sahla hamidah,pop up by DailyPM, Wireframe by Alfredo @ IconsAlfredo.com, Manual Testing Created by SBTS, Flow Chart Created by Ramakrishna Venkatesan, Writing by Design Circle, Palette Created by David,  from the Noun Project
persona by Valerie Lamm, Success Created by Econceptive, Fast Created by Fuse Studio, Communication Created by Oksana Latysheva, Lamp light by verry obito, from the Noun Project

Data Gathering & Defining The Goals

Starting Point
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.
Assumption Personas
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).

User Needs vs. Business Goals

Prioritization
We prioritized the user needs by considering business goals with the key team members and stakeholders.
Pain Points
  1. Most of the customers need instruction to open a door with a LightPass.
  2. Some of the customers find door installation process confusing.
  3. Some of the customers doesn't know or couldn't discover some of the main features of the app.
  4. Most of the customers find pass sharing feature complicated and are not sure if they could successfully shared a pass.
  5. Co-working or co-living spaces needs to leave some doors open during the day such as waiting rooms or main entrances that directs people into information desk.

Goal #1

Make the door opening feature intuitive and quick

Pain Points
Most of the customers need instruction to open a door with a LightPass.
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 attract more customers with the "easy open" function.
Challenge
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

Activities
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.
Task 1.
The product installed to the door, it 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?

How a participant performed "Open a door" task:

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 sketches and wireframes

Idea 1
Task Analysis
  • Tap on the "Open" button on the pass (The system finds the correct key in the background with GPS and BLE technology)
  • Use LightPass in front of the device
  • Use LightPass in front of the device
Idea 2
Task Analysis
  • Swipe right-left within last used 8 passes
  • Find the pass which belongs to the door you want to open
  • Tap on the "Open" button on the pass
  • Use LightPass in front of the device
  • Use LightPass in front of the device
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 UIs: "Open Door" screens

Final UIs were designed in collaboration with external UI designers.
Before
Task analysis
  • Scroll and display the passes
  • Find the pass which belongs to the door you want to open
  • Tap on the "Open" button on the pass
  • Use LightPass in front of the device
  • Open door
After
Task analysis
  • Scroll and display the passes
    I displayed as many passes as possible at a glance (less scroll)
  • Find the pass which belongs to the door you want to open
    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 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.

Visual Instructions

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.






The photos were taken by FSB Marketing Team.
Validate
Usability Testing
For the "Open Door" feature, the success rate increased from 30% (legacy app) to 100%.
Validate
Usability Testing
"It's clear which key opens which door."
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

Make door installation intuitive

Photo by Theme Photos on Unsplash

Pain Points
Some of the customers find door installation process confusing. They have to repeat some parts of the installation process if any technical error occurs.
User & Business Goals
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.
Challenge
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.

User Story Mapping for "Install a Door" feature

Clarify the user activities
User Story Mapping
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.

Workflow (Before) & Task Diagram (After) for "Install a Door" feature

Before
After
Improved user flow
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.

Final Work Flow

Door Installation Wizard
Prevent error
Guide the user
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).

Wireframes → Final UIs : "Manage Door, Door Detail" screens

Door Installation Wizard
Discoverable features

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.
Door Installation Wizard
Prevent error
Gather information in the background
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.

Wireframes : "Door Installation" screens

Final UIs : "Door Installation" screens

UIs were designed in collaboration with external UI designers.
Door Installation Wizard
Prevent error
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.

Final UIs: "Install a Door" screens

UI Design Components

Goal #3

Increase the discoverability of features by improving the information architecture and navigation.

Photo by NordWood Themes on Unsplash.
Pain Points
Some of the customers doesn't know or couldn't discover some of the main features of the app.
User & Business Goals
The user's goal was to intuitively navigate throughout the app regarding their needs, such as managing door settings, switching between accounts, or sharing a pass; the business goal was to reduce customer frustration moreover adding the value of the user-friendliness to the products in sales and marketing.
Challenge
According to customer feedback stakeholders received, users have difficulties in discovering:
 
- Sharing a pass (digital key) with someone else
- From which page to install a new door
- Logging out from other logged-in devices 

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

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:
Tasks 1
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?
Tasks 2
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?
Tasks 3
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.
Participant
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 expert reviews based on Nielsen's Heuristics Evaluations. The outcomes were like below:
Pros
  • Consistent error/success feedbacks 
  • Clean color scheme 
  • Consistent language
Cons
  • Poor navigation and information architecture
  • Inconsistent interaction patterns 
  • Hidden features
  • Unfamiliar terms
  • Poor design system 

Improve the content relation and information architecture (IA)

Icons were designed by attoma Berlin.
Before
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 were designed by attoma Berlin.
After
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.
Before
  • 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.
After
  • 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.
How would users name each feature?
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

Validation
Guerilla User Testing
After implementing the solutions to the prototype, I conducted user testing for validation.
Discoverable pass creation
Reduced 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.
Before
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.
After
Prototype
  • 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.

Consistent patterns

Before
The navigation menu was a long list under the sidebar. So, the user puts effort into discovering how to install a new door, share a pass, or log out from other logged-in devices.
After
I changed the type of navigation menu from side navigation to bottom navigation. In that way, the essential categories are discoverable in the bottom navigation, and crucial features are highlighted under the relevant category.
Before
  • To delete a door, the user taps on the settings icon on the toolbar and opens the sidebar menu, taps on the "Manage Doors" menu item, displays the door list, taps on a door and reveals the door detail page, taps on the delete icon on the toolbar.
  • To delete a pass, the user taps on a pass on the homepage, displays the pass detail page, and a list of the child passes, taps on remove button on a child pass. 
  • To install a door, the user taps on the settings icon on the toolbar and opens the sidebar menu, taps on the "Add Door" menu item, and starts the installation wizard.
  • To create a pass (digital key), the user taps on a main pass on the homepage, displays the pass detail page, taps on the "+" floating action button, and opens a one-page input form.
After
  • To delete a door, the user taps on the "More" icon on the bottom navigation and opens the menu, taps on the "Manage Doors" menu item, displays the door list, taps on a door and reveals the door detail page, taps on the delete icon on the toolbar.
  • To delete a pass, the user taps on the "Manage Passes" icon on the bottom navigation and displays the pass list, taps on a pass, and reveals the pass detail page, taps on the delete icon on the toolbar.
  • To install a door, the user taps on the "More" icon on the bottom navigation and opens the menu, taps on the "Manage Doors" menu item, displays the door list, taps on the "Install Door" floating action button, and starts the installation wizard.
  • To create a pass (digital key), the user taps on the "Manage Passes" icon on the bottom navigation and displays the pass list, taps on the "Create Pass" floating action button, and starts the pass creation wizard.

Before, Wireframes, Final UIs: "Manage Doors" screens

What changed?
I created a consistent pattern library for management features: to manage doors, accounts and the passes.

Both "Manage Passes" and  "Manage Door" pages has consistent patterns.

The user starts door installation wizard through "Install Door" floating action button on the "Manage Doors" page.

Final UIs: "Manage Doors" screens

UIs were designed in collaboration with external UI designers.
Implementation
We defined technical requirements for managing a door in collaboration with the Embedded development team. The user had to connect his/her phone to Bluetooth to be able to display the Door Settings and the Firmware version. In that way, the phone could communicate to the device mounted on the wall/door, and show the updated information. So, I added the screens for Bluetooth connection for guiding the user before managing these features.

Before, Wireframes, Final UIs: "Manage Passes" screens

What changed?
Both "Manage Passes" and  "Manage Door" pages has consistent patterns.

The user starts pass sharing wizard through "Create Pass" floating action button on the "Manage Passes" page.
App Features (Before/After)
Features were improved based on new information architecture.
  • Open Door & Share a Pass
  • Manage Doors 
  • Install a Door
  • Manage Accounts
  • Manage Passes
  • Open Door
  • Manage Doors & Install a Door (improved)
  • Manage Place & Account (new)
  • Manage Passes & Share a Pass (improved)
  • Manage People (new)
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

Increase ease of use of the "Share a Pass" feature and reduce errors .

Photo by NordWood Themes on Unsplash.
Pain Point
Most of the customers find pass sharing feature complicated and are not sure if they could successfully shared a pass.
User & Business Goals
Co-living or co-working spaces can share and manage access to any door through the website or app. So, guests or employees can access any door with a smartphone for a restricted time period. The user's goal was to intuitively share access throughout the app to a door for a restricted time period; the business goal was to reduce customer frustration moreover adding the value of the user-friendliness of the products in sales and marketing.
Challenge
As I mentioned above, an owner of a house can share access to his/her home, or an office manager can share access to the employees through the mobile app or desktop website. It has many steps, includes many customer inputs, and complicated time restrictions. We collaborated closely with back-end and app teams. The legacy app had many unfamiliar terms, inconsistent interaction patterns, and visual design.

Task Diagram for "Share a pass" feature

User Flow: "Share a pass" screens

Wireframes: "Share a pass" screens

Final UIs: "Share a pass" screens

UIs were designed in collaboration with external UI designers.
Implementation
  • I defined technical requirements for sharing a pass in collaboration with the React Native development team.
  • I gathered the most common time restrictions in collaboration with the Sales and Management team. So, I used them as a quick access feature and a base while the user is defining the time restrictions.
  • I reduced technical terms while improving the information architecture as I mentioned on the section below:Improve the Information Architecture (IA)

Goal #5

Conduct a Design Sprint to discover design solutions for the "Open in Office Mode" feature.

Photo by NordWood Themes on Unsplash.
Pain Point
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!
User & Business Goals
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.
Challenge
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.

Conduct a Design Sprint

Original Design Sprint
The original Design Sprint takes 5 days and the whole group is included for three days.
Design Sprint version 2.0
As many designers tailer the Design Sprint regarding their needs, we also used Design Sprint version 2. Because we had time limitations to include the whole group for three days, and we had to focus only on the "Office Mode" feature.
Photo by NordWood Themes on Unsplash.
Monday
Map & Sketch
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?
Photo by NordWood Themes on Unsplash.
Monday
Map & Sketch
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?

Photo by NordWood Themes on Unsplash.
Tuesday
Decide & Storyboard
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!
Photo by NordWood Themes on Unsplash.
Wednesday
Prototype
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.
Thursday
Test!
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.
Task 1.
You work at DAC Gmbh. Your company uses L700 (show the product) at the building. The mobile app 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 you would open "Meeting Room" via the app?
Task 2.
As you just experienced, you used the pass and entered a place. When the door was closed after you, it is locked again. So, another person who wants to enter here must use a pass too.

Suppose there's a function in the app that can leave any place like "Smoking Room" unlocked. So, after you used the pass and entered, the next person doesn't have to use a pass again. Can you try to discover and use this feature in the app?
Task 3.
There's a feature in the app that lets you leave some doors unlocked after the first pass usage for a defined interval. So, the employees or guests don't have to use the pass every time they want to enter the kitchen, common areas, or waiting rooms. 

Where would you expect to set this feature for "Tea Kitchen" in the app?
Further Questions
How would you check to see if you could open the door in Office Mode or not? (It remained unlocked after you.)

Where would you expect to find some more information about this feature in the app?

Where would you expect to find the Office Mode interval of the Smoking Room?
Photo by NordWood Themes on Unsplash.
Test Results
Task 2 that is investigating the office mode feature had 100% success rate. The key findings below confirmed that we're on the right track!
Key findings
Small Iterations
Implementation
I defined the design guidelines after the small iterations and the developers implemented the feature!
Next Steps
UX research
The next steps are to conduct meCUE or SUS usability questionaries, add an in-app user satisfaction survey, and to follow customer reviews on the app stores.
NEXT Project →