![\"\"](\"https:\/\/corythorpe.com\/site\/wp-content\/uploads\/2021\/03\/NOC-example.jpg\" "\\"\\"")
<\/a><\/p>\nExample Network Operations Center<\/p>\n
\u00a0<\/p>\n
The NOC Dashboard was the first project I finished (inheriting existing design files) when I joined Storage Insights, so I was familiar with it. For that project my role was simply finishing an in-progress design because it had been promised to stakeholders for a significant amount of time, and they wanted what they had seen. I didn’t have the freedom to significantly alter the direction late in the project, so I did the best I could and saved my ideas for the next opportunity to optimize how storage system status is communicated. That opportunity came almost immediately after as customers began to complain about the NOC Dashboard.<\/p>\n
\u00a0<\/p>\n
Customers complained the NOC Dashboard was difficult to use on a laptop screen. The design was made for a large screen where even a small graphic would appear readable. Designing specifically for a large screen made it difficult to interpret and obtain the data they needed when viewed at a laptop resolution. The first thing I did was meet with our Product Manager and the Design Lead to understand what we were trying to create, and why.<\/p>\n
\u00a0<\/p>\n
The NOC dashboard<\/p>\n \u00a0<\/p>\n We discussed what Sam, our Storage Admin persona, needed out of an experience enabling him to understand his storage at a smaller resolution. The target was to create an experience focused on device health so Sam knew which devices needed his attention.\u00a0 We had received complaints that the key performance indicators supplied were too small to read and interpret when viewed at a laptop resolution.<\/p>\n \u00a0<\/p>\n Our Storage Admin Persona, Sam \u00a0<\/p>\n My role<\/strong> on this project was the sole UX Designer, collaborating with my team of other designers working on Storage Insights. A visual designer worked with me to finalize visuals, helping me to be conscious of my use of space, my color choices, and typography. Two tests were conducted on this work, idea validation and a usability test with a design. A researcher joined me for the first usability test, helping me to progress the test script and test structure while I prepared the flow of the scenario and screens we would use for our conversations with users. The second usability test I conducted myself, leveraging feedback and input from my design team peers to help refine aspects of the script and design mockups. During my first year working on Storage Insights every design needed completion urgently and we were pressured to cram as much into the initial releases as possible, so this design was on an accelerated delivery timeline.<\/p>\n \u00a0<\/p>\n Working together,\u00a0 my research colleague and I drafted a research plan to understand if our target idea met the needs of the customers, and to identify any other critical needs we may be unaware of. I used our existing NOC dashboard to create questions that would help me better understand what users needed from the new experience, such as:<\/p>\n \u00a0<\/span><\/span><\/p>\n \u00a0<\/p>\n Excerpt from the Research Plan<\/p>\n \u00a0<\/p>\n We were able to confirm that health of systems was one primary aspect, however we discovered additional key needs not included in the initial requirement including:<\/p>\n Some of these needs existed in the NOC dashboard, however because of the complaints we received about how that data translated to a smaller resolution, we paid particular attention to size and amount of detail.<\/p>\n We took these findings to the Product Manager, Technical Architects, and Design Lead, and explained why we should include not only the health-focus need in the design, but additionally target the specific additional needs that came from the user interviews. This was a very high priority and high visibility project and garnered attention from our executive team, who decided to attend our research playback. Normally, our executives didn\u2019t attend research playbacks. We supplemented the presentation with an executive briefing to tailor our message to our executive audience.<\/p>\n \u00a0<\/p>\n Research Executive Briefing Page 1<\/p>\n \u00a0<\/p>\n Research Executive Briefing Page 2<\/p>\n \u00a0<\/p>\n After meeting with our stakeholders and explaining the results of our research, I began low-fidelity mockups. Since our team was new to this product, we hadn\u2019t established our design process yet, so our alignment was more ad-hoc than I’m comfortable with today. We now create many additional helpful alignment deliverables depending on complexity of work, including:\u00a0<\/p>\n During this project, time constraints and lack of established process meant less initial alignment deliverables were created.<\/p>\n I began my design explorations with our 3 key user needs in mind:<\/p>\n \u00a0<\/p>\n Additionally there was a “bonus requirement” of sorts. I knew we planned to expand this product to monitor more devices in the future. At this time it only monitored 3 types of storage. Though not an official requirement, I identified this need as crucial to keep in mind – what will this experience look like when our list of device types grows to 5? to 7?<\/p>\n \u00a0<\/p>\n Initial low-fidelity mockup concept 1<\/p>\n \u00a0<\/p>\n Exploring less prominent device type selectors\u00a0<\/p>\n \u00a0<\/p>\n As I explored ideas, I brought some design elements into a higher fidelity to better understand how they might work, though in many cases ultimately went in a different direction. For example, the selectors seen across the top of these mockups (directly below the navigation) enabled the user to switch the list along the left side between device types.<\/p>\n \u00a0<\/p>\n Device type selectors now include status<\/p>\n \u00a0<\/p>\n Concept 1 in medium\/high fidelity<\/p>\n \u00a0<\/p>\n Through multiple concepts, iterations, and reviews with my design team, I ended up exploring less prominent ways to call attention to the ability to switch between different device types.<\/p>\n \u00a0<\/p>\n Low fidelity concept replacing bubbles across the top with expanding list sections on the left side<\/p>\n \u00a0<\/p>\n Example of a non-default section expanded with default section collapsed<\/p>\n \u00a0<\/p>\n Those iterations and reviews helped me to realize that the information in the selectors was only important when the user wanted to switch between device types. I created a proposal that removed the device type from view, and nested that information in a dropdown menu.<\/p>\n \u00a0<\/p>\n High-fidelity proposal nesting device type sections in the menu<\/p>\n \u00a0<\/p>\n As part of my exploration into how this view would grow when we introduced other devices, I evaluated concepts such as how to show the relationship between a selected device and other devices. One exploration involved using the device list to show a selected device’s relationships. I created a few prototypes to explore these ideas, trying to understand how a user would go from a list of devices to looking at a device and its relationships in the same list location. Ultimately the concept proved too complex to easily communicate without a significant investment of time, and I came to the realization that the idea didn\u2019t address a core need of the minimum requirements. To avoid scope-creep from what may have been a good idea, but went beyond the needs at this stage of the experience’s design requirements, this idea was put on hold.<\/p>\n \u00a0<\/p>\n Links Change Context Concept \u00a0<\/p>\n After rounds of iteration and review with the design team, technical architects, developers, copywriters, and other stakeholders I had a medium\/high fidelity design I was ready to test with users. In those rounds of review I would bring my current design proposal along with any supplementing material (flows, data diagrams, or what I thought helped tell the story of the experience at that stage) to a meeting with the stakeholders. In the meeting I would briefly explain the needs I was attempting to address in the design, highlight where I had iterated since our last meeting, and walk the stakeholders through the experience as I proposed it. This enabled stakeholders to understand the progress of the design, ask questions, offer input, and explain any technical constraints that may have been not obvious. I took my medium\/high fidelity design and walked users through a scenario-based usability test in order to understand what worked, and what didn\u2019t. I tested with 8 users for 1 hour each.<\/p>\n \u00a0<\/p>\n Medium \/ High fidelity design tested with users<\/p>\n \u00a0<\/p>\n Example of menu open showing devices and health status<\/p>\n \u00a0<\/p>\n Testing feedback was generally positive. Users liked the simple and straightforward nature of the design which defaulted to the first system selected, and always showed the details of the selected system rather than having the details open and close. This was a departure from our NOC Dashboard which featured multiple animations, and forced users to interact before seeing detailed information about a system which would display in an animated panel opening from the side of the screen. The user feedback drove changes to the layout of the system tiles (the list on the left side of the screen) making them more informative by providing context about why a device was in an error or warning state. Additionally the layout of information in the details section changed, both by adding a new System Health section, and updating the way the Capacity numbers were calculated and displayed. I iterated on the changes from the testing, going through additional update and review cycles with the design team, technical architects, developers, copywriters, and other stakeholders. Some of the user\u2019s primary pieces of feedback can be seen in the updates, including:<\/p>\n \u00a0<\/p>\n Updated proposal based on user feedback \u00a0<\/p>\n An important part of the updates was a clearer understanding of the system\u2019s health. Here\u2019s a mockup of that idea which rolls up health about component types, and can expand to show specific sections of the system as seen here. I then presented the testing results and demonstrated the changes to our stakeholders, explaining why the reactions and comments users made about understanding health causes resulted in my design choices to better explain how the device health was determined.<\/p>\n \u00a0<\/p>\n Concept with System Health section expanded<\/p>\n \u00a0<\/p>\n After gaining agreement about the release readiness of the design I created a User Experience Document, or UX document. A UX document is a PDF document outlining all of the specific implementation details of the design. I met with our development team, who had seen progress on the design along the way as part of the stakeholder group, and went through the UX Document with them in detail in order for them to plan implementation and ask more detailed questions than they would have asked at the in-progress design stages.<\/p>\n \u00a0<\/p>\n Excerpt from the UX Doc detailing the Menu<\/p>\n \u00a0<\/p>\n Each of our designs was also delivered with a fully interactive specification HTML file, which developers could interact with to see the measurements of the design elements, colors, icons, and other details. In this case I also delivered a simple prototype to demonstrate the common interactions of the menu. This prototype was created in Sketch and didn\u2019t quite communicate the specific way I envisioned the device tile “sticking” to the top or bottom of the list when a user scrolled. Because\u00a0 I had a very specific vision of how this would look and feel, I animated this idea and included that as well to illustrate my vision to the developers.<\/p>\n \u00a0<\/p>\n Behavior of \u201csticky\u201d selected tile\u00a0which didn\u2019t animate in Sketch prototype \u00a0<\/p>\n Interactive spec file with measurements, colors, and icons delivered to development \u00a0<\/p>\n<\/a><\/p>\n<\/a><\/p>\n
(Art by Visual Designer Thy Do<\/a>)<\/em><\/p>\nUnderstanding the Need<\/h2>\n
\n
<\/a><\/p>\n\n
\n
\u00a0<\/h2>\n
Aligning on Findings<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\n\n
\u00a0<\/h2>\n
Initial Mockups<\/h2>\n
\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nAvoiding Scope-Creep<\/h2>\n
<\/a><\/strong><\/p>\n
InVision Clickable Prototype<\/span><\/a> (pw: abc)<\/span><\/p>\nTesting the Prototype<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\nResults & Updates<\/h2>\n
\n
<\/a><\/p>\n
Note the updated filter, device list header, and new System Health section<\/p>\n<\/a><\/p>\nImplementation Deliverables<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\n
Google Drive MPEG File Link<\/span><\/a><\/p>\n<\/a><\/p>\n
Google Drive MOV Example<\/span><\/a><\/p>\n<\/a><\/p>\n