ButterflyMX
Client: ButterflyMX (Project for Designlab)
Sector: Video call box for building access
My Role: UX Research, UX Strategy, UI Design
Project Time: 4 Weeks
Founded in 2014, ButterflyMX is on a mission to enable people to open and manage doors from a smartphone. ButterflyMX’s products are installed in more than 5,000 multi-family, gated community, and student-housing properties around the world.
The system works well for residential buildings, but Butterfly also markets itself as a solution for commercial buildings. Solutions that work for residential buildings don't mesh as well with businesses, their guests, and property management companies overseeing them.
Adding a commercial feature for both the call box screen itself as well as the internal CMS application will provide a unique advantage for ButterflyMX to remain more competitive as an industry disruptor beyond the residential property market.
Project Goals
Examine and define the current pain points in using the ButterflyMX system in a commercial setting
Ideate and prioritize solutions to maximize the success of a commercial version of the platform
Design and integrate solutions into the current ButterflyMX design system
This project provided me a unique opportunity to explore enterprise design. Unlike designing for consumers, I didn’t have much need to strategize how to drive users directly towards a singular call-to-action.
The users of this product are already using it and in most cases have no choice but to use it. It allowed me to focus on more specific high-level problems and explore wider solutions. By hearing user needs and increasing their joy, it would increase the business success of the application, overall.
Observe the existing to ideate for the possible
Having used the product both personally and professionally I was able to come into this project with a base of knowledge. In order to check my own assumptions, I created three different categories of users that were interacting with different parts of the system:
Building Administrators (operations managers, property managers, Administrators, Security personnel, etc.)
Business Users (the commercial building tenants- CEOs, administrative personnel, personal assistants, HR reps, etc)
Guests ( personal visitors, business partners, delivery men, prospective clients, prospective employees, etc)
I then established the following research questions:
How do most business users utilize the ButterflyMX?
How do property managers utilize the ButterflyMX?
How do outside users interact with the box?
Answering questions
Competitor Analysis
Rather than looking at what competitors exist or what design aesthetic they use, I was far more interested in how they are solving the problems of commercial building entrance management. I examined what features those companies use.
Behavioral Analysis
I was able to analyze a year’s worth of data from three different commercial buildings for user behavior patterns, pain points, and commonalities.
Ethnographic Study
Due to my position, I’ve been able to observe users from all three groups interacting with the current ButterflyMX system for over a year. This allowed me to both actively and passively note user behavior, explore user workarounds, and corroborate the behavior data with qualitative observations.
Gorilla Interviews
I choose to do some shorter on the spot interviews with users who were actively or had just been interacting with the system. This allowed me to not only observe their behavior but ask about it in a way that didn’t have them trying to guess what I might be looking for.
Research Conclusions
A personalized touch is important
Both the data and user interviews corroborated that Business User onboarding currently feels impersonal. The current system has new users automatically receiving an email from ButterflyMX when they are registered in the system. In most cases, this was an unexpected source and was thus ignored, went to spam, or wasn’t even received. Admin’s often had to send additional emails to alter the Business Users of the original email. This leads to frustration by both the Business Users and the Admins.
Virtual Keys are confusing
Despite overall growth of use over time, virtual key use remains consistently low. Only advanced Business users felt comfortable utilizing them and their guests consistently needed a practical tutorial to use them to enter the building. Unless they were for the purpose of recurring entry, they prove to be ineffective as a tool for seamless one time guest entry.
Time is precious
All users found it frustrating when the system costs them any of their time. If the interface can’t immediately solve their problem, building access; it becomes a burden. Admin’s lose time setting up and deleting Business Users, Business Users lose time trying to register or have themselves listed the way they choose, and guests lose time trying to figure out the correct way to ask for access into the building.
Continued use is an advantage
The foundational system of Butterfly is well thought out, discoverable, and memorable. Users who interact with it and build a mental model are able to quickly scale up from beginning to advanced users. This is an advantage for enterprise software since users are likely to interact with it almost every day.
Defining the project scale
Research led me to identify a number of potential problems to sink my teeth into. Many unrelated to my initial inspiration of adding a commercial feature. I made a list of features based on my research and then prioritized by which users would be most affected. I then created a feature matrix to decide what I wanted to tackle for the confines of this project.
I decided to focus on:
Creating the ability to add companies inside the Admin dashboard
Creating a more robust Limited Admin dashboard that would allow Business Users to manage their own employees
Integrating the commercial side into the callbox directory itself.
Always going back to the users
Because I have a lot of experience using the system as a user, I worried I was bringing too much of my own bias into the feature design. To hold myself accountable I created three jobs-to-be-done personas. Each has a user journey that maps the existing ways each user interacts with the system and illuminates the different pain points.
From there I iterated task flows for the three major flows I wanted to be able to test.
Testing early
Unlike my previous projects, it made far more sense to run usability tests earlier in this process. The ButterflyMX system itself already works and its design aesthetic wasn’t relevant to the testing. I created the wireframes for my three different interfaces: the full admin, limited admin, and the call box.
I created prototypes of each and basic set of tasks:
Full Admin: adding a company, adding an employee to that company, adding an employee to another company
Limited Admin: Exploring the dashboard and adding a new employee
Call box: Calling a company and calling an employee within a company
I then ran 8 usability tests and 10 a/b tests with various users. I ran 4 usability tests on both the Full Admin and Limited Admin dashboards. For the Full admin I was able to test one advanced user along with three first time users. For the Limited dashboard I choose to test first time users, since most Business Users would be interacting with the system for the first time once they were onboarded.
For the callbox interface itself I chose to run usability tests that focused more on a/b testing with 5 participants trying out each version of the company directory.
Usability Test Conclusions
The mental model is essential
The first-time users who struggled the most didn’t have a full mental model of how a portion of the interface played into the larger system. So they couldn’t always understand what their actions were affecting and therefore which actions were correct.
Information Architecture
Consistency of terminology across the app is an important decision. It will help orient the users. Deciding about the current use of the word “tenant” in regards to how it relates to “employees” will help with clarity. Also, whether users- receive registration, invitations, or activations.
The modal screen needs clarification
This was the area that tripped up all three new users, partially due to their lack of knowledge of the full system. Delineating what those three actions are along with the status of the system at that moment will help.
Skewed results for the A/B testing
I discovered partway through that overall I had phrased the question incorrectly. By asking them to look for a person as a part of the company, all the users initially wanted to use the directory rather than the companies list- which was the point of the test. That said, all completed it.
Priority revisions
Based on the feedback I got I came up with a list of revisions and prioritized them by asking myself
What is the impact of the problem?
How many users were affected by the problem?
Will users be bothered by the problem repeatedly?
The biggest question after testing was dealing with the modal screen. It was the thing that tripped up half of the first-time users. It also presented an interesting larger strategy question. While it tripped up some first time users, even during they test they understood it after completing multiple tasks.
I decided in this case, the benefits outweigh the initial confusion. I choose to keep the modal functionality and look to fix the problem of helping users understand it.
This lead to a list of five essential action items and a sixth to tackle if I had time:
Nail down terminology across the platform
Clarify system status
Clarify the actions in the modal screen
Update data visualization for Limited Admin portal
Add hover hint icons to limited admin portal
Potentially: Add a low impact onboarding flow to the limited admin portal
Integrating the feature
With my revisions in mind, I created a high-fidelity UI. Since the Butterfly UI already exists I kept my focus on iterating the process of the feature based on the user feedback.
I moved the modal earlier into the flow, rather than as the final task, which had been causing confusion
I clarified the terminology across the platform: swapping tenants for clients on the admin side and keeping registration as the main action word
I brought the system status out into the open: giving the user feedback to know when a company or client was officially created
Onboarding
Finally, I prototyped out a basic onboarding flow for the Limited Admin portal. ButterflyMX provides training as a part of their full admin rollout, so I felt that was already well handled. Adding a Limited admin feature means a huge increase in people who might need training. An in-application onboarding overview felt like the most practical solution.
Stopping at the edge of the real world
I enjoyed being able to tackle adding this feature for a product I have interacted with on a number of levels. Having spent so much time using it and watching others use it gave me much deeper insights into the different user needs and insights possible. It was also a nice challenge to leverage as many existing design components, processes, and terminology as I could to create a seamless integration.
Moving ahead I would look to tackle the following:
Usability testing of the onboarding flow
Ideation and testing of guest access pins