My tenure at HYPR is a growth trajectory from design leadership to thought leadership.

Purpose

The purpose of this software is to allow the mobile app and the computer to create a bonded relationship, once the computer is paired with the mobile application, from that point on, user can unlock their computer from their mobile device by utilizing any type of authentication method they use to unlock their smartphone.

Functionality

We made sure to make this nifty little software as simple as possible, but it does have vital and very important functionality, not only pairing the computer with user’s smartphone or multiple smartphones and security keys, such as Yubikey or alike but also allows the user to manage these devices, add, remove, change some details, etc.

2016-2018 Objective

Role: Researcher, Designer, Tester, Engineering Guide

The original objective of this product that bared the first name of Command Center, was to be duplicated for each customer, branded to their branding, at minimum the logo, and allow them to manage the deployment of their mobile applications with our SDK embedded into them.

The first product that we designed and built was based almost entirely on assumptions of how the companies would want to manage our technology without running command lines on their server sides.

However, launching the first few versions of the v1.0 allowed us to really start learning how our administrative users might need to use such a product since there was nothing like our technology on the market, it was hard to learn from existing pain points with similar products.

Research

We began our research by identifying who are the target users of this product, and to do so we have interviewed about a dozen of IT professionals about their daily life, what kind of mission-critical systems do they use, what are the likes and dislikes they can share with us about the products they use daily for work.

alongside we collected such data as the dominant gender and age groups in the IT industry, to my surprise back in 2017 it was a heavily Male-dominated industry within the age groups of 30-50, as we gathered this information and identified our key persona, we started working on the product and outlining key functionality that Jackson (our persona) would need in his daily work routine.

As we built our second iteration of the product closer to the end of 2017, at this point we were able to better identify what are the core functions that our customers need and how the admins might be using the product, and for what purpose.

We kept interviewing IT professionals to keep learning, as we released our first functional v2.0 of Command Center we ran another in-depth interviews session with the following professionals:

• Network Administrator

• Application Architect

• Authentication Engineer

• Authentication Architect

• Software Security Architect

• IAM Architect

• IAM Engineer

• Application Developer

• Application Architect

• Director of Infrastructure

• Enterprise Security Architect

• Identity Architect

• Software Engineer

• Information Security Specialist

The goal of the research was to learn the needs of these professionals from such software as ours, what is critical functionality, what is a must to have and what is nice to have, and understand on a detailed level how they function and how our product could be an added value within their respective organizations.

Outcome

When we started synthesizing all of the data we gather over the past 1.5 years from our first version of the product, an in-depth understanding of our core users of the product, running A/B tests, usability studies, learnability & memorability studies, we gained such insights as to the fact that the current state of tools available for the admins and other IT professionals is lacking any kind of at least moderate level of usability, and seriously over-engineered to such extent that even the highly technical people using them are annoyed at how many functions these tools have while utilizing 25%-30% at most to do their jobs.

“I’m an Admin, why are you asking me these questions? Just put a tool in front of me and I’ll figure it out!” ~ Admin User

Well, you are human being just like the rest of us right? Wouldn’t you want to equaly enjoy a software or an app?

“No one ever asked me that… this is so refreshing! I have never heard of a software company asking IT or Admins how we feel about the software… Thank you!” ~ Admin User

Based on the data we have gathered and analyzed, we realized that we have to make a drastic change in our Command Center, as we learned that there are trending pain points and/or needs by the users of this tool, such as:

1. A centralized tool for all related management activities is something most IT is lacking, as currently, they had to work within 5-7 different tools at the same time to accomplish just a few tasks.

2. Integration with outside tools - since they have been using so many different tools, integrations and free-flow of data between these tools is a “nightmare” (study participant).

3. Being able to manage deployed technology on a granular level is an absolute must so they have full control of every aspect of the product within their organization.

4. Being able to see basic information about the deployed technology, how many users are using it, what kind of modalities people have and use, etc.

In the next iteration of the product, I wouldn’t say we pivoted, but we definitely realized how many things we need to improve, remove and add for the product to be a lot more usable and productive for our customers, and so we began redesigning Command Center into Control Center.

2018-2021 Objective

Role: Researcher, Designer, Tester, Team Lead, Director, Product Management Guide

Early to mid-2018, we started to rethink and redesign the now named Control Center, based on everything we knew by this point, the objective of the product now was:

1. Since we pivoted our mobile application to be an Employee Access tool, we needed an App Creation process in the Control Center for our customers to be able to create applications for their internal needs or consumer needs.

2. Management of the created applications, app-based security policies, and user population management with access control abilities at a user level.

3. Authenticators AAID’s database management.

4. SDK generation for Consumer use cases and web-authentication use cases.

5. Analytics of each application usage

6. Ability to export all logs and analytics for our customers to be able to import them into such tools as Splunk, and alike.

As we launched the next iterated version of Control Center we knew that we needed to research more aspects of the tool, understand what we are still lacking and what features we should be bringing to the product next.

As Control Center started expanding its user population, and more teams among our customers were using it to deploy our technology and manage it in their organization, the requests for features just started pouring in… as the feature request Jira tickets were piling up, we needed to validate these requests and make sure we use our time and resources in the most efficient way.

Designing New Process

I gathered a meeting with the VP of Engineering and VP of Product and we spent several days in meetings working through ideas and options in how to develop a proper Product Development Lifecycle where we take in customer requests but still continue conducting research, studies, and validation of both internal ideas and external requests.

Taking into account the constraints of our resources and delivery timelines limitations we decided to create a product development flow that encapsulates the needed UX flows to validate or invalidate ideas or features, and constantly conduct research and studies, that involved design team and product team splitting responsibilities and tackling research alongside each other to gather data in a much faster way.

Research

Control Center was growing, growing faster than we could keep up with it, and in order to keep innovating and adding more features to make the IT professionals life better, we opened a line of communication and involvement with our customers and their IT teams to have a constant stream of information on how the product is being used and what kind of issues there are in Control Center and listen closely to customers’ team’s recommendations.

All while continuously talking with different IT professionals from outside of the customer base and our company.

As previously mentioned, we didn't just want to learn what our customers need or their respective teams, we were eager to understand how IT professionals do their work, and in order to do that, we regularly interviewed IT professionals from different level companies, from 50 people startups to Fortune 100 companies with over 300,000 employees globally.

By gathering findings from our customers and the IT professionals that we have been interviewing on regular basis for over a year, we have discovered some very specific workflows that an Admin or Infrastructure Engineer or IT Manager might need to go through in their daily work, but our tool did not accommodate for one very important part in that orchestration of tasks, and that is Delegation of tasks.

This led us to design an access management system within our product for Super Admins of Control Center to be able to assign roles and permissions to their team members that would allow them granular access to different parts of the product to perform their tasks based on their access level.

As we were getting ready to implement MVP of the Roles & Permissions flow in our product, our regular interviews with customers and outside IT professionals started to shine a light on something we didn’t really think about before.

HaaS (HYPR as a Service) started to emerge as the next iteration of Control Center, this was discovered through several channels of communication with our customers and their shift to more Cloud Based services in their organizations and it created a new goal for us as a company to start selling to SMB’s, coupled with the results of our interviews with IT professionals in the field who were increasingly looking for SaaS products to shift their operations to cloud and remove the high costs of on-prem server operations and maintenence.

Pivoting

When you combine years of research, user interviews, competitive analysis, market evaluations, customer requests, business goals, and objectives a fairly clear picture is being painted.

That picture was pivoting our entire offering to cloud service and rebuilding our product as a full SaaS Eco-System Platform.

late 2019 was the beginning of our in-depth research into not only how to shift our product to be a SaaS offering but how do we accommodate and create a self-service flow where SMB’s can sign-up and do everything themselves, being a solution that integrates with IDP’s and other Identity Management systems, if not done correctly this could turn into a very lengthy and cumbersome process, that might turn many potential customers away.

Realizing the massive list of complexities that is about to hit us, we set out to accomplish the rebuilding of the Control Center by incremental milestones based on data and internal feasibilities.

1. Create a seamless flow between the Website and HaaS that would cover the discovery of the service, and initial service sign-up.

2. Approval Flow that includes automated email communication and integration with Salesforce for sales team members approving service requests.

3. Onboarding flow to introduce the user into the service

4. Passwordless authentication enrollment onboarding for future Control Center login purposes.

Research & Analysis

First, we needed to identify the user flow for this new service that we are about to build… we went back to our original persona of Jackson (Jack) Romano to look at the needs and problems Jack has, then in order to make sure we are not missing anything, we ran another set of interviews with a dozen IT professionals to put together a flow that Jack would be taking in the product.

Major findings from the interviews were as follows:

1. The original idea of taking the user on a guided journey to create the HYPR App, Install the client, deploy it to the controlled group in the organization was completely misguided. Admins and alike, do not complete all these settings and set-ups in one single sitting.

2. Another key persona started to emerge during our research and that was Helpdesk Professionals, what we discovered is that SMB’s oftentimes share tools with the help desk and have them be involved in using the IT tools and resolve some employee and/or customer needs directly through these tools without delegating these tasks to IT departments.

3. Clear analytics and system health of the tool and all endpoints and connections must be available to the users at all times and that dashboard must be flexible enough for users to configure it based on their immediate or job function needs.

4. In-depth Auditing function that would allow detailed auditing trail for users of the applications and SDK’s to be able to trace their path and find where something went wrong if it did.

Outcome

• When we realized that creating an App or SDK is essentially a project style flow for many administrators and IT professionals, we changed our mindset and produced a project management feature to our Control Center, essentially allowing the user to create a new project (App/SDK) and keep working on it whenever they need/want, coming back to it and completing more parts, and also allowing delegation where other members of the team would be able to access the project and set-up different parts of it, with the system constantly checking the health of the system and end-points.

• As we discovered the new persona for HaaS (later renamed to HYPR Platform), we needed more, we needed to understand exactly how the helpdesk professional would or could be navigating and using our platform to help them do their job. We started the journey of better understanding by recruiting several dozen helpdesk professionals from across a vast spectrum of industries and company sizes, from small start-ups of about 50 people to global enterprises with over 500,000 employees. This led us to learn the workflows of the helpdesk and, how many layers of different helpdesk customer points could be in different organizations, also how and at what point to different layers of helpdesk escalate tickets to a higher tier or even executive level.

  This was a turning point for us in how our product should be designed and how it could be utilized.

As you can see, the outcome of the research, just leading to more research.

• When we learned that we need to provide clear analytics and system health to our users, well, we had a list of items of data we could collect and present, but how do you go about deciding what to present, in what order and we also didn’t want to present everything at once and create a serious cognitive overload.

  I decided to utilize Card Sorting for this research and have different Admins, IT pros, and Helpdesk professionals go through a card sorting exercise, I ran a workshop with two groups of people, each group had 9 participants that were met with pre-study questions about their workday, and how they do their jobs just to build kind of a behavioral profile, then we went through card sorting with each participant individually, while the user was moving cards (widgets) into the Main Dashboard column, the user was recorded both their facial expressions and their voice as they stated each action and explained why they chose that widget for their dashboard.

  After the exercise they completed an exit questioner in which I also kind of sneaked in a guessing game to see if they could guess what kind of product we are building, just to see if people who never used our product based on just the data points we will be presenting could guess what the product is for.

• For the auditing functionality that we built for our product based on the findings uncovered, we took a step farther and added a detailed function that allowed the user to really see at what point of a product flow something went wrong.

Form Discovery

2015 Version of the HYPR Key had all too many limitations and was far outside of the business objectives this product had.

It was too long, sharp corners, coin cell battery that did not keep charge for too long, and the finger print area proved to be way too wide and with little feedback if the user places the finger in the right reader area or not, which led to a lot of misreads and failed enrollments and authentications.

This was discovered during the first user-test that I ran to simply understand if there is anything wrong with the current design, which ultimately convinced the stakeholders that we must completely redesign the form-factor of the product.

We worked with our industrial design vendor to provide us with the craziest ideas possible so we could test them out.

And we did, we invited a dozen random individuals from outside our company and we asked each participant to hold the different pieces and tell us what they feel, is it comfortable, is it too big, too small, what do they think this is and might be used for, etc.

That helped us identify the form that we would be pursuing as the next form factor of HYPR Key.

But we didn’t stop there…

Behavior & Comfort

When we solidified the shape and somewhat of an idea of what this device is going to look like, I decided to test other key factors of the device and that would be Behavior - how people behave with it and once given how would they hold it, and of course the comfort of the device, but not only the device, the fingerprint well as was also highly important for me to understand, as this would be major contributor to comfort level of the key.

I devised a plan to run a Guerilla style research, and the plan was as follows:

1. 3D print 3 samples of the exact same blank pink piece of plastic with different depth of the finger well for the fingerprint scanner to be at:

• #1 - 1.3 mm depth

• #2 - 1.7 mm depth

• #3 - 2.2 mm depth

2. Get $20 in singles

3. Go out to Herald Square and offer $1 to passers-by, whoever agrees to take the dollar, give them the dollar and ask to hold the 3 different models, for them to tell you which one feels more comfortable.

4. Take a picture of each participant holding the model to see HOW they are holding it without knowing what this is and how they supposed to hold it.

Usability

By this point, we have learned a lot! We learned which form-factor would be preferred by users, we also learned that most users would a. understand how to hold the device with zero instructions, and b. what is the depth of the fingerprint well we need to make for optimal comfort and fingerprint scanner readability.

The industrial design vendor and our hardware team now had enough data to get to work and produce a prototype that per my testing milestones, needed to undergo actual usability tests, to make sure that we not only nailed the form-factor, behavior, and comfort but also made it simple and easily learnable interaction for enrollment and usage.

Working with the outside industrial design vendors we explored some more options of the form factor and settled on a half-rounded plastic bottom body with a flat polished gorilla-glass covered top part with fingerprint well and an LED light indicator, the device also contained an index-finger indentation underneath the fingerprint area, this kind of design solved for most of our needs.

• Keeping the rounded shape form-factor that proved to be successful in our tests.

• Having the rounded “belly” like addition made it more comfortable to hold and provide space to house the battery.

• Slimmer index-finger area allowed a continuation of the board in the housing and a slimmer area of the key for a comfortable press with the thumb while supporting it with the index finger.

Once we produced the functional MVP prototype with this design, we started rounds of user-tests.