5 users tested with A first, then B and 5 were reversed so as not to bias their results.20 tasks were identified and scripted into the prototypes, matching details in each version.10 users were identified for testing (5 existing customers trained and familiar with the legacy application and 5 non-customer DBA's).That prototype as well and tested both with the following conclusions:
With a more traditional (read copy/paste) version of the interface that leveraged a hiearchical grid. As part of the stakeholder review I agreed to conduct A/B testing With Axure in order to conduct user testing. Treatment allows the user to easily see the relationships between each node without overpowering them withĪfter the initial conceptual review with product management and stakeholders I created a clickable prototype Cards, rows and all sorting and filtering controls are married between the card presentation and the corresponding grid presentation.Īs the user moves through the cards, the focused card is highlighted and additional details are presentedĪbout it as well as the directly connected nodes both upstream and downstream. Remains in sync with the blocked grid providing a familiar set of controls to seasoned users.Provides sharing capabilities at each node level, allowing the user to determine how much info they want to provide outside teams.Focuses the user on the details of a single node but still provides sufficient detail of parent and child nodes to allow them to easily make a decision.Clearly illustrates the depth and complexity of the block chain.Upon the selection of a row (SPID) the user is presented with an interactive card-based UI that: Again, putting the focus on the elements deemed to be most critical in determining where to spend their time. In addition, the grid provides more detail with fewer columns than the original. DBA's are able to quickly determine what applications are a priority and where they should begin to focus their attention. The graphs provide some important summary-level information about specific resources being blocked as well as the actual applications that are being impacted by the block. The initial landing page for blocking (see below) provides the user with a more consumable set of data. include a count of the blocked resources to indicate the size of the issue more clearly.provide clear iconography and a legend to describe the data.condense the data set on the grid to the "most important" elements as id'd by the users.existing reports had great summary information, let's reformat the graphs and provide those as an intial tool for diagnosis.Once I had completed my research, I was able to determine several opportunities for improvement as well as what proven elements to bring forward for the initial "Blocking" landing page. product management was consulted for business priorities.engineering and architecture team members to best identify limitations and performance considerations.existing training materials, product backlog of bugs/enhancements, competitor's offerings.In addition to the user input, I leaned on a few other information sources to help provide a complete picture prior to designing: These issues were common within most areas of the legacy application, as the application delivers mass amounts of grid-based data directly to the user by default.
0 kommentar(er)
