RZMS
Timeline
2019-Present
My Role
UX Researcher
Project Details
Project for IANA Services, ICANN, and the multi-stakeholders involved
My Contributions
Research, Content and Metadata Audits, Wireframes, Content Migration, Final Product
Team:
The project was made up of 10 people: designers, developers, technical leads, operations, and project managers.
Background
What is RZMS?
The Root Zone Management System (RZMS) is the interface where IANA processes change requests that update top-level domains (TLDs) in the root zone. These TLDs include .com, .net, .org, and more.
Basically, RZMS is the system used to update domains like .com. Without it, the internet we use everyday could cease to exist!
How are RZMS Change Requests submitted?
Each domain (like .com) has their own respective set of contacts that directly communicate with the IANA staff. These contacts submit change requests in RZMS. As the operations team lead, I process the change requests in a timely manner and communicate closely with each TLD contact.
What type of requests are submitted?
Technical changes (such as changes to the name servers)
Administrative changes
TLD revocation requests
TLD transfers
Delegation requests
A Brief History…
Shortly after joining the project in late 2019, I took the lead position as the operations team lead, working closely with the DevOps team and our PMs acting as a liaison. In 2020, our efforts proved successful and our user acceptance testing began. In 3 years, I conducted research and aided in designing for RZMS. I focused on improving the change request submission process for our user acceptance testing. I invite you to explore a selection of user testing examples conducted by my team and I, which will provide you with valuable insights that influenced my passion for design.
UAT PROCESS: A THREE STEP DANCE
Preparation
In the first phase, I outlined objectives and picked select users in order to develop targeted test scenarios.
Execution
Next, I embarked on a journey navigating through the system interface, following the test scenarios and cases designed during the prep phase. As my team and I navigated, I evaluated each aspect of the interface, from functionality to design.
Evaluation
Finally I analyzed the feedback, fixed any issues, and validated improvements.
OVERALL UAT OBJECTIVES
Allow users to easily submit change requests
Streamline change request status update experience
Improve TLD search functionality
Boost performance satisfaction rates
Enhanced security and safety measures when processing requests
Preparation: RZMS Change Request Flowchart
I created this flowchart on how change requests in the Domain Name System’s Root Zone are managed. This helped us and our stakeholders understand the overall UAT process. It allowed us to define and map out different test scenarios based on the system's functionalities and user interactions. Each step represents a specific test case or scenario. By following the flowchart, we were able to identify different test paths or routes within the system. Thanks to the lovely flowchart, we were able to optimize our testing effort, focusing on high-priority areas, and saving time.
Research Questions & Considerations
How effectively does the current system prevent and minimize user errors during change requests, and how can it be improved?
How does the new user interface impact users' ability to navigate and perform critical tasks compared to the previous system?
How well does the redesigned system support users in quickly understanding its functionalities and features without the need for extensive training?
TEST TYPE EXAMPLES
Staff Interface vs TLD Manager Interface
I compiled a list of test scenarios that I divided into 2 main sections: functionality from the IANA staff interface and the RZMS user interface. In this case, our users are the TLD Managers. In total, I compiled a list of 181 test types. However, for the sake of time I'll spare you the details and highlight the most essential test types of each interface.
Overview of the User Interface Test Scenarios
Login to the Root Zone Management System
Submit all types of change requests
View and manage the status of different requests
Cancel and/or make edits to the submitted requests
Overview of the Staff Interface Test Scenarios
Login to the Root Zone Management System
View all change requests and organize them by type
Move forward respective requests
Make internal updates to requests
Cancel or create a change request
EXECUTION: VERSION 2 VS VERSION 3
Through this side-by-side comparison of the old and new interfaces, I'd like to provide a clear visual of the improvements made. This contextualization aims to highlight our team's specific design choices, enhancements, and optimizations that I helped to implement.
Version 2
Staff Interface - View List of TLDs
Version 3
Staff Interface - View List of TLDs
We prioritized a simple and intuitive interface to afford a positive user experience as it minimizes the time and effort required to learn how to navigate the system. This makes it more accessible to a broader audience, including beginners which is key as we were interested in hiring new staff soon. My team and I decided to keep the domains clearly listed in a way that is similar to version 2, but with more details. We added a "Status" feature, which I found it unnecessary to display, as we exclusively only work with Active TLDs. However, in terms of functionality, there were several significant improvements with ease of use.
Launching change requests from this screen was easier, as there were less steps in the process, making it more intuitive.
RZMS Version 2 - Staff Interface
View of Processing Change Requests
RZMSv3 - Staff Interface
View Processing Change Requests
I pushed to include the "Summary" of each change requests, on the change request landing page. This proved helpful, and was a major improvement from version 2 where no such feature was included. Knowing the summary of the change request is vital for those who are processing the request. It dictates which requests require more careful surveillance, as some types are more time sensitive. While there were significant improvements, I found the "Duration" column unnecessary since we have the created on column to the very right. This felt redundant and we plan to revoke this section for version 3.1.
EVALUATION
Analyzing Results and Feedback
After completing the tests, the developers and I sifted through the feedback and results to identify patterns and trends. This helped us pinpoint the areas that required improvement or revision.
Prioritizing and Resolving Critical Issues
Armed with our insights, I prioritized the issues based on their impact on the staff and user experience. We then address the most critical shortcomings, enhancing the system's performance.
Validating Fixes and Improvements
Due to certain limitations, we were unable to address all the concerns during this sprint. As a result, we decided to defer the less critical enhancements to RZMS version 3.1 which would launch just a few months later. Once the critical issues were resolved, the system trialed another round of user acceptance testing to ensure the improvements held up under scrutiny. This iterative process guaranteed a polished end product!
My Impact In Resolving Critical Issues
The password reset for the TLD Manager lacked functionality. When we launch RZMSv3, all users will need to reset their password. This was a high priority issue that was necessary to be fixed before launch. As a result, this was the first issue the DevOps team and I worked closely together on.
API updates and bugs.API, or application programming interface, is a set of definitions and protocols for building and integrating application software. By diligently documenting the occurrences of these bugs, I was able to precisely identify and communicate to the DevOps team the specific issues that required elimination prior to the launch.
REFLECTIONS AND FURTHER CONSIDERATIONS
Working with Constraints
I learned how to find a balance between having a good user experience design and creating an achievable design through this project. There were times when we were informed by DevOps that we had to make changes because the design was not feasible, but in the end we still managed to find other ways to make it work.
Open Communication Leads to a Better Project
Through this project, I've gained valuable experience in effectively communicating the design process to individuals with different areas of expertise. Collaborating closely with engineers and business professionals, I had the opportunity to grasp their key priorities. Moreover, I was able to listen while also successfully conveying my perspective, and ensured the design decisions were comprehensible to all parties involved.