DESIGNING FOR THE FIELD
Designing for the realities of integrators:
Evaluating commissioning workflows for smart security devices
Stock Image
THE PROBLEM
At Allegion I worked on a product team that developed a new app which would allow integrators to install smart security devices using an app on their phone. Once the initial prototype was designed we needed to know whether the step by step guide aligned with how professional installers actually set up smart security devices in the field.
The installation flow functioned from a system perspective, but it was unclear whether the sequence of steps, terminology and level of guidance reflected the installer's mental model and on-site realities.
The product assumed certain behaviors, like starting the process by adding a new device, understanding terms such as "claiming," and reliably connecting to wi-fi. This research effort aimed to uncover where the app's structure reflected internal system logic rather than real installation practices, so the team could close those gaps before broader deployment.
HIGH LEVEL TIMELINE
6 weeks
MAKE OF THE TEAM
I organized and conducted the user testing independantly and shared the findings with the product team.
KEY GOAL
Evaluate the app's commissioning process and see if we could validate the design's assumptions.
MY ROLE
For this project I led the research effort, choose the methodology, wrote the script, recruited a highly specific participant group, and finally shared results with stakeholders.
I decided to conduct moderated user testing because it would allow me to probe and better understand the user's context and mental framework while leaving space for new discoveries. Since there was both an expert and a novice level set up experience in the app, I looked for installers that were familiar with our devices but to varying degrees of expertise and had them work through both guided and expert setups, alternating the set up each participant reviewed first.
I needed people who the business refers to as "integrators," typically people who work at a locksmith company installing "auto operators." I worked with our sales marketing team to find this niche audience.
After conducting 12 testing sessions, I uploaded the Microsoft Teams recordings to Maze for easier coding and analysis. Once I synthesized the findings and built the deck out in PowerPoint I hosted a share-out with design, and both software and hardware product teams.
UNDERSTANDING THE USER
I needed to deeply understand who the primary users were, professional installers, integrators and locksmiths, and how their experience level, workflows and field environments shaped how they approach setting up devices.
I had already made an "Integrator Ivan" persona, which helped me understand that these users are not casual consumers, but skilled professionals who regularly configure hardware in active job-site conditions, often under pressure and with unreliable connectivity. Their expertise meant they valued efficiency, control, and clear technical context over heavy guidance, yet they still relied on structured support when encountering an unfamiliar system.
Their mental models were shaped by prior tools and industry terminology which influenced expectations around device discovery, setup order and configuration settings. Understanding this balance (highly capable users operating in imperfect environments) was critical to evaluating whether the app's workflows, language, and level of guidance respected their expertise while still supporting first-time use.
Integrator Ivan Persona
Part project manager, part solution architect, part sales representative. I'm responsible for finding an excellent solution for my customer. This job perfectly pairs my love of working with people and solving complex problems.
Environment: half in office, half on-site
Motivations: Problem solving, making the customer happy
Pain Points: High staff turnover, difficult to use software, lack of cell coverage or Wi-Fi causes issues with installation
Needs: Strong communication, more time
BREAKING DOWN THE PROCESS
I mapped and evaluated the end-to-end claiming and commissioning process to understand how each step of the workflow supported or conflicted with the way integrators expect to discover, configure and activate devices in the field.
The process included multiple interconnected stages: Discovering a device, adding or claiming it, selecting guided versus expert setup, configuring device settings and handling Wi-Fi connectivity, each of which required users to make decisions with varying levels of context.
While the system followed a logical technical sequence, installers often approached setup based on physical proximity to the device, signal detection, and prior tool conventions, which did not always match the app's entry points or terminology.
Breaking the flow into discrete steps allowed me to pinpoint where friction emerged, such as expectations around finding devices "in range" interpreting unfamiliar language, choosing setup modes and understanding configuration values without clear units or definitions. This step-by-step analysis revealed where cognitive load accumulated and where the product reflected internal system logic more than real-world installation behavior.
Screen shots from the app: On the left users choose between expert or guided set up, and on the right an example of unfamiliar terminology being used.
THESE WERE SOME KEY FINDINGS WHICH LEAD TO RECS AND DESIGN CHANGES
The app's workflow did not match integrator's natural setup sequence
Participants expected to begin commissioning by detecting nearby devices through an "in range" view, assuming powered devices would broadcast and be discovered automatically. Instead, the system required them to manually add a device first.
Industry-misaligned terminology reduced clarity and confidence
Participants were unfamiliar with the term "claiming" in the context of locks and commissioning, instead preferring more common language like add, connect, or set up. While they could infer the meaning, the unfamiliar terminology introduced hesitation.
Configuration decisions lacked enough context for confident action
When reviewing device settings, some participants struggled to interpret values without units or definitions, and expected certain settings to appear in a more logical order. Also, participants wanted to know the benefit of connecting to Wi-Fi.
Prior to this research effort I created the Integrator Ivan Persona which helped influenced how I crafted and directed the user testing protocol.
LESSONS LEARNED
Designing for experts means designing for context,
not just usability.
One of the biggest takeaways from this research was that "easy to use" is not the same as "aligned with real work." While participants found the flows generally intuitive, friction emerged when the app's structure reflected internal system logic rather than how installers actually operate in the field.
Supporting experts is less about simplifying the interface and more about providing the right information at the right moment, reducing cognitive effort without reducing capability.