Device deployment & authentication
Designer Next Gen (DNG) users can set up audio devices, including passwords before they are deployed to a new room. There was an existing deployment design but the authentication and password modification steps were not approved by security because authentication and password creation were on separate screens. I designed a new unified password screen that guided users through authenticating multiple devices and setting up new passwords while making it easier for users who don’t utilize passwords.
The problem
The existing design for the authenticate and deploy step of Designer Next Gen (DNG) had separate password entry and creation steps in the five step dialog. This design was found to be the most user friendly in testing but due to security requirements we had to create a design where users entered passwords and updated passwords on the same screen.
Solution
Give users without existing passwords simple screen to add a common password or continue without passwords. For users with password protected devices I created a design where users use a single password field-with each password attempt checked on all devices.
Password entry and editing were separated into two separate panes with password revisions showing in the disabled state until all devices had been unlocked. This created a sense of focus, and a sense of progress as devices are unlocked.
My approach
Review
I reviewed the current design for the entire five step device deployment workflow as well as similar workflows in other areas of the software to see what existing patterns might be drawn upon.
Research findings
As part of my research and review I dug through password related analytics on the existing version of Designer. A key finding was that (of users who opted into analytics) only 12% actually used passwords.
Based on this I suggested we determine programmatically if a user had devices with passwords and if not present them a simple screen that allowed adding a new common password or continuing without passwords.
Design and iterate
The security and engineering teams had found and offered one possible technical compromise if UX found it would benefit users. They were willing to check each password entered against every device. The challenge was finding an intuitive for users to utilize this possibility as it is not a common password entry pattern. Because of this I initially wanted to make sure there wasn’t a multiple device entry approach that would follow common password approaches, but none of them added enough ease of understanding to offset their lack of efficiency.
Based on an existing pattern, the early design shown here utilized password entry for each deployed device. This was slow and added to the overall visual noise on the screen.
Combined password entries
This iterative design has a primary password entry field with a prompt explaining that it would be entered for all, while also allowing users to enter a password individually. Based on an existing pattern from other SHURE software, once the main password field had the cursor inserted the other password fields would have their opacity lowered to show focus on the primary entry.
I was concerned that this was confusing. It wasn’t clear to me that putting the individual password fields into disabled state when the main field was entered clearly messaged users that this was “focusing” on the main password entry field.
Displaying successful password entry
It was important to communicate to users they had successfully unlocked devices. I wanted to convey a sense of progress and working through the list so one prototype I tried was to have devices disappear and the list slide up as they were unlocked with a snack bar informing of success. When that prototype was tested with users some found it confusing-and it isn’t a pattern utilized elsewhere in the software so the team decided we needed to find another way to provide password entry confirmation.
Final iteration
The final version I arrived at after a number of rounds of iterating and user testing had one password entry field that could be used to fill out the list of all devices needing passwords with a notification checkmark showing on each as well a countdown number in the section title. To help guide users through this screen the right pane for adding or deleting passwords is in a low-opacity state until users finish filling out passwords.
Challenges
The requirement to have everything happen in one screen was the largest challenge, followed by the need to unlock devices that shared a room with a user’s deployed device.
Needing to unlock these “room-mate” devices and meaningfully informing the user why they had to be unlocked but also not overwhelming them with info led to a lot of iterating and testing on copy to find the most clear instructions.
Finding the right balance of information to present was a major challenge to this design. To make this all happen on one screen view required having clear but very minimal directions and visual cues to guide users through the steps.
Final design
& next steps
I created a two panel design that user testing showed to have some initial learning curve but after initial hesitation users were able to quickly move through unlocking their devices. One user commented with a smile in testing that this design “gamified” password entry.
Moving forward I would have liked to create a more refined overall password system that tried to eliminate some of the pitfalls that we had to design around for this release. I recommended user research to see if there was a customer centric reason for allowing individual device passwords instead of room based passwords. There might also be a possibility to explore whether there was a better time in deployment to request passwords.