How can we give admins and managers the power to manage their users and communication channels?

We had a skeleton of a platform ready, but it lacked basic management capabilities. Our next phase in the project included implementing different types of settings to allow our manager and admin users to provision permissions in groups and for individual users.



need to be able to provision multiple accounts to effectively manage user permissions and roles, while also being able to set-up organizations to use our services.


need to be able to manage users within their own communication groups/teams to make sure their team can run smoothly, while optimizing their given workflow.


Web UX Designer (me)
Mobile UX Designer
UX Researcher
VP of Product
Director of Design
Web Developer Team

For the initial conception of the setting pages, I worked with the UX researcher to conduct user testing. I worked with the rest of the design team to iterate on mocks and discussed these mocks with the VP of Product and the engineering team.


We didn't fully understand how web app settings would connect with our mobile app or the Onyx device.

Our feature requirements included managing settings for the Onyx device through the web app. We had preliminary technical meetings with mobile, web, and hardware teams, but nothing was defined until sooner to development of those specific features. We knew it would take more effort to understand how to accomplish this from an engineering standpoint.

Discover & Define


Implementing settings into our user profile page and group details page needed to be clear and understandable. For users, settings would dictate organization-wide permissions for group communication and hardware settings. For groups, settings would dictate whose voice would take priority during group conversations, group privacy, and who has the ability to invite users to the group.

After initial whiteboard sessions and planning with the design and product team, I got to creating mock-ups. At this point, it was faster to create mock-ups than to create wireframes in Sketch, since most of the components were already built. I found myself stuck between two designs and could not make a responsible decision without user testing. Working with our user researcher, we came up with a plan to find out which version worked best.



Success Rate of Task

# of completed tasks ÷ total # of task attempts

  • Out of # of total users, how many completed the task?

  • Purpose: Track first-time user success rate to set a baseline metric that can be used to track improvement in the future, gives insight on learnability of web app.

These are the key performance indicators we chose to measure how successfully (or unsuccessfully) our participants were completing each task.

Since we had limited resources to conduct a user research, we narrowed our KPIs to what we thought were essential.


Time on Task

  • How long did users spend on one task?

  • Purpose: Can be used to measure efficiency of interface and be used as a baseline for future iterations, also can be used to diagnose usability issues.


Regression/Error Rate

# of total errors ÷ total # of task attempts

  • How many times did users click “Cancel” or had to redo a task?

  • Purpose: See where we can improve on usability in terms of helpful instruction in the UI, test clarity of UI - is there enough information on the screen to guide the user to success?


Clicks to Task Completion

# of actual clicks : # of expected clicks

  • How many clicks does it take for a user to complete a task once they’ve started?

  • Purpose: Improve usability by identifying where people are taking more clicks than expected to complete tasks/flows, and reducing number of clicks.


Frequency of Task

  • Which tasks/flows are users doing most often?

  • Purpose: Which actions are users doing most, so that we can prioritize streamlining those flows and making those most accessible.


To prepare for user testing, I created prototypes of the setting layouts for the "Users" page using Axure RP. These path for these prototypes included opening a user profile, altering device settings, and deleting a user account. While I worked on the prototypes, our user researcher worked on a user testing script to organize the sessions. This included a guideline of what to say during our session and specific task requests we would ask our participants to perform.


  • The gear icon layout would be favored because I assumed it was a universally understood icon to mean "Settings"

  • The tab label "Devices" would confuse users because it didn't explicitly say "settings

  • There would be less hesitation with the Gear icon

  • The tab layout would take less time to complete


  • Gear icon wasn't as obvious as I assumed it would be

  • The tab label "Devices" was easy to understand

  • The tab layout did take less time to complete

  • "Delete User" on the tab layout brought on the most hesitation, and participants were relieved to see a pop-up to confirm their action


The tab layout unanimously came out on top. It was faster, less erroneous, and took less clicks overall to complete. Since the device settings was supposed to communicate with the mobile app, the iteration cycles for this feature coincided with the Mobile UX Designer's process. We worked together to understand requirements each platform would have to take into consideration by sharing out work in weekly design review meetings to make sure our work aligned with the feature sets.

A slight roadblock..

Both mobile and web teams thought that "location services" toggled location services on/off for the Orion app through the phone settings (ex: on iOS, you can toggle which apps can use location services). We learned later on that "location services" does NOT denote iOS location services, but was meant to toggle location services off for the Orion mobile app, within the Orion mobile app. The Orion mobile app has a map view, so teams can keep track of each other's location. In this mobile app, users can disable location so that they do not appear on the map. A slight hiccup in our process, but led us to understand how this was so widely misunderstood - call it preliminary ad hoc user testing on vernacular - we ended up changing how we worded it and changed it to "Location of user". At the end of it all, we were able to deliver the second round of features successfully and in turn, garner more interest from our target clientele.


Users_ Settings (app & onyx_BasicUser-De
Users_ Settings (app & onyx_OrgAdmin-Def
Users_ Settings (app & onyx_infotip)
MVP_ Group Settings
MVP_ Group Settings-dropdown
MVP_ Group Settings-tooltip


Shipping the first pass of settings for the Command Center was a big step for us. We finally had a way to integrate managerial permissions into the web application to augment Onyx Smart-Walkie Talkie settings and group settings for their companies. This was essential in being able to spearhead our way into the enterprise arena. Through the Command Center, we could offer a full product that allows managers and admins to:
  • Change or edit group settings for their organization
    • Determine who has talk-priority in a group
    • Determine who "Basic" group members can talk to within a group
    • Set group members to be internal only
    • Assign "Group Leaders" to manage groups
    • Allow a group share link to be available
  • Change or edit app and device settings for users
    • Set push-to-talk modes
    • Set haptics for the Onyx Smart-Walkie Talkie
    • Toggle on/off location for the users in the mobile app

Case Studies

The Command Center

From conception to completion, we delivered our minimal viable product in under 8 months.


To give organizations a way to manage their users and groups, we created "Setting" views to help provision permissions.

Subscription Models