When you type “google.com” into your browser and press the Enter key, what happens? How do you get to Google? Where is Google? Is there a single data cable between you and Google?
The answer is that there are lots of computers called routers between your device and Google. The routers figure out which way to direct you. Your device connects to a router, which connects to another router and then another. After a long series of “hops” from router to router, you arrive at one of Google’s computers:
Those routers need engineers to pay attention to them and fix them when they break.
When one computer can’t talk to another, they need to find out why. They need to find the route between the two computers, identify the problem along that route, and fix it.
When too much data is going through the network, the routers begin to buckle under the load. Engineers have to analyze the network to understand how to expand it.
The product I designed helps engineers in Network Operations Centers fix problems. It listens to the routers in the network and records information about them. Then it tells the engineers what to pay attention to, how to fix any problems that arise, and how to plan for the future.
The company I was working with already had the technology to listen to the network. They didn’t know how to show what they recorded in a useful way, though. The user interface was raw, unprocessed data:
My first job was to understand what network engineers do. Then, I had to show them complex data in a comprehensible and usable way. Finally, I had to make it less ugly.
To do that, I talked to network engineers to understand the job they do and the problems they solve. I found out what they need to know about the network to do their job. And I learned what the difficult parts of their job are, so that I could make them easier.
Network engineers go to school for many years to do their job. I didn’t have time to learn everything there is to know about being a network engineer. What I could do was understand specific problems well enough to build tools to solve them.
Once I understood a problem, I began to sketch ideas for user interfaces that solved it. Then I used tools like InVision to make clickable prototypes from the sketches. Network engineers could use those prototypes to understand new ideas. That allowed us to test user interfaces before we actually built them.
We held many design reviews and collected a lot of feedback. We explored dozens of possibilities before deciding on a direction. I kept working on the prototypes until everyone was sure they showed exactly what we needed to build.
Once the prototypes were complete, it was time to work on the visual design of the user interface. To show the nuances of form and color, I made high-quality versions in Balsamiq Mockups or Sketch:
Somebody had to write the code to make these ideas real and it wasn’t going to be me. Luckily, the company had many talented developers. I did my best to make their job as easy as possible. When designs required lots of precise details, I liked to give them finished HTML and CSS.
If a new design element or pattern was likely to appear in many places, I liked to define that element in one place.
The impact we made was huge. We increased the number of users from 1 or 2 network engineers per customer to 20–30. We expanded sales and increased renewal rates.
Before, it was hard to convince potential customers to look at the product. Afterward, they approached us. Before, users asked our support team to use the product for them. Afterward, 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.
