Designing the OTIS Controller Interface App for Field Mechanics

Key Challenges: Human vs Machine in the OTIS Controller Interface App

1. Communication Breakdown

Mechanics must clearly convey intent to the machine under pressure. Lack of immediate, clear feedback leads to frustration and errors.

2. Connectivity Issues

Frequent Bluetooth/Wi-Fi dropouts break trust in the app. The older corded tool feels more reliable in critical moments.

3. Overwhelming Complexity

Navigating 500+ features is mentally taxing. Mechanics use different methods—menu drilling vs. code memorization—both must be supported.

4. Emotional Attachment to Old Tools

Years of familiarity with the SVT make switching difficult. Mechanics find it faster and more dependable due to tactile feedback and habit.

5. Phone Use Conflicts

Using the app while on a call often causes disconnection. The app needs to support multitasking in real-world field conditions.

6. Access & Permissions

Inconsistent feature access due to backend or role-based issues erodes trust. Users default to manual workarounds.

7. Poor Visual Usability

Small fonts, dense menus, and unclear icons make field usage hard—especially in low light or for older users.

8. Lack of Training

Many users receive no onboarding. Poor first-time experiences often lead to permanent rejection of the app.

9. Context Blindness

The UI doesn’t adapt to the situation—like specific faults, locations, or elevator groups—making problem-solving slower and more manual.

Design Methodology

The Controller Interface App is a client project that allowed me to plan and oversee every step of the design thinking process as a UX strategic designer with mobile experience. To start the project, I initially conducted generative research to gain an understanding of my potential users and the complexity of their needs, motivations, and behaviors. This research was instrumental in defining the problem for the CIA app and provided insights to guide the ideation phase.
Throughout the development process, I followed the lean feedback loop (build, measure, learn), making design improvements and enhancing the usability of my prototype. I achieved this through moderated usability tests, A/B tests, and preference testing. Finally, I delivered the finished product with its three core features.

Design Methodologies

When starting a new project, I initiate my process with design thinking and the collection of generative research data, which involves empathy and gaining a deeper understanding of user needs and desires. Subsequently, I incorporate both systems thinking and design thinking methodologies in the evaluation, definition, and development phases of the product. I begin by considering the broader picture and the specific interactions later on. I examine the core components within the product, their interconnections, and the overarching purpose they collectively serve. I question whether these elements effectively address my persona's problems. By comprehending the interrelated nature of the entire system, I can design for the user's journey and behavior within the entire ecosystem more effectively.

Discover

Surveys and Interviews

To kickstart the project, I initiated my research by crafting questions to pose to potential users experienced with the existing application. My target age demographic is 30–60, as these age groups are more likely to provide expert insights, while older individuals might be less inclined to embrace the technology and virtual call aspect. I maintained an open-minded approach, listening to and learning from my customers to gain a comprehensive understanding of their complex needs.

OCSS Controller Redesign - Investigation Detailed Report - Click Here

USER 1 : Field Support Expert (20 years)

While using the Service mobile app, user says it works pretty well...when the phone does connect (citing some dongle connection issues). User mentions that it can be quite disturbing to receive phone calls or text mes- sages while trying to use the app and that Otis should block/ignore these mobile functions while connected to a controller. To clarify, user’s suggestion would be to allow outgoing calls but not incoming calls. Regarding the corded SVT tool, they find it to be more familiar than the Service app because it was in their hands for so many years. User didn’t comment if one seemed easier to use than the other but would choose the corded tool over the phone specifically due to the reliability of the connection; “...you plug it in, it works instantly”. User also mentioned that they are less worried about having 10% battery left on the phone, when they have the service tool as backup plan. Another point that the user made is that there are 2 different groups of mechanics when it comes to navigat- ing the corded tool or Service app. One group will drill-down, traditionally, into the menus to get to what they need. While, there are a larger chunk of users who memorize (and input) the numbers which will get them directly there. User says the latter can be problematic because those users do not have a broader understand- ing of how those screens/features are categorized on a higher level

USER 2 : Regional Field Adjuster/Engineer (3 years)

User states that mechanics simply need wi-fi to function properly. When they try to use the phone, they often get disconnected. And when they can’t get connected, there are always issues. It forces them to try and reconnect, while getting very frustrated in the 30 seconds to a minute it takes to get back into the app. User also cites issues when they are trying to talk on the phone while simultaneously using it to connect to equip- ment. This is a common scenario for mechanics and some of the main reasons for mechanics to choose the “brick” over the mobile app. User says there can be a great deal of frustration around the idea that Otis has invested $5 million in a particu- lar app but nobody is using it. To help solve the communication problems they suggest that the number one way to get mechanics using these apps is to get the top Adjuster in each office onboard with it first. This way, everybody in the field will come to those “top guys” before calling ROLE. Normally, the Adjusters are more than willing to do this work because they love what they do (and it will actually make their jobs easier).

USER 3 : Regional Field Engineer (undisclosed tenure)

User prefers to use the corded SVT device because when they are on-site, they have adjuster level access which makes it easier to use than the Service app. [UX Note: User cites that permission issues have blocked them from several Otis apps on occasion, including Service app]. User mainly uses Service app when working with a maintenance person, as they found it important that they were learning/using the app vs. the corded tool on a daily basis. User, personally, feels that the SVT is also easier to use than the app/dongle due to convenience and speed factors; as well as the occasional need to be on the phone at the same time. [UX Note: User does comment that this is a feature which may have been fixed since they last used it]. Regarding both the Service App and SVT, the user finds the interface and navigation very comfortable, as they been using it for 17 years. User is hoping that we will retain the ability to switch over to the original service tool within the new app. The top, most frequently used, features which user would like to gain quicker access to are: Fault Log/Report, Motion and Drive Faults, RSL Health and i/o Check. User would love to have a ‘control screen’ feature where they can connect to another mechanic’s phone (via Service App) and have the ability to directly change settings and/or run commands to an elevator from a remote location.

The closer you stay to the blue tool and how it functions, as far as the menus go, the better off you're going to be. 
The more receptive the mechanics are going to be to it”œ

Design Observations

When video demonstrations of the currently developed CIA and top-level navigation became available, some users were shown the work and were asked to respond to it. Video Demos

• Liked the current navigation from home screen on videos.

• Liked how parameters can be applied to multiple floors at once in the Hoistway Configuration.

• Liked the advanced search feature due to it’s ability to filter results and asked for the ability to directly input a legacy feature codes to display immediate result.

• Further sub-categorize OCSS Features (as there are 500+ features).

• Worried that mechanics may not understand what the names of various OCSS features mean (he cited ‘Activity Scheduling’ and ‘AC Building Power Monitor’ as examples).

• For i/o screen, add whole names, as they currently need to look up acronyms in a paper manual (6,000+).

• For i/o screen, have descriptions expand in place as opposed to pop-up.

• Include graphic representation of the doors on top of Car Monitor screen.

• An RFE stressed the importance of sharing the video demos with actual field mechanics for feedback.

ADA Compliance - Detailed report - Click here

Affinity Map

With the results of my survey and interview research analysis, I synthesized the data collected through the creation of an affinity map. This process is a great method to help me make sense of all my information when I have a lot of mixed data. After synthesizing the data, I built user personas, user journey’s, and user flows showcasing the data grouped based on identified themes, and a list of insights supported by relevant examples and presented in a logical, visually engaging way.

Key takeways

“If Otis wants us to use these apps, they must work as expected...every time”

We must resolve connection issues, connectivity & speed of app, so mechanics will prefer to use mobile applications.

• Implement accessibility standards into UI design elements.

• Increase font size and overall contrast to help solve readability issues. Possibly provide larger display devices to utilize a larger display with more relevant data.

• Maintain corded-tool expertise within the new app, as part of the advanced search, so mechanics can search directly by code/module numbers.

• Search engines need to work properly. Display matches first; use appropriate keyword matching in code. Results should not display unexpected/unrelated numbers or words.

• Need to fix the timing of pushing notifications for the Search function (0 Results issue).

• Add user manuals and/or inline training through the app’s help menu. This will help the user understand how to use the app and important features in it.

• Plan training sessions for apps when launched. These sessions should include mechanics, in addition to supervisors (don’t just include the super users).

• App updates or What’s New information should be pushed to the user’s notifications and app itself.

• Stop ‘roadblocking’ users with authentication and password prompts. User’s device is secure to that user.

• Once a fingerprint or face scan access’s the device, that user should not need to provide additional log-in credentials.

• A lack of complete features when an app is released (MVP) makes users think the apps are broken or incomplete in some way; once a user abandons an app they tend to not try them again (first impressions are very important).

• Add graphic/animated representations of various equipment statuses/monitoring.

• Be careful with the overuse of iconography. In many cases the theme or idea may be too complex to visualize in such a small graphic and may cause confusion. These scenarios may require the use of text to support them.

• Spell out acronyms using plain English but maintain the original acronym beside it (for legacy users).

• Add a tracker to keep historical logs for various settings and changes made to equipment. A component to add notes and/or photos would also be helpful.

• We must resolve connection issues,connectivity & speed of app,so mechanics will prefer to use mobile applications.

• Our machine learning needed good resolution images to be able to compare facial images and flag fraudulent documents

• Usability sessions continually showed that taking photos with a webcam was cumbersome and frustrating

• Apple’s Safari browser did not actually support webcam use (only recently did Safari allow webcam support)

• Users need to operate the Controler Interface app to provide tailored research for their specific mechanics needs because they are busy and often struggle with using the applications to their corresponding components to update changes to the controller.

Potential Solutions

Develop a competitive industry-specific expert market place with a controller interface app, that delivers solutions to mechanics problems and eliminates the time it takes to find the correct widget. The goal of this app is to give people a simple, intuitive way to perform actions where the elevator has an issue in nearly any field quickly by utilising an informed interface so they can stay on top of all the details pertaining to elevators.

User Personas

Based on the generative user research I gathered, I created three user personas that capture the essence of my target users. Meet Peter James, Roland,Nicole and Jon kelly!.

User Journey’s

By creating persona journey maps, I wanted to illustrate the process of how Nya, Alex, and Kate behave, feel and what they think while accomplishing their goals to detect pain points or moments of delight.

User flow’s

I built user-focused flows to ensure that my personas can successfully complete their key objectives while reducing the existing pain points.

Card Sort

I conducted a closed card sorting user test using OptimalSort to help design and evaluate the information architecture of my app Controller Interface . In my card sorting session, the participants organized cards/content topics into already determined categories that made sense to them. I had 20 participants take my card sorting test and listed below is what I took away for analyzing the results of the test. These results were taken into consideration when building the second version of my sitemap. The popular placement matrix helps me understand what cards were placed in which categories that made sense to the 20 participants the most. When viewing the popular placement matrix, it’s easy to see how the results can help inform my decisions for my sitemap.

IA Sitemap

I created two different versions of my sitemap; the V1 Sitemap provides more details of the user journey, whereas the V2 Sitemap offers a higher level flow of the user journey. While building the sitemaps, I took into consideration all the research I have gathered thus far, the user personas, journeys and flows, card sort test, ZocDoc content audit, and usability heuristic evaluation. This process helped with informing the structure of my information architecture and how my primary features should be mapped out.

High-Fidelity Wires

I designed a mid-fidelity prototype for Controller interface App features and have taken my user personas through the feature build. For these feature flows, the persona has already launched the app and is engaging with the core product.

Event Log Features

Event Logs Proto Type - Click Here

Usability Test Plan and Results

The purpose of my usability test was to assess the learnability for new users interacting with the Control Interface application for the first time on a mobile iOS device. I observed and measured the success rate of 6 participants completing 2 task attempts each. I documented whether the participants understood my product, the value of my three core features, and how to achieve essential functions.

Usability Test Plan & Results

Objective

To evaluate the learnability, usability, and effectiveness of the Controller Interface App when used by field mechanics in real-world scenarios.

Test Goals

• Understand how easily new users can connect and interact with the controller.

• Measure task success rate, time taken, and error frequency.

• Gather feedback on overall user satisfaction, pain points, and preferences.

Participants

• 6 total participants

  • 3 in-person

  • 3 remote (via Google Hangouts)

  
  

• Roles: Field Mechanics & Adjusters (experience: 3–20 years)

• Devices: iOS Mobile Devices with Dongle

Tasks Tested

1. Connect to a controller via dongle.

2. Search and configure a parameter using advanced search.

3. View and interpret real-time I/O data.

4. Locate fault log and report an error.

5. Test offline vs. online controller connection preferences (A/B test).

Test Methodology

• Moderated usability testing

• Each participant attempted 2 core tasks

• Recorded:

  • Task success/failure

  • Completion time

  • Verbal feedback

  • Observed behavior

A/B Test Focus

“Connect First” vs. “Explore First” Flows

• Group A: Connect to controller at app start

• Group B: Explore app before controller connection

  Result: Most preferred exploring first, then connecting—less pressure and more confidence.

  
  

Key Findings

Qualitative Feedback

• “Loved the advanced search, but I wish I could search by the legacy code I already know.”

• “If it disconnects mid-task, I start over. That’s really frustrating.”

• “I want a simplified view like the SVT tool—I don’t need to see everything all the time.”

Usability Issues Identified

• Inconsistent Bluetooth connection disrupted tasks.

• Lack of onboarding made the advanced features hard to discover.

• Acronyms and technical labels were unclear without hover help or full-text.

• Navigation felt slow for users accustomed to shortcut entry.

Improvements Made

• Added inline help and tooltip explanations.

• Updated UI with larger fonts and simplified menu hierarchy.

• Designed a hybrid start flow: minimal explore mode before connection.

• Enhanced offline mode stability and recovery behavior.

• Simplified parameter filtering and added favorites/bookmarking.

Post-Test Actions

• Synthesized insights into an affinity map and rainbow spreadsheet.

• Iterated on high-fidelity prototype with prioritized fixes.

• Prepared for additional round of tests with refined flows and broader user roles.

Let me know if you want this formatted as a slide deck or visual report (e.g., charts, screenshots, rainbow spreadsheet summaries).

Design Documentation

My UI Style Guide is a design and development tool that brings cohesion to my digital product’s user interface and experience. All brand and UX components including usage documentation will be managed in a single sketch file. This file has been built based on OTIS Design principles, an effective interface design system which is not a linear process, but rather a mental model to help my team members think of our user interfaces as both a cohesive whole and a collection of parts at the same time.

I have created the attached documents for this project

Click here for UX Strategy

Click here for User Discovery

Click here for Style Guide

Click for Design System