The global Internet is huge and complex. The biggest ISPs, enterprises, and defense agencies need a way to understand what’s happening on their networks and how they’re communicating with the rest of the world. Packet Design’s Explorer Suite makes it easy to see everything and understand how it’s working—or failing. I was the principal designer.
When I came to Packet Design they had some amazing data, but they were struggling to show it successfully. In order for customers to take advantage of the insights the data offered, a better interface was needed. My job was to turn an ancient, convoluted product into something attractive and useful.
The biggest challenge was the complexity of the subject matter; our users were networking PhDs, and it would have been impossible to know what they knew within a reasonable amount of time. Because of this I had to lean on subject matter experts where appropriate, and get better at intelligently solving problems in a forest of unknowns.
Also, I was the only designer on the product team. The others were product managers, sales engineers, and technically-minded execs. This meant that I had to work extra hard to develop an inclusive design process. Instead of using the usual designer shorthand, it was often necessary to explain the fundamentals of interface design and user psychology as we went. My freelance experience came in handy.
Because of the complexity of the product and the fact that no single person completely understood every use case, rapid iteration on cheap sketches was even more important than usual. Adobe’s Draw for iPad Pro was a great tool for this, as was Balsamiq Mockups.
As usual, full-detail mockups in Sketch and Adobe Comp were essential to establishing a good visual design language and ensuring that we knew exactly what we were building before we built it.
Of course, static images and text only go so far. Motion and interactivity are often required to communicate a robust idea. With Marvel and InVision I was able to make interactive prototypes very quickly, using either fully realized renders or rapidly developed sketches, depending on where we were in the process.
Where we ran into the same design questions repeatedly, I found it helpful to develop guides that saved time and promoted a consistently high-quality experience.
One of the biggest tasks was creating an interactive map of huge computer networks that network engineers and operators immediately understood.
To accomplish this I spoke one on one with several staff network specialists, and asked them about the various tasks they needed to accomplish when reading the map. Some just needed to understand the structure of the network, others needed to use that information to help diagnose network failures, or set up back-up plans for potential failures.
I learned that when a failure occurs an engineer is immediately on the clock to solve it, with money and customers on the line. The interface needed to be more than informative, it had to be fast. Similar to a fighter pilot in his cockpit, the user would have no patience for a lot of progressive disclosure, mode switching, or other interface management. Everything had to be right there.
It was necessary to convert sentences and sometimes paragraphs worth of information into a condensed format, so that the user could see both the high-level descriptions and the low-level failures.
Once I understood what had to be solved, I had to figure out how to solve it. So I looked at each of the various scenarios a user might run into, and worked with network engineers to select a sample dataset for each scenario. I started by drawing out circles representing each of the devices, and lines representing the links between them.
We then walked through the scenarios and annotated the things the engineers needed to know, in the order they needed to know it. Which nodes represent what kind of hardware? What do they need to know about that hardware? What do they need to know about how various devices are talking to each other?
We ended up making heavy use of abbreviations and colors, preferring to label things directly rather than rely on the slower method of a legend. Adapting the information architecture exercise of card sorting, I had various engineers tell me what abbreviations would make sense to them, and what they understood by a certain status color on a particular element. I looked for overlap between the different engineers’ answers. Where I got conflicting answers I knew that I was off the mark. Where everyone reflexively agreed, I knew we had something good.
When we had worked out a good system using static images, I worked with engineering to help them understand exactly what we needed. Once they had a prototype together, another layer of learning began. Unforeseen conditions arose: labels overlapped one another, ambiguity had crept in some places, and edge cases were too slow, both computationally and use-wise.
I worked with engineering to iterate in near-real time by updating icons, layout algorithms, and labels to work out the kinks as they revealed themselves.
Once we had a viable prototype that users could actually interact with and use to solve real challenges, we were able to observe them and record their successes and failures, using that data to inform successive waves of improvement. That process continued well after the “finished” product was in customer’s hands—you never fully know what you have until it’s in the wild.
The impact of the changes we made were huge. We transformed arcane data and interfaces into an attractive and useful experience. We increased usage dramatically, from 1 or 2 users per customer to 20–30 users. We expanded sales and improved renewal rates.
Instead of us convincing customers to look at our product, they approached us. Instead of users asking our support team to use the product for them, they knew immediately what they were looking at and how to use it. We made a big difference that the whole team can be proud of.